Nice inversion. The emotional appeals come from the pro-systemd people, valid technical arguments on that side are nowhere to be found.
Anyway, systemd won, and I can now enjoy seeing all the incompetent fools that were against systemd be proven as truely incompetent fools as time goes by and systemd just chugs along without the mythical problems they were talking about but never explained (as they don't exist).
You mean like RH prior to RHEL 7? Or how about Slackware? Gentoo? Ubuntu LTS? Plenty of distros exist[ed] without systemd and didn't suck. What Red Hat and the systemd crowd doesn't want to here is that most users that care do not want systemd. Most users have no opinion one way or another. Most that do care were perfectly content with the old system and saw much bigger problems in the Linux world that fighting over replacing init takes time away from. If we really needed a new init system, then why not adopt launchd, SMF (which systemd wishes it was), or upstart, and focus on issues that actually matter? Instead, Linux is losing long time supporters and is fracturing itself.
But you're wrong plain and simple.
sysvinit and its shell scripts was one of the reasons I decided to make my own distro from upstream sources 15+ years ago.
I saw already that these things were security nightmares added to the fact that they were buggy and impossible to fix in the cases where design flaws were involved.
To this day, they are full of kludges and nonsense, and proprietary software vendors are no better than a newbie sysadmin as to their knowledge of init scripts.
Everything I've seen was full of bugs or made for the most simple case.
I think that's why LVM was so badly supported in most distro, except in Red Hat ones, as RH employees develop LVM2.
And I say that because I mastered init scripts, I corrected countless ones on distros. But I could never do anything about its design flaws, and had to just shake my head when I saw sysadmins launching them directly when the scripts weren't cleaning their environment correctly (which they can't do properly anyway) and they got different bad results, like believing a daemon was launched because the script said so, but the daemon wasn't launched at all.
People that say init scripts were working correctly, I just can't take them seriously, init scripts never worked correctly in the first place, unless you knew what you were doing and mastered everything about a session and its environment, and lots of other things.
I'm no genius to have seen all the flaws in sysvinit, lots of people saw them and tackled the problem, and I often used their solution, I've went years with simpleinit-msb (after using simpleinit), which I had to support (patch) myself when it was abandoned until it was too hard and when I went searching for a better one, I first tried Upstart, which was a PITA, then systemd appeared and I never looked back.
None of the init solutions I've tried along the years gained traction. Even systemd at first, the inertia was too strong. I thought it was sad, but at least I didn't have to deal with sysvinit crap at home.
That tired old lie again...
Making a distro is not something a single person can do. And if you were not intent on spreading lies, you would acknowledge that as it is rather obvious.
You're plain wrong. If you count LFS as a distro, then I have made a distro as a single person, as I made my own more than a decade ago and that's the one I use at home since then. It's used for all the family to use, several computers in the house, on my embedded ones, on my MythTV one, on my firewalls,
The only big difference is that I don't maintain it for other people.
This is where most of the hard, boring and tedious work is, and I don't want to do that, especially when I see how distro makers are treated here or elsewhere.
Lots of people asked me why I don't release my OS as a distro. This is the reason, and I can add the fact that it surely would be duplicate with one from other people who are knowledgeable enough to do exactly the same thing that I'm doing.
Red Hat is operating right out of Microsoft's playbook.
Remember when Microsoft was buddy-buddy with Apple, and IBM?
Once Linux is completely dependent on Red Hat controlled technologies, Red Hat will always be two steps ahead of the competition, it will be seriously difficult for Linux users to use anything except Red Hat.
What happens when Red Hat decides there is no reason for more than one package management solution? Red Hat will say that users demanded one standardized package management, and systemd will only work if Red Hat's solution is installed. Wait for it.
You should learn what Free Software is, because right now you look like an idiot.
The GPL prevents the kind of control you're talking about, and systemd is licensed under the GPL.
Plus systemd contains a PID 1 daemon so what you say doesn't make any sense.
Theres an old saying, which Im going to modify for my own purposes.
Those who can, make distros. Those who cant, whine endlessly about what the distros are doing.
I make my own distribution using Linux From Scratch (LFS) as the basis. Yet I do not think SystemD is a worthy replacement for SysVinit. No log file should ever be binary. Period. Full stop.
I'm doing that too, all my systems are made from scratch with an automated tool based on nALFS that I maintain alone.
I use systemd since before it was even officially released and have never looked back since. I abandoned shitty sysvinit 15+ years ago on my systems and never looked back.
You don't even understand what the journal is doing, I won't debate this nonsense while on all my servers, I have the journal plus text log files via rsyslog.
If you can't even do that and yet you claim to use LFS, I bet you didn't understand one thing of what you were doing, which defeats the purpose of using LFS.
But linux use on the desktop is growing?
I mean if we want to include android it's one of the most popular OSes in the world.
Android is not Linux, nor is Android a desktop OS of any kind. Yes, Android probably is one of the most popular OSes in the world, but we're talking about Linux on the desktop here, which is an entirely different animal. The kernel is the only thing they have in common.
It is hard to say whether it's growing or not. You say it's growing, hairyfeet says it's shrinking, who's right? What I do know is true is that desktop PC sales are shrinking, thanks to mobile devices and to people hanging onto their hardware longer.
Except that Android is Linux on the desktop, Android is used as a "desktop" on lots of tablets actually.
You didn't know it, but the kernel is Linux, so Android is actually Linux, it's not GNU/Linux though.
You may not like these facts but I know lots of people have problems with reality, that's life.
Obviously you don't grok anything about what you are doing, you're ignorant but still you blame systemd.
Hint: systemd is not what is installing your distribution, systemd has nothing to do with the fact that your distribution won't upgrade correctly.
Lol no, and it likely never will be, sadly.
Perhaps if Devuan was headed by someone other than a pot-smoking hippie called Jaromil that bans anyone who is opposed to feminism etc, then maybe Devuan might do something and save us.
But it is, and it won't.
Oh man, I knew Devuan was BS, just by reading their supporters on Slashdot who are mostly people with no technical knowledge at all regarding init systems, but now that I know that its members are feminist friendly, I'm sure it won't go anywhere. SJWs are not compatible with improvement IMHO, I wouldn't touch these people with a 10 feet pole.
Plausible. Also a strong indication of inexperience and incompetence on the side of the systemd team. Of course we already knew that. It is not like they could have looked at what was already there and find solutions that work, like mounting/umounting NFS at a different time....
Actually, it's a strong indication of inexperience and incompetence on the side of the "sysadmin" who experience this issue.
I have several servers and desktops with NFS mounts and systemd, and they all start and stop extremely fast.
Some desktops have the home mounted as NFS, and they shutdown in less than 2 seconds, which always amazes me.
Perhaps the difference is that all my NFS mounts are defined as systemd units, and they are all using the "on demand" feature of systemd, which equals automount. Automount was how I was handling my NFS mounts before systemd, so as not to break my systems in case of network issues, which would mean a reboot.
In the past year, someone on
You should not go everywhere talking about your understanding problems. We understand you can't read correctly or understand anything about computer science.
For the record, the log is NOT lost, it is still there (unless the filesystem removed it), and only the corrupted part in it are not displayed by the systemd standard tools.
And no, systemd does not corrupt the log during unexpected shutdown, there is no code to do such a mischievous thing in systemd.
Actually, computer programs are not sentient entities, they're not magic, they're not self aware. It's just that an unexpected shutdown in itself prevents the OS from doing its normal cleanup, and the corruption can happen at any level. Filesystems and (log) files got corrupted by unexpected shutdown before systemd was even created.
The devs don't care. These issues have been reported. Like the binary log corruption bug. After over 1 year of sitting, the bug got closed with a "working as intended" and dev border-lining lambasting the submitter. I can understand that a file can get corrupted because of faulty hardware or an FS bug, whatever. What I don't understand is how someone designs something as critical as a log to be non-atomic and easily get corrupted from an unexpected shutdown because it's designed that way.
As someone who designs systems that must be maintained, logging is vital to any amount of debugging why a system failed. SystemD fails with the most fundamental issues.
I can't believe one moment that a company gives system design to people like you who have astounding comprehension issues.
You don't have any idea of how a log or any file is written to disk, you are still wondering why an unexpected shutdown can corrupt a file, I dare not tell you that can corrupt an entire filesystem, gasp!
It's pathetic to read such behaviour, because logs got corrupted before with your syslog daemon, but you weren't aware of it. For you, as you weren't aware of it, your log weren't corrupted: a fallacy you can't manage to grasp. Sorry, that's not how it works in the real world. Now, journald can verify its log integrity, and all of a sudden, lots of ignorant people come complaining about a problem that always was there, because journald actually provides this information. Instead of being thankful, ignorant people calling themselves sysadmins want others to do the work only themselves can do, which is securing their log files and their filesystems.
Already a little bit older, but still completely relevant:
- There are no technical merits of systemd that are important or critical, just some convenience issues
This is your opinion, you're entitled to it, my opinion is the contrary of what you're saying.
systemd replaces many of the kludges that were inconsistently added to sysvinit (like daemontools or inetd) to have a system that was a little bit manageable.
Even process management was pathetic with sysvinit, nobody used it because of that, except to launch getty and a bunch of scripts, which is very sad.
- Systemd is in hurried development, a stable feature set is nowhere in sight
That much is true, that's the true problem between systemd and stable distributions. The other benefits must be huge for the distributions to accept to maintain old systemd releases (like 209 which is full of various bugs which can be annoying).
- The development leads are known incompetents with inflated egos and no communication skills
Fallacy, and again your opinion, mine is different. I find the development leads very competent, I'm noone to judge on their ego and I don't care, it's irrelevant to code an init system, like communication skills which are not needed at all to code. To troll on Slashdot, perhaps communication skills are useful, but not to code an init system. Which must be why systemd is so much more advanced than the other init systems on Linux.
- There are a number of design decisions that are very, very bad for security and stability
So file bug reports, that's how it's done in the community. Anti-Linux shills however, they only troll and never do anything.
You can even go to the dev ML and explain the problems. I don't see any design decision which is bad for security and stability myself, but several minds are better to locate these.
The rest of your post is nonsense: systemd has only been evaluated on its technical merits, that's how it won nearly every Linux distro.
Is there any proof or are the faster boot times just on the wish list?
I can't remember where but I distinctly remember reading that systemd does NOT provide the fastest boot times. Faster than sysvinit in many scenarios, but not faster than some other parallel startup setups.
But then really fast boot times was not at all the point. It was more of a side effect of being an event based init system rather than a linear list of scripts executed in order. In fact the speed of boot is not mentioned on the project page, and even Poettering's blog only mentions that it's faster than Upstart in Fedora 17 and only due to one specific reason.
systemd actually DOES provide faster boot times, but that's in a native systemd environment, not in a kludge one where systemd has to launch shell scripts.
Actually, systemd is so fast that it showed lots of race conditions in many projects startup, like gdm or mysql.
It's true that fast boot times was only one point at the start of the systemd project, it never was its ultimate goal.
Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds
sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.
Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.
My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...
Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.
Your examples are useless as long as we don't know if systemd was running in native mode (with only systemd units) or in compatibility mode (by having to translate init scripts to units and still launch them as shell scripts). In compatibility mode, systemd has more work to do than in native mode. The compatibility mode is basically useless for systemd, it's only useful for the admin as a temporary workaround, when you're translating init scripts to systemd units.
Only then can you really enjoy the power of systemd.
Ah yes, SSD. Didn't Poettering recently yank the "spinning rust" optimizations from systemd because all the devs used SSDs?
This will the kernel devs decided to keep an old subsystem around because someone, somewhere, was still using it?
The difference in attitude between the kernel and userspace is staggering. I swear userspace devs are actively user hostile at times.
There's no difference between kernel and systemd for old subsystems, you're just plain wrong with understanding problems or ignorant on purpose.
What was yanked is the readahead part, and it is because there was no maintainer for it. The devs didn't have SSD so they couldn't maintain it.
It's pretty basic stuff that are very easy to understand, the same happens in the Linux kernel.
Now, when I read your conclusion from these facts, I'm sure I won't ever ask you any advice or logical thinking.
People will buy anything that's one to a customer.
