From what I’ve heard from NixOS users, your intuition seems right. When you learn NixOS, you learn NixOS rather than Linux. The question is, what your goals are. If you want to get a job as a Linux sysadmin, you’d probably be better off using a more common distro. But if you just want to use Linux privately, dive into whatever seems most exciting to you or fulfills your needs the best.
When you learn NixOS, you learn NixOS rather than Linux.
That is exactly what I am talking about. You seem to have understood me the most. NixOS could be the unequivocally best distro ever. However, that does not change the fact that a big portion of your knowledge acquisition and experience gained from your time on NixOS, will be for NixOS alone.
I am obviously not putting the two on the same line, but mac shares a lot of terminal syntax and programs with Linux. They still remain vastly different. So, this is exactly what concerns me with the growth that I seek in the Linux ecosystem.
I don’t mean to sound crass here, but the best answer I can give you is, “because I want to”. I wouldn’t go as far as to say that I will pursue Linux professionally as a job. But who knows? I wouldn’t out-rule that.
It’s something that I am passionate about and enjoy using. Therefore, I will naturally want to grow my knowledge in.
Not crass at all. I would suggest that you follow your gut instinct. If NixOS excites you, go for it. If you want to understand the intricacies of Linux itself, look into Linux From Scratch. If you want to understand how “regular” distros work (and what sets them apart from each other) hop around between your usual suspects until you’ve scratched that itch long enough. Want to form your own opinion around init systems? Use a distro that supports Runit, s6 or OpenRC besides systemd.
I don’t think anyone else can tell you what you should do in this situation.
The traditional init systems suited me just fine, i saw no need to change them. If they were so bad, then they could’ve been fixed or replaced.
The migration to systemd felt forced. Debian surprised everyone with the change. Also systemd’s development is/was backed by corporate Red Hat, their lead developer wasn’t exactly loved either and is now working for Microsoft. Of course Canonical’s Ubuntu adopted it as well. Overall feels like Windows’ svchost.exe, hence people accusing it of vendor lock-in.
It’s not just an init system, it’s way waaay more. It’s supposed to be modular, but good luck keeping only its PID1 in a distro that supports systemd. It breaks the “do one thing right” approach and, in practice, does take away choice which pisses me off.
I had been using Debian since Woody, but that make me change to Gentoo on my desktop which, to me, took the best path: they default to OpenRC but you’re free to use systemd if you want to. That’s choice. For servers i now prefer Slackware and the laptop runs Devuan whenever i boot it up.
To be fair systemd hasn’t shown its ugly face in the Ubuntu VMs i’m forced to use at work.
YMMV. If you’re happy with it, fine. This, of course, is only my opinion.
Rebuilders are fine, and RedHat is fine to not spend the effort to debrand their source rpms. The problem is one of value. The value RedHat provides for some people is probably worth more than RedHat charges. The value RedHat provides to others is less than the effort it takes to renew a developer license once a year for 16 installs. The problem is that there are several who are ending support for RHEL because they fall into the latter group (notably Jeff Geerling for ansible roles). RHEL losing out on that support might be huge, might not, only time will tell.
My company runs thousands of centos VMs. We cannot exist if we have to license rhel. We’ve been working on switching to Alma. We may have to look elsewhere for a free distro that has robust SeLinux support.
We’d probably need to qualify this with “bad compared to what”. I can’t complain, as it does its job, and I’ve been able to tweak what I needed to. As I don’t tinker with it every week, I keep a sticky note rolled up on my desktop, or I quickly use ‘cheat systemd’ to remember some key examples.
I was getting really long start up time earlier this year (like 19 mins before the desktop was fully responding) and after trying everything else I tried ditching BTRFS and reverting my /home drive back to ext4. Turns out BTRFS start and checks was killing my boot times. Now, as fast as anything.
The following have been my saviours though in identifying boot times: journalctl -b -p err systemd-analyze blame --user systemd-analyze blame
You have an off by one bug, the format of the commands says “0-9/0-9/0-9” but your columns and rows are labelled 1-9, you either need to zero index your board or 1 index the commands you give.
That is and always was nonsense. Systemd shortens boot times by starting things in parallel. That’s one of its key features.
There are some things to note about that:
Systemd only starts services in parallel when it isn’t told otherwise by Before and/or After settings in the service files. This makes it pretty easy to make systemd slow by misconfiguring it. You can use the systemd-analyze program to see which services held up your boot.
Systemd has a very long default timeout (90 seconds) for starting or stopping a service. It’s appropriate for the big, lumbering servers that systemd was probably designed for, but it might be wise to shorten the timeout on desktops, where a service taking more than 5 seconds to start is almost certainly broken. It’s a setting in /etc/systemd/system.conf.
Is the current SystemD rant derived from years ago (while they’ve improved a lot)?
I’m an early adopter of systemd. I installed it on my Debian desktops pretty much as soon as it was available in Debian, and I later started moving servers to it as well. I had long been jealous of Windows NT’s service manager, and systemd is exactly what I had hoped would come to Linux one day.
Yes, the rant you’re talking about is old, and yes, systemd is better now than it was then, but not in the sense of what the rant was complaining about. The rant was already patent nonsense when it was written, which has given me a very dim view of the anti-systemd crowd.
Besides systemd proper, they also spent a lot of time ranting about the journal system, which redirects syslog entries into a set of binary log files. They complained that this would make logs impossible to read in emergencies. This isn’t even close to being true—any emergency bootable Linux image worth its salt has a copy of journalctl on it—and the binary nature of systemd’s logs has caused me serious problems on exactly zero occasions.
Nice post, and a good overview over why RedHat is doing what it’s doing.
Before reading this I wasn’t really feeling good about redhat and the stuff happening rn but now i’m able to understand the decision making and there’s still hope for me that redhat won’t turn into a shitshow in a couple years haha
Also working with RedHat in the past has been quite nice so it’s good that i don’t feel a slight hate against the company anymore.
Quite hard to solve the problem when everyone is so emotional
One other thing I want to add: I’ve read a bunch of comments about how the Rebuilds were used in educational and scientific settings, and that there is a prohibitive cost for RHEL in those environments. After reading so many comments about it, I have to believe that Red Hat is going to make some modification to their Developer License program to allow more than 16 ‘seats’ for those use cases.
I don’t have any expectations of them doing this (but I also have no expectations to the contrary), but I think it would be a good move from Red Hat to make the official RHEL more available, as you suggest.
In another thread I compared the RHEL rebuilds to piracy, and in that vein one could quote Gabe Newell and say that piracy is a service problem – part of the reason Alma/Rocky/etc. exist is because there is a group of users who want to use RHEL but cannot afford it. Red Hat seems to believe that these users should be satisfied with CentOS Stream, and maybe most of them would be, if they only gave it a try. But making RHEL more widely accessible, both to paying users and developers, would probably be good too.
I worked for a bank. When they decided to deploy Linux on their infrastructure, they chose RHEL and they have signed a big contract with RedHat for tech support.
Overall, they chose RedHat for the same reason they chose Microsoft before: tech support. They have >10000 engineers, and yet somehow they think they absolutely need tech support… They pay a lot for it. In my building, they even got a Microsoft engineer once a week on-site until Covid. I don’t know for the other people working for this bank, but I asked for Microsoft support only once in 2 years. In the end, their guy sent me back an email telling me “I’ve transmitted your question to the corresponding engineering team” and … diddlysquat.
Now to be fair, for paying customers, RHEL and Microsoft both ensure security updates for a really a long time. Red Hat pays a lot of people to backport security patches from upstream to previous versions. It allows companies like the bank I worked for to keep running completely crappy and obsolete software for an insane amount of time without having to worry too much about security vulnerabilities.
Anyway regarding RedHat contributions, a lot of them are subtle.
A friend of mine works for RedHat. He is a core Python developer and is paid full-time by RedHat to work on Python.
Through this friend, I applied for a position in their company at some point (unfortunately, it didn’t happen ; don’t remember why exactly). The position was in a team dedicated to improve hardware support. They have built an infrastructure to let computer manufacturers (Dell, Lenovo, etc) test the compatibility of their new hardware with Linux/RHEL quickly and automatically.
Part of the technical support they provide to some clients is “making things work”. It may imply fixing bugs or improving drivers and then sending patches upstream.
If I’m not mistaken, they paid Lennart Poettering to work on Systemd and Pulseaudio.
They pay for the development of some infrastructure software like Corosync for instance.
This list is far from exhaustive. I’m sure they have paid for a lot of other things you’re using daily without knowing it.
RH will just cut them out soon enough, if you believe the trends.
Best have a plan to move on FROM them, though. Look into parallel porting to PCLinuxOS for now, as it’s a VERY similar maintenance routine, and it has a very wide app support window. Their unattended install (ie packer for vagrant or ovirt) is absolute ass, but that’s their achilles heel. Ultimately, that may not be a problem for you.
I’d direct you to the PCL/OS lemmy sub, but I think there is none yet.
You’re not doing it right. There’s absolutely a reason why enterprise linux works with a version that’s more-or-less locked in place (but for security updates, like a maintenance fork). You need to understand the value you’ve been overlooking.
ten years of a stable platform. Because, yeah, it’s not this week’s release with the glitter, but it’s also not a moving target of broken suck you have to constantly chase, and you can actually do dev.
dependencies are figured out
updates are trivial when security stuff comes out. Honestly – yum+cron is so stable and reliable, and the compatibility is part of the guarantee; so you - and your customers - don’t have to worry or - please god no - delay updates to gauge risk. Since updates are 99% of the work to avoid exploits, this goes from ‘huge risk’ to ‘no-brainer’. And you don’t have to worry that your dev environment is non-trivial to replicate on the daily.
your requirements for your software becomes ‘EL7’; maybe ‘EL7+EPEL7’ or so. Your installation process becomes ‘add repo RPM which pulls in other repo RPMs. yum install’ , and you’re already onto mere config work.
validating the install isn’t ‘did you install this ream of apps from this particular week in time, then run some wget|sh bullshit? Now run this other set of commands to confirm your installation’ – but in our case is just ‘rpm -qa|egrep’ or even an snmpwalk.
not working? Give me your one config file and your rpm-qa and we’ll replicate here trivially and find out why. (I didn’t work in support, but I liaised with them a bunch in the security work, and that was common practice) Tossing 4 lines and a <<EOF construct into a vagrant config is just so easy, now, and gives the entire machine to play with.
As someone who used to dev a notable app in the past, cross-distro problems alone made so many of the fringe OSes impossible to support, and so we didn’t. EL was the backbone because we respected what we had.
I just can’t figure out why this-week’s-glitter is more important than losing the install/support/update/validate burden by choosing a stable platform to work within. Life’s too short to support dependency hell or struggle just to replicate a failing setup in your lab for testing. Do you just not support customers?
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:
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.
sshd’s init script under OpenRC is 87 lines, of which around half are blanks, comments, closing braces, and other boilerplate. Granted, that still makes the real code maybe three times the size of your systemd unit file, but the difference isn’t as impressive as you’re making out.
95% of people shouldn’t need to poke around in their init scripts or unit files anyway. If you actually need to do that, your use case is already somewhat unusual.
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.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.