Flatpak works on Steamdeck.

https://flathub.org/apps/org.DolphinEmu.dolphin-emu

As an end user, unless you’re running a server, then no you shouldn’t have to mess with any of it.

If you’re running a server or a sysadmin you absolutely 100% should be paying attention. Almost every single vendor I’ve seen selling their applications only have initscripts. Which then cause issues. I’ve gone to the vendors and told them and they’ve said go to Red Hat. Well Red Hat doesn’t support that vendor’s init scripts.

Not naming an application, but it was from a BIG BLUE company and they said their only instructions are to call their script from the user. But it won’t remain running if you do that because systemd will close out the slice when the user logs out. SO it’s obvious they haven’t tried what they’re suggesting.

And I’m not attempting to state that systemd is impressive in any way. systemd basically took what had been building over 40 years of init scripting and threw it out the window and said our way is better. I don’t think it is. I’m just saying, with a directive based unit file it’ll be simpler to parse than a bash script.

Ok, so I have a very unique background in systemd. I worked at Red Hat supporting it basically as the primary support and I’ve worked with the developers of systemd at Red Hat directly. I no longer work there.

So first off, it’s “systemd” all lower case. I don’t care, but for some reason Lennart Pottering (creator) does.

systemd was a MASSIVE change. And Red Hat did a TERRIBLE job relaying it. To the point where I’m still trying to get my company to understand that it can NOT be treated like the old init systems. You can NOT just drop an init script in place and walk away and hope it works. Because a LOT of times it doesn’t. Due to forks, switch users, etc.

systemd is NOT an init system. RHEL 5 and older had sysvinit as it’s init systemd. RHEL 6 had UpStart as it’s init system and looked exactly like sysvinit that no one even noticed. systemd again is NOT an init system. Init system is 1 part of systemd. systemd does a lot of cool things. It bundles applications together, it manages those applications and can restart them or kill children, it can do resource constraints, it separates out users from the system, and lots more.

Because it is not an init system there is a LOT LOT LOT of bad recommendations out on the internet where someone has X problem and person suggests Y and IT WORKS! … except it doesn’t REALLY work as far as systemd is concerned and you’ll hit other issues or your application takes longer to start or stop and people just blame systemd.

It is systemd’s fault that it has done an ATROCIOUS job of helping people adapt. It’s a great example of RTFM. systemd’s man pages are INCREDIBLE and extensive, but when you drop so much knowledge it becomes more difficult to find what you want/need. systemd.index and systemd.directives are your best bet.

So systemd does a lot of amazing things that sysvinit never attempted to do. It’s never attempted to explain anything it expects everyone just learn magically. it’s INCREDIBLY complex, but once you understand it’s basics you can more easily get an application running, but as soon as there’s a problem it’ll just break your brain.

To give you an example, sshd’s old init script is like 250 lines of bash. systemd’s unit file comparative is like 12. Because systemd handles a LOT of what you manually had to handle before. BUT to get to that 12 you literally have to learn EVERYTHING new.

There is no “is it good or bad” here really imo. It’s a completely different fundamental design. Red Hat made it for themselves. Other distros picked it up. It can be argued that lots of folks followed Debian and Debian had a few Red Hat board members that were pushing it. Whether they pushed it of their own accord or because they were with Red Hat I don’t have a clue.

What I can say is at my current company they’re suffering from a LOT of systemd issues and they don’t even realize it. I’ve been working with Red Hat to try to get Insights to alert people to the failures and we’re making progress.

To see if you have issues just to start run the two following commands:

# systemctl list-units --failed
# systemd-cgls

If you have any units that are failed, investigate those. If you don’t need them, disable them. As for the systemd-cgls this shows HOW systemd is grouping things. ANY application that runs as a service (or daemon or application or runs in the background or however you wanna say it) should be under system.slice. ONLY humans logging into the system (meat bags NOT applications switching to users) should be in user.slice. A LOT of times what happens is an old init script is dropped in place, they start it, it has a switch user and systemd assumes it’s a user and puts it into user.slice. systemd does NOT treat anything in user.slice the same as in system.slice and this WILL eventually cause problems.

