This! The systemd documentation is horrible. And, why should stderr be discarded by default?
Learn to read, it's written in the configuration that the default is NOT to discard stderr, but in the contrary to log it in the journal. The systemd documentation is actually wery good, your reading skills though are horrible.
It is! The default for systemd upstream is to put standard output in the journal and inherit this setting for standard error. Which means with the upstream configuration of systemd, everything goes to the journal. So if that is not the case in your distribution, it's the distribution that actually chose that way.
The upstream systemd defaults are sane from my sysadmin point of view : I never had to change them.
You forgot those of us who have been around long enough to have survived major sea changes like os390 -> UNIX -> Solaris -> windows -> linux. Systemd saddens me because it makes servers act like workstations. And sadly, the distro maintainers made way too hard of a turn into systemd, forgoing 20 y/o standards. For example, on a CentOS minimal system, no ifconfig/netstat? Instantly breaks monitoring tools.
Very bad sysadmin masquerading as a good one, that's the problem right here. For the record, ifconfig is deprecated (and useless in any slightly complex setup) for years on Linux in favor of iproute2 tools, and netstat disappearance has nothing to do with systemd and everything to do with your distribution or how you installed it. And systemd didn't make my servers into workstations, what does it even mean? Is systemd installing X onto your servers? If that is the case, I can assure this a distro choice (strange for a minimal one) and has nothing to do with systemd. Next thing we'll learn is that you were one of the few using LSB extensively.
Ah, so there is a propaganda guideline. Fits. It nicely explains why the same fallacies and emotional bullshit is vomited by the pro-systemd sect every time. They seem to have fallen for "it it is written, then it is truth" and completely have stopped to actually think about anything.
Nice inversion. Actually, 99 % (to not say 100 %) of the anti-systemd crowd show a complete lack of understanding of even the simple issue discussed in the OP. It's sad that even a mainly developer like Poettering is understanding more about system administration than most of the crowd that vomited fallacies and emotional BS on Slashdot. It's scary and just shows that there is no technical answer to systemd in the horizon anytime soon. I've seen not even ONE technical rebuttal on the article. At the same time, it would be difficult as the problem here is specific to systemd related to the environment and security, and makes perfect sense. Fortunately, some people pointed that systemd was not replacing su, only someone that didn't understand what was being said would say that, which means the frightening thing that even the OP didn't understand what was being said.
The good news is that it means good, seasoned sysadmins don't care anymore to answer to these nonsense articles disparaging systemd from their lack of understanding. The bad news is that given this pathetic level of skills in opposition, systemd is not to see competition before a very long time. The pathetic news is that uselessd dropped out of their nonsense project... for the very specific reason that was cited by L. Poettering, no less, and which was obvious for even someone like me who is no professional programmer. Reasons that were cited as nonsense by people that have no skills and no knowledge, and most of all not willing to do the work: the anti-systemd crowd.
Like most reasonable sysadmins and I said, time will show who was right and who was wrong. Given my level as a professional admin and the fact that I jumped into systemd as soon as it appeared, I have no doubt on the future.
The classical UNIX philosophy is one daemon one goal, perfectly implemented, fully secured and full documented. Systemd breaks this view and takes the windows 7 and before concept.
We know that results of this second philosophy: One software that does everything, using a quick and dirty implementation, with an incomplete, and erroneous documentation, and the security is done in a fully procrastination way... Are you sure that systemd can really escape this second philosophy? In my opinion it can’t. I’m still using the slackware distribution, and I hope they will stay away from systemd.
Your premise about systemd is already wrong from the start, because you don't even know what you're talking about. No wonder then that everything else you say is plain wrong. systemd has nothing to do with Windows 7 and before, it's based on Linux specific kernel features, so you mean Linux takes Windows 7 and before concepts? systemd opponents love making fools of themselves, it's pathetic really. Don't you know the systemd proponents are mostly proficient people, not stupid enough to believe such nonsense?
"One big gain is not having to write my own custom init scripts"
Is this really a big problem for people?! I hear this all the time. Init scripts are shell scripts. They're really simple. I can't even conceive of how one could manage to develop a UNIX daemon and not the shell script to manage its execution.
Init shell scripts are not really simple, that's why you don't understand the problem. They require lots of work and maintenance, which was invisible to users, especially in Linux distributions. The same people that repeat that shell scripts are simple and work perfectly, usually know this, and they know that as soon as distro sysadmins stop maintaining them, the work will be on these users shoulders. So they spread lies, but lies won't make the work. So this was a lost battle from the start. There's a reason sysadmins were writing their own custom init scripts, and custom scripts means you have to maintain them when the system updates, so you have to register every single one of them and look for regression. This is lots of work. And no, good daemons need no shell scripts to manage their execution, and it is nonsense to do that. Even sysvinit has a very basic daemon management feature, that nobody used because it was too basic. Shell scripts have none and can't do daemon management properly, efficiently or securely.
Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.
Which is why lots of good Unix tools have a way to export some meaningful data from binary format to text, tools as different as compression tools, databases, document processors,... Even the systemd journal has such a tool.
The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.
There are legitimate points on both sides, and which side you come down on may depend on your primary use case.
I agree with everything except the part where you say it is not a problem for system administrators. It is a huge problem for sysadmins on the contrary, mostly because syadmin time is not infinite. And every single time a sysadmin has to update a system component related to these specialised scripts, he has to get back the knowledge of the script, to be able to migrate it. If you have done sysadmin work, you know that even your own scripts written long ago need you to relearn what you have done to be migrated correctly, so it's even worse when you have to parse others'. This is the most common problems the old sysadmins have when migrating to systemd actually, all the custom scripts they don't master at all and that take lots of time mastering before they can be adapted. I had to do that for systemd, for example tackle the apachectl or mysql start scripts, sth which is not fun to do at all. This is the main problem syaadmins face when migrating, we all fear this, and this is caused by the fact that lots of complexity was actualy hidden in shell scripts, the thing that systemd opponents call "simple". So to me, systemd opponents are either lazy or very bad sysadmins, or no sysadmin at all, who balk at the difficulty of having to labor in complex shell scripts. You can see that all the complaints are about people migrating their systems, not people starting from scratch on systemd distros.
And contrary to lots of false beliefs spread, people like me that hate sysvinit and shell scripts since more than a decade are actually the most proficient with them. In work environment, most sysadmins I work with have no clue at even how everything works, especially shell scripts. I had no problem understanding the shell scripts I talked about above for example. I'm sure systemd proponents are more proficient with shell scripts than the opponents anyway, it's a skill needed to migrate. And 15+ years of not using shell scripts for boot didn't lower my knowledge of them, syadmins use shell scripts for lots of things not related to boot.
Proper responsibility? No, you have that wrong. They did everything they had to do.
I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:
As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason. Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.
systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number. Much more secure, and it even makes things much less complicated for the daemon writers.
I can attest to that. systemd is just a life saver, and I have a recent example of this. Every year, at summer time, I see loads of attacks on HTTP servers, and often mine are compromised one way or another, and I have to react quickly, and sometimes there is no fix in time. This summer was no exception, with an attack on my drupal web site, which was successful in trying to launch lots of mails from my server, as I had not updated drupal to the latest version. But now, my HTTP server is protected by systemd via its unit file: it can't tamper with my system or data, everything is protected by systemd, capabilities are very tight, and it couldn't even send the emails as everything failed (but that's more credit to the Web Server that drops privilege). Basically, only legitimate actions work. So it was much less headaches than with other init systems, and I wasn't in emergency mode this time, I just watched all the attempt ultimately fail, even though the attacker thought they succeeded. For the security alone, there is just no way a decent sysadmin would stay with shells scripts.
From a purely user perspective where everything is assumed to be working properly (or it is someone else's problem) then it is great. The same can be said of Microsoft offerings.
Wrong! You just assumed that Microsoft offerings are assumed to work properly, which is just plain false. MS offerings need lots of glue from the start to work correctly temporarily.
But if you are coming at it from the sysadmin side then you might want something that is easier to understand and debug and fix. The init system has to have a lot of glue because it has to start up services from a lot of different code bases. There is a lot in favor of having this glue in a simple language that is easier to understand and fix. Systemd makes more sense for commodity, user-oriented devices. It makes very little sense on servers.
Wrong again! I come from mostly a sysadmin side, and systemd crushes shell scripts and sysvinit in every single way. And this on every workload, from embedded to clusters/HPC going through servers and desktops. There is just no good thing today on Linux about shell scripts as boot system, and this was true 15+ years ago already. Systemd is better precisely because sysadmins want sth easier to understand and debug and fix. I still use shell scripts for booting my Live CD, but very little is done in them, before I switch root FS and launch systemd. Once systemd is debugged and fix, it's debugged and fixed for every single units you have. While with shell scripts, you know a tuning/debugging nightmare is coming for every single one you add. Shell scripts are just not reliable at all, few admin even know how to restart a service properly with them, leading to tools like "service" which don't solve every problems like race conditions.
So your backup is sth you wrote. Let me get this straight: you're some kind of genius, everything you say is the truth, right? You are proven wrong just by Gnome adopting systemd-logind API instead of the ConsoleKit one that everyone involved agree was very bad, and systemd-logind API far better. The most obvious giveaway is that you have nothing to say about this interface and what is bad about it, you just write "it's bad". You thus have nothing to say and have no case, until you find sth bad about the interface. Same for the other DBUS interfaces.
"Poor understanding of portability by the lead developers." - portable to where? its a linux system.
You don't even understand what portable means, even in the nonsense you've written in your journal. The portability discussed there is between hardware architecture, and systemd is perfectly portable (at least between x86, x86_64 and ARM, the one I've tested), and it's sth very well understood by systemd developers. You're talking about compatibility between OS, which is nonsense in this case because the problem here is not that the systemd developers can't handle autotools, it's that systemd uses Linux specific API. These API have to be implemented at the kernel level for the most part, which is sth systemd developers don't want to do, and I can't blame them.
"Scope creep (there is no reason Gnome should depend on systemd)." - thats Gnomes problem, LP issued a library to allow Gnome to avoid using logind but GNOME decided not to use it.
Lennart actively pushed Gnome to use systemd, the forum threads are still available if you want to find them.
Repeating again the same misinformation. Gnome doesn't use systemd, some Gnome component use the systemd-logind API, can't you understand the difference?
only the journal has an element of binary and as a journal, it shits all over syslog/rsyslog with better content.
If the init system dictates what logging system you must use, then that's poor design. Also, corrupt binary logs are harder to read than corrupt text logs.
Fortunately, systemd does'nt dictate what logging system you must use. And no, corrupt binary logs are not harder to read than corrupt text logs: both are unreadable. Only the non corrupted parts are perfectly readable in both cases.
I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
So you're saying Linux Torvalds has not enough creds so it's likely that he's talking through his hat, and you're making a fallacy by talking about Linux adoption which has nothing to do with this controversy. This controversy makes no sense for most Linux users who don't even understand what "init" is about.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
The C standard has moved since these decades, so I wouldn't say sth like that unless I was still heavily programming today. And having problems with an init which is a very simple OS component, shows that moving to yet another UNIX environment would not be so easy for you. Besides, Linux is not a Unix environment, it's Unix-like, but Linux is as close to Unix as systemd is close to sysvinit. It's precisely because systemd is made for Linux that it is not natively compatible with other Unix systems like the BSD.
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
You should do your homework in any case, but it doesn't seem like your job makes you involved in sysadmin problems, so it's understandable you clearly don't know what systemd is or does. Which is a blessing, because that means you didn't modify initscripts which were all working perfectly for you, and so migrating to systemd will be a breeze. And you will be able to continue not caring about your init. What is so great about systemd has been explained time and time again, it's a very easy information to find, so people still asking these questions are obvious time wasters, aka trolls.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Your problem is right there! You know less than the people proficient with this matter, so you trusted them. And yet, now you say you know more than them and don't trust them anymore, even though it's obvious you don't know anything about what you're talking about, still asking where to find information. But no, you decided you are now more proficient than maintainers just because.
Unfortunately, for my needs, simplicity and understandability are far more important than a fast boot and feature-rich management of the runtime environment. I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
So systemd is good news for you, as it removes the frightening security mess that shell initscripts were by configuration files that are not executables. Trojan could be hidden anywhere with sysvinit, especially with links everywhere, it was just impossible to monitor. Security is one of the reason I stopped using sysvinit more than a decade ago on my servers and desktops.
I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
It always was important, Snowden just opened more eyes, but lots of people already knew, some still have their eyes closed though.
If the improved functionality is at the cost of burying the configuration and logging in non-human-readable form and entangling diverse processes into an interlocking mass under a complex and ever growing manager, the shark has been jumped.
That was the sysvinit situation, even one of the big problem of initscripts, fortunately systemd corrects this. Now all the truely active configuration is easily readable as is logging, which is readily available, not scattered across 3 or 4 different files.
Though Linux has been becoming (MUCH!) more usable with time, its configuration has been buried progressively more deeply under more and more "convenient and simplifying", but non-transparent, configuration management tools. Systemd is the continuation of the trend. But it is also a quantum leap, rather than another thin slice off the salami. So it has apparently created the "Shelling Point", where a lot of frogs simultaneously figure out that NOW is the time to jump out of the pot.
So that is the nonsense that is going through the head of non-technical people unable to understand technical concepts. It looks like insane thoughts for something like systemd that is actually very simple to explain what it does to non-technical people, but not so simple to code. You'd better not use buzzword you hear in movies, they don't understand that they're saying nonsense either. For example "non-transparent, configuration management tools", this doesn't make any sense. systemd is not even on the same level as these, it's part of the core of the OS.
It's been a great ride. It had the potential to be even greater. But I think this is where it took the wrong turn and it's time for me to get serious about switching.
There's good reason to switch to NetBSD at work, on the product. (The code supporting the secret sauce is on the user side of the API and is Posix compatible, so it should be no big problem.) Porting my laptop, home servers, and desktops to OpenBSD now looks like it's worth the effort - and less effort than trying to learn, and keep abreast of, the internals of systemd.
systemd detractors don't make any sense : switching to another completely different kernel and OS is somehow easier than learning a new init system commands. I don't remember people saying such nonsense when Red Hat appeared with chkconfig or service, or when Ubuntu launched Upstart. And I can guarantee it's easier to learn a new init system than switching OS. Also, I don't understand why someone would advertise that he gave up because of his inability to grasp new technology and instead took the harder rou
systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
So that everyone can see the level of BS of this user : "Linux's position as a kernel on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position Linux developers can take is "we're not ready, please don't use this even as a test in your released distributions". This is the level of discussion, it's pathetic actually.
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
The problem for you shills of proprietary OS vendors and appliances, is that Linux actually succeeds in being many things to far too many people (in your eyes). You'll have to do better than that: while you shills cry here, Linux succeeds, and with systemd, is available in even more products than before. You know the stupid Cloud rage going on right now, systemd allows Linux systems to be rapidly deployed there. Yes, you shills have no purpose in this matter actually, you've already lost.
Lennart [...] likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.
I guess the problem is that systemd is heavily dependent on Linux, whose "developers don't understand the arguments of simplicity, composability, and small programs that do one thing well", to quote you. These developers (Linux kernel and systemd) only understand the arguments of programs that just work, are robust, adaptable, coherent, fast and efficient, easy to use, difficult to break, the most secure possible.
The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.
I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development. I hope it comes sooner rather than later.
So you came to the same conclusion as myself. Except that I think Linux, Lennart and co are far more intelligent than you are, and I just happen to agree with them on technical ground with my knowledge of the field. Even my experience of 15+ years of building special purpose Linux OS from scratch agree with systemd and Linux OS, and even with GNU most of the time, believe it or not.
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in/lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
There is no "systemd crowd". There are systemd users that find it easier to use than previous solutions which have bugs which won't ever be fixed like Upstart. systemd is actually far less complex than using Upstart + countless tools and daemons with their configurations scattered all other the place. I don't see the crazyness you talk about in/lib/systemd or/usr/lib/systemd. I don't use every systemd utilities, but I caved in for a lot of them and threw away xinetd, my custom FS mount scripts, my custom network scripts... And my simple and vanilla systems, with their LVM on software RAID, FS on SAN and NAS,... which were a pain to tune so that they bootup correctly every time, were a breeze to migrate to systemd. So yes I don't see a problem with my vanilla systems that even distributions didn't know how to setup 15 years ago, and some still can't today.
The reason that "nobody put up a fight" is because every intelligent Linux user has seen systemd for the disaster that it is, and they've moved to FreeBSD, PC-BSD, OpenBSD, NetBSD or DragonFly BSD months ago. The only Linux users left are the ones who'd be just as happy using Windows, which is pretty much what they get when using a modern GNU/Systemd/Linux distro.
So I'm a unintelligent Linux user that is happoy using Windows to you. You should revise your hypothesis, as you're plain wrong in my case: I just can't stand using Windows, the latest one I've used is Win7 though, and I can't stand using it as it doesn't work correctly. I can assure you none of the Linux I use/make/administer are like Windows, I actually understand how they work far more than any Windows I ever used, and they don't crash like Windows.
because some software expects it and doesn't run without it. shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
You're right of course. Fortunately, the startup utility systemd (PID 1) doesn't provide user authentication, so you and I can sleep well at night while using systemd. Some people will tell you that PAM is no better, but that's what most distribution use these days. But if you want and are knowledgeable enough, you can make a system without PAM for user authentication too.
The better question is why bother supporting two sets of packages and scripts that accomplish precisely the same thing. Pick one and go with it. Given the support for systemd (by people who matter, not trolls), it seems the logical choice.
It's a good thing that they bother if they have the workforce, which they seem to have. There's no problem with that, gentoo is doing the same thing. As long as they are also going with systemd so that when the burden of initscripts is unbearable they're not stuck with an even bigger moutain to climb, it will go well. It will still be really painful for initscripts users though. For now, the chasm isn't so big, it will really be huge when kdbus enters a Linux kernel release, even in experimental.
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.
Your facts are plain lies, any sysadmin can see that. systemd does not corrupt logs when you power-cycle your system either, the fact of power cycling your system is actually what corrupts your file-system, and that's not even always the case. Stop using "data=writeback" on your ext4 FS, take the performance hit and start using "data=ordered" instead of spreading lies, perhaps your FS will leave you alone then. Up to this morning, I used the journal to debug an embedded system (raspberry pi) that would not boot, for which I don't have a console nor ssh access. I just shut it down electrically, then get the SD card, then read the journal file from another system. Guess what: the entire file is readable every single time (I've done it a lot to debug boot problems) with journalctl, with even the kernel boot messages as thanks to systemd, I get really everything in the log.
I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.
But that's the problem: people who constantly rage against systemd and its binary logfiles are not AT ALL interested in knowing if they can read it, they never tried, they never looked at explanations of how it works or anything. The fact is that you can actually use "strings" (the shell command) against your journal file and get A LOT of text logs with a lot more information than in a standard log file. Of course you lose all the semantic like the integrity of the text you're reading. Which is because journald won't even compress small logs because it would take too much space. Only big log lines or blobs are compressed usually. All this talk about systemd binary logs being unreadable is just plain lies and BS from detractors. Of course, if you read your log with journalctl, it will get you all the extra benefits.
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.
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.
Slashdot Mirror
This! The systemd documentation is horrible. And, why should stderr be discarded by default?
Learn to read, it's written in the configuration that the default is NOT to discard stderr, but in the contrary to log it in the journal.
The systemd documentation is actually wery good, your reading skills though are horrible.
And why isn't it turned on by default?
It is!
The default for systemd upstream is to put standard output in the journal and inherit this setting for standard error.
Which means with the upstream configuration of systemd, everything goes to the journal.
So if that is not the case in your distribution, it's the distribution that actually chose that way.
The upstream systemd defaults are sane from my sysadmin point of view : I never had to change them.
You forgot those of us who have been around long enough to have survived major sea changes like os390 -> UNIX -> Solaris -> windows -> linux. Systemd saddens me because it makes servers act like workstations. And sadly, the distro maintainers made way too hard of a turn into systemd, forgoing 20 y/o standards. For example, on a CentOS minimal system, no ifconfig/netstat? Instantly breaks monitoring tools.
Very bad sysadmin masquerading as a good one, that's the problem right here.
For the record, ifconfig is deprecated (and useless in any slightly complex setup) for years on Linux in favor of iproute2 tools, and netstat disappearance has nothing to do with systemd and everything to do with your distribution or how you installed it.
And systemd didn't make my servers into workstations, what does it even mean? Is systemd installing X onto your servers? If that is the case, I can assure this a distro choice (strange for a minimal one) and has nothing to do with systemd.
Next thing we'll learn is that you were one of the few using LSB extensively.
Ah, so there is a propaganda guideline. Fits. It nicely explains why the same fallacies and emotional bullshit is vomited by the pro-systemd sect every time. They seem to have fallen for "it it is written, then it is truth" and completely have stopped to actually think about anything.
Nice inversion. Actually, 99 % (to not say 100 %) of the anti-systemd crowd show a complete lack of understanding of even the simple issue discussed in the OP.
It's sad that even a mainly developer like Poettering is understanding more about system administration than most of the crowd that vomited fallacies and emotional BS on Slashdot. It's scary and just shows that there is no technical answer to systemd in the horizon anytime soon.
I've seen not even ONE technical rebuttal on the article. At the same time, it would be difficult as the problem here is specific to systemd related to the environment and security, and makes perfect sense. Fortunately, some people pointed that systemd was not replacing su, only someone that didn't understand what was being said would say that, which means the frightening thing that even the OP didn't understand what was being said.
The good news is that it means good, seasoned sysadmins don't care anymore to answer to these nonsense articles disparaging systemd from their lack of understanding. The bad news is that given this pathetic level of skills in opposition, systemd is not to see competition before a very long time.
The pathetic news is that uselessd dropped out of their nonsense project... for the very specific reason that was cited by L. Poettering, no less, and which was obvious for even someone like me who is no professional programmer. Reasons that were cited as nonsense by people that have no skills and no knowledge, and most of all not willing to do the work: the anti-systemd crowd.
Like most reasonable sysadmins and I said, time will show who was right and who was wrong. Given my level as a professional admin and the fact that I jumped into systemd as soon as it appeared, I have no doubt on the future.
The classical UNIX philosophy is one daemon one goal, perfectly implemented, fully secured and full documented. Systemd breaks this view and takes the windows 7 and before concept.
We know that results of this second philosophy: One software that does everything, using a quick and dirty implementation, with an incomplete, and erroneous documentation, and the security is done in a fully procrastination way...
Are you sure that systemd can really escape this second philosophy? In my opinion it can’t. I’m still using the slackware distribution, and I hope they will stay away from systemd.
Your premise about systemd is already wrong from the start, because you don't even know what you're talking about. No wonder then that everything else you say is plain wrong.
systemd has nothing to do with Windows 7 and before, it's based on Linux specific kernel features, so you mean Linux takes Windows 7 and before concepts?
systemd opponents love making fools of themselves, it's pathetic really. Don't you know the systemd proponents are mostly proficient people, not stupid enough to believe such nonsense?
"One big gain is not having to write my own custom init scripts"
Is this really a big problem for people?! I hear this all the time. Init scripts are shell scripts. They're really simple. I can't even conceive of how one could manage to develop a UNIX daemon and not the shell script to manage its execution.
Init shell scripts are not really simple, that's why you don't understand the problem. They require lots of work and maintenance, which was invisible to users, especially in Linux distributions.
The same people that repeat that shell scripts are simple and work perfectly, usually know this, and they know that as soon as distro sysadmins stop maintaining them, the work will be on these users shoulders. So they spread lies, but lies won't make the work. So this was a lost battle from the start.
There's a reason sysadmins were writing their own custom init scripts, and custom scripts means you have to maintain them when the system updates, so you have to register every single one of them and look for regression. This is lots of work.
And no, good daemons need no shell scripts to manage their execution, and it is nonsense to do that. Even sysvinit has a very basic daemon management feature, that nobody used because it was too basic. Shell scripts have none and can't do daemon management properly, efficiently or securely.
Text is attractive because it's a least-common-denominator and *universal* format. However inconvenient it may be to parse and organize, you can write a reasonably simple script to do it, and you can pipe it through just about any command to transform or process it in whatever way you want. With text, you never have to worry about a black box of a file, because it's always human-readable, and thus more amenable to hacking.
Which is why lots of good Unix tools have a way to export some meaningful data from binary format to text, tools as different as compression tools, databases, document processors, ...
Even the systemd journal has such a tool.
The downside for log files is that text-based formats are incredibly inefficient as backing stores for any substantial amount of data. And as a configuration format, it's incredibly difficult to write front-end configuration software for scripts, although less so with regular formats like json or xml. Once the configuration is in a script, automated management of that configuration pretty much goes out the window - you're essentially committed to maintaining scripts by hand. This is not a problem for system administrators or advanced users, but horrible for normal users and GUI systems.
There are legitimate points on both sides, and which side you come down on may depend on your primary use case.
I agree with everything except the part where you say it is not a problem for system administrators. It is a huge problem for sysadmins on the contrary, mostly because syadmin time is not infinite. And every single time a sysadmin has to update a system component related to these specialised scripts, he has to get back the knowledge of the script, to be able to migrate it. If you have done sysadmin work, you know that even your own scripts written long ago need you to relearn what you have done to be migrated correctly, so it's even worse when you have to parse others'.
This is the most common problems the old sysadmins have when migrating to systemd actually, all the custom scripts they don't master at all and that take lots of time mastering before they can be adapted.
I had to do that for systemd, for example tackle the apachectl or mysql start scripts, sth which is not fun to do at all.
This is the main problem syaadmins face when migrating, we all fear this, and this is caused by the fact that lots of complexity was actualy hidden in shell scripts, the thing that systemd opponents call "simple".
So to me, systemd opponents are either lazy or very bad sysadmins, or no sysadmin at all, who balk at the difficulty of having to labor in complex shell scripts.
You can see that all the complaints are about people migrating their systems, not people starting from scratch on systemd distros.
And contrary to lots of false beliefs spread, people like me that hate sysvinit and shell scripts since more than a decade are actually the most proficient with them. In work environment, most sysadmins I work with have no clue at even how everything works, especially shell scripts.
I had no problem understanding the shell scripts I talked about above for example. I'm sure systemd proponents are more proficient with shell scripts than the opponents anyway, it's a skill needed to migrate. And 15+ years of not using shell scripts for boot didn't lower my knowledge of them, syadmins use shell scripts for lots of things not related to boot.
Proper responsibility? No, you have that wrong. They did everything they had to do.
I strongly disagree. SysVinits "simplicity" was exactly because it left all complexity to others to fix. I won't dwell with PID problems, daemonizations or other classic criticisms of SysVinit, some dating 30 years back, but show one example:
As you know, daemons need special (root) privileges in order to access port-numbers below 1024. This is for security reasons. The backside of this is that the daemon then needs high privileges to run. Enter setuid and similar Posix syscalls; they have basically been demonstrated to be impossible to use in a safe manner, and have provided decades of remote exploits of Linux for the same reason.
Then came Capabilities which meant setuid root programs could be ditched for that, but Capabilites still means the Daemon can freely talk through low port numbers, so spammers have for years exploited this to install spamming smtp servers on exploited hosts or serve malware from port 80.
systemd on the other hand, can give the daemon a low port-number through a socket so that all such low port-number privileges can be completely dropped; even if the daemon is exploited, it can't send spam through a low port number.
Much more secure, and it even makes things much less complicated for the daemon writers.
I can attest to that.
systemd is just a life saver, and I have a recent example of this.
Every year, at summer time, I see loads of attacks on HTTP servers, and often mine are compromised one way or another, and I have to react quickly, and sometimes there is no fix in time. This summer was no exception, with an attack on my drupal web site, which was successful in trying to launch lots of mails from my server, as I had not updated drupal to the latest version.
But now, my HTTP server is protected by systemd via its unit file: it can't tamper with my system or data, everything is protected by systemd, capabilities are very tight, and it couldn't even send the emails as everything failed (but that's more credit to the Web Server that drops privilege). Basically, only legitimate actions work.
So it was much less headaches than with other init systems, and I wasn't in emergency mode this time, I just watched all the attempt ultimately fail, even though the attacker thought they succeeded.
For the security alone, there is just no way a decent sysadmin would stay with shells scripts.
From a purely user perspective where
everything is assumed to be working properly (or it is someone else's
problem) then it is great. The same can be said of Microsoft
offerings.
Wrong! You just assumed that Microsoft offerings are assumed to work properly, which is just plain false.
MS offerings need lots of glue from the start to work correctly temporarily.
But if you are coming at it from the sysadmin side then
you might want something that is easier to understand and debug and
fix. The init system has to have a lot of glue because it has to
start up services from a lot of different code bases. There is a lot
in favor of having this glue in a simple language that is easier to
understand and fix. Systemd makes more sense for commodity,
user-oriented devices. It makes very little sense on servers.
Wrong again! I come from mostly a sysadmin side, and systemd crushes shell scripts and sysvinit in every single way.
And this on every workload, from embedded to clusters/HPC going through servers and desktops.
There is just no good thing today on Linux about shell scripts as boot system, and this was true 15+ years ago already.
Systemd is better precisely because sysadmins want sth easier to understand and debug and fix.
I still use shell scripts for booting my Live CD, but very little is done in them, before I switch root FS and launch systemd.
Once systemd is debugged and fix, it's debugged and fixed for every single units you have. While with shell scripts, you know a tuning/debugging nightmare is coming for every single one you add.
Shell scripts are just not reliable at all, few admin even know how to restart a service properly with them, leading to tools like "service" which don't solve every problems like race conditions.
I've already linked to pages explaining these, but you obviously didn't read them.
"Poor understanding of interfaces by the lead developers." - thats a new one - where did you get that from, give us some backup to see what you mean.
This link discusses it
So your backup is sth you wrote. Let me get this straight: you're some kind of genius, everything you say is the truth, right?
You are proven wrong just by Gnome adopting systemd-logind API instead of the ConsoleKit one that everyone involved agree was very bad, and systemd-logind API far better. The most obvious giveaway is that you have nothing to say about this interface and what is bad about it, you just write "it's bad".
You thus have nothing to say and have no case, until you find sth bad about the interface. Same for the other DBUS interfaces.
"Poor understanding of portability by the lead developers." - portable to where? its a linux system.
Exactly lol. Linux only. Not portable. This link goes into more detail.
You don't even understand what portable means, even in the nonsense you've written in your journal.
The portability discussed there is between hardware architecture, and systemd is perfectly portable (at least between x86, x86_64 and ARM, the one I've tested), and it's sth very well understood by systemd developers.
You're talking about compatibility between OS, which is nonsense in this case because the problem here is not that the systemd developers can't handle autotools, it's that systemd uses Linux specific API. These API have to be implemented at the kernel level for the most part, which is sth systemd developers don't want to do, and I can't blame them.
"Scope creep (there is no reason Gnome should depend on systemd)." - thats Gnomes problem, LP issued a library to allow Gnome to avoid using logind but GNOME decided not to use it.
Lennart actively pushed Gnome to use systemd, the forum threads are still available if you want to find them.
Repeating again the same misinformation. Gnome doesn't use systemd, some Gnome component use the systemd-logind API, can't you understand the difference?
only the journal has an element of binary and as a journal, it shits all over syslog/rsyslog with better content.
If the init system dictates what logging system you must use, then that's poor design. Also, corrupt binary logs are harder to read than corrupt text logs.
Fortunately, systemd does'nt dictate what logging system you must use.
And no, corrupt binary logs are not harder to read than corrupt text logs: both are unreadable. Only the non corrupted parts are perfectly readable in both cases.
It actually says 7.1 % Red Hat, can't you even read correctly?
I do observe the controversy around it, and the image of it and its project, painted by its opponents (some of whom have enough creds that it's unlikely that they're talking through their hats), indicates that the claimed issues are likely to be real problems, and this may be a tipping point for Linux adoption and user choice among distributions or OSes.
So you're saying Linux Torvalds has not enough creds so it's likely that he's talking through his hat, and you're making a fallacy by talking about Linux adoption which has nothing to do with this controversy. This controversy makes no sense for most Linux users who don't even understand what "init" is about.
I did my first Linux drivers (a PROM burner and a Selectric-with-selonoids printer) on my personal Altos ACS 68000 running System III, wrote a driver for a block-structured tape drive for AUX - working from my own decompilation of their SCSI disk driver (since the sources weren't available to me initially), ported and augmented a mainframe RAID controller from SvR3 to SvR4, and so on, for nearly three decades, through hacking DeviceTree on my current project. I don't think C has many problems left for me, nor does moving to yet another UNIX environment - especially to one that is still organized in the old, familiar, fashion. B-)
The C standard has moved since these decades, so I wouldn't say sth like that unless I was still heavily programming today.
And having problems with an init which is a very simple OS component, shows that moving to yet another UNIX environment would not be so easy for you.
Besides, Linux is not a Unix environment, it's Unix-like, but Linux is as close to Unix as systemd is close to sysvinit. It's precisely because systemd is made for Linux that it is not natively compatible with other Unix systems like the BSD.
As for trying to learn how systemd works, that's not the proper question. Instead, I ask what is so great about it that I should spend the time to do so, distracting me from my other work, and how doing this would meet my goals (especially the undertand-the-security-issues goal), as compared to moving to a well-supported, time-proven, high-reliability, security-conscious alternative (which is also under a license that is less of a sell to the PHBs when building it into a shippable product.)
You should do your homework in any case, but it doesn't seem like your job makes you involved in sysadmin problems, so it's understandable you clearly don't know what systemd is or does.
Which is a blessing, because that means you didn't modify initscripts which were all working perfectly for you, and so migrating to systemd will be a breeze.
And you will be able to continue not caring about your init.
What is so great about systemd has been explained time and time again, it's a very easy information to find, so people still asking these questions are obvious time wasters, aka trolls.
Unfortunately, I don't get to make that choice myself. It's made by the distribution maintainers. My choice is to accept it, open the can of worms and redo the work of entire teams (and hope their software updates don't break things faster than I fix them), or pick another distribution or OS.
Again, why should I put myself on such a treadmill of unending extra work? If I could trust the maintainers to mostly make the right choices I could go along - with no more than an audit and perhaps an occasional tweak. But if they were making what I consider the right choices, I wouldn't expect to see such a debacle.
Your problem is right there! You know less than the people proficient with this matter, so you trusted them. And yet, now you say you know more than them and don't trust them anymore, even though it's obvious you don't know anything about what you're talking about, still asking where to find information. But no, you decided you are now more proficient than maintainers just because.
Unfortunately, for my needs, simplicity and understandability are far more important than a fast boot and feature-rich management of the runtime environment. I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
So systemd is good news for you, as it removes the frightening security mess that shell initscripts were by configuration files that are not executables.
Trojan could be hidden anywhere with sysvinit, especially with links everywhere, it was just impossible to monitor. Security is one of the reason I stopped using sysvinit more than a decade ago on my servers and desktops.
I need to KNOW that things are being handled properly and securely. That's become far more important since Snowden showed us, not that the spooks were getting into our computers (which we'd already figured was happening), but how DEEPLY and EFFECTIVELY their technology and personnel are able to do so.
It always was important, Snowden just opened more eyes, but lots of people already knew, some still have their eyes closed though.
If the improved functionality is at the cost of burying the configuration and logging in non-human-readable form and entangling diverse processes into an interlocking mass under a complex and ever growing manager, the shark has been jumped.
That was the sysvinit situation, even one of the big problem of initscripts, fortunately systemd corrects this. Now all the truely active configuration is easily readable as is logging, which is readily available, not scattered across 3 or 4 different files.
Though Linux has been becoming (MUCH!) more usable with time, its configuration has been buried progressively more deeply under more and more "convenient and simplifying", but non-transparent, configuration management tools. Systemd is the continuation of the trend. But it is also a quantum leap, rather than another thin slice off the salami. So it has apparently created the "Shelling Point", where a lot of frogs simultaneously figure out that NOW is the time to jump out of the pot.
So that is the nonsense that is going through the head of non-technical people unable to understand technical concepts. It looks like insane thoughts for something like systemd that is actually very simple to explain what it does to non-technical people, but not so simple to code.
You'd better not use buzzword you hear in movies, they don't understand that they're saying nonsense either. For example "non-transparent, configuration management tools", this doesn't make any sense. systemd is not even on the same level as these, it's part of the core of the OS.
It's been a great ride. It had the potential to be even greater. But I think this is where it took the wrong turn and it's time for me to get serious about switching.
There's good reason to switch to NetBSD at work, on the product. (The code supporting the secret sauce is on the user side of the API and is Posix compatible, so it should be no big problem.) Porting my laptop, home servers, and desktops to OpenBSD now looks like it's worth the effort - and less effort than trying to learn, and keep abreast of, the internals of systemd.
systemd detractors don't make any sense : switching to another completely different kernel and OS is somehow easier than learning a new init system commands.
I don't remember people saying such nonsense when Red Hat appeared with chkconfig or service, or when Ubuntu launched Upstart. And I can guarantee it's easier to learn a new init system than switching OS. Also, I don't understand why someone would advertise that he gave up because of his inability to grasp new technology and instead took the harder rou
systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
So that everyone can see the level of BS of this user : "Linux's position as a kernel on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position Linux developers can take is "we're not ready, please don't use this even as a test in your released distributions".
This is the level of discussion, it's pathetic actually.
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
The problem for you shills of proprietary OS vendors and appliances, is that Linux actually succeeds in being many things to far too many people (in your eyes).
You'll have to do better than that: while you shills cry here, Linux succeeds, and with systemd, is available in even more products than before.
You know the stupid Cloud rage going on right now, systemd allows Linux systems to be rapidly deployed there.
Yes, you shills have no purpose in this matter actually, you've already lost.
Lennart [...] likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.
I guess the problem is that systemd is heavily dependent on Linux, whose "developers don't understand the arguments of simplicity, composability, and small programs that do one thing well", to quote you. These developers (Linux kernel and systemd) only understand the arguments of programs that just work, are robust, adaptable, coherent, fast and efficient, easy to use, difficult to break, the most secure possible.
The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.
I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
I hope it comes sooner rather than later.
So you came to the same conclusion as myself. Except that I think Linux, Lennart and co are far more intelligent than you are, and I just happen to agree with them on technical ground with my knowledge of the field. Even my experience of 15+ years of building special purpose Linux OS from scratch agree with systemd and Linux OS, and even with GNU most of the time, believe it or not.
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
There is no "systemd crowd". There are systemd users that find it easier to use than previous solutions which have bugs which won't ever be fixed like Upstart. /lib/systemd or /usr/lib/systemd. I don't use every systemd utilities, but I caved in for a lot of them and threw away xinetd, my custom FS mount scripts, my custom network scripts... ... which were a pain to tune so that they bootup correctly every time, were a breeze to migrate to systemd. So yes I don't see a problem with my vanilla systems that even distributions didn't know how to setup 15 years ago, and some still can't today.
systemd is actually far less complex than using Upstart + countless tools and daemons with their configurations scattered all other the place.
I don't see the crazyness you talk about in
And my simple and vanilla systems, with their LVM on software RAID, FS on SAN and NAS,
The reason that "nobody put up a fight" is because every intelligent Linux user has seen systemd for the disaster that it is, and they've moved to FreeBSD, PC-BSD, OpenBSD, NetBSD or DragonFly BSD months ago. The only Linux users left are the ones who'd be just as happy using Windows, which is pretty much what they get when using a modern GNU/Systemd/Linux distro.
So I'm a unintelligent Linux user that is happoy using Windows to you.
You should revise your hypothesis, as you're plain wrong in my case: I just can't stand using Windows, the latest one I've used is Win7 though, and I can't stand using it as it doesn't work correctly. I can assure you none of the Linux I use/make/administer are like Windows, I actually understand how they work far more than any Windows I ever used, and they don't crash like Windows.
because some software expects it and doesn't run without it.
shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
You're right of course. Fortunately, the startup utility systemd (PID 1) doesn't provide user authentication, so you and I can sleep well at night while using systemd.
Some people will tell you that PAM is no better, but that's what most distribution use these days. But if you want and are knowledgeable enough, you can make a system without PAM for user authentication too.
The better question is why bother supporting two sets of packages and scripts that accomplish precisely the same thing. Pick one and go with it. Given the support for systemd (by people who matter, not trolls), it seems the logical choice.
It's a good thing that they bother if they have the workforce, which they seem to have.
There's no problem with that, gentoo is doing the same thing.
As long as they are also going with systemd so that when the burden of initscripts is unbearable they're not stuck with an even bigger moutain to climb, it will go well. It will still be really painful for initscripts users though.
For now, the chasm isn't so big, it will really be huge when kdbus enters a Linux kernel release, even in experimental.
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.
Your facts are plain lies, any sysadmin can see that. systemd does not corrupt logs when you power-cycle your system either, the fact of power cycling your system is actually what corrupts your file-system, and that's not even always the case.
Stop using "data=writeback" on your ext4 FS, take the performance hit and start using "data=ordered" instead of spreading lies, perhaps your FS will leave you alone then.
Up to this morning, I used the journal to debug an embedded system (raspberry pi) that would not boot, for which I don't have a console nor ssh access. I just shut it down electrically, then get the SD card, then read the journal file from another system. Guess what: the entire file is readable every single time (I've done it a lot to debug boot problems) with journalctl, with even the kernel boot messages as thanks to systemd, I get really everything in the log.
I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.
But that's the problem: people who constantly rage against systemd and its binary logfiles are not AT ALL interested in knowing if they can read it, they never tried, they never looked at explanations of how it works or anything.
The fact is that you can actually use "strings" (the shell command) against your journal file and get A LOT of text logs with a lot more information than in a standard log file. Of course you lose all the semantic like the integrity of the text you're reading.
Which is because journald won't even compress small logs because it would take too much space. Only big log lines or blobs are compressed usually.
All this talk about systemd binary logs being unreadable is just plain lies and BS from detractors.
Of course, if you read your log with journalctl, it will get you all the extra benefits.
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.