For people trying to run desktop BSD, I think systemd has caused some real pain. For most Linux users and sysadmins, systemd has been helpful in the way it has standardized service management.
The freedesktop standards just seem to be offensive to BSD people as a matter of taste, though.
At its worst, PulseAudio was basically fine but pushed on some users by their distros before it was mature. And even then, Red Hat has also driven the development of its replacement, PipeWire, which has been widely recognized as kickass pretty much from the get-go.
> The freedesktop standards just seem to be offensive to BSD people as a matter of taste, though.
The freedesktop standards should be offensive to everyone as a matter of taste :-D. They are the ACPI of the desktop world.
(Note: if anyone wishes the freedesktop standards gone because they're the ACPI of the desktop world, they have probably not experienced the pre-ACPI world :-D)
My entry into Linux was actually a trip backwards into the pre-ACPI world, although that world was before my time.
As a kid, I was gifted a junker laptop that was otherwise destined for the trash heap after some hardware damage caused it to reboot whenever the AC adapter was plugged in or removed. Due to some wobble in the charging port, this meant the thing would reboot constantly— on Windows, anyway.
But when Linux booted on it, it could tell that something was not normal in what it heard via ACPI. So it disabled ACPI support, reverted to APM, and ran more or less normally. I still remember seeing those messages about APM being printed on every boot!
That was the first computer that was ever my own, and the reason I learned that Linux existed. Something mysterious going very wrong with ACPI was the start of a lifelong love for me. :)
systemd is dual edged sword really. Yes, ops wise we removed thousands of lines of fixes for "simple" (BSD people lie to you when they say sysv is simple) init scripts and also get rid of stuff like monit (auto restart of failed services) because builtin features of systemd replaced it better.
But on flipside for example journald introduced utterly misdesigned binary log format that needs to traverse every file it has on disk just to tell you "sorry, I don't have logs for this app". If it was just an SQLite file(s) I'd be utterly thrilled, ability to just throw an SQL to get logs I want ? Sign me in! But currently it's just.... bad.
Overall it is a positive change but I definitely do not blame people for disliking it, there are many parts of it to complain about.
> At its worst, PulseAudio was basically fine but pushed on some users by their distros before it was mature. And even then, Red Hat has also driven the development of its replacement, PipeWire, which has been widely recognized as kickass pretty much from the get-go.
It took 5+ years for it to be "fine", and the design was shit from the beginning. Like completely ignoring needs of real time audio, meaning anyone that wanted to do any serious audio stuff needed to either go to JACK or directly to ALSA and making JACK/ALSA and Pulseaudio play together wasn't for the faint of heart.
I still have some dumb udev scripts to apply a bunch of pulseaudio commands because apparently "remembering config of a device" isn't in scope of pulseaudio.
Even putting stuff in actual pulseaudio config is not enough as it will only apply it if device is present before pulseaudio started.
So if say you have USB audio card (that can be say just an digital output of a synthesizer or other instrument) that you plug after you have to manually apply any configuration, every time you connect it.
Sure, if you were lucky it might've worked for you but I for years heard "sec, I gotta restart pulseaudio" any time someone needed to run a skype or some other voice chat... and also had it just start screeching sounds once or twice a year, or "just" randomly starting to stutter till I kill it.
>(BSD people lie to you when they say sysv is simple)
Ah, *BSD do not use sysv init but BSD init, a totally different startup. And if you are old enough, you may remember the BSD init vs SYSV init wars, I think they made the systemd conflict look like a tea party with one mildly obnoxious person in attendance.
The current BSD init is by far the easiest. IIRC, most BSDs moved to something similar to this:
systemd has been helpful in the way it has standardized service management
From where I sit, absolutely not. And it's brought over-complexity, and monolith design, and far far far more bugs than other options, as a result.
My point is, the only reason systemd is less 'contentious' these days, is because fewer and fewer know how stable, streamlined, and more functional systems were before it. Systemd won by Redhat (via Gnome hard requirements) forcing it into all distros, and now, by the fact that it is now a Linux standard.
NOTE: I had to counter the assume statement here. I can get people may have differing opinions, and that people may view systemd differently, but cannot sit by when someone just says "this has been helpful!".
Debian was always exceptionally stable with sysvinit. Certainly moreso than systemd ever has been.
Yes, sysvinit had issues. Yet you could fix those issues quite handily. The core init binary was small. The scripts individual, and issues readily addressed. And once you resolved an issue, you reported upstream and debian typically fixed.
Meanwhile, systemd has an entirely new litany of problems with every single release. It's an insanely fast moving target. And worse, due to the nature of the project, it keeps extending its scope, and when it does so, it does it in what I can only refer to as a half-assed way.
Want nuanced DHCP services? Have to disable systemd's builtin, and go with an external. The same is true for ntp, have to disable that and go with ntpd. When it comes to mounting NFS services, I've had systemd:
* prevent a proper shutdown
* prevent a proper startup
* fail to mount on user login
* fail to start other services, because nfs is down
Meanwhile, nfs /home may have been an issue in certain circumstances... but there were very simple, very easy ways around this. And any breakage was simple to deal with.
I guess my point is, you may have had problems with whatever you used prior, but many distros ironed out most of the kinks. And the init system wasn't, essentially, an entirely new init system every 2 years.
Systemd has so many tweaks in its code now, so many edge case fixes, so much scope and size, overlaid with so much constant change, that it is essentially easier to consider it an entirely new codebase, every new stable release of a distro.
That's the complete opposite of stable.
What really should be done, IMO, is fork systemd and:
* remove every single thing that isn't core init
(No network code, no dhcp code, no ntp, no udev, nada, nothing)
* stabilize and simplify that core code
* anything of potential value, and save it as a separate
code base, maybe keeping systemd's udev or some such
I mean, look at binary logfiles, and having its own internal logging system. It's just insane. I literally cannot comprehend the logic of this. Now almost every single linux system in use, has two parallel logging systems. systemd's silly system, and then a syslog variant.
Just... why?
It's the same as the entire network blather, claiming naming conventions are more simplistic. Wha?! Before systemd, debian's udev implementation would give you eth0 for all but edge cases. It would retain knowledge of what NIC had which label, keep that through boots, no matter where you placed that NIC. It worked, it was perfect, it was simple, it had zero issues, for a decade plus.
Yet today, I still get insane interface names such as 23423434234weesa34r325233rwef from systemd in some cases. Hello?! What?! How is that a "predicatable" name. You know what's predictable? eth0.
Not some insane 'name it after the NIC slot, or then the MAC, or then the $x, onward forever.
It is immensely clear that systemd authors had very little understanding of server use linux when they started. And all of their goals were primarily, at the time, to "speed up" booting of VMs, to make VM instantiation of network easier (hence, naming after PCI(e) slot, which can be set in hypervisor configs).
Meanwhile, sysvinit had parallel bootups, and all systemd bootup optimization speed is gone, because systemd had to take into account all of the issues that sysvinit had to.
What a shocker. I recall systemd devs toting how fast stuff booted, then spending a decade adding edge cases, adding the ability to prevent instant reboots (eg, proper shutdowns so DBs and other daemons can exit gracefully), and wow, look at that, now bootup times and shutdown times are slower than sysvinit systems I manage.
Yes, slower. Along with cases of systemd not rebooting, just doing a shutdown and failing to reboot, because systemd. Literally the most absolute worst thing an init system can ever fail at. Pathetic. Beyond pathetic.
It's at least once a month I have to deal with a new systemd edge case. Literally, once a month. Yet when I managed non-systemd systems? Years would go by before an edge case hit, I'd resolve it, and done for years.
I don't know why you would distrust old init systems. Their scope was quite simple. Outside of starting/stopping a service, that was it. And outside of something more complex (shutting down a DB, and maybe a 4 minute wait for that), this was a very simple task.
What issues did you have? NFS boot issues (an easy thing to resolve, but yes this was and still is an issue, even with systemd).
> For people trying to run desktop BSD, I think systemd has caused some real pain. For most Linux users and sysadmins, systemd has been helpful in the way it has standardized service management.
It only standardized anything if you deny anything else exists.
To make desktop Linux a reality we need more standardization in the Linux world, not less. If some GNU/Stallman types get offended, so be it. It's a worthy tradeoff.
Desktop Linux is a reality. "Standardizing" won't make it any more mainstream and will destroy what makes it special: That you get the OS that YOU want.
Do you visit people's homes much, or to schools and universities, or anywhere in China?
Because various vendors have shipped something like ¼-⅓ billion ChromeBooks over the last 3-4 years. That's a lot. That's more than Apple has shipped Macs.
You don't see them in offices much, it's true, but that's because they're in homes and educational institutions.
China has been following an aggressive program to dispense with foreign computers, called 3-5-2:
Most people who consciously prefer 'desktop Linux' do so not because it's based on the Linux kernel. They do so because it feels better to use than alternatives. And the reason a Linux desktop feels better to use goes understated because it seems 'political' and the people who have explicitly advocated for it most visibly have been smeared as extremists, ideologues, etc. But it's clear: using a system comprised as far as practicable of free software is refreshing, because it provides respite from the artifice, malice, and opacity of big tech products. It's a lost treasure from a forgotten world.
Chromebooks are so thoroughly productized that they have very little to do with what most 'Linux' advocates really like about Linux. We should wake up and recognize ourselves as advocates of software freedom, user choice, community-driven development, and a particular free software ecosystem, instead of getting into nonsense arguments about 'what is really Linux'. The same goes double for similar discussions that crop up around Android, which is as productized as ChromeOS but additionally much more locked down, further alienating it from the actual virtues that make good Linux experiences good.
I find this a very strange response, because while I can't really argue against any of it, it reads to me not as an answer but as a passing comment, tangential to what I was writing about that intersects with it almost incidentally.
There are big issues here but I am not sure that our views overlap by more than a wafer-thin ellipse.
One question: does it really matter why people use it?
Another: which is more important, the people who use it for political or ideological reasons, or the ones who use it from pragmatism?
Another: does it maybe matter how many use what form, than why they do it?
For 3 decades or so, there have been 2 main camps in the FOSS world, which is why the term "FOSS" was invented. One camp is the GNU folk, the Free Software types. The other is the Open Source folks.
Free Software: purity is more important than functionality. Don't use anything non-Free.
Open Source: what's important is that it works and does the job. Try to keep it all Free but if the choice is not working or not being free, it's more important that it works.
Fair so far?
This split exists in Linux.
So, for example, some distros (Ubuntu, Mint, and others) include proprietary blobs and drivers because without them it won't work on most computers.
Other distros (Fedora, Debian) don't. If you have problems getting it working, tough. Try a wired Ethernet connection. Try a USB wifi dongle. It's more important to them that it's all Free, but they may include non-free firmware in some versions or as extras.
Other distros refuse that, and purge the whole codebase of all BLOBs: Trisquel, Purism Pure OS. They accept and embrace that this choice means restricted hardware choice, and you may have to build computers specifically to run them.
But the thing is that now there's a 3rd kind of Linux. Linuxes that don't even claim to be a Linux, corporate products that happen to be based on Linux, but don't mention it, and are sold to the public as appliances, devices that work and let you use the Internet, and who cares how it works underneath.
Android, ChromeBooks, ChromeCast, etc.
And the thing is, these are way more successful. Billions of people use them and don't care what they run.
As a result, some of the changes have filtered back up the software chain and now desktop Linux is way more viable than it was, and a lot of stuff mostly just works.
But the two FOSS camps unite over this: these things Do Not Count and are not considered Real Linux.
I think market success matters more than ideology. We can say that it's arrived and it's practical and usable because hundreds of millions of people buy this kit every year and just get on with using it and enjoying it, and they don't care -- and don't need to care -- if it's FOSS software underneath.
No thanks. I'm not sinking myself deeper into the Google data collection and advertisement empire. The whole point of the Linux desktop is freedom from such anti-consumer behaviors.
> The whole point of the Linux desktop is freedom from such anti-consumer behaviors
[[Citation needed]]
That may be your use-case, but it's not everyone's. I use it because it works well on cheap generic kit, it's free, it's faster than Windows, and it's largely immune to viruses.
My machines are all connected to paid Google accounts.
>systemd, pulseaudio, freedesktop have bought much pain in the way of open standards and interoperability.
You were down voted, so I will be glad to join you in the swamps :)
I fully agree with that statement, with freedesktop being by far the worst of the bunch. Seems these so-called "Open Groups" are doing all they can to eliminate the BSDs and probably some rather unique Linux Distros along the way.
And yes, I stand by this and I doubt my opinion will ever change. So let the down-votes begin :)
or they put it into crontab via @reboot ... . Or they run it in screen/tmux, or they will run it from crontab via @reboot which will start screen/tmux session with sudo for specific user..that's what I've seen myself so far on Linux servers. I believe having simple structured unit files saved us from part of such setups at least. Another big part is [hidden] under Docker now.
Seen nothing of that chaos on FreeBSD servers, but not cuz it's init system is superior, but cuz literally 0 presence on server market.
systemd, pulseaudio, freedesktop have bought much pain in the way of open standards and interoperability.