So again, is it good or bad? Eh. It does a lot of cool things, but they did a MASSIVE disservice to ALL of us by just expecting to relearn absolutely EVERYTHING.

Guess me as an end user for Fedora should stop contributing my time and energy to identify and fix bugs, or get Fedora’s name out there, because I FIND NO VALUE in giving Red Hat my FREE work.

One thing while I worked at Red Hat, they will under pay you, they will push you beyond the breaking point, they will under value you, because “we will change the world.” And apparently you change the world by all those things I just mentioned.

Pixel 3 with CalyxOS.

Picked it because I don’t want to spend $500+ on a new phone and I want to be able to control my OS. Just buying the phone and using Android on it to going to CalyxOS saw a huge increase in performance, theoretically because it’s not working to process all the data collection. My phone should be MY phone and not someone else’s bottom line.

I used to be quiet about it, but now I’m pretty open about it. Joined The Satanic Temple and wear my shirt lots of places out and about and surprised when so many folks react positively to it. I like it.

Actually dated a girl in High School that was VERY devout Christian, though she wanted to do more things than I did, and she was constantly surprised that I was as moral as I was. She’d say I have such a strong belief in right and wrong, more than her even. And she asked how I even know what right and wrong was without the Bible. I was honestly stupified by the question. And I told her, because I understand that hurting people is hurting people and I don’t need a book to tell me that.

I feel like we’ve also gotten confused on legality and morallity. I’ve already taught my 6 year old, though I’m sure he doesn’t fully understand, that not everything that is right is legal and nothing everything that is legal is right.

That’s my understanding.

The only caveat being that Rocky and Alma have stated they’re attempting to figure things out. Something similar, though I can’t remember the exact change, happened like 10 years ago and everyone thought CentOS would die.

If there’s one thing I have faith in is that open source always finds a way. It’s not just you figuring something out. It’s entire communities of insanely brilliant and PASSIONATE folks. Never underestimate the passion that drives these folks. Red Hat does.

So Red Hat was getting closer and closer to CentOS. Then a few years ago, instead of being in partiy, Red Hat, and supposedly CentOS council, agreed it’d be better for CentOS to lead RHEL. This became CentOS Stream. And then the original creator of CentOS started Rocky. Alma was another distro that moved in to fill the niche of CentOS. I believe there are others as well.

CentOS Stream is closer to RHEL, but if I remember correctly, it’s rolling. So supposedly you as a developer could target CentOS Stream for RHEL’s NEXT major release and be ready when RHEL’s next major release gets to beta and you should be good to go.

I’ve never heard of ANYONE actually using or targetting CentOS Stream personally, but maybe there are folks. Pretty much everyone I know that was using CentOS in any kind of unofficial capacity has pivoted to Rocky or Alma or something else.

You can send a letter OR a package OR pictures OR a birthday card, etc through the standard mail.

Big corporations lead you to believe that only MAIL could go their service X or PACKAGES go through service Y. Both could NOT go through the same, because they wanted to make MONEY.

Fediverse is the open service that proves them wrong. And it needs YOUR help to survive and thrive by putting your content into the fediverse and not those walled gardens.

• Lemmy & KBin - Reddit alternative
• Owncast - Twitch alternative
• Mastodon & Pleroma - Twitter alternative
• Peertube - Youtube alternative
• Funkwhale - Music Spotify like alternative
• Pixelfed - Instagram alt
• Diaspora - Facebook

And you could build and host your own. It’s open for EVERYONE.

It’s not really proprietary. The code is still open. They’ve just locked it behind a paywall. There is the developer subscription that anyone can get 1 or a few of, can’t remember, so you still have access to it. Legally, based on the GPL, they HAVE to give access to their customers.

They also do contribute back upstreams.

But there are somethings they basically put together behind the scenes that would be very difficult for you to do yourself.

