Linux kernel 6.11 lands with vintage TV support
io_uring
is getting more capable, and PREEMPT_RT is going mainstream The Linux kernel has around 27.8 million lines of code in its Git repository, up from 26.1 million a year ago, while systemd now has nearly 1.3 million lines of code, according to GitHub stats analysed by Michael Larabel at Phoronix. There were nearly 75,000 code commits to the kernel during 2019 which is actually slightly …
I agree. It does.
It also - like anything new - introduces problems we didn't have before, and in *some* cases those new problems are much worse than the old problems. I'd be much happier about it if certain people in the systemd camp would acknowledged that.
My Biggest problem is that it doesn't follow the mantra of everything else on the system: "Do one thing, and do it well"
There isn't really a good way to just use one part of it to solve 'a' problem. This leads to the described issues in being forced into adopting new problems.
One of Linux's best features is that you could always change what you wanted to get what you wanted out of it, and systemd is actively breaking that.
As a user, I just want something that works. As a tinkerer, I want something to play around with. Systemd only "kinda" solves one of those use cases.
I've not used FreeBSD other than in a "That up there is the firewall pair. Leave them alone, they've not been rebooted since 2004" kinda way, so it may well have some variant of this:
One thing I can think of that systemd does that sysv didn't is "status management" where if a service dies, it will be restarted. If some idiot stops a service for a quick config change without disabling it and forgets to bring it back, then it will come back on it's own.
This is actually very useful *sometimes* and a *colossal pain* at other times. Plus side: Protects against "Ooops, I forgot to restart the service". Minus side: "Something is badly broken, but the service auto-starts after crashes so no one ever actually notices, because it was up every time Nagios checked on it."
There's not _nothing_ that systemd gets you. But it also gets you a lot of things you probably don't want.
Daemontools isn't a drop-in fix. You have to have a split between your daemontools processes and their scripts, and your init processes and there scripts, while never the twain shall meet. systemd just needs one line in the config to maintain a service.
Daemontools also goes wrong, plenty of times... leaving processes running it was supposed to stop. systemd is much smarter and more robust. It also has other modes of monitoring the health of a process, not just waiting for the PID to quit, handling crazy forking processes, etc, etc. You should have at least said "monit" rather than daemontools.
NOTE: I dislike systemd as much as anybody, but the old init system was long overdue for improvements, and something like upstart is worse than systemd.
NOTE: I dislike systemd as much as anybody, but the old init system was long overdue for improvements, and something like upstart is worse than systemd.
I suspect that was the issue really, the system V init system was always a bit 'weird'. I still prefer the NetBSD and FreeBSD rc system to systemd (although that's probably more familiarity than anything; only used systemd on a debian box I had as a pvr).
Still think 'runlevels' are a thing that sounded like a good idea at the time though; my occasional forray into Linux (and Solaris) always confused me with the weird numbers and odd symlinks. But NetBSD's 'write a simple script then set a variable in rc.conf' seemed to work quite well.
The restarting failed daemons thing was a problem with it though.
Still think 'runlevels' are a thing that sounded like a good idea at the time though
And mostly were. They were pretty simple in essence - the runlevel is linked to how the machine is used.
Runlevel 1 is single-user (mostly used to fix badly broken stuff)
Runlevel 3 is normal server mode (no GUI)
Runlevel 5 is normal desktop mode (ie GUI + all the services needed).
Each runlevel inherits the stuff from the lower runlevels - so runlevel 5 includes all the stuff from runlevel 3.
Can you tell I used to use old Redhat a lot before discovering Mandrake? (Essentially Redhat+customisations). The only linux I use nowadays (other than proxmox for my VM server and what used to be called Astaro for my firewall) is devuan..
auto-restart services... (*sigh*)
a) run a simple shell script that does "service blahblah stop" sleep 1 "service blahblah start" whenever 'ps ax | grep blahblah' doesnt return anything back. have it loop every 5 seconds or something.
b) don't use applications that crash
c) log in with ssh periodically and do a 'ps ax' to see what's running
d) if it's mission critical, it should restart ITSELF [and NOT need a 'systemd']
by "solving" that one problem, and introducing BOATLOADS of "feature creep", systemd basically did it WRONG but the "developers" *FELT* [not thinking, FEELING, with emotions, which make CRAP decisions] it would be "BETTER" and they were *FREAKING WRONG*!!!
Actually, I think it's excellent advice.
The acceptance that "all software has bugs" is one of the biggest drags on the software profession in existence. It might have been true in the early days of software development when that was almost entirely done by amateurs, but it certainly doesn't need to be true now, with the kind of modern software development, verification and proof techniques that are available. I can't think of any other industry where catastrophic failure of its products would be so airily dismissed on a regular basis.
Software developers could develop applications that didn't crash (or very, very, rarely crashed) if they were prepared to put in the engineering effort, and sometimes they do. You wouldn't think much of the Linux kernel if it fell over every five minutes, or even every five months.
Your response seems filled with arrogance to me, it almost sounds like you're saying "if only developers could do their jobs".
Crashes happen for various reasons and there are multiple cases where crashing is in fact preferable to continued running of a service. There are major differences between daemons running on a server and some terrible app that runs on a smart phone. More so, a lot of the time daemon failures aren't even the software's fault but the fault of the administrator for not properly configuring applications in the first place and supplying insufficient resources for what they are trying to run. A Daemon killed by OOM-killer for example is not the fault of the software but rather are usually the fault of the administrator(s) responsible for that server. Further there are hardware failures and failures in other software/libraries which also add to the stack. No serious developer is going to create their software from Assembly code to make even a basic web daemon.
So this isn't about developers being amateurs or designing bad software that crashes a lot but rather a mixture of many complex issues being over-simplified by somebody being naively idealistic on what is truly achievable in the real world.
"there are multiple cases where crashing is in fact preferable to continued running of a service. "
Correct, subject to one major clarification/caveat.
Do you understand and accept that there is a difference between
* a controlled but unexpected daemon exit due to some unrecoverable condition e.g. unrecoverable resource exhaustion. Many people (often the "greybeard" people?) wouldn't call this a crash, especially if the reason for the exit could be logged for troubleshooting and recovery.
* an uncontrolled daemon crash of the kind that used to lead to a core dump (for whatever reason).
Does it matter that your post makes no distintion between the two?
"naively idealistic on what is truly achievable in the real world."
Well behaved computer-based systems have been achievable for decades, but have become unfashionable, especially since uncontrolled system failure became widely acceptable. Discuss...
Obviously I understand there is a difference, thus the very wording "there are multiple cases where", this is not an all encompassing phrase to begin with. I can only see you going to this point if I had used an all encompassing phrase, which I didn't. So why are we here?
"Well behaved computer-based systems have been achievable for decades, but have become unfashionable, especially since uncontrolled system failure became widely acceptable. Discuss..."
Why would 'well behaved computer-based systems" become unpopular unless there was fundamentally something wrong with them? The answer is that there is something fundamentally wrong with them almost every time. It is impossible to build an entirely crash-proof computer because components do degrade and resources get pushed too far, and there are simply better ways to achieve uptime than being reliant on a design with systems that are single points of failures.
Your response seems filled with arrogance to me...”
I don’t think it’s arrogant at all. Software does not have to crash. If it’s written well. I have written many applications that run for literally years with no problems. And that’s not because I’m super-human. It’s because that should be the norm.
Anyone working in an embedded environment will (should!!) have written stuff that doesn’t crash and which is likely to need to carry in not crashing forever. In my experience, software often fails because it was a heap of crap in the first place. Yes, even well written stuff might fail because of some unforeseen circumstance. But it should never crash. At worse, it should fail gracefully But even that should be limited to initial development and testing.
Typically embedded software is many orders of magnitude less complex than the monster codebases many of us work with. Despite our best efforts to divide & conquer, the complexity still usually scales exponentially or worse, plus some more as team sizes increase and bring their own thinking differences to the party. Complexity that surpasses the capabilities of any automated proof or testing software.
I'll also remind you how frequently we hear about buggy embedded software. Software really is hard.
Software really is hard.
Yes, but a great many developers refuse to do even simple things that could greatly improve quality, such as writing readable, well-designed code; refactoring and otherwise improving quality during initial development and maintenance; using static and dynamic analysis tools, a number of which are freely available; and performing decent testing.
But yet neither the linux kernel nor systemd are limited to only supported single embedded systems and nor is software in most web sites hosted on the Internet.
And indeed, there are cases where software fails because it is a heap of crap but this is just one of MANY cases, software also often fails when it is running on dodgy hardware, software often fails when the supporting system is not up to spec or ill-configured. Software also fails because of unforeseen events too, it's impossible to always know what a system is going to deal with but blaming it ALL on software developers is like blaming the Car Manufacturer for every punctured tire that car gets, even if say it ran over a nail.
This is why I say the previous statement war arrogant because it was so limited in scope and some idealistic world where you can just code away all issues in the world but software developers just won't do their jobs....at least that is VERY much how it came across.
"blaming it ALL on software developers is like blaming the Car Manufacturer for every punctured tire that car gets, even if say it ran over a nail."
Well, back in 1985 (ish) I bought a low end UK car that came as standard with "run-flat tyres", so that if a tyre was punctured you could relatively easily (and safely) get to a safe place to have the tyre looked at.
Five or so years later I had a different car (from the same group), allegedly a bit more upmarket. It didn't have run-flat tyres. One day on the motorway the steering wheel started vibrating oddly. I was travelling a around 70mph in lane 3 and made a hasty and rather uncomfortable retreat to the "breakdown lane".One of the front tyres had fallen to bits (manufacturing defect?). The breakdown lane wasn't actually a safe place to change a wheel, but hey, I got there in one piece.
Is that progress?
My current car (2012 model) doesn't have run-flat tyres either. And in the last few months it's had tyres replaced or repaired three times in less than 2000 miles, because of nails and screws through tyres.
Lots of cars currently on the market seem to come with remote sensors for tyre pressure. Based on comments from people who've had them, these sensors and associated logic cause lots of confusion and false alarms, perhaps because of poor system design?
Now, actually, because cars are in general based on a mix of "standards" and "implementations", people can already choose from a selection of differet manufacturers for (amongst other things) tyres. I could probably even choose to have run-flat tyres fitted to my current car. Because standards exist and interfaces are documented.
On a related note, mass market cars have had dual-circuit brakes for maybe three decades now (at least on this side of the piond). It's relatively tricky to have a total loss of braking capacity, because a car without dual circuit brakes isn't saleable. It's getting increasingly difficult to find a modern vehicle that isn't reliant on untrustworthy computer systems :(
How does that approach work for systemd? Systemd addresses aspects of a real and known problem, and addresses it in a rather poor way in many respects. Can system builders choose a plug-in replacement and expect it to address the same problems? Not at the moment, though *maybe* things will change. We can but hope.
So let's not hear too many suggestions that doing things properly doesn't matter because it isn't needed, is too expensive, and can't be done anyway. That's the kind of attitude that will quite possibly see Boeing bankrupt within five years, and hopefully see Boeing management and their regulatory puppets accepting responsibility when their actions lead to unpleasant consequences.
That won't bring Boeing's victims back, but it might encourage others to adhere to the proper standards in future.
whoever said doing things properly doesn't matter? Nobody ever made that argument. The Argument is about having realistic expectations of what is actually achievable instead of believing everything can just be fixed with software, such as hardware failures or badly configured systems/servers.
As far as run flat tyres go, they are another example of where there is fundamental issues, Run flats are more expensive and generally degrade faster than conventional tires, blowouts are still possible with run flats and they generally only protect against specific areas, punctures from the side of the tire may leave the tire still completely unusable. Meanwhile development of self-sealing tires has come along and for many small punctures is an alternative method of keeping the tires still working while looking to get service/tire replacement.
"whoever said doing things properly doesn't matter? Nobody ever made that argument."
Some people here have suggested that some things aren't realistically achievable. Spot the difference? I happily accept that *some* things aren't realistically achievable (honest management?), but in the case of Boeing we're talking about a major player in a business sector where there is supposed to be effective regulation and oversight of compliance with standards and policies and procedures.
Boeing management and others similar elsewhere may not have explicitly said "not worth doing properly", not in so many words, but their actions are what count. "Safety is our first priority" - about as useful a platitude as "it worked last time I tried it".
Reuters and others have some interesting reports today (10 Jan)
https://uk.reuters.com/article/uk-boeing-737max/designed-by-clowns-boeing-releases-internal-messages-that-disparage-737-max-regulators-idUKKBN1Z902L
https://www.reuters.com/article/us-boeing-737max/designed-by-clowns-boeing-releases-internal-messages-that-disparage-737-max-regulators-idUSKBN1Z902N
"Boeing Co has released hundreds of internal messages that contained harshly critical comments about the development of the 737 MAX, including one that said the plane was “designed by clowns who in turn are supervised by monkeys”. "
Just imagine engineers saying "All bridges collapse" and just sort of accepting that under normal everyday circumstances a bridge might fall down. All software does not crash. Well written software will deal with known and unknown circumstances. Occasionally, yes, something weird might happen. At that point you want your system to fail to another host or stop, not just restart and hope for the best. We don't rebuild bridges to the same spec during a hurricane because we know the new one would break immediately. A crash should be your warning that something is very, very wrong and unusual. I'd almost suggest that instead of restarting the service a system ought to keep a record on a three strikes principle - if software crashes three times, permanently block it from running to force a real solution to the problem!
You can plan for known and unknown circumstances. It's the unknown unknowns that get you.
Which is why I will always believe that software will have bugs in it, not matter how much time you spend on it. Even some of the most robust software ever written, used on, for example, space probes, occasionally reboots itself because something somewhere got in a state that was entirely unpredictable.
So never expect software written to a schedule to be bug or crash free. Because that schedule means you can never take care of everything.
This post has been deleted by its author
> One thing I can think of that systemd does that sysv didn't is "status management"
Well, when it works it does, but :-)
So if you hate NetworkManager and want to continue to use the network service and ifup/ifdown you can disable the dreaded NM and enable network. Great. Then if a NIC goes down on you or someone does something like reloaded the NIC driver to tweak a load time param the network goes down and systemd won't bring it back up again. You can't do a systemctl start, it won't do a proper stop or a restart. You have to go in and manually cleanup before you can restart it.
Oh and of course the systemd team have subsumed udev, but they've imposed their "my way or the highway" approach so you can't just have udev do the ifdown & ifup for you as they take longer that the systemd-udev allows anything run from an action to take and even if drop them into their own process group and session it tracks them down and does a kill -9 without bothering to log anything.
I think there are some great ideas in systemd, I really do. But there is a less than stellar implementation at times.
NetworkManager isn't something you should disable as of RHEL/CentOS 7, it's actually better (IMO) than Network in RHEL/CentOS 7. The reason most people hate NetworkManager was because of how terrible the implementation in RHEL/CentOS 6 was.
One of the reasons Network Manager is better in RHEL/CentOS 7 is that it gives separation between connection and device which (in my opinion at least) gives you far more power over your network configuration and more versatility all-round, but it does require a lot more learning for it but at least bash completion exists.
One reason for hating NetworkManager is that it breaks things. When you run NM it tries to react to changes in your networking environment, this is its job. So when you create a new networked device NM wants to react. Some of these reactions can be good. So in the case I mentioned above you reload the NIC driver and NM restarts the networking on the NIC, which is nice.
But it can also do things like restart other bits of SW, for example the DHCP server. So you create a VM, it gets a vnet device for each vNIC and NM restarts the DHCP server for each of these new vnet devices. If your VM has several vNICs or you manipulate a bunch of VMs together you get a storm of network device changes and therefore a storm of restarts. At this point systemd and NM get into a punch up which results in systemd disabling the services that NM is causing to restart. As a user what you see is that when you start some VMs other random bits of SW stop running. I'm guessing this is why step one of the OpenStack installation guide say disable NM (OK I've not checked this for a a year or so, but it did the last time I checked).
NM can be great on laptops.
But I use CentOS/RHEL as a server OS and that tends to mean you use it in different ways. On a server I'm not sure of where I might want to separate a connection and a device, whereas on a laptop it is useful to be able to switch between wired and WiFi networks.
To my mind there are too many things in 7 which seem to be aimed at the destop/laptop world which are detrimental to the server world. YMMV.
You still seem stuck in the mindset of where NM was in CentOS/RHEL 6, it was majorly reworked for CentOS/RHEL 7 and no longer randomly breaks things. What was released in CentOS/RHEL 6 was definitely a daemon aimed at laptops and it was terrible by all accounts.
If you want to go for RHCSA/RHCE now, you have to learn NM properly which today it has vastly superior tooling to where it was on CentOS/RHEL6 and actually knows how to play ball with a server. In fact, NM has a new alternative to bonding, it has teaming. Further to this you can pass it configuration in JSON and it actually bothers to read what was in /etc/sysconfig/network-scripts/ too now. The only reason I see for disabling NM in CentOS 7 is the memories of trauma from what was given in CentOS 6.
Sorry, you're wrong.
The problems at RHEL6 are totally different. The problem I described above is what happens at RHEL7. Go try it.
If you look at the comments I made above you'll notice that I was talking about how NM & systemd interact, does that sound like I was in "6" mode?
Seems I skimmed a bit too fast, apologies. Personally I haven't experienced anything like that but then generally try to avoid DHCP in the first place where possible, static configurations have (IMO) always been more reliable but I understand/know that static isn't always possible (of course).
My playground server is currently down due to moving but I suspect the behaviour mentioned here is controlled within the NetworkManager.conf, perhaps the dhcp setting but can't test to be sure and thus can't currently make an argument about it being configuration.
@R3sistance, no worries, but it isn't only the DHCP server, that was just the just app that I hit the issue on. It's anything that gets restarted when the NM finds a new device.
I know that for the certification exams these days that you need to know NM, for the Red Hat ones its hardly surprising that RH want to examine you on Red Hat's software, but even LPIC now lists NM and is threatening to stop requiring ifup/ifdown.
I've not had time to explore things at 8, if you want to use the script approach at 8 you have to install it, it isn't there by default. I've not seen what the OpenStack world is saying for 8 either.
"One thing I can think of that systemd does that sysv didn't is "status management" where if a service dies, it will be restarted."
Look at the respawn option in inittab
One of the (many) things that I don't like about systemd is that it's authors seemed to have blundered ahead blindly, claiming that some utility or other "can't do that" without even reading TFM to find out that it in fact can.
Seriously? That's horrifically broken. Windows does auto service restart, but it's not stupid enough to restart a service when it's manually stopped.
If I manually stop a service I intend it to stay stopped. If it falls over, it should be restarted. This is not rocket science.
" If some idiot stops a service for a quick config change without disabling it and forgets to bring it back, then it will come back on it's own."
So how does systemd know when said idiot is finished making the 'quick change' and decide to restart the service all by itself (which may or may not be before the idiot has finished)?
I also use FreeBSD, and whenever possible, Linux distros like DEVUAN that do *NOT* have systemd.
Unfortunately, I made a decision for embedded development for a customer, to use Raspbian (based on Debian) and THAT has systemd in it. I've had to waste several HOURS trying to un-do systemd's STUPIDITY (like 'out of the box' assuming that all serial ports are MODEMS, and hence run the modem daemon/service/whatever-the-hell-it-is which kept B0RKING the startup sequence for device control of a serial port connected device from a headless Raspberry Pi, but I digress...).
systemd has TOO! MANY! BUT-IF! QURKY! STUPIDTHINGS! EMBEDDED! IN! IT! and in TOO many cases I've had to *FIGHT* *IT* to make a simple Linux-based embedded solution ACTUALLY! WORK!!!
However, by using Raspbian, rather than a Devuan distro, it's more likely to support "bleeding edge" hardware that plugs into the RPi, or that was my thinking...
[fortunately only a few hours wasted out of hundreds, so it's hard to say if my decision was in any way "bad", though it was the safest path in my opinion]
I! *HATE*! SYSTEMD!!!
(nuke it 'till it glows, then SHOOT IT IN THE DARK - see icon)
I got to agree. I have FreeBSD and Devuan everywhere, except at work (where all the Linux boxen are systemD, and virtualised on Windows to provide stability and reliability), and the raspberry pi's, because raspbian uses it.
Needless to say, Like you I spend a lot of time fighting systemD on the pi's (*) to stop assuming what I want. That is a core problem with systemD (one of many).
I have been trying to switch to FreeBSD on the pi, and it works well, but a lot of the raspi tools are by default written assuming Linux. The good news is Devuan now supports the pi's as well, but their support lags behind raspbian.
It is good that Linux is still flexible enough to not have a hard dependency on systemD, so you can use other systems (or no system at all. I have written my own init programs for embedded systems in the past).
However I wonder how much longer that will be the case. As systemD absorbs more and more, like the home directories (WTF?!), it will get harder to use the kernel without it. Even Devuan has to use systemD "shims" that handle things systemD has subsumed to the point it is hard to detangle them, and I suspect that will only get worse with time.
(*) If I am honest, I spend a lot of time fighting it on servers, and on desktops as well. Generally trying to do anything with systemD is a long fight that only makes configuration/admin longer, and generally assumes it knows better than me (which is deeply irritating). Great if I bill by the hour, but otherwise a waste of life and nerves.
You're very, very right here...
So let's repeat it, just for clarity...
As systemD absorbs more and more, like the home directories (WTF?!)
"As systemD absorbs more and more, like the home directories"
Like 'The Blob' from that movie in the early 1960's (*pop* Beware of the blob it creeps, and leaps, and crawls, it's crawling up the walls... etc.)
Absorbing home directories - that *ENTIRELY* *BREAKS* the beauty of the common desktop model as it is *BEFORE* that happens. Additionally, there's the fact that '/home' can be a) on a different partition, b) EASILY backed up (and restored) using tarballs [including user preferences], c) can be CLONED ONTO MULTIPLE SYSTEMS AND VM's using those backup tarballs, *AND* d) is NOT a monolithic "the Registry" like Windows. And standard directory names and links do NOT have spaces in them!!!
These are HUGE advantages of the way Linux does things TODAY, as compared to Windows [let's say]
And I can (unfortunately) see the systemd "developers" going off into the weeds to "solve" this...
Even a stopped clock ...
The good old Italian[1] phrase "punto e basta" springs to mind..
[1] My dad worked for an Italian phrama company from 1969 until about 2005. He spoke fluent Italian (and Hebrew, some Hindi and some Russia) with a pronounced MIlan accent. That phrase was one of his favourites. And it has nothing to do with Fiat cars..
This post has been deleted by its author
The OpenBSD installer is a small (optionally large) iso image. It takes about 2 minutes to answer the installer questions and 10 to download and install all of the o.s.
It works with Dell desktops. It has an auto or manual update feature for patches. It has a single-command auto upgrade to the next release (well, you have to "pkg_add -u" to update packages. ) Altogether about 18x better than windows.
And by "large" I mean 450MB. Linux Mint is 2GB. And yes you should install all of it.
OpenBSD is a brilliant integrated operating system provided it matches your use cases. It's great at networking and firewalling, less so as a desktop.
I'm toying with moving to NetBSD as a general desktop once 9.0 comes out. 9.0RC1 has a new hypervisor (in progress), ZFS has reached a state where it looks to be usable on a daily basis (although ZFS on root isn't implemented), WINE has been updated, it has a decent implementation of the Linux DRM interface so modern graphics cards work well, and it uses classic Unix commands for administration rather than the different ways FreeBSD. It's definitely a bit of a quirky hacker OS.
I've been using ZFS with FreeBSD for quite a while now (years in fact). I have 2 systems that are "all ZFS" that are my priomary desktop and backup desktop systems.
I put ZFS on 2 hard drives on 2 systems years ago. One was a workstation, one was a server. Occasional scrubs revealed that the hard drives were going bad, so I replaced them with no apparent data loss, while it was still possible to clone the drives using tarball-style backups.
So yeah ZFS is extremely good at automatic data recovery (especially if you enable replication on critical mount points) and error reporting. It also supports compression (I typically compress everything I can).
As for error handling, you'll potentially get things reported to you that never otherwise would with other file systems, at least from my experience, so you can do something about it before a REAL problem happens.
I don't know about the stability of ZFS on Linux, but in FreeBSD it's been _exceptional_ for quite a while now.
What's right for the kernel programmers isn't necessarily right for the operating system users.
Despite being a programmer, having used Linux since the days of 0-numbered kernels and Slackware, and not being afraid to get my hands dirty in bash or anything else, I have absolutely given up with systemd. It either works or it doesn't, and when it doesn't, I stop caring and use something else. Diagnosing it is ridiculous, it interferes with everything, it has complete apathy to my desires (e.g. if I want to use another DNS resolver), and is just a blackbox that interferes in every possible system.
And along the way, I've lost simple abilities. Like the ability to choose the name of a device in /dev/, for instance. If it's a network card, I can rename it. If it's anything else I can't. And that's been put into the kernel and can't be changed. So when you have a device that appears as /dev/somethingrandom, the best you can do is symlink it from what you want it to be (and god help you if there's already something else in that name, because you can't overrule the kernel).
Hell, it takes me minutes to find relevant logs, find out why a service didn't start, etc. whereas it used to just be starting the service and watching that name in /var/log (even via a recurring cat or other basic tool).
I tried to find out how to make a systemd service the other day, I literally gave up and did it via the old backwards compatibility with runlevels.
Just because it makes your life easier does not mean it makes anyone else's. Just reminds me totally of the whole "cdrecord must have a full scsi path and you can't use, e.g. /dev/sr0 even if that's where the device lives" shite that plagued that bit of software for no sensible reason. I'm sure it make the author's life easier, but everyone else was just screaming "I just want to burn the damn CD!".
Systemd is a damn nightmare of usability, readability, capability and culpability. It's improved absolutely nothing my end, and destroyed all kinds of things that were working perfectly fine. I'm sure if you have a thousand services spread across dozens of machines it makes something simpler, but if you're just a guy with a personal computer it's a fecking nightmare from every angle. And literally *every* advantage it gave could have been done the old way, with the same kernel functionality (e.g. cgroups) exposed to the bash shell to let it happen.
Systemd solves no problem that I ever had, but is such a problem in handling that just the name is enough to make me give up now.
Hell, I tried to make a little gaming box the other day. Guess when I realised that there's literally NO WAY to move another device to become, say, /dev/input/js0 when a program is specifically looking for that path if a kernel driver has already claimed it. Literally, your device naming order depends on device discovery order and is pretty immutable unless you want to go hard-moving dev nodes around after every single boot.
It merges kernel and user-space, it destroys the init process's replayability, it doesn't do anything any faster, or any more securely, and it literally throws a paddy if you want to have anything other system systemd's named in place (plus a million and one other "essential" daemons that just seem to take over existing programs while providing less functionality and flexibility).
Honestly, I was never so disappointed as to hear that the Debian project voted to keep it "but explore alternatives" recently. It's a heap of junk.
Well, with zero proof because I just bang around in the shell now days, there WAS a way to define device order. I once had to make sure the onboard audio came up before the audio card (XLR related) and it was doable with systemd.
But yeh, I don't fuck with systemd anymore because it feels like a OS inside a OS, definitely NOT that POSIX feeling you'd expect. In a way, with how popular Linux is today, systemd makes all UNIX books obsolete.
"In the same way that emacs is an excellent OS, lacking only a decent editor?"
Funny!
I remember when Emacs used to be thought of as big. Now it's just tiny, compared to a single random web page displayed by <pick any browser>.
Emacs was great before windowing systems became common, giving you multiple windows into your document. Come to think of it, most apps today are useless at doing just that.
I still have the emacs key commands programmed into my spine.
multiple windows - yeah, multiple tabs are a bit better. I've been using pluma (and before that, gedit the gnome 2 version) to edit code for quite a while now. Pluma finally solved the "spaces at the end of lines": problem and now is a pretty useful editor, does code element 'color tagging' and things like that. Not perfect, but usable out of the box for that purpose.
The beauty of it: if you have a headless embedded system running Linux, and you want to edit code on that system, you can install pluma [just don't bother with an X server] and other X11 GUI tools, enable TCP connect on your workstation [must run Xorg, not Wayland, for this], and then in a console (serial or ssh) to the embedded system, "export DISPLAY=workstation.LAN:0.0" and on the workstation, "xhost +embedded.LAN" and then you can run pluma from the console and it displays on the workstation.
On a related note...
I believe that X11's built-in method of doing 'remote desktop display' *IS* the SINGLE! BEST! FEATURE! of X11 because it was literally designed for that VERY purpose! And on a desktop, it'll leverage multi-core to do it.
But you KNOW that if systemd could STOP that ability, and force you to use WAYLAND, it WOULD... (all too many distros make it unnecessarily difficult to set up the X server that way, from [ab]use of display managers to just obfuscating where all of the magic config files ended up)
NOTE: on FreeBSD, I have '.xserverrc" in my home dir that says "exec Xorg -listen tcp". On other systems (like Linux) you probably have to muck with /etc/X11/xinit/xserverrc and/or config files like /etc/slim.conf to remove the "-nolisten tcp" and/or change it to "-listen tcp" but if your distro isn't insane, it should be easy enough to do. Just make sure you block incoming port 6000 at your firewall.
Also possible with some trickery in kconfig. If the onboard audio uses a different driver than the card, then bake its driver into the kernel and the card's driver as a module. The built-in will be detected and setup shortly after the kernel starts booting and the card would need to wait until /lib is mounted to load its module.
They are not concerned with "being unix" - it's a new black-boxed OS in it's own right... As time goes on, the whole system will become more monolithic, and less modular. You won't be able to pick and choose which DNS server to use etc. - it will all be baked in.
I'm not commenting on security or stablity, but from an admins point of view, it will be just like another sort of "windows".
Linux/systemd is as much "Linux (the whole os)" as Android is.
If he couldn't figure out how, there is something wrong.
[Unit]
Description=
After=multi-user.target
[Service]
Type=simple
User=0
Group=0
ExecStart=
ExecStop=
TimeoutStopSec=20
KillMode=process
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Fill in the what you want to start and how to stop it and give it a description if you want.
Not rocket surgery.
It isn’t that it’s hard, it’s that it’s *unnecessarily* more difficult than sysvinit. Why do we need unit files? Parallel startup tasks. Why do we need parallel tasks running at startup on servers? I’m not sure. Progress? It’s far easier & faster for a server admin to ln -s a script into an rc.N directory, than to Google the unit file syntax (or, arguably, find another service that requires a similar startup profile). Are unit files demonstrably more maintainable?
If a valid reason exists for parallel tasks, is there not a better-architected way than using a massive, ever-encroaching, 1.3M-line behemoth to get that benefit?
> If a valid reason exists for parallel tasks, is there not a better-architected way than using a massive, ever-encroaching, 1.3M-line behemoth to get that benefit?
The irony is the old Linux init system supported parallel tasks since 2004 (I know because I used Gentoo back then, and it was a big feature for "fast boot times"). As I mentioned before, I find systemD boots slower (if it boots at all) than my Devuan box.
Seriously. SSDs etc... have made boot times fast enough that nobody cares about the efficiency of the init system anymore.
I still maintain that the number of people who cared about fast booting from cold was minuscule. Most Linux systems were servers that are so rarely rebooted that nobody cared if it took a few mins when it happened (especially as it could take a good 10 mins for the hardware to be probed, arrays spun up, etc...), and on desktops Linux has supported suspend/hibernate for longer than I can remember (15+ years I think), so you did not need to reboot often there either.
OK, so one possible example.
In traditional Unix/Linux you list all the filesystems you want mounted at boot time in the /etc/fstab file. At some point in amongst the startup scripts someone runs a mount -a or a mountall and all your filesystems get mounted. What happens if one isn't there yet?
In the systemd view of the world early on something reads the fstab file and generates a set of mount units with a dependency on device units. When the devices are found udev processes them, in the systemd world a flag tells systemd-udevd to make a device unit associated with the device. When both the mount unit and the device unit are there the dependency is met and the filesystem gets mounted. This allows for a certain degree of asynchronous mounting if the storage devices are starting at the same time that the servers are starting.
Now, there's some dumb stuff with this, like needing to kick systemd to get it realise that the fstab file has changed.
There are lots of things I don't like about systemd. Like you I don't see the need start a lot of the services at boot time in parallel. I don't like its spreading its tentacles in every direction. But I've come to quite like the idea of having one central manager for all sorts of different services. But please for the love of all we hold precious can we not have PID 1 having such a large attack surface.
Well, in all 20 or so of my systems, systemd has always had issues with mounting anything remote via /etc/fstab.
Leaving out the travails in the first bunch of versions - all of which required workarounds that themselves quit working on a subsequent version of systemd....requiring a good bit of backing and forthing to implement some new one which wasn't always the same (mint vs raspian for example).
At this point, a remotely mounted NFS share (so I can access a huge nas from all my machines and not fight with samba's permission issues) - slows down booting on any of them while systemd figures out that I meant it when I said background this in fstab.
And then, god help you if you've unmounted something manually and then try to reboot - be prepared to wait some minutes while systemd tries over and over again to unmount something that's already unmounted.
It's even worse if that thing is mounted over a network and for whatever reason connectivity is lost. Be prepared to manually cycle power.
You don't have to guess, you see the "waiting on a stop job for ..." in the splash if you hit esc while wondering why stuff appears to be hung.
Note - all this worked flawlessly and seamlessly before sytsemd, and unlike systemd, didn't wait for disks on the share to spin up from a sleep state just to boot.
And Poettering's take? "Don't mount remote shares at startup, WONTFIX".
At this point, a remotely mounted NFS share (so I can access a huge nas from all my machines and not fight with samba's permission issues) - slows down booting on any of them while systemd figures out that I meant it when I said background this in fstab.
Or wait minutes for the timeout (on a perfectly available share) only for it to finally come up without any of the NFS shares mounted anyway. No amount of faffing with fstab options has yet managed to fix this on our systems.
I don't think the device naming weirdness is down to systemd, that's down to the kernel initializing stuff in parallel. So if you've got multiple disk interfaces they're being enumerated at the same time, so it's anyone's guess which device will be sdWhatEver. You could see issues in pre-systemd boxes too, Linux doesn't natively have persistent device naming, hence the pre-systemd udev rules to make /dev/disk/* and the similar arrangement for tapes etc.
I must admit I've not tried changing the names of disks with systemd-udevd just used symlinks. If multiple udev rules generate the same symlink then the one which remains at the end is the last rule to fire, so you'll see this for multipathed disks is if you compare /dev/disk/by-id and /dev/disk/by-path, and RHEL7's (with systemd) and RHEL6 (without) behave the same here.
BTW, I'm not trying to defend systemd here, I've got enough gripes against it.
But udev has been subsumed into the systemd project. It ain't part of PID 1, but they've done things to udev so that some things which worked fine in previous version no longer work in systemd-udevd.
One of the things that I don't like about systemd is that lots of things which have nothing to do with PID1 or even the general idea of an all purpose service manager have ended up inside the systemd world, udev being one such thing.
I removed udev once it got eaten by systemd.
In its place I use mdev, which is one of the many faces of busybox. I know busybox smashes the rule of "do one thing well" but it's still small, and it works. In my case, there aren't many things I need after boot. Automounting USB drives; changing the optical drive for a hard disk in the dock of my venerable Fuji; changing a mouse or keyboard.
I did need to add some modules to the set loaded at startup, and I had to change some device permissions and ownership (in rc.local) but everything is stable and trouble-free.
the GREAT pleasure of fsking about in Lennart Poettering other hell on earth creation "PulseAudio".
Think systemd , but for sound, but probably be part of systemd in some point in the future ...
I think he really is an Employee of MicroSoft in disguise ... or a total asshat .....
"if they just made OSS work like it does on BSD systems.."
It wouldn't be the first thing ported to L from BSD. I'm pretty sure netfilter originated on one of the BSD's as ipfw. The code just looks TOO similar in too many ways... [I did netfilter kernel modules for a $CUSTOMER a decade or so ago, spent a lot of time in the low-level guts].
But yeah it wouldn't surprise me in the least to have seen contributions from the same devs at the very least.
And so it could be with OSS. That'd be awesome, actually! [I *love* OSS for sound on FreeBSD, it's solid and has been working VERY well for ~10 years or so as I recall, no serious problems on my end when it first appeared, and no observed problems at all for nearly a decade].
Mozilla, Google, take notice please: Direct OSS support from your web browsers!!! Just make it a compile option, at the very least. [as I recall you only support pulseaudio on FreeBSD]
OSS on FreeBSD has supported mutliple mixed virtual audio devices (and hardware-provided ones) for as long as I've been using it, which is over 20 years.
[ https://www.freebsd.org/cgi/man.cgi?sound ]
Linux did use OSS, but their implementation was buggy, and couldn't do virtual audio device mixing.
Instead of fixing it, they wrote "the new shiny" ALSA (The "L" standing for Linux just in case anyone still thought that linux users cries about MS software not being "cross-platform" actually meant anything other than "it should run on linux.- don't care about anything else!"
And so, we get the sitution where Mozilla etc. drop OSS for alsa, or pulseaudio etc. and so FreeBSD has to support these unnecessary gimmics just for sound to work..
I think he really is an Employee of MicroSoft in disguise ... or a total asshat .....
The former would be difficult to prove.
The latter .... not so much.
He's the new millennium's answer to Joerg Schilling (if you don't know who he is then look him up - Poettering clearly took asshattery lessons from him)
And yeah, PulseAudio is an absolute fucking abomination.
Oh, yeah. That's the one that silently breaks if you ask it to record more than two audio channels, innit? Great fun for anyone trying to record a concert, something Linux used to be able to do but can't anymore (go ahead, tell the audio engineer he has two channels. You might get a heavy piece of machinery on the head in short order).
I'm pretty certain that MacOSs kernel is derived from Mach, not from the BSD kernel (although I believe that it's no longer a true mrico-kernel implementation, but a bit of a hybrid between micro-kernel and monolithic kernel).
They have a large part of the BSD commands, but there's not that much difference between those from BSD as from GNU.
As much as I like using Linux for anything, I really think you should not be using it in this case. MacOS,
Cool -- can I get source code to MacOS and its programs to verify Apple hasn't snuck in a backdoor somewhere, that I'm not being tracked, etc? Or if I need to add a feature I'm free to do so? If I don't like something in the OS I can remove it and recompile the OS, then install that version on my hardware?
No?
Then I'll stick to ALSA on Linux, which works very well. If even that breaks at some point in the future, then I'll hold my nose and fix PulseAudio, though I may not like it, it's still the lesser of two weevils here. No need of course to make that patch public, since I don't really want to deal with the Pottything and the naff code section, complete with fixme notice, has been untouched for years...
I think the plan was for PulseAudio to handle the entire sound stack, but when they found that it was difficult, and that there were many different devices to handle, the scope was reduced, so that it's just a layer on top of ALSA, and further development seems to have stalled. One thing you can do with PulseAudio that you can't with ALSA itself is to adjust volume per process. So that if you are listening to two things at once, you can... actually, why would you do that?
I've always disliked ALSA in that it's stuck on the side of the kernel source, and the configuration syntax is obscure and illogical. However, I've learned to live with it. You can do some powerful things, such as routing or replicating audio, which you might expect to have to use another daemon to do (I mean jackd).
Your incoming email chime is so loud that it drowns out the movie you're watching.
The music you want to play in the background means you can't hear what the software you're using is doing, or the game you're playing.
I hate to say it, but it *is* potentially useful - which is why you would think alsmixer actually acted like a mixer and let you change levels of all playing channels out of whichever output you would like. It does the latter, not the former.
P.S. Windows has had per-process audio volume control since... what? 7 / 8? You can then make sure that your MP3 is louder than your game, that you can have the volume up to hear alerts but don't get deafened by every window click or program startup jingle or Chrome notification in the world, and you can actually choose WHICH programs you want to hear from, ever, at all, in any way.
when they found that it was difficult, and that there were many different devices to handle, the scope was reduced
Yep. I think Lennart came to that conclusion, then said 'works for me' and stopped doing anything to make it work for others as well, all the while pattimg himself on the back for a job well done and pushing the broken Pile Of Software into almost every Linux distro..
Starting to see any parallels already with systemd?
Yes, but for everybody that has to actually use Linux in the real world systemd is often worse than what came before it.
As an experienced Linux SysAdmin I've had to come to terms with the fact that systemd is here to stay, and have had to learn to use it, and it does have some very good attributes. But, it also has it's flaws, and often those flaws are ignored by it's proponents, homed being a prime example. It solves a problem with security, and portability, of home directories. But it also breaks ssh keys, and rather than acknowledge and accept this state, and offer any concessions or work arounds the answer is "well don't use it then" ignoring the fact that systemd is being deliberately developed in a way that makes it difficult to not use. New features are added, and tied closely to systemd, then downstream products are encouraged to use these features making it difficult to use alternatives.
I want to be happy using systemd, I like the ease of creating new services over having to write init scripts (which can sometimes be tricky), and holding onto the past is often counter productive. But I run Linux Servers, and systemd isn't appreciably faster than sysvinit for booting, and parallel service startup creates problems that never existed in the slower sequential start up of sysvinit.
This would be easier to take if there was any indication that the developers or proponents of systemd gave a shit about these issues, but hey, if it solves problems it has to be good right?
...has not actually agreed that systemd is the proper solution.
Don't cede ground on the back half of this gross generalization. Greg Kroah-Hartman doesn't speak for anyone but himself, pending an unlikely expletive laden message from Mr Torvalds.
No surprise that one of Lennart's apologists that is still on the kernel team is, like Lennnart, having a hard time grasping things like basic logic and rhetorical fallacies.
Also don't cede the false argument that if you don't like them ruining the parts of the OS that other people use without asking them first, that you are free to give up and use something else.
If 40 people decide to throw a party and put together a DIY bar, for the duration of the party it is a community resource. If someone dumps grape Kool-aid in all the liquor bottles, they shouldn't be surprised if the rest of the party gets upset. The central issue with the Pottering school is that they don't engage with, understand or respect the concerns of the community, and constantly pose as if they are the victims when someone points out their missteps.
Problem is, we have large Linux server farms. Perfect use for systemd, right?
Fast forward to post-systemd migration of most VMs (forced "upgrade due to distro changes). On each VM host, a simple bash script has to run now that didn't before. One that pings each host and does a literal "kill -9" on the VM process if it's not responding.
Why?
Because systemd randomly decides that it won't be shutting down today. No logs, no reason, just hangs. Randomly. Takes the network down and just sits there.
init never did that. When you issued a reboot or init 0 the box was going down, one way or another, unless the hardware was busted.
And I'm not even going into the fun of "standard process to start this machine is to enter recovery shell, rerun the mount command, and exit.". Why? Who knows. It's become easier to apply Windows style workarounds to the systemd monster than to fix it as we used to do in the init days.
The true unholy trinity is systemd, pulseaudio, and wayland. I think I might go over to the BSD side if that happens.
Preaching to choir there.
I'm no fan of systemd, and am well aware of it's many, many, flaws. Not least of all the most important aspect of server startup isn't speed, which systemd isnt actually all that good at, despite being one of it's early selling points, it's stable, repeatable, consistent, debugable, startup. Which systemd does not do.
But denying it's advantages is also not helpful.
There were nearly 75,000 code commits to the kernel during 2019 ... the top contributing individuals were Linus Torvalds, with 3.19 per cent of the commits ...
That's 2392 commits over the year, which is one every 3 hours 40 minutes, day and night with no holiday. Impressive, but not a patch on
Another point of interest is that systemd, a replacement for init that is the first process to run when Linux starts, is now approaching 1.3 million lines of code thanks to nearly 43,000 commits in 2019. Top contributor was not systemd founder Lennart Poettering (who was second), but Yu Watanabe with 26.94 per cent of the commits.
That's 11,584 commits, which is one every 45 minutes with neither sleep nor time off. Wow.
Bullshit, Greg, and you know it. if it was that easy, devuan wouldn't take two years to do (with some fake systemd binaries still needed to run).
What about hardcoded dependancies in udev? How many things I have to replace to jus get rid of systemd?
The amount of damage you've done with your support for systemd is only comparable to amount of great work you've done in kernel (USB, kernel releases, etc.), Greg!
Why don't you take a little break, go build another wooden canoe or something and think clearly about things.
In my opinion, systemd is a virus.
There is a striking parallel between systemd in Linux and the registry in Windows OSs.
Systemd in Linux brings back memories of my difficult transition from W3.11 to W95, with the end of the familiar and usually well documented *.ini files I understood (and could tweak when things went foul) to the obscure workings of *the registry*, which took me a few years to get a minimal hold of, basically through unending trial and error grief.
After a few years (W95 to XPSP3) I understood what it was all about: a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the OS with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what was going on inside your box/the OS as it became more and more obscure.
When systemd appeared in Debian (I used Ubuntu) and saw what and how it did it, I realised that systemd was nothing more than a registry class virus which was infecting the Linux ecosystem at the behest of the developers involved and the complicity or indifference of most of the others.
So I moved from Ubuntu to PCLinuxOS and then on to Devuan.
Paranoid?
No. Just strongly convinced that there are people both inside and outside IT that actually want this systemd takeover to happen and are quite willing to pay shitloads of money to push that agenda.
Poettering is undoubtedly the prime suspect but surely not the only recipient.
I don't see this MS cozying up to/barging into Linux and areas of influence (GitHub, WSLinux (!), etc.) in various ways as a coincidence: these things do not happen just because or on some senior manager's whim.
What I do see (YMMV) is systemd being a sort of a putsch to generate a convergence of Windows with or into Linux, which is not good for Linux and will be its undoing.
But there's really nothing new here: it's just the well known MSbrace at work.
It's been going on for more than 30 years, should anyone be surprised?
I think that it would probably be a good thing that the awesome manpower behind all the Linux projects scattered out there team up to find common ground instead of everyone of them wanting to do their own thing while mindlessly waving the flag of choice, a flag which they are set to lose if they do not react fast enough.
The writing has been on the wall for a long time now.
And it's well past the time to heed the warning.
O.
Unsurprisingly missing both the point and the real parallels,
The registry is an poorly or undocumented dumping ground, which complicates or blocks management, integration, recovery, and reliability. The surface level windows tools couldn't even process Unicode strings that could be still be written to the hive (a common copy protection hack for license key info back in the day).
Plenty of shots to take on the original post, but the classic "it works for me" won't cut an air biscuit. Possibly because you are interacting with that mess in a superficial way that has shields the the sprawling horror that lies below the surface.
As to the OP, I'm not expecing to see Pottering's devil baby becoming "Winux" anytime soon. They are just examples of a dumb antipattern and bad project management. They should be studied, taught, and avoided.
Unsurprisingly patronising and presumptuous of others knowledge. My superficial interactions have paid the bills for thirty years and have never caused the gnashing of teeth and railling against the system that seems a requirement of working with Linux.
And after i went out of my way to be polite too!
you miss the point with regards to "the registry". I blame "the registry" for the following windows (unsolved) problems:
a) slow application startup
b) slow load times for 'file open' dialog boxen
c) delays during bootup
d) why does it take 20 minutes to create a new user in Win-10-nic? THE REGISTRY!!!
polluted registries slow EVERYTHING down. The POSIX sensibility of every application having its OWN config file, located in ~/.config or ~/.application-name , makes MORE sense. Sure, PRIOR to this 'registry thing' it was always an INI file in C:\WINDOWS (which really should NOT be user writable) but it does NOT need to be in C:\WINDOWS if you have a "user home directory" and that's the entire point here with the POSIX way,
POSIX does it right, WINDOWS DOES IT WRONG, and we do NOT need a "systemd" to MAKE LINUX DO THINGS THE WINDOWS (aka WRONG) WAY !!!
Obviously you never had to deal with things that checked to see if a registry key was *absent* and changed behavior based on presence alone. So in half the cases, searching for it means nothing - not being there IS the information.
And knowing what to search for even if it is there wasn't always straightforward.
"strongly convinced that there are people both inside and outside IT that actually want this systemd takeover to happen and are quite willing to pay shitloads of money to push that agenda."
a) they FEEL (not THINK) that it is "better", and their ARROGANCE demands they CRAM IT INTO OUR BODY ORIFICES whether we want it or not, without the benefits of anything even remotely "slippery"
b) they did NOT read Arthur C. Clarke's "Superiority" or they did and were confused by its conclusion...
c) they have a hidden agenda in which systemd becomes "the new windows" and they can THEN inject adware, spyware, online licence activation, DRM, subscription licensing, ... [and crowd out the non-systemd-Linux distros and BSDs and Apple for NOT having it]
d) all of the above
Your position = Weaksauce
This is a classic deflection and re-frame that systemd apologists flood discussions with. If you can't successfully defend the indefensible, then claim it's all a matter of taste, and accuse the other side of being mean when the other side raises real issues.
"It works for me" is basically admitting defeat. The people screaming about the real issues with systemd deserve to have their concerns heard, and ADDRESSED. They are screaming because, despite being stakeholders in the distro's that have been impacted, those concerns have been ignored over and over.
The problems that Systemd created and exposed can't be reduced by tools Simile or Analogy to a matter of taste.
No you get a superficially cheaper product.
I'm sat here using a laptop that really needs a new battery (I just don't use it "portable" enough to justify the cost), and has had RAM and storage upgrades - allowing me to keep using it for a lot longer than if it had soldered in stuff. So your "cheaper" translates to "have to shell out sh*tloads of extra money for a new[er] laptop".
I also have a mobile that I'd really like a lot more storage in. It's not upgradable, so I either have to live with it, or shell out for another phone - paying manufacturers massive markup for a bit more soldered in flash rather than swapping in an industry standard module.
"Distros have adopted it because it solves a problem for them."
Most distributions have adopted it because the majority of them are based off either Redhat or the freeware version (CentOS? Can't remember - I haven't used anything Redhat for a long time).
Others (I'm looking at you SuSE) have done it to fit in with what Redhat are doing or because they use Gnome which has been infected with SystemD and it takes a positive effort to disinfect systemd from the dependencies.
So, we just agree now that systemd is the way to go? And downstream distros have what choice, exactly?
Just checking if flatulence intake is at maximum, yet.
"Android doesn't use it because they use other things"
I am stunned by this logic.
This is why we can't have nice things.
That's really pretty impressive considering I don't think I've ever seen a program belonging to systemd itself crash. I can tell they must have very strict testing standards. I may never figure out how to get systemd-networkd to play along with the other network autoconfig utilities that invariably come with every distro, but it sure beats editing init scripts and cron jobs and dealing with every daemon's logs and pidfiles in each ones own special way.
journalctl is a godsend particularly if you don't care about any log messages older than 10 seconds and/or are running everything off flash storage where if you're actually writing all those log messages out to disk, it will wreck both the performance and lifespan of your disk
And, if you do happen to find a particular enjoyment in editing init scripts, it has some pretty good backward compatibility with those too; I still have plenty of init scripts just I use systemctl to start stop enable and disable them now instead of that 'service' contraption.
Because systemd actually caused multiple root exploits, the arbitrary changes in the logging system required hundreds of downstream projects to have to do major re-writes because the systemd team didn't care about maintaining backward compatibility (a Poettering hallmark). Many of those people were feeding that log output to other processes, and care about much more back history than the last 10 seconds. Journalct also complicates searching log output.
Your point on the write load is not a trivial one, but it isn't a blanket justification to systemd many failings and questionable design choices. (and the write loading is solvable by less extreme measures).
Systemd also broke many of the standard system tools that have existed from the System V wayback, and didn't replace them all with a working equivalent. The team than stubbornly refused to acknowledge that was a problem or address the issue by fixing the problems they caused.
Is this meant to be trolling?
“I use systemctl to start stop enable and disable them now instead of that 'service' contraption”
Systemd has that stupid “Unit file” thing that *complicates* writing services. You don’t simply “use systemctl”... before, you could just ln -s them into an rc.N directory.
Not a fan of the implementation it solves some things, complicates others and for me personally has made more work than it should have. All fixed now but pain was involved.... How its been used by Debian has at times been very frustrating, which is their fault and not that of systemd.
The principle however I can get behind, a secure layer bridging kernel to userland providing a standard way to provide system configuration, at least that is how I see what it should be.
My hope is that at some point its functionality gets abstracted and documented in the abstract which may or may not align with what systemd is actually doing. With that abstraction defined however others can start producing their own modules for what in theory would be a drop in replacement. Don't like how systemd-resolved is working on your system? then try bsd-resolved or debian-resolved.
The biggest ongoing issues with systemd are the lack of modularity and dependency sprawl.
It spreads like kudzu, engulfing cleanly isolated processes, and choking them out by making the rest of the system incompatible with them.
If it had been developed to Unix principles you could part it out for a compatible version, and it wouldn't blob together so many functions into one bowl of pasta.
system V method was VERY secure, actually. It was easy to see what started (S## script symlinks) it was EASY to see what was stopped (K## script symlinks), and it was EASY TO READ THE SCRIPTS [and create your own, or modify the ones that were installed to meet your needs].
Good luck with doing ANYTHING THAT SENSIBLE with the hideous abomination known as "systemd".
"Everybody who has ever worked at that level in the operating system has agreed that systemd is the proper solution. It solves a problem that people have. Distros have adopted it because it solves a problem for them.”
Who’s “everybody”? What problem(s) does it fix that a more modular, do-one-thing-and-do-it-well approach wouldn’t have?
I could be wrong, but it certainly seems like most users are either not happy or indifferent with systemd’s black-box implementation. I can’t understand why it’s been so widely adopted.
and about as cool. Lenny P, like many dinosaurs from his era, also seems to lack the basic wiring to understand the idea that the masses enjoy and expect a degree of informed consent in this day and age. He is a super prolific programmer, but he needs to take a keyboard break and get out of his echo chamber for a while.
He reminds me a little of that celebrity chef from Berkeley, only people aren't calling him out for crossing the lines, because they weren't race or gender based lines. A lack of sexism/racism dosen't make his arrogance or lack of concern for the community right, and he has no grounds to play the victim when those his actions impact complain.
Funny, ‘cause I’ve tended to think of “Lenny P” as a narcissistic millennial, who doesn’t care about “dinosaur” stuff like backward compatibility or maintainability.
Maybe we’re both wrong: perhaps he’s just a human being who has poorly architected a piece of software that has overzealously been adopted without the best interest of users in mind...
...Nah.
When systemd was being discussed, the idea was to not force carry a large FOSS shell (emphasis on FOSS btw) for handling "init". The mantra was that we needed something simpler.
1.3 million lines of code in systemd.
365 thousand lines of code in bash.
Just something to thing about.
"Everybody who has ever worked at that level in the operating system has agreed that systemd is the proper solution."
Total, complete and utter bullshit.
I know plenty of people who have been developing un*x kernels since before BSD was called BSD. Very, very few of them consider the clusterfuck known as systemd to be a good idea. For anything.
There is a reason that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else is a vanity project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble. systemd is b0rken by design and implementation.
... also need to take care of the orphan processes. There is also a question for some kind of glue to help with device initialisation, file system mounting and service dependencies - was not needed before but apparently kernel maintainers are expecting this from PID1 today. Very sad.
Couldn't have put it better myself! I'm not a programmer, but the occasions when I've had to do battle with systemd (and pulseaudio, come to that) have driven me to distraction!
All my personal machines run Slackware, which is systemd-free. Even someone like me, whose programming knowledge is over 30 years out-of-date, can understand it, and it rarely causes me any issues. However, I also maintain computers for my wife and sister-in-law - both technophobes - so for them I install Mageia which has the dreaded systemd. I do this because Magiea has a semi-automated update system, that flags up an icon when updates are available. Click on it, agree to the update, and it all happens automagically, without having to get me involved. Most of the time.
When it doesn't work, I find myself having to do battle with systemd. Frankly, anyone who can design a system where essential log files are only readable if the system is running (ie NOT plain text!) - well, boiling in oil is too good for them!
I note that within this thread, virtually no-one has a good word for this ghastly abomination. Even those who can see some justification for it also seem to conclude that it doesn't justify the issues that surround it. When I find that my opinion of this pile of steaming excrement is shared by many who are far more proficient with operating systems than I am (or will ever be!), it makes me feel slightly better about my own inadequacies!
A suggestion...
You might consider using MX Linux for your wife/sister-in-law. Based on Debian/antix/"with help from mepis developers". MX supports sysv OR systemd, with sysv the default. Of course with sysv there are those f'ing systemd 'shims'...
I support (remotely - VNC) several senior citizen technophobes, and I strongly dislike that POS, systemd. I switched them to MX from Linux Mint and they are all happy users.
At one time I was a 'crunchbang' user, and when CB went away I started using Devuan/CrowZ. Because MX worked so well for the technophobes (and they easily/quickly adapted to MX), I decided to give MX a go, using my preferred WM 'openbox'. Works great... Very nicely done distro and now my main/daily driver.
At first I thought MX might be cluttered (bloated) but performance is excellent and it has a lot of handy utilities/tools, and was easy to install and set-up as I prefer. 'openbox' installed easily and was easy to configure.
But....
NO SYSTEMD... YES!!!
I must feel that I need to comment on Mr. Greg Kroah-Hartman !!
ANOTHER ASSHAT.
The year, 2002 and I'd just gotten my shiny new Sony Clie, but There was no support for it.
I joined the CLie users group and everyone was having the same problem
I then research and following Mr. ASSHAT's articles I updated the header files to now include the
Clie in the USB stac. I posted what I did to the CLie users group and everyone was happy.
I sent my change request along with the source to Mr. Hartman and explained I knew nothing about the process of getting something included in upstream revisions and could he please include them for me.
A few days latter I got a email reaming my out for what I had done.
A few weeks latter a USB update came out with the EXACT Clie changes I had made, but with all the "updated" Copyright (Gpl of course) with my name being removed.
Some of these guys are PURE EGOTISTICAL DICKS !!!!!!!!!!!!!!!!!
Linux is getting ever more windowsy, and systemd is a classic example. However the user community has changed. I started on Slackware when everyone was delving into and tinkering with Linux internals, but a recent visit to a Linux user group found everyone just talking about high level things they were doing taking the OS for granted. The only specifically Linux-related aspect was the rude comments about Windows. So I suppose the user base dictates the way forward, but as a community we're losing the metal level skills that contribute to real progress.
A few honest questions here. Serious answers please.
1. Exactly what serious, genuine problem does systems claim to solve? Is it such a grave problem as to require an approach that violates the UNIX compartmentalization principle?
2. If systemd is so bad, why haven other key personnel of the kernel team spoken up or raised motions against it, particularly Mr. Torvalds himself?
3. If so many people disagree with the direction Linux is taking, why hasn't someone forked Linux itself to remove anything like systemd from the tree and enforced the compartmentalization principle (call it trunix or something)?
Quote
3. If so many people disagree with the direction Linux is taking, why hasn't someone forked Linux itself to remove anything like systemd from the tree and enforced the compartmentalization principle (call it trunix or something)?
/Quote
Debian, for example, has been forked to Devuan.
But there can still be issues (like availability of packaged proprietary blobs) where the developer has concentrated their resources on making dependencies on systemd only. Probably, I suspect, because of the installed dominance in the comparatively mass installed distros based on Ubuntu.
2. Because Linus likes convenience of having Greg as maintainer too much.
3. Forking kernel won't help - just ask Android guys. Forking full os will and devuan did just that.
Problem is hyperscalers are running the show and they like systemd for programmability - no one cares about stability much: so one container out of 1000 will hang, so what?
And other users? One that actually got Linux there it is now? Fought to get it in corporate environment? No one gives a shit about them.
2. Because Linus likes convenience of having Greg as maintainer too much.
Do we all not remember the old Linus, the profanity-laden Linus who stuck to his guns? If he is conceding to Greg at this point, then he's probably already been pushed aside as the root user of this project, all the more reason to fork the kernel (and yes, it needs to be the kernel, before it becomes too thoroughly tied into systemd to be able to make a systemd-free distro--if MySQL and OpenOffice can be forked, why not the Linux kernel into Trunix or something?).
1) It solves the authors ego problems, to answer the first part of your question. The answer to the second part is "apparently".
2) There is no real need for them to speak up. The Kernel and the init are two different things with a clear demarcation between them. In essence, the kernel doesn't give a shit which init is used, never has, never will. This is as it should be.
3) There is no need to fork anything. systemd isn't in the kernel tree (see above). In fact, systemd isn't a part of Linux at all. It is, however, a bit of bloated code that some Linux Distributions use as their init code.
systemd and other inits are (loosely) the bit of code that handles the passing of control from the booting kernel to the fully working computer environment. It is the first process run on the system (imaginatively named "PID1"), and it basically keeps an eye on the rest of the processes as they start, stop, sleep, close, etc. It's kind of an important piece of code. Traditionally, it was a little, tiny thing that did it's job, and did it very well, with little to go wrong.
Along comes systemd. It is designed to handle far more than just the init function. And as more and more bits of the running system are incorporated into systemd (unnecessarily, for the most part), leading to dependancies upon systemd in that code, systemd will become MANDATORY to run Linux. This is already starting to happen.
To me, this sounds foolhardy, at best, and an attempt to take over the entire Linux ecosystem at worst (if the paranoid among us are correct). A power grab, if you will. Probably brought about because the two primary developers were kicked out of kernel development because they don't play well with others, and so are throwing a tantrum.
And that's without going into any of the technical arguments against it.
Clear as mud?
Isn't systemd like Windows services? And if so, then I think it's only fair to consider the systemd framework, sd-bus et al (which I assume maps to the Windows kernel services API) separately from the actual systemd units/services (which are akin to the Windows services themselves). I'm sure there are millions of lines of code in the entire set of WIndows services too - modern OSs do a lot of things for a lot of people.
As a non-kernel hacker, systemd the framework seems very long overdue in Linux: a way of managing interrelated services: encapsulation, dependencies, lifecycle, querying, logging, diagnostics and more.
Surely adhoc log files with random formats, pid files, process locks, arbitrary entries in /dev etc... are not scalable. I don't know about the quality of the systemd units themselves however; maybe like Windows services, some are good and some... less good.
Finally Poettering debunks a number of 'myths' (my quotemarks) here: http://0pointer.de/blog/projects/the-biggest-myths.html - is any of this true? All BS?
This reads very sensibly to me...
It's not clear exactly what the figure of 27.8 million lines applies to, but I assume this is the *accumulated* total of all the commits. If the present source code is 27.8 million lines, then with the kernel binary presently being about 70MB, it would mean that each line of code compiles to less than 2.5 bytes of binary on average - even an assembler source would compile to more bytes per line than that (unless perhaps written for an 8-bit CPU with hardly any ASCII strings or tables, or if it has a huge amount of comment and formatting lines).
As such the figure means very little. I could check out a 100000 line source, change a single line, check it back in 30 seconds later and it would be reported as 200000 lines. With many people working on the code, the figure would mount up very quickly.
I am borrowing Bjarne Stroustrup comment about Java because SystemD behaves the same way.
The proof is to find that it has more than one million lines of code. With that size, it could be a complete operating system. And, several things are being "attached" to its working model instead of being created as completely independent things. These facilities will not work without SystemD.
Then, if you like that platform or if that platform is good enough for your pattern usage, go ... use it. But if this doesn't work in the expected way or impose hard restrictions that you can't follow, then you must find a complete replacement for those more than 1 million source code lines. In fact, SystemD with Linux is more and more similar to MacOS than to UNIX.
In that case, Greg is wrong when asserting that SystemD is "the" solution. I will agree with him if what he say is that SystemD is "a" solution to problems "some" people have. And the main issue here is that if you want to do something very special (the type of things Linux is extremely good at), to dig on those thousands and thousands of lines of code to understand why your solution is not working as expected is a complete waste of time that leads to nothing. But ... you always can replace SystemD, right?
I expect, and pray, that Linux "the kernel" never be hard attached to SystemD. They must be different and completely independent things. And you see, as it is usual with software, somebody in the future will arrive with a better solution to the problems that current SystemD users have and, in that moment, the right thing to do is to discard SystemD as an "obsolete" piece of software without breaking Linux.
A lot of people were mentioning Linux here.
I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, SystemD/Linux, or as I’ve recently taken to calling it, SystemD plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning SystemD system made useful by Redhead Enterprises, Inc., some shell utilities and vital system components comprising a full OS as defined by POSIX. All the so-called "Linux" distributions are really distributions of SystemD/Linux.
Thanks for your attention.
"Everybody who has ever worked at that level in the operating system has agreed that systemd is the proper solution"
I can do it too :
Everybody who I speaking to agreed that's you are...
Everybody who has ever worked with systemd known how it suck, that gnome3 and all stuff you are making belong to the trash. But anybody is wheeling to do your craps when redhat and ms push it with $...
10 years from now Microsoft will own all this stuff.
io_uring
is getting more capable, and PREEMPT_RT is going mainstream