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.
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/. had a link to SystemD's own bug tracker where there was a bug someone submitted which was about SystemD corrupting the log during unexpected shutdowns. It wasn't just that you couldn't write to the log, but the entire log was lost. When one of the main devs closed the bug, he added a very sarcastic reason rhetorically asking the submitter how SystemD should be able to read a corrupted log and to delete the log and move on, working as intended.
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.
You use words and talk about things you don't even understand, you make gross generalizations and I'm sure you think that makes an argument. First, a customer is everything but stupid, surely you meant a consumer. You make fallacious sentences like "many systemd proponents will lie shamelessly about its characteristics". This sentence is a subject of study in itself, given that its meaning changes depending on who reads it. It contains no evidence, is based on nothing but your perception of reality. Then comes the scare tactic with this gem : "That also means that the NSA has its fingers deep in there, possibly without Poettering realizing". It seems to me you don't have even the start of a clue of computer science and how it works. It also seems to me that you keep the NSA as the utmost authority in security. Did you know that (you won't understand one thing of what I'm going to say but whatever) the NSA was beaten by their own weak cryptographic algorithm policy (low key length) that they imposed on foreign countries? The NSA is not the supra smart entity you think it is.
Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.
Was that an exercise in truth inversion? The Linux ecosystem is exactly what made systemd "win". And the rise of systemd occurred in a bottom-up manner actually. systemd actually didn't win anything, it just allowed the streamlining of using the Linux kernel specific features that nobody used because of catering to the lowest denominator. I was not surprised at all at how fast true admins got rid of sysvinit or even Upstart. On the machines I control, I've done this more than 15 years ago, going with simpleinit-msb for most of this time, before having to switch to an alternative because maintaining it was leaving me sometimes with security vulnerabilities to fix alone.
It worked.. except when it didn't. I should not have to hack my init scripts just because I have iSCSI or Clustered Fileystem mounts. Init was made in a time when the boot dependencies are more flat and don't do well at all when your setup requires network+daemon before the filesystem can be mounted.
Exactly! When you have several layers on top of your block devices, like RAID and LVM, it's even worse. It was such a pain before, despite the LVM or multipath daemons, I was never sure the servers would reboot correctly, or the config freeze or corrupts itself. Such a nightmare before systemd tackled the problems and sometimes the bugs in kernel or daemons, now it just works.
"And your vision of systemd is wrong by the way : educate yourself please."
How about you tell me then. Apparently you're such an uber admin that surely it'll be no problem to list the advantages of systemd compared to init. Right?
I won't do your work for you, and you must be a pretty bad one to talk about things you don't even know about. If reading skills and understanding skills are so challenging to you, you won't understand a thing, which is probably what happened already, given the copious amount of documentation available on systemd. There never were any for sysvinit and its scripts, and a very bad one for Upstart. Besides, you need experience with sysvinit or Upstart to understand the biggest advantages of systemd. Given my experience, I just don't take people that say sysvinit (or Upstart) had no problem seriously, less of my time lost this way.
its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.
the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.
Stop making fool of these veteran good unix sysadmins please. I will not associate with some fool like you. You people that know nothing love to give yourself a false authority by saying this nonsense everytime. But a good sysadmin will see through you without any problem. You trolls are so nonsensical that you say Upstart WORKED WELL and was available in the 80. Linux is not Unix BTW, if you were a seasoned Unix sysadmin, you would loathe Linux more than systemd, systemd is only possible because of Linux. You are wrong on all counts, so blinded by your hatred for something you don't even understand, it's pathetic. I've encountered very few admins that even understand how a Unix-like boots anyway, lots of seasoned admins just have no ideas. I've encountered far more Linux sysadmins that had this knowledge than anything else. At best you're one of them.
see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!
what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE).
You're wrong, plain and simple! Upstart was trying to solve lots of problems of sysvinit that a seasoned Unix admin should know about, it even used dbus. And the decision to use systemd by default in Ubuntu was the distro maintainers choice. No good reason to make better than sysvinit? I've seen reasons 16 years ago, that's why since then I never installed sysvinit init anymore on my own made Linux OS. And yet, in my work environment, I'm still to this day the most knowledgeable around about how all this sysvinit crap works, be it SYSV or BSD style.
faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?
If that's the only reason you know about, it just confirms you know nothing about systemd. This is not even one of the main advantage of systemd since years. The dynamic nature of the Linux kernel and its devices is one main reason.
So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?
No, once you said "I am not looking back", and then you come to a thread of the thing you weren't supposed to be looking at, I call you on your BS. Besides, this serves no purpose at all, this doesn't help people in the thread, and doesn't help him either. I see a poor person looking for validation because of his/her insecurity of having changed OS, which doesn't help his/her cause actually.
Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.
You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head. Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way. Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily. systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.
Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.
So you found vulnerabilities but don't even know how to exploit them ? People talking about things they don't even understand...
Systemd, eh? I predict that this thread will be filled with sensible and rational comments.
Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.
I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".
It's obvious you're not a fan of systemd, you can't even manage a Linux OS properly, restarting because of a PA crap (which would normally show a audio Linux module bug) that you're unable to handle correctly and then talking about debugging the init of your system which is far harder to do. Actually, debugging systemd startup is easier (or I should say faster) than debugging Upstart, especially the dependencies, there are tools included in systemd that do nearly everything for you. Besides, a sound server has nothing in common with an init system, so making comparisons between the two shows no technical knowledge at all. The end user experience of Ubuntu is not about the self-contradictory "debuggability, hackability and simplicity", it's about simplicity which contradicts your "hackability" statement. I don't see how the end-user experience is inferior, this makes no sense. When you change your timezone in the graphical UI and it is now synchronized automatically with the underlying OS, and the change is visible in the command line, when it was not the case before with Upstart (or sysvinit), that's an improvement in my book.
You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it?
Sure, there's a good reason. It makes things a lot easier for *them*.
Whether it makes things better or worse for everyone else remains to be seen.
No it doesn't remains to be seen, it's pristine clear that it's better for everyone else, as the "them" you're talking about are the only people affected by this change. Which is exactly the reason why everyone else don't understand what the change is about, they were never aware of this part of the system, except when they were affected by a bug in it (and there are tons of bugs still present today in upstart, bandaids and the like). It's striking to see that when Debian had sysvinit, Ubuntu made Upstart because sysvinit was such a pain. But the switch of Debian to systemd was enough of a step forward compared to managing Upstart alone, that Ubuntu decided to switch to systemd.
Its like asking whether you'd preferred to be mauled by a rottweiler or a pitbull.
Both are just change for changes sake and neither bring much new to the table. Sure the scripts for init could get messy but they worked, everyone was familliar with them and if no major issues have cropped up since 1991 (or 1970 for unix) then its a fair bet its a reliable sub system.
But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls decided they could reinvent the wheel better. Well so far the jury is still out on that.
Actually, what you say just says a lot about your knowledge of these sysadmin issues : you know nothing at all and you are spewing nonsense, which perhaps will fool people that aren't interested in these issues, or will be brushed off as ignorance by people affected by these issues. The outcome will be the same in both cases : what you say won't have any credence and is completely useless. I don't know in which world you live where "so far the jury is still out on that", you must have missed the last 6 months at least : it's over. And your vision of systemd is wrong by the way : educate yourself please.
sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits
You haven't looked back, and yet here you are looking back at a linux distro that uses systemd. Basically, you make no sense : lying to yourself is not a solution. It's obvious you crave for what is happening in the Linux systemd world, which is the contrary to "not looking back". Or perhaps you're right, which would mean you think that you have gone back by going openbsd, and you are now looking forward to Linux distro using systemd.
The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD.
Isn't that supposed to be funny? People on Slashdot actually believe this load of bullshit? UUID for disks folded into systemd? systemd crowd (developers?) are windows devs? sysadmins don't reboot servers? If that's the "knowledge" of the new wave of Linux users, I guess old Linux sysadmins won't have to fear for their jobs.
Essentially it's being bundle in with other services.
That's the only truth in this post till now.
Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.
Another lie. The main problem of systemd is that there's so much to do given the state of Linux init systems, that it's still a fast moving target, too fast for distros. It will stabilise when most of the features are implemented.
Pros: * Boots fast
Cons: * When it breaks, you're fucked * Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools * No real new features * Is network connected and running as superuser * Is unaudited * Is virtually untested * Was written by a raging moron * Is completely unneeded by a large section of people who have run linux for a long time
Essentially, it's the Windows 8 of the *nix world
This shows a lot of ignorance on even how a Unix like system works. Init is launched by the kernel, so of course it runs as super user, and no, it's not network connected, not PID 1 at least. The rest is drivel or nonsense, like it obsoletes 20-30 years of best practices and knowledge, this makes no sense, I can operate my servers with best practices that I couldn't use with sysvinit, and I still use the linux (you mean GNU?) tools the same with systemd. Executables configuration scripts (init scripts) are not at all best practice, even less when they use configuration files of their own, scattered in several different files, and whose behaviour can be modified by the environment, making for a huge attack surface that can go undetected. That's what you call best practices? And calling people names doesn't make your argument any better.
But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).
You would not understand as you've shown below and above that you're not the audience to even start to understand what it's all about. The minority you're talking about is the exact same that was maintaining the init scripts before, you can be assured they know what it is about. And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible. systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.
I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows: -About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know. -The same Fedora box cannot mount/home at bootup. I have to log in as root, and mount it over command line. -Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.
The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it. Reading bash scripts is much easier.
Now you're spewing nonsense. This is not your experience with systemd, this is your experience with some specific version of Fedora. Linux crashes,/home not being mounted and other problems are not fixed by searching Google blindly or reading manuals or reading bash scripts, this makes no sense at all. Reading init scripts wouldn't help you understand what is going on. There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that. Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration. Other vocal people don't even have that common sense unfortunately.
Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.
Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.
What you are saying doesn't compute. If the init scripts were working well in the last 20 years, why do you need distro maintainers to maintain them? Why is there the fear of these init scripts rotting away if not tend for? Real sysadmins who have worked with these damned init scripts and are not lying to themselves know perfectly why. Init scripts are flawed by design on a dynamic kernel like the Linux kernel, and this problem was there before 2000 already. That's actually one of the main huge benefit of systemd, with gettiong rid of executable configuration files (init scripts), which are a huge surface attack on any sysvinit system. I have seen countless security issues related to bad things done in init scripts, like for example creating temporary files or directories, which is handled securely by systemd.
Slashdot Mirror
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 /. had a link to SystemD's own bug tracker where there was a bug someone submitted which was about SystemD corrupting the log during unexpected shutdowns. It wasn't just that you couldn't write to the log, but the entire log was lost. When one of the main devs closed the bug, he added a very sarcastic reason rhetorically asking the submitter how SystemD should be able to read a corrupted log and to delete the log and move on, working as intended.
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.
You use words and talk about things you don't even understand, you make gross generalizations and I'm sure you think that makes an argument.
First, a customer is everything but stupid, surely you meant a consumer.
You make fallacious sentences like "many systemd proponents will lie shamelessly about its characteristics". This sentence is a subject of study in itself, given that its meaning changes depending on who reads it. It contains no evidence, is based on nothing but your perception of reality.
Then comes the scare tactic with this gem : "That also means that the NSA has its fingers deep in there, possibly without Poettering realizing".
It seems to me you don't have even the start of a clue of computer science and how it works. It also seems to me that you keep the NSA as the utmost authority in security.
Did you know that (you won't understand one thing of what I'm going to say but whatever) the NSA was beaten by their own weak cryptographic algorithm policy (low key length) that they imposed on foreign countries?
The NSA is not the supra smart entity you think it is.
Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.
Was that an exercise in truth inversion?
The Linux ecosystem is exactly what made systemd "win". And the rise of systemd occurred in a bottom-up manner actually.
systemd actually didn't win anything, it just allowed the streamlining of using the Linux kernel specific features that nobody used because of catering to the lowest denominator. I was not surprised at all at how fast true admins got rid of sysvinit or even Upstart.
On the machines I control, I've done this more than 15 years ago, going with simpleinit-msb for most of this time, before having to switch to an alternative because maintaining it was leaving me sometimes with security vulnerabilities to fix alone.
It worked.. except when it didn't. I should not have to hack my init scripts just because I have iSCSI or Clustered Fileystem mounts. Init was made in a time when the boot dependencies are more flat and don't do well at all when your setup requires network+daemon before the filesystem can be mounted.
Exactly! When you have several layers on top of your block devices, like RAID and LVM, it's even worse.
It was such a pain before, despite the LVM or multipath daemons, I was never sure the servers would reboot correctly, or the config freeze or corrupts itself.
Such a nightmare before systemd tackled the problems and sometimes the bugs in kernel or daemons, now it just works.
"And your vision of systemd is wrong by the way : educate yourself please."
How about you tell me then. Apparently you're such an uber admin that surely it'll be no problem to list the advantages of systemd compared to init. Right?
I won't do your work for you, and you must be a pretty bad one to talk about things you don't even know about.
If reading skills and understanding skills are so challenging to you, you won't understand a thing, which is probably what happened already, given the copious amount of documentation available on systemd. There never were any for sysvinit and its scripts, and a very bad one for Upstart.
Besides, you need experience with sysvinit or Upstart to understand the biggest advantages of systemd.
Given my experience, I just don't take people that say sysvinit (or Upstart) had no problem seriously, less of my time lost this way.
if I had mod points, I'd mod you as troll.
its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.
the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.
Stop making fool of these veteran good unix sysadmins please. I will not associate with some fool like you. You people that know nothing love to give yourself a false authority by saying this nonsense everytime. But a good sysadmin will see through you without any problem.
You trolls are so nonsensical that you say Upstart WORKED WELL and was available in the 80. Linux is not Unix BTW, if you were a seasoned Unix sysadmin, you would loathe Linux more than systemd, systemd is only possible because of Linux.
You are wrong on all counts, so blinded by your hatred for something you don't even understand, it's pathetic.
I've encountered very few admins that even understand how a Unix-like boots anyway, lots of seasoned admins just have no ideas.
I've encountered far more Linux sysadmins that had this knowledge than anything else.
At best you're one of them.
see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!
what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE).
You're wrong, plain and simple!
Upstart was trying to solve lots of problems of sysvinit that a seasoned Unix admin should know about, it even used dbus.
And the decision to use systemd by default in Ubuntu was the distro maintainers choice.
No good reason to make better than sysvinit? I've seen reasons 16 years ago, that's why since then I never installed sysvinit init anymore on my own made Linux OS. And yet, in my work environment, I'm still to this day the most knowledgeable around about how all this sysvinit crap works, be it SYSV or BSD style.
faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?
If that's the only reason you know about, it just confirms you know nothing about systemd. This is not even one of the main advantage of systemd since years.
The dynamic nature of the Linux kernel and its devices is one main reason.
So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?
No, once you said "I am not looking back", and then you come to a thread of the thing you weren't supposed to be looking at, I call you on your BS.
Besides, this serves no purpose at all, this doesn't help people in the thread, and doesn't help him either.
I see a poor person looking for validation because of his/her insecurity of having changed OS, which doesn't help his/her cause actually.
> journalctl -f
Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.
You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way.
Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily.
systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.
Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.
So you found vulnerabilities but don't even know how to exploit them ?
People talking about things they don't even understand...
Systemd, eh? I predict that this thread will be filled with sensible and rational comments.
Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.
I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".
It's obvious you're not a fan of systemd, you can't even manage a Linux OS properly, restarting because of a PA crap (which would normally show a audio Linux module bug) that you're unable to handle correctly and then talking about debugging the init of your system which is far harder to do.
Actually, debugging systemd startup is easier (or I should say faster) than debugging Upstart, especially the dependencies, there are tools included in systemd that do nearly everything for you.
Besides, a sound server has nothing in common with an init system, so making comparisons between the two shows no technical knowledge at all.
The end user experience of Ubuntu is not about the self-contradictory "debuggability, hackability and simplicity", it's about simplicity which contradicts your "hackability" statement.
I don't see how the end-user experience is inferior, this makes no sense. When you change your timezone in the graphical UI and it is now synchronized automatically with the underlying OS, and the change is visible in the command line, when it was not the case before with Upstart (or sysvinit), that's an improvement in my book.
You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it?
Sure, there's a good reason. It makes things a lot easier for *them*.
Whether it makes things better or worse for everyone else remains to be seen.
No it doesn't remains to be seen, it's pristine clear that it's better for everyone else, as the "them" you're talking about are the only people affected by this change.
Which is exactly the reason why everyone else don't understand what the change is about, they were never aware of this part of the system, except when they were affected by a bug in it (and there are tons of bugs still present today in upstart, bandaids and the like).
It's striking to see that when Debian had sysvinit, Ubuntu made Upstart because sysvinit was such a pain. But the switch of Debian to systemd was enough of a step forward compared to managing Upstart alone, that Ubuntu decided to switch to systemd.
Its like asking whether you'd preferred to be mauled by a rottweiler or a pitbull.
Both are just change for changes sake and neither bring much new to the table. Sure the scripts for init could get messy but they worked, everyone was familliar with them and if no major issues have cropped up since 1991 (or 1970 for unix) then its a fair bet its a reliable sub system.
But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls decided they could reinvent the wheel better. Well so far the jury is still out on that.
Actually, what you say just says a lot about your knowledge of these sysadmin issues : you know nothing at all and you are spewing nonsense, which perhaps will fool people that aren't interested in these issues, or will be brushed off as ignorance by people affected by these issues.
The outcome will be the same in both cases : what you say won't have any credence and is completely useless.
I don't know in which world you live where "so far the jury is still out on that", you must have missed the last 6 months at least : it's over.
And your vision of systemd is wrong by the way : educate yourself please.
sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits
You haven't looked back, and yet here you are looking back at a linux distro that uses systemd.
Basically, you make no sense : lying to yourself is not a solution.
It's obvious you crave for what is happening in the Linux systemd world, which is the contrary to "not looking back".
Or perhaps you're right, which would mean you think that you have gone back by going openbsd, and you are now looking forward to Linux distro using systemd.
The SystemD crowd are windows devs who hate 8 so much, they finally decided to get into linux. Sadly, they want linux to work like windows, so they foist their shit into it. It does make boot times faster: something sysadmins usually don't give a shit about since you don't reboot servers. Red Hat wants systemD because it will let them abstract linux (the kernel) away to the point where they can control it instead of "the community". In addition, several genuinely nice tools, UUID for disks, are being folded into SystemD so, in order to get those tools, you *must* also use SystemD.
Isn't that supposed to be funny? People on Slashdot actually believe this load of bullshit?
UUID for disks folded into systemd? systemd crowd (developers?) are windows devs? sysadmins don't reboot servers?
If that's the "knowledge" of the new wave of Linux users, I guess old Linux sysadmins won't have to fear for their jobs.
Essentially it's being bundle in with other services.
That's the only truth in this post till now.
Sadly, SystemD is not well tested enough for most people running linux on a server to trust it especially since the guy who wrote it wrote PulseAudio and people are still having issues related to that piece of shit.
Another lie. The main problem of systemd is that there's so much to do given the state of Linux init systems, that it's still a fast moving target, too fast for distros. It will stabilise when most of the features are implemented.
Pros:
* Boots fast
Cons:
* When it breaks, you're fucked
* Obsoletes 20-30 years of accepted best practices and knowledge of how to use linux tools
* No real new features
* Is network connected and running as superuser
* Is unaudited
* Is virtually untested
* Was written by a raging moron
* Is completely unneeded by a large section of people who have run linux for a long time
Essentially, it's the Windows 8 of the *nix world
This shows a lot of ignorance on even how a Unix like system works. Init is launched by the kernel, so of course it runs as super user, and no, it's not network connected, not PID 1 at least. The rest is drivel or nonsense, like it obsoletes 20-30 years of best practices and knowledge, this makes no sense, I can operate my servers with best practices that I couldn't use with sysvinit, and I still use the linux (you mean GNU?) tools the same with systemd.
Executables configuration scripts (init scripts) are not at all best practice, even less when they use configuration files of their own, scattered in several different files, and whose behaviour can be modified by the environment, making for a huge attack surface that can go undetected. That's what you call best practices? And calling people names doesn't make your argument any better.
That baffles me too.
But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).
You would not understand as you've shown below and above that you're not the audience to even start to understand what it's all about.
The minority you're talking about is the exact same that was maintaining the init scripts before, you can be assured they know what it is about. And I can perfectly understand why these people would ditch sysvinit and init scripts as soon as possible.
systemd is a good thing for a lot of reasons that you will be unable to understand, given what you write below.
I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows: /home at bootup. I have to log in as root, and mount it over command line.
-About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
-The same Fedora box cannot mount
-Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.
The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
Reading bash scripts is much easier.
Now you're spewing nonsense. This is not your experience with systemd, this is your experience with some specific version of Fedora. /home not being mounted and other problems are not fixed by searching Google blindly or reading manuals or reading bash scripts, this makes no sense at all. Reading init scripts wouldn't help you understand what is going on.
Linux crashes,
There is one thing to do in this case : searching for logs that will give you a hint at your problem (the error at bootup is not enough), to have a start of an understanding of what's going on. That's the basic and you don't even have that. Fortunately you have the sense of not being vocal about systemd when you don't have the basics of system administration. Other vocal people don't even have that common sense unfortunately.
Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.
Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.
What you are saying doesn't compute. If the init scripts were working well in the last 20 years, why do you need distro maintainers to maintain them? Why is there the fear of these init scripts rotting away if not tend for?
Real sysadmins who have worked with these damned init scripts and are not lying to themselves know perfectly why.
Init scripts are flawed by design on a dynamic kernel like the Linux kernel, and this problem was there before 2000 already.
That's actually one of the main huge benefit of systemd, with gettiong rid of executable configuration files (init scripts), which are a huge surface attack on any sysvinit system. I have seen countless security issues related to bad things done in init scripts, like for example creating temporary files or directories, which is handled securely by systemd.