IDK if I fully answered WHAT CentOS is. CentOS WAS a completely 1 to 1 compatible RHEL operating system that was started by the community and given fully 100% free. Years ago, idk maybe 5-10 at this point, Red Hat went to the CentOS devs and said, come work WITH us. Not FOR us, but WITH, but we’d pay you (somehow I’m not sure on the financial details), us so we can help you make this better. Because they saw CentOS as a good onboarding ramp to sales of subscriptions for RHEL.

Myself, and others, worried that this was the end CentOS, but they kept moving forward.

A couple years ago while I was at Red Hat, Red Hat decided that the gap between Fedora and Red Hat was too large. So they were going to pivot CentOS into CentOS Stream so that developers could build against CentOS Stream and expect it to work in RHEL. Myself and many others inside of Red Hat were VERY vocal this was a bad idea, but we didn’t matter and even my mentor told me this was a good thing for RHEL. I didn’t care, RHEL was fine, I cared about CentOS going away. So now they’re turned CentOS into their play thing. And they’re forcing people to build against CentOS Stream, which IS NOT stable RHEL.

So Fedora is an “upstream” linux. So what that means is developers push their code directly into Fedora. Every 6 months, approximately, Fedora releases a new release. People on Fedora get that and file bugs and features to the next code.

CentOS Stream pulls from that. So they’re more stable. They don’t have the bugs that the Fedora folks hit (in theory), because it’s been solved upstream. By the time it gets to them, down stream, it’s been smoothed out.

Red Hat Enterprise Linux every once in a while will put a stake in the ground and say THIS is the code we’re going with from CentOS Stream. Make sure THIS version works, and pull in any bug fixes.

To give you a “real” kind of idea. Let’s say you have an application. We’ll call it the hiya 0.2 version. Fedora pulls in hiya 0.2. Then you keep upgrading until you get to 1.0 then 2.0 then 3.0. Fedora pulls each of those in.

CentOS Stream slowly pulls those in.

Eventually Red Hat says Hiya is what we need in RHEL! Except you’re going too fast. We want Hiya 1.0. BAM! Hiya 1.0 is going into RHEL 10. HOWEVER, since you’re faster, you’ve solved bugs in Hiya in 2.0 and 3.0. So RHEL will say well we don’t need that feature or that feature or that feature. But we DO need THAT bug fix in 2.0. So we take that bug fix and we backport it into OUR Hiya 1.1 code base. We do need THAT security fix in 3.0 to our code. So we make Hiya 1.2.

This is a VERY simplified version. And I’m not certain anymore on the interaction between CentOS Stream and RHEL. But that’s generally how it works.

The TIL is Red Hat had publicly accessible source code for RHEL. They’ve removed that and only thing you see is their upstream contributions to CentOS Stream. So you can’t build a RHEL counter part at this point, because their source isn’t available.

This affects projects like Rocky Linux, Alma Linux, even Oracle Linux.

Fedora runs basically future code for CentOS Stream which is basically RHEL Next really.

Some folks, like I just read Jeff Geerling, are now deciding their code, he makes Ansible stuff, won’t be guaranteed on RHEL because they can’t publicly test it.

Red Hat is a corporate entity that justifies locking down open sources to satisfy the bottom line. I’m a disgruntled former employee though.

“This change means that we, as builders of a RHEL clone, will now be responsible for following the licensing and agreements that are in place around Red Hat’s interfaces, in addition to following the licenses included in the software sources. Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.”

Sad. Very glad I got out of Red Hat when I did. It’s not the same place.

So then Oracle just gets 1 dev account and pulls the source.

Fedora is upstream. CentOS Stream is fed from that. RHEL is fed from that.

RHEL (Stable) <- CentOS Stream (Dev Test Bed, basically RHEL Next) <- Fedora (Cutting Edge)

Worked perfectly! Back to 100%! Thank you very much for your help!

I NEVER knew this! That’s awesome! Thank you! :-D

WHOA! SLOW DOWN with throwing out the mystical text! You wanna summon a demon right here?

Black background with GREEN text is the ONLY way you HEATHEN! We are now enemies! And we shall settle this like gentlemen!

TO THE GRID!

😁