Slashdot Mirror
Devuan Jessie 1.0 Officially Released (softpedia.com)
prisoninmate quotes a report from Softpedia: Announced for the first time back in November 2014, Devuan is a Debian fork that doesn't use systemd as init system. It took more than two and a half years for it to reach 1.0 milestone, but the wait is now over and Devuan 1.0.0 stable release is here. Based on the packages and software repositories of the Debian GNU/Linux 8 "Jessie" operating system, Devuan 1.0.0 "Jessie" is now considered the first stable version of the GNU/Linux distribution, which stays true to its vision of developing a free Debian OS without systemd. This release is recommended for production use. As Devuan 1.0.0 doesn't ship with systemd, several adjustments needed to be made. For example, the distro uses a systemd-free version of the NetworkManager network connection manager and includes several extra libsystemd0-free packages in its repository.
So, how do I install systemd on this?
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Developers use Ubuntu; server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases now have an option.
What I'd really love is a Fedora fork (or EL clone, such as Scientific Linux) that reverts to the EL6 initscript build-out and considers systemd as just another option to be used on top of a standard SysV base -- much like xinetd. There if you need it, but not affecting the core.
Hire a Linux system administrator, systems engineer,
but i already have slackware14.2 fixed up nice the way i like it, and i am not wiping all that off to try out a 1.0 release, but still i have to say kudos to Devuan because i am one of those hardcoded systemD haters http://without-systemd.org/wik...
Politics is Treachery, Religion is Brainwashing
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
While I agree with your general sentiment, I think your counting is off. I think there are a few non-desktop systems that run linux, so that 2% number may be a little low.
If Devuan was offered as a default AWS AMI, I would prefer to use it over Debian.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Obviously, they didn't do it for market share. They did it for themselves and then shared it with everybody. Bravo to them.
> Linux has 2% market share.
He said, posting from a machine that doesn't use Linux, the packets quickly routed through a machine that uses Linux, to a farm of Linux boxes, to a box that runs Linux, which stored the information.
> I learned Unity.
Unity3D, the multiplatform development environment, or Unity, the now-defunct user interface?
> I learned systemd. It's not bad at all.
The problem is really how quickly it blazed through the community, as major distro after major distro switched to it, and how it was suddenly present in everything. Opting out was overly difficult. If it had moved slower, you'd have seen systemdless distros pop up in due time, instead of after the fact.
Maybe systemd has won the day, but that's no reason to stop people from working on a systemd-free system if that's what they want to do. Maybe systemd will turn out to be the disaster the naysayers were predicting and we'll all be happy they didn't give up. More likely, it will remain a hobby project for a handful of people who are resisting change for the sake of resisting change.
Ultimately, though, that's their choice. When systemd really started taking over, one of the regular comments was that people who didn't like it were free to fork their own distributions that didn't use it. Nobody who said that back then should complain because somebody took them seriously. As long as they aren't actively interfering with anyone else, they should be free to pursue their interests. Real freedom of choice includes the freedom to make unpopular choices.
There's no point in questioning authority if you aren't going to listen to the answers.
But with no competition they would probably never fix the logging dropped messages. Hopefully one day systemd will fix that.
That does make it terrible to use systemd on a server. Had a typo yesterday with BIND. Before systemd, the error message would have been displayed on the console. Now, it is dropped by the journal so it made troubleshooting difficult especially since we host over 1,900 domains so we didn't know which file to look in.
server admins use Debian. And server admins who consider systemd to be a destabilizing atrocity that chucks reliability out the window in favor of GNOME edge cases
What are these server admins doing? I have the defaults on EL7 and Debian 8 and all I notice is the VM's come up much faster and with fewer race conditions than under previous inits.
This is over dozens of unique VM images, but they're all doing pretty standard server stuff. What unusual things are people doing that break systemd-based distros?
I understand that some people have philosophical objections - fine - but I haven't heard any of my colleagues complaining of actual instability or unreliability.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Yes, yes, that's all very interesting, but let's see how inclusive their Code of Conduct is, and what their project diversity stats look like, before we decide to take them seriously.
I hate systemd but there's no way I'm running any software dominated by a bunch of privileged white men.
Amazon's Default AMI Linux is systemd-less, and is very possibly the most widely deployed linux distribution in use on servers.
Fascinating. By the same logic, ACs have around 0.001% of the intelligence of normal people. Hey, that one may actually be true!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
and OS instead of children: R! /path/to/remove/.*
https://github.com/systemd/sys...
Pottering's Response:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Unrelated, I also found sound worked much easier in FreeBSD than it did in Linux with pulseaudio. I wonder who designed that trash.
I genuinely mean it, good on them. Systemd isn't of that bigger deal to me, but at least these people have gone ahead and done something instead of just sitting around complaining about the fact that they don't agree with having systemd in a Debian default install. That's my biggest peeve with a lot of people in the Open Source community.....they're good at complaining, but they never do anything about it. These people actually have.
I wish them all the best and I hope Devuan has a long and happy life. Perhaps I'll check it out some time :)
I have installed Devuan on a laptop so far, and will be switching my other systems over time. I had one problem, the lack of a good replacement for network manager, and it seemed that as soon as I complained that the developers put network-manager in the next test release.
Bruce Perens.
I don't see how this is modded as flamebait, except that this community has a pretty obvious anti-systemd bias. Mr McGonigle was pointing out the hyperbole used by the vocal systemd opponents.
/. account to comment on systemd stories. Maybe I take exception to the level of hate directed at the members of the "community" for the work that they've done. If you see this Lennary Poettering, thank you for all your contributions! Ignore the haters, systemd is great and people don't have to use it if they don't like it.
My own anecdotal systemd experience has been positive, on desktops and servers. It is a major improvement over sysvinit, and many of the improvements make it a lot easier to admin a server.
For some reason I only ever use my
I've been using Devuan for some time now. I actually lack a lot of the required technical expertise to really have an opinion one way or the other about systemd.
However, I've been around long enough to know what kind of effect, 'dumbing things down has', and it's a great staple in American culture.
It's this sort of why have 5 buttons when you can have 1 button do everything. If you know what I'm talking about I don't need to explain it, and if you don't, you probably don't care and enjoy things being dumbed down. I'm sure I also enjoy a few things others would consider dumbed down, but...
When there are moves to take away, 'options', I'm against it. Convenience, should not be confused with simple and elegant efficiency. So for me, as soon as I heard about Devuan, I was on board.
Glad to hear Devuan reached 1.0.0 finally! Great job folks. I appreciate it. I have the option and have had for some time now, to use one of my favorite Distributions with the OPTION to not have to use systemd.
I don't see how this is modded as flamebait, ...
Because some moderators downgrade things they don't agree with or understand - like contrary opinions or sarcasm.
Welcome to /.
It must have been something you assimilated. . . .
How does this affect anyone? Linux has 2% market share. That tiny percentage is dominated by Ubuntu and Red Hat. Why does anyone care about this distribution? Nobody will use it. It is inconsequential and isn't news at all.
Let's see... Windows only holds a majority in the DESKTOP market.
In mobile, the vast majority of devices are Android, and iOS comes in second. All Android devices are Linux. They also don't use systemd.
In servers, Windows holds a minority market share. Guess who the leader is? Linux. Even on Microsoft's own cloud (Azure) a hugely significant portion of users are using Linux - the numbers keep going up for Linux - started out 1:5 use Linux when they first published about it, and it's something like 1:3 now.
Want a super computer? The market is pretty much dominated by Linux.
Want a main frame? Well, you're either looking at Linux or one of the older systems.
Oh, and embedded? Linux outpaces most everyone when a non-custom OS is possible; even many custom OS's are tending to be based on Linux.
So yeah...Linux has a huge world-wide, cross market, cross functional market share. All-in-all, we're probably talking somewhere in the 70-90% range of the computer industry is using Linux in some form.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Props to them for the commitment but systemd ( and all its warts) has won the day.
systemd has only won the day by fiat. There's a lot of people that are not happy about systemd. I've been looking forward to Devuan, and will probably start moving all my systems over to it. I caught the 1.0 release when updating my RPi3. My next laptop will probably be running it too - though I'll have to verify the external PPAs I use (Docker, KDE) work with it just fine too. But yeah...I don't need the trash heap that is systemd.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Perfectly legitimate question. As a sysadmin myself, only problem I've had with systemd is when I upgraded one system. It had an entry in the /etc/fstab file for a removable USB drive. I had to append "nofail" to the options for that entry, to ensure the system booted properly.
Otherwise, it's been smooth sailing. From a practical perspective, systemd works fine.
Someone with mod points and a liking for sceptical attitudes will soon ensure you're modded up again.
I gave systemD a spin on a VM to see if it would be suitable. Unfortunately, it flunked when I disconnected a redundant drive and it flatly refused to even attempt to mount /home in degraded mode. It just dropped me to the emergency shell. I attempted the mount command by hand to see the diagnostics and iot worked perfectly. It seems there is no way to make a command imperative. I looked on the mailing lists and found exactly the same problem with RAID. The response was a collective shrug.
I can absolutely work around that problem, but I can't just put aside the fact that the developers just don't give a crap because it would be a hard problem and their architecture won't accommodate a solution cleanly.
It's just too brittle for me to want it in charge of a server.
Can I do apt-get install systemd ?
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
You got a collective shrug because the problem was with mdadm not reporting the UUID correctly early in the boot process and not with systemd itself. This was fixed last year in mdadm 3.4.4 and if you search on the topic you won't find a problem of booting degraded affecting current releases of Debian, Ubuntu or CentOS, unless your mdadm config specifically says to not boot degraded.
The thing people are complaining about is precisely what lead to this problem in the first place. Everyone complains about the monoculture of systemd, but the monoculture of sysvinit not being effected by some design bugs in other software is what is causing a lot of this other software to fail due to undocumented or unexpected behaviour. Then people misattribute it to systemd and complain when systemd developers don't bend over backwards to accommodate bugs in other people's software.
What are these server admins doing?
I can't speak for them, however in our use cases we use initd to control server processes where we want control over the application latency, generally using CPU isolation and affinity. We built a test lab to understand how systemd would interact with our application and so we could learn it well ahead of our clients attempting deployment. This is a quality mindset used in ISO environments that prevents downtime.
For some inexplicable reason a lot of people seem to think that if you want to use initd you don't know anything about systemd which I find to be a poor understanding of the sheer variety of use cases and perhaps a little condescending.
My reasoning for using initd is specific and based on our test cases. Some of those reasons (off the top of my head) initd isn't a large monolithic process that generates a lot of software interrupts, we don't want a process manager to manage an event system we don't need, unit files are soft replacement for not knowing how to shell script properly, journalctl and binary logging poses a threat to uptime and timely root cause analysis, initd doesn't presume a large base of (potentially redundant) knowledge of the properties required to control it.
Sure there are some good points about systemd and some valid criticisms of initd (particularly the way the rc scripts are used) however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd. systemd tries to be that and a process management system.
I have the defaults on EL7 and Debian 8 and all I notice is the VM's come up much faster and with fewer race conditions than under previous inits.
That's great, however systemd has no effect on application processes that take time to start. These are easily parallelizable by using initd's existing inittab file so it doesn't impact boot.
This in practical terms means the difference between going home and doing an all nighter.
My ism, it's full of beliefs.
Why not set "ForwardToConsole" in your journal configuration file?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
reading an indexed file is one reason and the power of journalctl makes life a lot easier than inventing and reinventing scripts to extract specific ranges of data across lots of individual log files, you can still pipe the output from journalctl to existing tools to do anything more specific not covered by it. its a time saver, the sort of things that programs are meant to do.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
You can still run Debian with an init system that is not systemd. In fact, several Debian Developers are doing exactly that. There are even packages in the archive which facilitate using software that would otherwise require systemd as an init system to work without it (see systemd-shim). So what is Devuan doing that Debian doesn't offer already? Is it that Devuan compiles everything without even libsystemd0? But what harm is having libsystemd0 installed if you can at the same time still use your init system of choice? Is this really about everything systemd being evil and that's why it must also be evil to link against their shared library? I hoped this was a matter of how one likes to start and manage system services for which there are many init systems available but also rejecting a shared library seems to me like there is some emotional nonsense mixed in as well?
Sound on Linux in the late 1990s didn't really "just work". If you were lucky, you could get one application (and only one) to send audio to your audio card. The situation was so bad that many people used ESD, a quick and dirty hack from the Enlightenment people with horrible latency, to try to get something approximating to manageable sound on the GNU/Linux desktop.
The reason you probably think sound "worked" during the late 1990s was that it was considered a small miracle if sound worked at all, given the lack of drivers, and most people were happy if they reached the point that they got anything to work. Back then it wouldn't matter if running your MP3 player meant no notification noises, because the chances are the latter weren't important (and could be resolved with ESD anyway), and the MP3 player being capable of playing MP3s was "good enough". This problem ran right into the early 2000s.
It was once the drivers started to work, ALSA reached critical mass, etc, that the shortcomings of having the kernel manage audio as a single device started to really show up.
PulseAudio has a bad reputation not because it isn't necessary, but because early versions (1) had problems, (2) clashed with mountains of hacks that everyone else had installed to get around the problems kernel audio, and (3) the developer had a reputation for being a little bit prickly.
If PA wasn't necessary, then given 1-3, do you really think all significant GNU/Linux distributions would have adopted it?
You are not alone. This is not normal. None of this is normal.
> Maybe I take exception to the level of hate directed at the
Maybe because some of us simply prefer not to use systemd, and see piles and piles of hate and derision directed at us. Some of that hatred has come directly from Lennart Poettering, as well.
The living have better things to do than to continue hating the dead.
Problem is, when it doesn't work it is 99% usually one of the following problems,
A) They intentionally broke it, or were doing something to workaround missing initd functionality and it clashed with systemd. For example, see above post where user is using wicd without disabling an already existing network daemon, probably networkmanager. They blame this on systemd. Solution: use a clean systemd distro, and migrate old configs on a case-by-case basis as the need arises. Many old and crusty initd workaround are no longer needed, and if you blindly go in trying to use them anyway, you are going to create problems for yourself.
B) Software has bugs in it, bugs that were not noticed before with initd because initd did not depend on that functionality working correctly. For example, see above post where user couldn't boot in degraded mode because of a bug in mdadm. They blame this on systemd when all systemd is doing is depending on mdadm to report the drive UUID correctly. The fix in mdadm fixes the problem. Probably, in this case, initd is not affected because it doesn't (or can be made to not) use the UUID when mounting the pool, which is a generally bad practice overall. There is a fair quibble to be had here with distro maintainers who have not properly vetted all aspects of the system to uncover these bugs earlier in the process, but getting these bugs out into the open is the only way they get fixed.
You would look in the syslog file you configured bind messages to go to. Or with that many domains, you would run a config test on all zone file before you reload the config. I don't have that many domains configured and I have scripts that alert me to config errors as well as scripts that alert me to domains that are no longer pointing at my server.
Feel free to use my email address to contact me if you need to improve your hosting environment.
I don't think many of the people complaining about systemd are "crusty old sys admins", I think we're talking about mostly hobbyists who don't like change. SysV init has never been considered a thing of beauty by those who have to maintain GNU/Linux (or any *ix) systems. That's why systemd is the latest in a long line of replacements, from Apple's LaunchD (also about to be used in FreeBSD) to Ubuntu's Upstart.
Strongly disagree here, at least from RedHat land. SysV-style init scripts have been a solved problem for quite a while. If there are problems, they're usually a result of the daemon/app itself having problems that workarounds are needed for -- workarounds that usually end up in the systemd.service files as well unless upstream finally did something about the underlying issues.
Seriously, when I need to create an init script for something in EL6, just cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript#Initscript_template, change a few variables and/or add customization needed, and you're done. It's not rocket science and worked perfectly adequately. BSD folks complained about using chkconfig to manage your rcX.d/ structure (compared to rc.conf), but that wasn't that hard to figure out.
Debian (and Ubuntu) init scripts, on the other hand, seem to more or less be an unmitigated dumpster fire of strange techniques and non-standardization. But I've been a RH guy for forever. If systemd had come out of Debian-world, I'd totally understand its genesis and probably sympathize more. That it came out of Fedora/RH strikes me as quite bizarre. The only thing systemd could use to really justify itself with at F14/F15 time was boot speed, something which Debian had seen good improvements at by swapping https://wiki.debian.org/DashAsBinSh. Had Fedora/RH adopted that, we might not have seen systemd exalted to the degree it was.
Hire a Linux system administrator, systems engineer,
OSS in the 90s supported mixing multiple sound sources into a single audio output stream ... on systems other than Linux. Linux imported a crap version of OSS, never improved it, and declared OSS as dead and outdated ... when other OSes were using it just fine.
FreeBSD still defaults to OSS and supports pretty much all the same non-networked features as pulse.
OpenBSD has a sndio setup that supports pretty much all the same non-networks features as pulse, also running on top of OSS. sndio is also supported on FreeBSD and NetBSD.
There's also an OSSv4 release that can be installed on most Unix-like OSes.
It was only the Linux devs in the 90s who couldn't get OSS working properly. So they scrapped it and wrote a new sound system (ALSA), which didn't really fix anything. Which lead to the development of sound servers running on top to try and hide/work around the issues in ALSA. But they didn't work very well. So PulseAudio was developed to hide/work around the issues with ALSA. And it mostly works. But it's a bandaid, on top of a bandaid, running on a bandaid, with bandaids wrapped around it to hold it all together.
All that being said, PulseAudio does work fairly well these days, and can be used with ALSA or OSS backends on pretty much any Unix-like OS.
Since I was using BTRFS, I sincerely doubt mdadm was the problem. What I was seeing was another manifestation of the same basic issue, systemD THOUGHT it understood the dependencies but in fact, it did not. That's why it wouldn't even try the mount command.
The systemd design failure is that it refuses to acknowledge that there can be such a situation where it has no idea what the dependencies might be. It demands that everything else must conform to it's concept of what constitutes a dependency. It doesn't even have a way to tell it "use this external program to decide if dependencies have been met" nor does it have a way to tell it just give it a try and if the command returns no error, all is well.
Bottom line, stubbing systemd out and using SysV to bring the VM up worked flawlessly. One of MS's sins is that they demand a perfect world in order to work correctly and will not allow the admin to tell it to just give it a try. Systemd shares that sin. Without systemd, a great advantage of Linux is that when the actually intelligent human knows more than the system, the system will defer to his of her judgement and the job gets done.
https://lists.freedesktop.org/...
Specifically:
> Unless the systemd-haters prepare another kdbus userspace until
> then this will effectively also mean that we will not support
> non-systemd systems with udev anymore starting at that point.
> Gentoo folks, this is your wakeup call.
>
> Lennart
Now another thing in there. Just because I prefer not to run systemd, I have been characterized as a "hater". Other than the fact that I'm also not into Taylor Swift, I'm not that much into the whole "hater" thing, but I recognize that I'm being categorized and insulted.
I actually tried being an early adopter of systemd, years before its widespread adoption, and found that it didn't work for me. By the time it started getting widespread adoption, the THERE CAN BE ONLY ONE! attitude really annoyed me. If it were just the attitude I could probably get over it, but I also have technical and software-philosophical objections. But none of that appears to matter in discourse, because it all comes down to haters and steamrollers, instead of real discussion.
The living have better things to do than to continue hating the dead.
No, you keyed off of the wrong sentence. Look at, "Gentoo folks, this is your wakeup call." Up until the Devuan fork, Gentoo and Slackware were the only Linux distributions not converting to systemd. There was context surrounding this quote, implying the inexorable forcing of systemd into Gentoo.
I will add that you've got a bit of the attitude here, too. Note your words, "fact resistant, knee-jerk reaction against progress". There are certainly interesting ideas in systemd, I'll grant that. However overall I don't consider it progress, so in wishing to not adopt it I don't consider myself anti-progress.
If you really wished to engage in a technical discussion about this, what I like and what I don't like about systemd, I'd be happy to. However your last paragraph has lumped me as a systemd-hater, and therefore I cannot possibly have technical arguments to make. That is not true, I (and others) have technical and software-philosophical arguments, its just that nobody from the systemd camp (There, how's that for polarizing?) wants to hear them.
The living have better things to do than to continue hating the dead.
It would help if you didn't reinforce that perception with such a poor use case justification.
I don't profess to be a systemd expert, just that I've tested it and tried to see what benefits it can offer.
Systemd is not a large monolithic process.
systemd has its own lib directory. It is a much more memory intensive process than init.
By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout.
No. I mean it generates interrupts for service from the CPU and steals context from other processes. If it write I/O it forces other processes to minor page fault back to ram and off the CPU core. Though I still have more research in this area about systemd behavior.
That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
Which is not very useful if some problem causes you to loose your last buffer full of critical information that you need to determine why you system went down.
You are contradicting yourself, because you just said,
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
My ism, it's full of beliefs.
> That's also not a pile of hate. You could say it's not polite, but the implied message that I pick up on here is that Gentoo will need to implement alternatives to systemd technologies if they
> want to continue to benefit from other software projects that use systemd.
The you missed something in earlier lines in that post. Gentoo already maintains its own udev fork, eudev, so that's not the issue. He spoke of moving kernel event signalling from netlink to kdbus, which "breaks userspace" at a much more fundamental level, not just Gentoo's eudev.
I put "breaks userspace" in quotes, because the statement of simply changing interfaces like that breaks normal kernel practices, like keeping published APIs around for years of non-use before removing them. I've no problem with a kernel config switch that says something like "netlink or bus1 for event signalling", that's fine, breaking currently in-use and in-development software isn't. This betrays either a lack of familiarity or lack of regard for normal practices, neither of which belongs in a piece of infrastructure as important as systemd has become.
> That's great, but I didn't see any technical arguments from you. Maybe I missed them.
You didn't. I've mentioned technical or software philosophy several times, and this is the first time in this thread that anyone has picked up on it, or expressed any interest.
1 - PID1 is critical. If it crashes, the whole system crashes. I know that everything in systemd is not PID1, but it's still got a big one. Every line of code may someday translate into a bug or a crash. Proof, look at the bug history of IEFBR14 some time - that really is quite literally a one-liner, that managed to accumulate multiple bugs. My hair is grey, I used to use IEFBR14 all the time.
From what I've seen the functionality of systemd's PID1 could have readily been separated into a much smaller PID1 that did less, and one or more helpers that PID1 could restart as needed. That would have also allowed updating systemd without rebooting the system, as long as the PID1 portion hadn't changed, and being much smaller, that would have been more likely.
2 - Unix philosophy - small pieces each of which does one job and does it well. Then tie them together to do bigger things. In other discussions on this topic, I've been told that the Unix philosophy is obsolete, but I disagree. It has kept Unix running for some 40 years, through orders of magnitude of change in every aspect of computing. I'd be hesitant about throwing it out that quickly.
3 - I like initscripts written in a Turing-complete shell script language. You don't always need it, but when you do, you've got it. I've never written an initscript from scratch, but I have so heavily modified some that they practically end up from-scratch. From what I've ready, systemd has a decent configuration language for service units, but it's not Turing complete, and if they did, why not just use something that already exists and is well-debugged - shell script?
4 - Right now systemd is one package, even though it has many parts. That means that a bug in its logger requires a complete sytemd update... Or a bug in its new resolver subsystem, etc, etc. If the packaging were split, kind of the way the old functions that systemd has been subsuming were, then such updates would be simpler. Don't forget that a systemd update requires rebooting.
I could go on, but that's a few.
By the way, when attempting to make technical arguments like this, I've been called quite a few names, along the names I've been called when calling for network transparency out of Wayland. I try to let it roll off my back, but it can get to you after a while, especially when technical arguments are answered with insults and name-calling, rather than counter technical arguments.
The living have better things to do than to continue hating the dead.
> Specifically I was asking about examples of piles of hate. It's okay if you want to retract that statement.
No, but I'm not sure I feel like retreading that ground at the moment. I may keep one of these links around, in case I do. In the meantime, I'm running my computer as I see fit, and am only mildly inconvenienced by the things that require systemd. Incidentally, as far as userspace goes, I never had packages that required sysv, upstart, or whatever. Usually once the system is up, applications have been init-system agnostic. That's another thing I don't particularly like about systemd.
You're right, the sky hasn't fallen - yet. But so far systemd doesn't really have a lot of penetration in the big server space, where rebooting really is a big deal. By the same token, there have been a few laughably bad bugs found in systemd, and other than mentioning them in this sentence, I'm not hammering on them. I'll simply say that nobody has yet started the real bug search - the subtle bugs, timing bugs, the nasty stuff that takes years to discover - and get hidden by TLAs, and that type of stuff.
Perhaps that's the most disturbing thing about sytemd. It came in and practically took over the Linux ecosystem in about a year or so, and it was only a few years old at the time. It takes many years for software to truly get wrung out, to get the subtle bugs out. Systemd is too young for that to have happened, so most of the Linux ecosystem is part of a big experiment and learning curve.
Note that I'm not hammering specifically on systemd for being immature, this is part of the curve for any software. It's just that I think systemd has become too ubiquitous, too soon, for all of our good. Time will tell.
The living have better things to do than to continue hating the dead.