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.
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.
So, how do I install systemd on this?
Props to them for the commitment but systemd ( and all its warts) has won the day.
Get your PostgreSQL here: http://www.commandprompt.com/
..except hardcode systemd haters and trolls care about this. The rest of us who actually need to have work done just use systemd and move on.
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
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.
I'm glad that folks can "have it their way" and roll a distro the way they want.
Myself, I'm an old school unix guy, and for years I fought against all the new fangled stuff that was being introduced. After many years, I finally gave up. I learned systemd. It's not bad at all. I learned Unity. Yep, it wasn't that bad at all.
For me, life is easier when I pick the right battles to fight. But more power to the Devuan folks. Have fun and knock yourselves out!
With a nancyboi name figure on a nancyboi lusrland . GIMP anyone ?
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.
Nobody cares... About 0.001% of computers run Debian or its variants.
No one cares. Let sysvinit die. It's trash.
Now, now guys. I'm an SA the past 10 years on centos/Ubuntu sever. The best thing about systemd is unit portability. Plus there are added features for security.
I know, I know. Die hard experts on pid 1 do not like it. But, that's OK, you have Devuan. We have everything else.
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.
c-title
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.
Everytime I read about the systemd wars I think of this Dilbert comic strip and smile!
Can I do apt-get install systemd ?
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
From what I see in the discussion, the correction has been merged. So it has been recognized as a bug, and corrected as such.
Public shaming works.
Appreciate the work the Devuan team has done to make another Linux distribution option.
I wonder who designed that trash.
Someone who wanted an audio subsystem capable of meeting the user requirements of people in the 2000s instead of people in the 80s. It's quite telling that every distribution adopted it despite your assertion that it's "trash".
I am so happy. It boot (from SSD) fast. At same speed than Ubuntu 16.04
It takes a couple of seconds extra to shut down, but I will survive.
It is a relief to see Linux working without SystemD around doing extra and unneeded tasks.
I installed with Mate. It seems I will be comfortable and will not miss ubuntu 16.04. We will see.
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.
Someone who wanted an audio subsystem capable of meeting the user requirements of people in the 2000s instead of people in the 80s. It's quite telling that every distribution adopted it despite your assertion that it's "trash".
why not.. like.. umm.. late 90's? you know, when it it just worked.
world was created 5 seconds before this post as it is.
The proposed correction was merged even before Poettering's comment.
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?
"poettering locked and limited conversation to collaborators on 17 Apr"
Ah yeah, smart move.
Ahem, but isn't it the same argument we hear about systemd: if all distros use it, so it must be good?
Funny thing, when you do not use it, things no longer work. Things that worked for decades. Because the code that was there before was removed (remember David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience https://linux.slashdot.org/sto... ).
So, from a distro perspective, not using it mean doing the extra work to make things work as they did before. Work to get nothing more than what was before. Work for nothing, in short. Who wants to afford that? Because it is not meant as an alternative but a replacement for all.
Now, does that benefits to the end user? Well, as long as the replacement suits your needs, no problem. When it breaks, that is another story. /foo/.*" will work the exact same way, no?", not only it shows lack of knowledge (annoying considering how much his decisions can affect GNU/Linux main distros), it shows lack of concern about other people priority. /foo/.* and rm -rf /). But what when it is not an issue with such an obvious answer? Well... Guess.
And, then, how the Poettering and his gang manage things is quite important. When Poettering write "I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf
And, here, we can laugh about it because he is so obviously wrong (as shown in the comments, tests about rm -rf
You must have been using a different audio system to me in the late 90s if yours "just worked". By contrast, audio on Linux is now in the "solved problem" category, for me at least.
Public shaming works retroactively.
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.
So basically your complaint is that systemd does provide something that developers like David find useful?
How about providing something equally useful that KDE/Gnome can use instead?
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
It would help if you didn't reinforce that perception with such a poor use case justification.
initd isn't a large monolithic process that generates a lot of software interrupts
Systemd is not a large monolithic process. By software interrupts, I assume you mean it uses dbus instead of just piping everything to stdout. The difference really is whether there is a defined message pattern to the IPC (dbus) or just a dump of whatever data in whatever random format that has to be parsed by the receiving process (FIFO). While the latter has certainly worked, I think it is hard to argue against the former as a generally good practice.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever. Shell scripts were a quick and dirty way of getting a system up and running. The fact that they have lasted so long is a testament to how flexible the shell scripting languages are, but viewing it as anything other than a workaround for lack of necessary functionality in init is crazy.
journalctl and binary logging poses a threat to uptime and timely root cause analysis
Another argument that makes no sense whatsoever. Nothing inherent about binary logging prevents root cause analysis. Teach your tools to read the binary log, and it will actually be better because you will get a lot more information.
however all that speaks to is that it is initd needs a matching event management system that controls and is controlled by initd
You are contradicting yourself, because you just said,
we don't want a process manager to manage an event system we don't need
So, which is it?
It's a fair point to argue that initd worked fine for you and you don't see a reason to change and don't want to learn a new system. But just say that and save yourself the time.
Is there a reason OSX and Windows don't spam my network with audio data? I forget which distro/version but PulseAudio had multicast on by default.
every distribution
And FreeBSD didn't yet in 2017 my audio works. It shows up as a simple device in /dev. It behaves like any other device. Doesn't spam my network with audio chatter.
why not.. like.. umm.. late 90's? you know, when it it just worked.
I'm going to add my 2c here - sound on Linux in the late 90s didn't just work, it was a PITA. Maybe you were better than me at figuring it out (wouldn't be hard) or you got lucky, but I used lots of distros back then and sound was always a sticking point.
>If PA wasn't necessary, then given 1-3, do you really think all significant GNU/Linux distributions would have adopted it?
Yes, because you missed the most important part of sound history: 4front and paid sound drivers (which actually worked).
Guess what, distributions didn't want to charge users $xx and give all the money to 4front, because they know it would never work as a business model.
PulseAudio does what 4front's mixer did, but for free. Unfortunately, it does a shit job. But it is free. It is not the first time we have seen shitty-but-free beat good-but-paid in the linux world. Fortunately, it has been improved (as tends to happen with problem-solving shitty open source software) and is mostly not shitty now.
why not.. like.. umm.. late 90's? you know, when it it just worked
I can see you first used Linux in 2005. Certainly didn't use it in the 90s if you thought it "just worked". Hell the forget "just". Often it didn't work with a huge amount of effort and hacks.
Say what you want about pulseaudio, it was required to make Linux a possible desktop operating system capable of any kind of multi-media.
Ahem, but isn't it the same argument we hear about systemd: if all distros use it, so it must be good?
I didn't say it was good. I said it wasn't trash, implying it had a purpose. But yes that is the same arguement. All three base distros went through a technical evaluation (except maybe RedHat which probably assumes everything Lennart touches is pure gold), and they all adopted it on technical merits. That is documented in mailing lists regardless of what people think.
Things that worked for decades
Are we still talking about sound? Tell me you're not talking about sound. Because if you're talking about sound you deserve a +5 funny for that sentence alone. Linux sound was a horrid clusterfuck of workarounds just to be able to get sound from one place to a soundcard, and even that more or less rarely worked.
If you're talking about the init system well it worked for decades, you're delusional. It worked through a set of hacks to make it work. It got the system booted and then basically left the rest to crap on itself. It allowed services to turn into zombie processes, it lost track if PID files got upset, it was incapable of handling system events so it spawned yet another service that it didn't control which handled network events to control more services that the init system didn't even track at all.
But yes I'm sure it worked well, and that Poettering is the only one who wanted to mess with it. It's not like anyone else thought the same way. Not like the guys who wrote OpenRC, or the guys who wrote Upstart. The sysvinit did have something going for it, it was small. But yet too big which gave us busybox-init for embedded systems. But yeah it's the Unix way right? Well Solaris also replaced sysvinit with SMF. It's almost like people who adopt Linux or Unix have for the longest time tried to get rid of that piece of shit. Like Apple, the first thing they did after adopting a Unix base for it's OS is create launchd (what systemd is based on).
But yes, let's all focus on that one rm -rf /foo/.* issue and use that to claim that a person who has now written the underpinnings of a large part of the OS has no clue. What an idiot he must be.
Tell you what, why don't you write a better system.
So you don't know how to change a setting and you're complaining. *golfclap*.
You also know what FreeBSD did in the late 90s and early 2000s? Oh man you're not going to believe this when I tell you. You ready for it? Really? : They abandoned the god fucking awful Linux OSS / ALSA combination and rewrote it from scratch.
Linux audio was for want of a more technical term: fucked. With pulse audio it now works, despite your weird network / RTFM problem. Not that this is a pulseaudio issue. It's not Pulseaudio's job to set defaults, it's the distribution maintainers.
So you don't know how to change a setting and you're complaining. *golfclap*
I spent a week trying to diagnose *why* my machine was so chatty before narrowing it down to PA. Then turning it off took no time. But having a default setting like that makes no sense.
rewrote it from scratch.
No one is claiming that it didn't need re-written. Just like I'm not claiming the old init method couldn't be improved. I take issue with what it was rewritten into. Which is the flaming pile of PulseAudio and SystemD.
launchd has been out for 12 years now. Ported to FreeBSD and running as NextBSD's init. I have yet to hear of issues like those caused by systemd. But it was also designed to do one, launch programs.
> Unrelated, I also found sound worked much easier in FreeBSD than it did in Linux with pulseaudio.
But firefox will not work without pulseaudio.
I think you can only run old versions of chrome on FreeBSD.
I know you can only run old version of LibreOffice on FreeBSD.
Not a single statement you made is true.
You can turn off PulseAudio in make config.
Latest download on LibreOffice's website: 5.3.3
Latest FreeBSD package available: 5.3.3
Latest available stable chrome(ium)
58.0.3029.110
Latest available in FreshPorts: 58.0.3029.110
.
systemd was adopted on technical merits? Probably. Do these technicals merits affects me? I tried and used systemd before any distribution adopted it. Then I noticed it broke stuff I relied on and wanted to switch back to another init, because why not, eh? And then I found out people around (like KDE, like provided earlier) remove code and functionalities of software because it would make a duplicate with systemd. So switching back was no longer an easy option.
And many of these functionalities are way beyond the scope of an init system. It is almost a system. So that, for me, itself, raise quertions.
The rm -rf /foo/. might be insignificant if we were talking about a guy that contributes to an init system. It is quite different when it is about one of the guy that have a say on the system that gradually all other software depends on.
As you said "underpinnings of a large part of the OS". It is not about an init anymore.
Fact that a new init system is welcome does not mean that it is so great to have a new system on top of GNU/Linux, much more than an actual init system.
When considerable amount of software regress (upower, etc) because their functionalities are now handled by systemd, in an effort of rationalization, for distros, it does not make much sense not to use systemd, because it forces them to chase all these regressions that are being made day after day. Which mean working just to keep things as they were, instead of improving anything.
And it is not like a new thing in the libre software community, to write a blank check to some crowd (Helixcode, Eazel, etc) due to marketing and promises more than results while there was obvious warning sign to where it would, in the end, lead (and which it did - kind of joke to have GNOME, part of GNU, led by people that ultimately were releasing proprietary software).
I wont get in details about sound. In the past, it was shitty to set up but once it was set, it was working reliably. Not my feeling right now. At least, old audio system was not providing functionalities while advising not to use them (PulseAudio as a system daemon). Here there is a pattern about the development process (writing code you want people not to use? why? because you need to pretend there is no regression?).
Finally, what is the meaning of your last sentence? Is it not allowed not to enjoy systemd until you wrote yourself some systemd? I need to be president of the USA to have an opinion about president USA ? I need to be famous singer to like or not to like some famous song? WTF.
You forgot that part.
the mentality behind Devuan is ludicrous. Lets remove a far more modular, flexible and powerful init system and make a distribution that is less flexible and less modular and less configurable. That is because systemd is actually more flexible, easier to configurable and more modular than the old system was.
To cover many of the myths about systemd: http://0pointer.de/blog/projects/the-biggest-myths.html [0pointer.de] . It is extremely damaging to the Linux ecosystem for people to continue to spout lies about systemd that are not true. Most people when confronted with the facts about systemd and the benefits it offers and the fact it takes nothing away, you are free to have sysv style shell scripts to your hearts content because systemd is fully backward compatable with the old init system, and is actually MORE modular and decentralized than the old system, agree that it is a benefit to Linux.
Please, stop spreading lies about systemd.
Ubuntu has had systemd type init for years because of Upstart, so with systemd, we are simply seeing standardization with what the other distros are doing. So, this kind of init model is nothing new to Ubuntu.
The opposition to systemd is nonsensical. Because you can continue to use SysV init because it supports that, the additional functionality is additive, it adds onto what was there before. Because SysV is still there, and you can start your services that way, you have nothing to complain about and there is no reason to oppose systemd.
One big benefit is the service files which are shorter, simpler and easier to read than shell script and actually make starting services easier. You can still write shell scripts to your hearts content, but for most people service files are easier because of the declarative format.
systemd is actually more decentralized than the old system and is more configurable. This is because of the D-BUS based design. That is, you can write a D-BUS daemon that monitors the system bus for whatever events you are interested in and write your own custom code to decide when to start a process. This allows you to trigger something when multiple other events happen and allow you to do so cleanly and easily because you are watching a standardized protocol over DBUS. It would be much much harder to do this without a standardized loosely coupled design of DBUS. Events can include kernel events and events generated by other processes, including other processes starting. Your daemon can also generate its own event messages when it starts or stops a process. The reason Gnome uses some features associated with systemd is that Gnome for instance wants UI notifications for different system events for the user being able to monitor the system via a user interface.
Some utilities have had a D-BUS backend added, for instance, su. This is to allow users to have a process started when a user logins in. It is a lie to say that su has become built into one big massive monolithic systemd process. This is not the case at all. All that was added to some utilities is a small amount of d-bus code;. They are still completely seperate binaries and are not a part of a monolithic systemd process because the utilities are still completely seperate, in fact it keeps the utilties seperate because the whole point of d-bus as a loosely coupled architecture is to allow applications to communicate without these applications having to be directly linked or even know who each other are.
Systemd in this way is far more modularized than the old init system was.
systemd has a lot of functionality but you are not required to use it, but its there if you need it. Its probably better to have a simple sequential startup for many services, you can still do that with systemd. systemd takes nothing away. want sysV type init? Feel free to use it on systemd, its still supported.
I tried and used systemd before any distribution adopted it.
Great. Your views are outdated. There have been hundreds of commits and bug fixes not to mention work to incorporate and make it stable in distributions.
So switching back was no longer an easy option
Also wrong. Not a single piece of major software doesn't work on non-systemd systems.
And many of these functionalities are way beyond the scope of an init system. It is almost a system
That was kind of the point. Starting a system and letting it be is 80s era OS design. Continual system management is what it's about. systemd is NOT an init system, it's a system management daemon, it's right there in the name.
When considerable amount of software regress (upower, etc)
If upower actually worked it wouldn't be abandoned. That's the problem with nasty hacks to try and make a system look like it's in control. When the system actually gets control the hacks become useless. If upower is important the non-systemd distros will support it.
In the past, it was shitty to set up but once it was set, it was working reliably
Reliable and functional are not the same things. Once you eventually battled through the setting the system up you were still stuck with a shitty architecture which couldn't cope with something as complicated and mindblowingly advanced like plugging in a set of headphones. The Linux sound system sucked. FreeBSD's system is better, they too completely abandoned the Linux variant due to it's horribleness.
Finally, what is the meaning of your last sentence? Is it not allowed not to enjoy systemd until you wrote yourself some systemd?
Of course you are. You're not allowed to shit on someone who doesn't realise one single thing while at the same time writing large parts of the fundamental parts of an OS, at least not until you yourself have contributed that much and have shown yourself to be *certified flawless*. The whole thing about the rm thing just shows how childish the entire debate is.
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.
unit files are soft replacement for not knowing how to shell script properly,
Why should you have to know how to shell script to boot your system properly? How is it better to have a full shell interpreter executing arbitrary logic to load system services better than just parsing a config file? That argument just makes no sense whatsoever.
If you do not know how to shell script, you have no business administering a server (ie, being a sysadmin) in a real-world environment. systemd may be fine for end-user graphical boot desktop environments (launchd works great for OS X), but this experience is from systems engineering and administration's perspective.
There are plenty of reasons why having logic over a config file is a tenable position. It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it. Config files are not a net win, and the win they do give you (boilerplating the most simple initscript cases) could easily be achieved a different way (like variables sent to a shell script that executes library code, a la /etc/init.d/functions.
Hire a Linux system administrator, systems engineer,
But having a default setting like that makes no sense.
Blame your distro manufacturer.
I take issue with what it was rewritten into. Which is the flaming pile of PulseAudio and SystemD.
Do better. Plenty of people have tried and this is the best we've got winning out on all technical merits.
I have yet to hear of issues like those caused by systemd.
Funny how you don't hear about closed source very well integrated and tightly controlled processes not having the issues of early adopted into the wide clusterfuck ecosystem that is Linux has.
But it was also designed to do one, launch programs.
If that's what you think then you know just as much about launchd as you do about systemd. Not a lot.
"Also wrong. Not a single piece of major software doesn't work on non-systemd systems."
Last time I checked, upower (working without functionalities is not working). upower is not major. But KDE power management is (was ?) done by upower. So power management in KDE does not, at least without workarounds. An example among others. I wont make a catalog, just to point out that your argument is kind of flawed.
(when you write "That's the problem with nasty hacks to try and make a system look like it's in control. When the system actually gets control the hacks become useless" I am under the impression you are clueless about the topic)
"Starting a system and letting it be is 80s era OS design. Continual system management is what it's about. systemd is NOT an init system, it's a system management daemon, it's right there in the name."
You cannot claim systemd is not an init and yet say that people should not complain because it is just a change of init.
I was fine with the notion of an init system. I am not interested in this continual system management why I managed to find broke in my uses cases already a few time.
"You're not allowed to shit on someone who doesn't realise one single thing while at the same time writing large parts of the fundamental parts of an OS"
Reality check: I am. Fact is I liked this OS better before he touched it. Fact is I am using now distros that does not contains the changes he made. But dont make it personal. It is not about one person. /foot/." is not a problem. Because that was the point you apparently missed, the problem is not that they guy is clueless about it but the fact that, because he was clueless about it, he decided we should not care.
And I am perfectly untitled not to trust someone that find "rm -f
Well, it seems I rarely share view with this guys about what matters. So I can only welcome people doing something else, like Devuan does.
Regarding sound in Firefox, default support for anything but PulseAudio has already been pulled and they are planning to remove the code supporting anything but PulseAudio in the near future.
https://bugzilla.mozilla.org/s...
Or maybe you want state-defined infrastructure and continuous integration, not just a bunch of ad-hoc scripts holding everything together with glue and tape. You can have logic in a config file if you think you really need it (see nginx, for example) without running a full blown interpreter with arbitrary code execution capabilities and complete freedom to operate as the root user anywhere on your system.
It basically boils down to: If you start with complex logic in a simple language, you can always simplify your implementation. If you start with simple logic in a complex language, you're stuck with that complexity as soon as anyone else starts using it.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
Funny how you don't hear about closed source very well integrated and tightly controlled processes
launchd is opensource. Which is how it made it into FreeBSD.
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.
systemd has its own lib directory. It is a much more memory intensive process than init.
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.
You are comparing apples and oranges. Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init. And systemd is much better in this regard than init.
Which shows you are using inncorect assumptions and don't know how to configure initd properly.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
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.
That doesn't happen.
No I am not. An evet management system and a process managenment system *should* be separate process entities that interact.
Maybe, maybe not. It depends on a lot of things. If your events need to spawn processes and your processes send events, there's a good argument to be made that they can't be easily separated. As an analogy, in the old days of compositing window managers, it was originally thought that a separate compositing manager could be made that would just communicate with the window manager. That turned out not to work because compositing needed to know more about window placement than originally thought and window placement need to know more about the compositing layer, so the necessary bi-directional communication was just creating too much latency overhead.
Initd farms out all of its work to the shell, so if you're going to look at memory consumption and software interrupts, you need to include the shell processes when comparing with init.
So what? unit files are going to run shell scripts and systemd has both problems, however you've missed the point - but I'll get to that next and address the new point you've raised first.
You are falling into the same flawed thinking all systemd proponents fall into, that the mis-used rc system (incidentally designed by red hat) is the justification for ditching initd and replacing it with systemd. Your example fails to take into account system processes that are compiled, executed from inittab with their environment managed by a shell that exits after it has done it's work, which is how the init system is supposed to be used.
For your example to be true I have to mis-configure init, and then configure systemd so that it won't spawn a shell for a process, which is common however the bar for failure on unix systems is generally so high that a shell process has to be so absurdly bad for it to become a problem. That's common between systemd and initd, so it's hardly a fair comparison.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources top(pped) only by firefox, X11. Even with 60 shell processes running they don't even make it into the top 80 processes consuming resources on my system. So I'll be interested in trying this on a server when I get back into the office.
So let's get back to the point.
And systemd is much better in this regard than init.
Only if the linux CPU scheduler has been re-written in the time between now when I posted my OP. systemd generates I/O and initd writes small messages to stdout as a char device. So as far as I can tell your premise, like the design of systemd, is based on flawed thinking because the CPU scheduler *will* bump processes off cores that hog resources in favor of I/O bound processes. In other words systemd can bump my important CPU intensive tasks that I want to be extremely responsive off a CPU core unless I configure the scheduler, which most people do not.
So unless systemd is now assuming the role of the kernel's CPU scheduler it is a Post Incident Review in waiting compared to initd.
The primary arguments behind using shell scripts are a) flexibility, and b) the shell is already there. So in other words, you can write a quick boot process for your system without properly designing system bootup. Once you have a proper dependency tree for bootup, you no longer need the flexibility of shell scripts and you can put a better system in place.
That's windows registry thinking, why the hell would I want that?
I want shell scripts to set up and check the dependencies are in place before my process is initialized in its appropriate runlevel. The thinking you have cited is the core reason for objections to systemd, that the flawed thinking is so apparent and obvious and forces us into a flawed paradigm by people who wrote a solution to a problem they did not properly understand.
That doesn't happen.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes we are relegated by systemd to scan through memory dumps to find that last block of information that should be in a log file. Sure the class type logging of systemd is pretty good, but not at the expense of root cause information that we may need to fix our own fuck-ups.
This is what highlights the fundamental design flaw of systemd. To write I/O for logging it demands CPU resources that otherwise would be consumed by a client process (breaking the usefulness of top as well), or it's less demanding of CPU with a higher chance of loosing logging and root cause information.
An analogy would be the ty
My ism, it's full of beliefs.
So what? unit files are going to run shell scripts
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
You are falling into the same flawed thinking all systemd proponents fall into,
Look, it's pointless to argue about this because it really comes down to a matter of needs and opinions. Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd. Furthermore, if you happen to like initd, you probably hate systemd. But it is not about right or flawed thinking. It is just a matter of opinion. You don't like systemd, that's fine you are entitled to your opinion.
Out of curiosity I tested your premise on a desktop linux box and found that systemd remains in the top 10 processes consuming CPU and memory resources
Systemd as PID1 doesn't sleep. If you are looking at that and comparing it to an idle bash process, you are not looking at the right thing. There is a lot of documentation on benchmarking of systemd if you really care about it, but if not feel free to keep building up strawmen just so you can knock them down.
Well unless you can explain to me how systemd writes the log blocks to disk as a machine crashes
The same way syslog does. Do you also complain about syslogd hogging CPU resources? Seriously, what are you smoking?
No, it depends on one thing. Does the first process manage system processes or everything? An event manager is a system process listening and acting on events. They are two different things.
What if the event manager responds to events by spawning processes? I guess it would then need to signal some kind of event to the process manager to do that.... <head splodes>
When you are only confined by your imagination, anything is possible. You won't actually know, though, until you try to implement it. There are plenty of cases in software development where the ideal of perfect modularity has been compromised to meet practical benchmarks. Go talk to Linus sometime about monolithic vs microkernels if you don't believe me.
My conclusions is systemd has several fatal design flaws, some presented here, that make it unsuitable for server systems.
Well, for your use cases that may be true, but it clearly isn't generally true. Some of the most enthusiastic systemd adopters are server admins and systems integrators.
I've had this discussion with MrKaos. Their use case and philosophies tend to be unique. Yes, init and inittab were designed to do some things that sysvinit and systemd reimplemented, but no, that's not necessarily a good reason to prefer using those tools. MrKaos should refrain from generalizing about systemd based on their own experiences and use cases.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
systemd has only won the day by fiat.
No need to lie, the processes were all public. Your side lost on technical merit, and you've never even bothered to familiarize yourself with the arguments. The simple truth is that not only were there good reasons to replace sysvinit, but every other commercial Unix and OpenRC and Upstart replaced sysvinit for the same good reasons. Fundamentally, scripts are a bad way to manage system processes, which is why there have been twenty years of effort trying to introduce kernel-level process management in Linux. Systemd is the result of a long development effort that you ignored from inception until after it was the dominant technology, and now instead of learning about this new technology you're walling yourself off from it. Good. Stay that way. Hopefully devuan can be the shibboleth that identifies ossified intellects and those who reject change on principle.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
No, unit files don't run shell scripts. They can as an easy migration path, but they are designed to operate independently of the shell.
I realise that. I said unit files are *going* to run shell scripts, in fact they are going to run *existing* int.d entries for most vendors that .
The way you *say* unit files *should* be configured is how inittab entries are configured after *optionally* being set up by shell scripts in the rc system, that is why a dependency tree isn't required. This misuse case is consistently demonstrated in these arguments and I haven't seen a distribution that utilizes initd properly. Which is crazy.
Systemd was designed to solve problems that are not easily solvable with initd. If you don't have those problems with initd, then you don't see the need for systemd.
Well what are they? I keep asking this question and I get no clear answer. I see plenty of vendors and distributions not using initd properly. They look at the steaming pile of shit scripts that Red Hat created in their misunderstanding of the rc system and throw their hands up, and I don't blame them.
What I don't buy is the same group that had a crap understanding of sysVinit and the rc system in the first place is now leading the charge to replace initd <slaps forehead> WTF? Perhaps my tolerance of bullshit is just extremely low.
Furthermore, if you happen to like initd, you probably hate systemd.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is. The best argument offered by systemd proponents is 'well you must be stupid, cause RTFM systemd" but have they ever spent any effort figuring how to actually use initd properly?
Have you? Have you ever configured a custom runlevel? or figured out how an rc script and an intitab entry should be used together? If you haven't where are your grounds for criticism? I've invested effort in learning systemd, it looks like a whole lot of domain knowledge to me. I don't really want to invest any more of my time into it, but I have to because inevitably I am going to encounter it somewhere.
What I don't like is being maneuvered into learning software and putting effort into something I can see is pretty awful.
but if not feel free to keep building up strawmen just so you can knock them down.
And you just feel free to ignore all the arguments about how the CPU scheduler actually works. How you can call that a strawman just boggles my mind with evidence that you are relying on social proof.
Seriously, what are you smoking?
Look, I don't really understand why you what to hurl emotive language around about operating system concepts. I can do it too, I just prefer not to. Yep, you can piss me off if you want but so far I've conducted a conversation with you about these things through a hang-over and a pretty bad headache right now, so maybe if you can keep it civil instead of treating me like a jerk maybe we can both learn something. Is that ok?
If systemd is so good, why can't you guys explain to me why instead of ignoring my arguments?
I sincerely want to know why I'm being asked to replace skill with a whole lot of dead wood domain knowledge? You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better. How can I take that argument seriously?
The same way syslog does. Do you also complain about syslogd hogging CPU resources?
No I don't, I just don't want my init process to do it. I want it to be lightweight and I want it to be out of my applications way. I don't want it to generate application latency. I don't care about syslog gener
My ism, it's full of beliefs.
Or maybe you want state-defined infrastructure and continuous integration
I think you'll find the reason that Etcetera has not answered you is because this is the primary operating mode of initd. These sorts of arguments for systemd are flimsy at best because they ignore existing functionality in initd.
I have no idea what you mean by this. Accurately defining the dependency graph for booting a system in a general way (ie: for any type of system with any type of hardware) is not a simple process in any language.
He is telling you initd is not complex, it is a foundation that you build complex modular interactions on, and that you can't make systemd less complex because it already is. Etcetera is telling you that you don't need a dependency graph because you are attempting to solve the wrong problem.
My ism, it's full of beliefs.
Well what are they? I keep asking this question and I get no clear answer.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
I see plenty of vendors and distributions not using initd properly.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
It's not about liking it. It's about how valuable the return on investment in learning a bad idea or investing effort in calling it out for what it is.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
You're suggesting to replace an elegant and subtly powerful initd with a complete paradigm shift, by the people who couldn't use initd properly in the first place and the best reason you can give me is, because someone else knows better.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No I don't, I just don't want my init process to do it.
Your init process (systemd) doesn't do it. Journald does.
You seem to thing having an highly active init process that generates I/O is a good thing
An event manager/dispatcher is going to generate I/O. I don't consider that a good or a bad thing inherently. It depends on how much (or if) you need the event manager. Considering that it is generating polling events at the same level as the watchdog and kworker threads, I don't think this is a huge problem to worry about. If you are going to make the argument that it causes significant application latency, then show me a real benchmark. Otherwise, this is just hand-wringing.
I think that initd could use a complementary event management subsystem, which is what I thought systemd was. If you understood how initd worked, the answer would be immediately apparent because it is obvious.
The only "obvious" thing that comes to mind from your description is an event manager that switches runlevels for you. Such a thing would be so inferior to what systemd does that it would laughable.
That's because you're not listening. You're just shouting people down saying the problems aren't really problems. As I said earlier, it comes down to your opinion. You don't think they are problems, so you don't see them.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets. I have repeatedly asked this question and still I have no answer. You are trying to reframe the arguments you yourself have not been able to answer. If any systemd advocate was able to answer they would simply answer the question with a concise justification.
Considering systemd advocates also have the benefit of hindsight to provide that concise justification of why you should use systemd, why don't you?
I'm listening, intently, for the use case over all the crickets.
Well, if you think it's so straightforward, why don't you lead the charge and implement all of systemd's features with init+inittab? Why is it taking so long for the anti-systemd crowd to come up with a suitable replacement? If it was really that easy, I would have expected to see it years ago.
I'm pro-initd, it's better than anti-systemd and much better than being anti-initd. You can't even justify the existence of systemd with a concise use case, so what exactly has to be written?
That said the reason I have been asking is for that exact reason: what complementary piece of software is required, what does it need to do, how should it interact with initd. So far the answer is software to make the core features of initd available to a wider audience because they aren't being used, that SCO effectively stole core functionality from initd with the AT&T source code license, Cgroups and, of course, better documentation. Most of all, is to free initd from that bloated crapware rc implementation that Red Hat surrounded it with.
So yes, I'll contribute to the devuan effort as I ascertain what exactly is required.
An hour of reading man pages and learning how to use some new utilities doesn't seem like that much an investment to me.
And how much time did you invest learning initd? A question you have avoided.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl, exploring its multitude of properties over a year ago because I have to be able to understand its impact. Guys like you are professing that it is so good that anyone using initd must be fucking idiot, all I've seen you and many systemd advocates profess is your ignorance of how to use initd properly and that someone says systemd is really good and that I should use it too.
I'm not a systemd expert, I'm still testing it. You and all the other systemd experts are supposed to tell me why I *should* use it, what I'm missing, why it's so great and you haven't and I think that is a rather hypocritical and disingenuous position that you maintain. Testing systemd so far hasn't shown me a good reason to use it, however it has shown me a few reasons why I should not.
You see, you don't understand why nobody is explaining it to you, but it has been explained many times by many people. I could make a list, but I'm tired of doing it, and you probably won't listen anyway. There are a ton of whitepapers and discussion topics on the init system and the various ways of implementing it. It is you who is ignoring all of the arguments in favor of your preference.
No, you won't make a list because you don't know. You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude. Pretty typical of someone arguing from a position of social proof to be unable to answer counter-rationalism and instead replies with moral superiority.
You should examine your own position relative to your accusations.
If you are going t
My ism, it's full of beliefs.
Bullshit. I ask one simple question What is the use case that systemd answers that initd does not and so far all I hear is crickets.
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification. Fact is, it doesn't matter the justification. You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore. Like I said earlier, it comes down to a matter of preference. If you don't need it for your use cases and/or you prefer initd, that's fine. Go ahead and keep using it. Those of us that like systemd and need it will continue using it.
So far the answer is software to make the core features of initd available to a wider audience because they aren't being used
No. What it comes down to is, I don't want to replicate systemd functionality by writing a bunch of shell scripts. I know it can be done. Apparently you enjoy doing that sort of thing. I don't. I want core functionality (ie: booting a system with a complex set of dependencies) to be readily available by writing/modifying a few configuration files, and that's it. Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
Considering I have a lab of VMs with systemd testing our applications, that I got my head around unit files, journalctl, systemctl
You claim that, but you still don't seem to know the difference between systemd and journald.
Guys like you are professing that it is so good that anyone using initd must be fucking idiot
Actually, if you look up in the thread, you will see that I am, and have been, saying the exact opposite. If you want/like initd, by all means keep using it. I have no problem with that. But if you call me an idiot for liking/preferring systemd, that's what I take issue with.
You and all the other systemd experts are supposed to tell me why I *should* use it
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
You've had two weeks and the only argument you can provide is to twist my words, ignore my questions and be rude.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude. But I don't see how I'm twisting your words. You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all. And you assert that somehow the principal operation of journald is so inherently different from syslogd that you lose information, which is just wrong.
And there we have it. You yourself are now citing Red Had's dumb serialization of initd's functionality with a crappy set of runlevel shell scripts and your limited understanding of initd's functionality
Speaking of twisting words, that is not what I said. However you choose to do it, rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
http://www.manpages.info/linux...
Being forced into following fools who can't make an
Multiple people have tried to tell you. There are plenty of whitepaper documents that describe the use cases. There is the entire Debian debate topic on the subject. In what way is any of this an insufficient justification? Why do you need yet another justification.
Multiple people have demonstrated that they didn't use initd properly in the first place. If you have further documentation to send me that demonstrates a full understanding of initd functionality before advocating replacing it send it. So far all of the articles I've read don't demonstrate that understanding.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question. This double standard again reeks of social proof.
You've decided systemd is unnecessary, so any justification that is provided you will refute or ignore.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
You are making claims about impact on performance without evidence and I'm asking for proof. You are making statements like "it generates i/o and therefore it is worse than a bunch idle processes doing nothing", which doesn't make any sense at all.
My advice is you understand how the CPU scheduler functions to understand this. As I said, I'm still testing systemd and it involves doing work to understand it.
Moreover, if I want to determine the status of a process and do something with that information, I think it is quite handy that systemd provides that interface. I don't have to scrape a bunch of logs or test for sockets and such. That information is just there for me to grab in a standardized, easily parseable format, provided by systemd.
You mean like the /proc interface.
Perhaps we will see a shell like interface emerging for systemd next?
You claim that, but you still don't seem to know the difference between systemd and journald.
I also claim not to be a systemd expert and that I am getting my head around it and in the process have found that it is a monolithic concentration of domain knowledge.
I've also repeatedly asked for the use case it answers that initd cannot so I can test it.
I don't have a lot of time to write long, detailed responses. I apologize for being curt; it is not my intention to be rude.
ok, appreciated.
rc scripts or some other mechanism, ultimately your "event manager" would have to initiate a runlevel change. That's the only thing init can do in response to some sort of "event".
No, just no. Obviously this is why better documentation is required.
Answer: use it if you want to, it has nice features. If you want to redo all of that with a bunch of custom shell scripts, go ahead and do it. Clear enough?
What you are arguing is a change of paradigm and mindset. You are arguing that complex is better than simple and I am arguing that simple can become complex.
And here you are, again, accusing me of being rude while in the same breadth calling me (and everyone else) a fool and/or idiot, but I digress...
No, who is the fool, the fool or those who follow the fool. Being forced to use systemd in some distributions is what I mean by being forced to follow fools.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer. That is a sign of foolishness.
If you're going to claim that it's because everybody is an idiot, then that's a reasoning that is pretty hard to accept.
This is the first time I've lost my patience and I di
My ism, it's full of beliefs.
Even you have demonstrated a consistent lack of understanding of initd functionality and when asked, three times now, how much time you've invested in learning it, you ignore the question.
I have not made a concerted effort to learn about undocumented features of init. I have used the features various distributions have provided for me to use. That's why distributions exist after all. If I were interested in building my own distribution, maybe we would be having a different discussion. As it is, I am more interested in just maintaining my systems and keeping things running smoothly. So I use the distribution tools that are provided to me. In the past it was initd and I used it without complaint. Now it is systemd, and I'm glad for the change.
What you are arguing is a change of paradigm and mindset.
No, I'm not. I am simply accepting of the fact that distro maintainers have chosen to replace initd with systemd. I have learned the new tools. I like them. I don't see the huge problem.
You are arguing that complex is better than simple
No. I'm arguing that simple is not simple. It just seems that way because you are used to it. When you've piled up a bunch of hacks and workarounds and have become used to implementing on your own or doing without missing functionality, you may think everything is great but it's not.
and I am arguing that simple can become complex.
If you want to write it. That's the whole point. I don't want to write it. I want the functionality to just be there.
The theme throughout systemd discussions is that those advocates refuse to listen to dissenting opinion and when challenged with counter-rationalism have nothing to offer.
You may think you are offering counter-rationalism, but you're not. Your entire argument boils down to "initd is better because I prefer doing things that way." You yourself have offered no other compelling reason for it. There is nothing wrong with a dissenting opinion, but understand that you are arguing for a preference, and other people have different preferences.
and I didn't call anyone an idiot
Well, I didn't call anyone an idiot either. So I guess we're even.
No, I'm looking for the irrefutable systemd use case that initd isn't capable of answering and so far no one has provided it.
Ok, I have time for one: socket activation. Tell me how to do that with initd. Don't say I don't need it. I want it. And don't say inetd. That's not good enough.