Slashdot Mirror
Busybox Deletes Systemd Support
ewhac writes: On 22 October, in a very terse commit message, Busybox removed its support for the controversial 'systemd' system management framework. The commit was made by Denys Vlasenko, and passed unremarked on the Busybox mailing lists. Judging from the diffs, system log integration is the most obvious consequence of the change.
The real "Libtards" are the Libertarians!
link dont work?
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346
No repositories found
"Legacy is a stupid thing! I don't want a legacy." -- Bill Gates
"We are all born ignorant, but one must work hard to remain stupid." -- Bill Gates
"The wise are instructed by reason, average minds by experience, the stupid by necessity and the brute by instinct." -- Bill Gates
"640K ought to be enough for anyone." -- Bill Gates
"Nietzsche was stupid and abnormal." -- Bill Gates
"An intelligent hell would be better than a stupid paradise." -- Bill Gates
"The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt." -- Bill Gates
"If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?" -- Bill Gates
"The person, be it gentleman or lady, who has not pleasure in a good novel, must be intolerably stupid." -- Bill Gates
"I've never met a funny person who wasn't smart. I've met a lot of dramatic people who were stupid. But I've never met a funny person who wasn't smart." -- Bill Gates
"The stupid neither forgive nor forget; the naive forgive and forget; the wise forgive but do not forget." -- Bill Gates
"People think a Muslim has to have a turban or a big beard. It's stupid." -- Bill Gates
"A good man can be stupid and still be good. But a bad man must have brains." -- Bill Gates
"Whether or not Twitter makes you stupid, it certainly makes some smart people sound stupid." -- Bill Gates
the busybox people have always been, well busybodies.
nice concept though, if you'd like to see what happens when someone without a 35 cedar lodged
up their ass does it, look at toybox
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
...remind me why I should care?
"systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them."
Wonder why so many other devs are so eager to put the systemd dick in their mouths.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
TOAD IS LORD! halleluyah! PRAISE TOAD! halleluyah! amen! TOAD TOAD TOAD TOAD TOAD TOAD forever and evererever!
UNITE with the Campaign for a Free Internet because today, our future begins with tomorrow!
Makes it very difficult to troubleshoot. This was a good change.
P.S. I think I Love You.
Don't know what they're so mad about. Systemd has been a great innovation for Linux and GNU. I guess busybox will be obsoleted by some other project.
With the major distros all moving to systemd, it's nice to see someone burn that bridge. I think if at least one top level distro was anti-systemd, then the drama would all go away, because the group that distrusts systemd could just go there. Someone quick spend your life forking fedora to a non-systemd thing. Pls?
Great work BusyBox!
Now if some of the desktop distros would listen to their core base and drop systemd as the default things would really be looking up for 2015 and next year.
That's not to say some of the ideas in systemd are entirely without merit. But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.
If given a choice, the user base stays with what works and quick adopts the better available alternatives. When forced they will look for the quickest out, seeing those that try coercion as a form of damage that must be rooted around.
The best thing to come from this is that the systemd crew have pulled much their code under one umbrella making it much easier to see which bits to replace. Now if they can try a little harder and embrace avahi and pulseaudio in the same way.
The answer to the question no one asked.
Besides being really Windows NT style rather than UNIX style, the rudeness and lack of empathy will kill systemd.
It isn't very technical? Why don't you use ReiserFS than? I still hear it is unmatched in technical quality in some aspects.
Have they received any death threats yet?
I have a problem with my debian server. The problem is that since upgrading to systemd, running fdisk causes the server to mount the partitions from the disk I'm trying to repartition. Even removing them from /etc/fstab doesn't prevent them from being mounted.
I did not have this problem before systemd and God alone know where the stray configuration causing this misbehavior lies.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
The Linus Torvald's you know and love is but a figurehead puppet used by the open source conglomerates as clean shaven media representative. This man was born without birth certificates as part of a Middle Eastern slave harem and is commonly known as the Lunix Colonel.
The real Linus Torvald's has not left his mothers basement for 25 years. Nor has he shaved in this time. In March 1994 the Kernel was released as version 1.0.0 to celebrate Torvald's beard reaching 1 foot in length. 2 years later, largely due to a healthy diet of lutefisk they celebrated the milestone of 2 feet.
Unfortunately due to interference by corporate actors such as the Soviet conspiracy, Red Hat, the numbers became stagnated and no longer accurately reflected the true length of Torvald's beard. He was forced to trim.
This event caused Torvald's great sadness and resulted in him spiralling out of control into deep depression like parts of Mark Shuttleworth's Challenger spacecraft. He stopped showering for several years and this corresponding time period contained the greatest number of bugs in both the Linux kernel, and his beard.
The depression and lack of hygiene was contagious and spread to Open Source Wizard Richard Stallman who became known for his podiatric-auto-canibillia and was more likely to be associated with sores and sauce than source. The rival HURD kernel will never be completed as Stallman has forgotten how to program.
Torvald's mean while continued coding until his fingers bled, pushing code into his git under pseudonyms of various nerds around the world who paid the open source conglomerate to keep the sole Linux Mainframe online.
In 2011 Torvald's was able to wrestle control back over his versioning system and matched the released to the length of his beard for the 3rd time. This greatly improved the kernel and led to the development of some of the key technology of the 21st century: System D.
Seeing that his kernel was getting bigger, Torvald's began researching peer to peer Bitcoin block chains and Tor network services as a way to revolutionise the kernel for the first time since Al Gore invented the internet. System D was to use the one true linux mainframes hard drive to store pictures of Torvalds Penis, the system D version numbers were to reflect it's size at any time in some of the first research into Quantum computing versioning. After Jarrod from subway the initial angel investor due to seeing how this technology could be useful for his own interests, Google joined the project with the creation of it's D-wave computer - The first self contained and self replicating System D computer.
This caused a further rift between Stallman and Torvald's, as Linus had turned his operating system into a more advanced version of HERDs naming system. Many gnus were killed in the great battle of recursion.
In 2013 Torvald's beard had grown to a staggering 4 feet, as long as Eric S Raymonds was tall. This also marked the first time that Linux and System-D were the same thing as at the time Torvald's penis was 4 feet long.
Torvald's beard is currently approaching 4.3 feet long. He last had a shower this morning when he nearly got an erection and it is currently free from bugs.
People have found.
I know it's not the Slashdot way, but systemd discussions generate much more smoke than fire. Could people posting here please provide very clear links which show a real history of comments and preferably real code. The systemd guys have been under very specific pressure and so there should also be some tolerance of "overreacting too quickly"
Who found what bugs? with what software? who precisely responded? What exactly was incompatible? How did the distro makers feel about it?
As far as I can tell systemd has a few new neat features for normal users (show me the logs from the last day / boot etc) but is mostly pushed by distro makers. Since distro makers are the people who deliver Linux to the users and then have to fix the bugs they are pretty much the most important people in the community. If systemd is doing something they need then we need to either support it or provide an alternative which can provide the same things.
Judging from the diffs, system log integration is the most obvious consequence of the change.
He's removed the code that allowed syslogd to be socket activated by systemd.
72 lines of code.
Watch this Heartland Institute video
It's not an init system. It's a "system management framework", didn't you read the article?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Since the systemd my Linux desktops have become faster, more reliable (init.d for instance had no service watchdog), the logging infrastructure is nicer to use, and significant amount of resources have been released. Why on earth any distribution really would want to go 15 years back? That would be suicide for the distribution.
It's always good to see mature professionals make decisions for solid technical reasons.
I doubt if everyone who jumped aboard the systemd cargo ship really knew the journey they were in for. Some of those travelers started to regret their ticket purchase when sudo was eaten up by systemd. And others... well it will take a bit longer to realize their fate.
Mature professionals are not swayed by the latest coolness. In contrast they are strongly aware of risk and liability, and working with an uncooperative supplier introduces both, as well as unpleasantness and annoyance at work.
Oh, a framework.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Commit Message:
systemd people are not willing to play nice with the rest of the world.
Therefore there is no reason for the rest of the world to cooperate with them.
Signed-off-by: Denys Vlasenko
http://webcache.googleusercontent.com/search?q=cache:eoce3kM0y_gJ:git.busybox.net/busybox/commit/%3Fid%3Daccd9eeb719916da974584b33b1aeced5f3bb346+&cd=1&hl=en&ct=clnk&gl=uk
Also with regard to systemd, I really do like distros that have it in my virtual machines because I can do a full reboot in seconds, whereas other distros take much longer.
I don't know how the hell you borked the init systems, but booting VMs is so fast that I always have prompt as soon as I have console output up which is around 1s after the virtual BIOS. If you have trouble during shutdown the speedup isn't even desirable. I'd rather have my apps save data than and shut down than be killed and loose data. At least they pulled that 'feature'.
Maybe the problem is the distro used: RHEL and SUSE pre systemd are slow as hell while Debian 7 boots as fast as I have described. Which is even a little slower in version 8, because the first terminal spawned is a little buggy. Hurra for dynamically spawned ttys to save memory. A nice example for solving a non-problem with a complex solution and breaking lots of stuff.
Or just read the posts on ssh restart behaviour. Be true to systemd style and break remote sshd updates or make an exemption in behaviour to appease sysadmins.
The thread referenced above is worth a read. I wish I had mod points to recommend it.
Good. Let more projects follow suit.
Busybox has no business supporting systemd. Busybox is designed to be as lightweight and as portable as possible, with only the bare minimum of dependencies.They shouldn't have included support for systemd, in the first place.
Commit was removed 5m ago. Systemd may be successful at bribing busybox as we speak.
Just an anecdote: during a recent upgrade from Debian Wheezy to Jessie, the first boot into the new system failed with a message from systemd about mtab not being a link into /proc/something (a trivial problem as far as I can see).
Can't remember the exact message from systemd, but it was something about being "frozen"
No going into single user, nothing, just F... you and go reboot on the CD image. Happy enough that the machine was on my desk...
And they wonder why many people don't like systemd....
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Dependancy and target based startup is not a bad idea and can be useful in many scenarios. Its probably not necessary to start many services, though many admins can benefit from the feature where needed and it can actually make administration easier. Since SystemD provides Sys V init, and backwards compatability, the criticism of systemd is a bit overblown as people can simply use system v init features on systemd if they want. The integration of cron, syslog and init was important for being able to launch a service dependant based on say another cron event occuring. There are better ways to do this however using a decentralized model using well defined IPC bus interfaces and protocols allowing for the functionalities to be in seperate processes but allowing processes to communicate with each other, and each a user swappable components as I will describe later. There is no need to have one big monolithic process or poorly understood components which are not swappable and do not communicate using well understood and documented protocols that can facilitate users swapping out components.
I doubt that systemd would be as big of a controversy as it is if the additional functionality was added but not heavily used all over the place for most of the services on the system and the distribution had not felt the need to convert every single service to the new type of init file. Its sort of like people who think they have to use every single C++ feature when C++ is not intended for that, its a bag of tools where the programmer is supposed to choose the tool they need, rather than something where the programmer is supposed to use every single last tool. Instead, the distributions who adopted it felt the need to convert most services over to the new init file format. This created a very much so in your face kind of obtrusiveness that was easily noticeable by many. It was unnecessary in many cases as dependancy based startups can stil even be triggered from System V style initializations. Since systemd supports SysV startup, the majority of init files could have been left in SysV format which would have avoided much controversy. Another possibility is to offer init files in both the old and new formats so people can choose which one they desire.
I believe in a mechanism not policy approach. Systemd's own model of dependancy init are useful in some cases however, are probably overkill for other services. The features should be there for those cases that people may need to use them. Systemd does allow users to the flexibility to use sysV init so the fact is for starting your services you can always have the started from sysV scripts even on Systemd. Ive done it and works fine.
Many complain about the all or nothing approach of systemd. An init system like this should be built around IPC bus, using well defined protocols, interfaces and message formats which are extremely well documented to the public. This way we can get the dependancy based start up, while giving admins complete control and allowing the init system to be built from swappable components. Lets say we wanted to have a daemon started after 5 conditions are fulfilled, 3 other daemons started, the network interface up and 5 minutes elapsed from system boot. The init components that start the 3 prereq daemons would produce IPC bus messages as each of those are started. The kernel would generate a bus message when the network interface would go up. You could write your own init daemon that would watch the bus for all of these events and would also set a 5 minute timer as well, it would keep track of all of these events and when all of them are fulfilled it could then start the daemon and would announce on the bus that it it doing so.
This would allow you to write drop in replacements yourself for any part of the init system. The bus interfaces would all be well documented so you could write your own python script if you wanted to watch the bus for events and be able to start a daemon or process when you see the prerequisite events on the bus. Th
Red Hat paid for the development of systemd because their high-paying customers (probably IBM chiefly) wanted a systems management suite like SMF. For companies like IBM and Google, deploying a million virtual servers every day, having faster boot times, not having to craft init scripts, etc. are worthwhile features. There was no conspiracy to destroy the other init systems--Debian, Ubuntu, SUSE, Arch, and the others have merely found that systemd is easier to develop upon than SysVinit or Upstart, since it automates a lot of the maintenance routines that SysV pushed into user space.
And produced within the past 3 years that would not run anything larger than busybox acceptably and still have room in its flash for the rest of the device-specific applications necessary.
Furthermore, as musl-libc proves, there is room for improvement in both standards compliance as well as memory/disk usage. musl managed to produce a libc that not only provides better standards compliance in most cases than glibc, but be dramatically smaller (1/6th or less the size of equiv glibc so/a files), have proper posix thread error reporting, have equivalent dlloader support to glibc, and work with all compilers back to 2.95.3 or earlier (it requires 3.4 or later to compile due to C99 compliant features, but will compile apps supporting 2.95.3 just fine.
Users are the most important people. No users mean no distro and no distro people. But take away the distro and users will just find another or another os.
systemd is not for users or for admins. It is only for distro people. They want to push the work of packaging software for their distro to the people writing the software. They are lazy.
Also, a few corporate monkeys at redhat are willing to screw millions of people over with shitty distro so that their docker/container stuff will boot a half second faster. That is what systemd is all about.
I think there there should be RedhatOS and other distros should be real Linux - i.e. Linux without systemd.
I'd give you mod points if I had them.
GNU, BSD, Linux, et cetera became ubiquitous because they all offer lots of choices. Minimal, text-only OS? Sure. Fancy GUI with special effects? Sure. Headless? Sure. A single, simple ethernet connection to the world? Sure. A multi-interface, multi-homed, routing, NAT and firewall setup? Sure.
Try to take away people's choices, and you're going to piss people off. I don't even run GNU/Linux, but I'm pissed about the mess that is being made to open source software. Now we're going to have to come up with a label for software that depends on systemd, like "systemd encumbered", because it won't be compilable on any other operating system.
systemd started as a port to launchd over from BSD architecture to SysV. Most of your comments lack foundation. Systemd has the capabilities of launchd. As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet. The people opposed are mainly people who manage dozens of servers and came up in the Ubuntu years post Unix. So your facts are simply off.
As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet.
I don't think that's true lol.....you are the only person in that category I've ever seen who favored systemd. And from what I gathered discussing it with you previously, you only like it because of features you hope will eventually make it into systemd (features which I think will never make it, but that's predicting the future so who knows).
"First they came for the slanderers and i said nothing."
System boot time is only important if the system is booting frequently.
Such as a laptop that's booted for fifteen minutes between boarding the city bus and transferring to a different bus.
The posts were people are wrangling about whether Sytemd is workable or ran by asshole devs as opposed to asshole sysadmins etc is the one of the problems with Linux at large. The problems with Linux like this, are the reason that Windows as crappy as it has become, as nosy as it have become, and generally onerous, is still in control of 90% of desktop computers. The ONLY place Linux in ANY FLAVOR has reached critical mass is via Android which is Google's custom flavor. I would love to have an alternative to windows and apple. Yet, because you all still haven't got your act together, I am stuck waiting for Google's chrome os. smh
> the people pushing systemd the most strongly are the people who run the most sophisticated date centers
This kind of dismissive attitude is a classic example of the systemd problem. It's fanboys just baselessly assume that anyone who's not on board is "just an amateur". Both parts of that are quite wrongful. That includes the assumption about the experience of critics AND the idea that the "amateurs" don't matter.
If Redhat wants to build "pretentious cloud Linux" they should just do that and leave the rest of Linux alone.
A Pirate and a Puritan look the same on a balance sheet.
And they give exactly the worst problem with systemd as a reason: The people behind it. These people are not part of the Linux community, they are a hostile invasion force.
Of course, there are numerous technical problems with systemd, but the simple and clean way to address them is to just not use it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well said.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Rewriting scripts into more powerful and flexible C libraries is also a central part of UNIX. Add some markup so you can do dependency resolution, support for cgroups and parallel startup, and you have either OpenRC or Systemd. OpenRC admittedly is more of a work in progress.
Systemd takes the position that, because the key component in process management is Linux-specific, it's okay if the service manager is Linux-specific too. Having an OS-independent service management layer was seemingly a bad idea, since most of the major UNIXes have replaced it. In point of fact, cgroups are only the latest version of process tracking in Linux, because pidfiles just aren't a substitute for kernel-level features that guarantee that processes are what they say they are with the resources they say they have.
The failures of SysV init are as much political as technical: pretending that SysV was a one-size-fits-all solution just pushed the maintenance problem onto the distro maintainers. The distro maintainers are maintaining Linux, not UNIX, and fragmentation doesn't hurt them -- quite the opposite. So in a few years the big players' existing practices will be codified as The New Standard, the smaller vendors will grumble and implement it, and everything will be fine until the next new OS/feature comes along.
Have you learned anything else about technology in the last thirty years, or just shell scripts?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
You can't quite pout you finger on exactly what is wrong
I think I could Poett my finger on what's wrong.
Bravo for common sense.
some of the comments are worthy of comment.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840843
^Redhat was "ok" until 7.3. Many, including myself, abandoned it at 8.0. They are Microsoft wannabe's. That was when we found out.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840903
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840959
^ The fact is that systemd strives for basic control of the rest of whatever Linux system is affected by it. The binary logging issue is an obviously intentional distraction. Busybox got it right.
If systemd is sofa king great... have a systemd distro. One. If it is so outstanding.. people will flock to it in droves. Now why is this shitstain pwnd being pushed on other distros? Find that out you will find some lying fucks.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50843055
^ This is an emotional response regarding the attitude of systemd folks and Redhat. Yep. They are dicks. This is not news. Again, Busybox is right.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840695 ... for an AC. That is like trophy shit on Slashdot now. Why 5? It is total shill. That AC said "That's not to say some of the ideas in systemd are entirely without merit. " ... while saying "But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.". Am I hypnotized now? No. systemd is precisely control freak thinking. It should be deleted from all distros and let Redhat lose it's users in droves. Natural selection. Look up the definition of shill.
^ This got modded to 5
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346
^ Every dev of every other Linux distro should print that out and fasten it to a wall above their monitors in font size 10,000+.
There is no believable overt incentive for any distro to absorb systemd into their code.
There was a factual statement made. That factual statement was false. And as an aside I didn't say the opponents were amateurs I said the opposite. But I did deal with the reality of where the center of opposition is.
I don't see why you can't just set the service to start after the network is up. Hell, that's a simple sysvinit thing, an iirc, systemd supports such a thing. Admittedly, I've not been on a Red Hat system in quite a while, as my primary concentration has been focused on debugging Android related issues, so I'm behind the curve, on systemd, these days.
With you except for the reference to btrfs and AAA video games. Whatever its technical merits or shortcomings, btrfs has yet to achieve the level of "integration" of systemd. You can happily run most modern GNU/Linux desktops without it. While some distros are using some of btrfs's more advanced features, these tend to be optional and extX remains the system default for practically all distros. Contrast that with systemd, which has its footprint in practically all the major distros released within the last few years.
It's only a little, lightweight framework. You worry too much.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
Please provide at least one example.
What you say is just an opinion by someone who, from my point of view of 20+ years of Unix administration, doesn't understand anything of what he's talking about and is spouting BS he read somewhere else.
The small issues amassing in real annoying rare cases are sth that always existed on any OS, but you seem to say only systemd is causing that.
So what you're saying is clearly BS.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have.
You don't even understand the GPL and what it's for, so your case is getting even worse. You sound like a proprietary software shill, not like someone who understands Linux, and therefore not as someone legitimate to talk about systemd. FYI, launchd is one of the init that have been studied before making systemd.
Studied by people that actually understood the GPL, Unix (BSD and System V), and Linux. At least far better than you ever could.
Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Oh my god! Thankfully you don't do systemd administration. FYI, the kernel works just like that! Systemd is tailored for Linux, and it shares lots of its design.
If your memory is physically malfunctioning and corrupted, the kernel (and systemd) is choosing to not do anything about it, and not handle it, because they decided they can't, and prefer launching a kernel panic (or a systemd halt)! That you hate that just means you hate Linux and systemd, but some people like me find this a legitimate and sensible choice and will continue to use both.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development?
Did you know there was a problem with the licences of both and the GPL? Did you know that LaunchD and ZFS were not made for Linux?
These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
In the case of a free GPL OS like Linux, I would not want any of these sysadmins touching Linux infrastructure at all. People trained in proprietary buggy Unix OS, no thanks! People that couldn't to this day do better than the GNU OS? No thanks!
Now, if the sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are was actually working on Linux, yes of course I would chose this one. Oh wait, that's exactly who Lennart Poettering (the one that launched systemd) is!
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Don't worry, it shows in what you've written. Fortunately, the one developing systemd and Linux are not like you.
The Linuxtoday editors are biased toward systemd benefits and contributors, I thnik. This issue about Busybox has not entries in Linuxtoday covarage in October.
Funny, when you're posting in a new thread instead of replying.