But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.
Yes, these scripts are workaround for the deficient sysvinit, like trying to guard against environment tampering, managing user options without modifying the init script itself (often scattered over several locations),... systemd removes these nonsense scripts and replaces them with a simple configuration file (a unit) without any drawback. You can even modify the systemd units, with your modifications usually still valid after an upgrade (it won't work if your unit is renamed to something else than apache2). This just shows how horrible init scripts were. It's even worse when you know you can manage isolation like chroot, or security features very useful for a web server like hiding filesystems or directories from the daemon.
Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.
This is correct, except for the bunch of people unfamiliar with modern OS operation. Their goal was to reduce this number, which doesn't solve any use case I know for big servers, except reduce attack surface at boot perhaps, this I can agree with. For smaller servers and limited resources systems, like embedded systems, the efficiency is very welcome. My security frontends say thanks to systemd.
Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.
*Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.
Actually, systemd works far better with my use cases. It works far better with LVM2 for instance, than my shell scripts ever could. Actually, it works every time now with systemd. mysql and apache works far better now, especially mysql which was a pain to start and especially to stop with the initscripts. Now with systemd it's far better. I agree there's some tuning to do at first, but not the kind of bad hacks we had to use with init scripts. The attack surface of init scripts was also huge, without any hope to discover it without constant monitoring. Some init scripts had 4 (yes four) different ways to configure them, each one could be exploited.
The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems.
There is no such "established-over-decades code in scripts" in the real world, which is why sysadmins around the world constantly had to tinker with these scripts. This is also the exact reason why if no one cares about them, these init scripts will wither and die. The most important plumbing init scripts are flawed by design, init is flawed in a dynamic environment like the one created by the Linux kernel, which is why everyone wanted to flee it since a long time. But sysadmins and distro makers couldn't agree on anything until systemd.
Systemd is tying into everything from initial boot to how to configure your soundcard.
Actually, systemd doesn't tie into how to configure your soundcard, but if you don't understand what people are talking about, especially systemd opponents, I see why you would think that. You must believe pulseaudio is part of systemd I gather.
On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.
I don't understand why you're talking about Windows here as a party, you're not making any sense. systemd is free software, so I assure you that you don't have to deal with undebuggable binaries, as the code to these binaries is readily available. Exactly like the source code of sysvinit or the numerous daemons launched by the scripts you're talking about. Perhaps you believe the init scripts themselves were serving as daemons, but that's rarely the case : these scripts were just there to try (badly) to understand the context to then launch "undebuggable binaries".
It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.
I don't understand what is scary about that. Your system depends on lots of binaries working as expected, starting with your bootloader, your kernel, your daemons,... That's the job of a sysadmin, I can assure you they're not scared at all providing they know what they are doing.
I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.
Actually you can still do that with systemd, but even better than before, especially when your keyboard is not qwerty or your character encoding not ASCII.
On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.
Why? I'm on the second side and I do exactly as advertised, even better than with sysvinit.
More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.
This was always the case in Linux, like most of the Linux plumbing ecosystem, which is not a bad thing imho, as long as the projects are active.
If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.
You are plain wrong added to the fact that you're not a good sysadmin then, or one with very little experience if any. You need a threshold of time to know if your server will go up or not. Guess what, a server won't always go up for various reasons, especially when you have init.d scripts patched everywhere with various timeouts, that can break at any reboot. You need to monitor your server startup, and it starts to become tedious when you have tens of server startup to monitor.
it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.
There is no so called "linux design principle" of do one thing and do it well, and even if there was, it would be the contrary of what you're saying as Linux (the kernel) has a monolithic design. In the case you were talking about GNU, systemd uses the same design as most GNU software, which is a "software collection". There is no linux principle of "everything is a text file", this is pure nonsense as sure enough, not everything in Linux is a text file (just look at sockets or block devices). There is a Unix principle that says everything is a file, but not a "text file". You're mixing several things without understanding the purpose of what you're talking about. Anyway, guess what, outside the United States, often the classic log files are actually binary files. Because what you describe as "text files" are actually "ASCII files" which is an encoding, but if your kernel or tools don't support UTF-8 encoding which is mostly used on Linux, you will extract mostly garbage from log files (all of mine are UTF-8 files, and yes I have log files despite using systemd). But that's nitpicking, binary log files are not a problem with systemd as you can use classic "text files" juste the same with systemd. Finally, there's no "single subsystem" that takes a large number of roles with systemd, each subsystem in systemd has one role.
In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.
Actually, systemd is an actual huge upgrade for system administrators who manage servers, in the actual world, not in an hypothetical one. The problem is that actual administrators, to switch to systemd, will have to manage the more or less huge number of hacks they inserted into deficient init.d scripts, which can be a huge tasks depending on if they documented them or not. And probably most didn't...
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.
That is my understanding looking in from the outside.
Your understanding is wrong, but you're not to blame, it's understandable because those opposed to systemd have no other argument than to make you believe all the components you cited are integrated into one tool/process. Of course this is false. systemd, the PID 1 process, manages initializing processes on bootup and scheduling jobs after boot-up, like sysvinit. It has lots of features to do these tasks even when the environment dynamically changes. Maintaining logs is in another process, managing devices alo in another process, managing network devices in another process... So actually, if that's your definition of Unix "philosophy", systemd pretty much is adequate. There is no Linux "philosophy", but you believe that because Unix "philosophy" (which has as many meanings as there are people using these words) is used to attack systemd, as if Linux and Unix were the same things. Actually, Linux (and GNU) by itself already detracts from Unix in lots of ways already.
It isn't just Linux; it's the nature of modern systems to become "too complex". Back in the days of my youth, it was possible for one person to grok an entire operating system, but it simply isn't possible anymore, unless it's a tightly-focused and built-to-purpose system.
And yet that's exactly what I'm doing today on my systems, which I build from scratch. And I grok the entire operating system, systemd was a god send tool for me. I run in a setup where multiple graphical sessions run on one computer, which only Linux allow me to do very easily.
There is one exception though : polkit. It is the only tool on my systems that I never tried to completely understand. Now I don't even need to anymore with udev + systemd. And I bet that's where the op is having problems, as it was fixed by installing systemd.
The behaviour of "Linux" (all the distributions and kernels) as a whole is exactly the same behaviour you see in companies with poor management. Everyone is working on stuff, and maybe even working hard, but all those things don't add up to the whole. There's no 1 person over-seeing it all to ensure everyone is working smart, and in the same direction.
And the outcome is pretty good as Linux runs on every computer available to this day, be it embedded or phones or HPC. So I don't understand what you mean by poor management, are they able to do that in poor management companies?
To me, this is what is happening with Linux. Everyone has ideas, and some of those ideas are great, but when everyone can fork and create and merge without an overall management process, you end up with a bit of a mess and mass confusion for those on the "outside."
You're just new to this: Free Software is like that since it started, what you say is laughable to people used to FOSS. You talk like you just discovered FOSS.
This is both the advantage (choice) and disadvantage (lack of alignment) with Linux. Should I use Gnome or KDE or Unity? Do I even know what those are as a end-user? Should I?
What I get OSX, I know what I get. When I get Windows, it's the same.
Should you use Windows or OSX? Windows Vista, Windows 7, Windows 8, Windows Server 2008? When you get Ubuntu, you know what you get just as much as when you get OSX, you even can test it without installing anything. You're juste spewing fallacies here.
Everything (mostly) from the previous version will work with this version, the interface isn't some massive surprise, etc (which is partially why Windows 8 was such a fiasco; things WEREN'T compatible and the UI was totally different).
You must be young as what you say is patently false, especially in Windows. Nearly everything I learned in Windows 98 was made useless when Windows XP came, including most of my work environment. I can say the same with Windows NT to Windows Server 2003. While nearly everything I learned in school on Unix 20 years ago is still usable today on Linux which is not even Unix.
At the end of the day, what needs to happen is exactly what most Linux devs hate the most: a large corporation with 1 vision needs to come in and create a clean, uniform experience that allows consistency and compatibility for years/decades, and reduces "choice" to a degree in order to provide consistency.
To some degree, you can argue RedHat did this a bit, especially with packages, but everyone hates on them too now..
This is what distro do, it's nothing new, it's just you discovering it now, but everything you're saying has already been done and evolved since then.
I would personally like to see three flavors of Linux:
Server - lean, NO systemd or plug-and-play crap, focus on security
So you will need systemd on your servers, especially if you want focus on security. The Linux kernel provides dynamic interfaces since a long time, and no one in userspace provided the tools to cope with it until systemd. Devices was done with udev and its predecessor devfs, but init was unable to cope with it before systemd, despite higher level tools trying to cope with the linux kernel dynamic nature.
When vague anecdotes start to pile up (and they do for systemd unreliability), they become facts in themselves.
No, anecdotes never lead to facts even if you have millions of them. You can't even say facts of what. Only analysis of anecdotes can lead to facts. This is becoming ridiculous, pushing dogmatic thoughts like that is dangerous.
Add to that that systemd problems are exceptionally hard to debug (you have to look into complex C source code for many) and the development team is unhelpful
This is pure lie that can be debunked by just looking at the devel ML. Why systemd haters always have to rely on lies?
The reason many, many people are reporting vague anecdotes about their system being unstable from systemd is not that they are lying, or fantasizing or on drugs, the reason is that systemd does indeed break reliability and on top is very hard to debug and fix.
No, the reason is that the unstable distro these people are using is really unstable, but they are too young to have experienced previous big breaks in GNU/Linux distro, like udev predecessor, kernel 2.2 to 2.4, 2.4 to 2.6, 2.6 to 3.0, 3.3 to 3.4, Gnome to Gnome 2, Gnome 2 to Gnome 3,... systemd is far from being the biggest change and challenge in Linux since I've worked with it starting in 1999, it's actually a breeze that no decent admin that know several Unix + Linux should trip on.
Some very old engineering failure analysis wisdom applies here: To really break things, you have to screw up in two major aspects. Systemd manages to do this easily by being unreliable and so hard to debug that most people fail at it. People are scared of it and angry at it, because they cannot master this complexity. And they are right to fight it: A decent OS has no business at all being complex in any place where it is avoidable and in particular, it has no business at all replacing simple things that work with complex ones, regardless of whether they work or not. If Linux is not kept free of high complexity in core components, it will implode.
When I read this I could be made to believe I'm a genius. This is wrong on so many levels, the first one being that things didn't work before, things were duct taped constantly by distro providers or by admins. Which is why the first thing systemd haters talk about is being able to tweak their initscripts, because the secret to unknowing people is that the basic distros just don't work with their setup, which has to be tweaked with ugly hacks for every specific environment. It becomes a hell to maintain and every distro upgrade is at risk of failing very badly or erasing their change. Usually what happens is that you forget about it, then when it blows up, blame the distro, and then quickly flee in shame when you realise it was all your fault to begin with. Now these admins blame systemd for their faults, the good ones come regularly to the ML to see their problem fixed. Fortunately systemd is part of the fix for this mess.
>When a computer is less useful today than it was last year thanks to systemd getting installed, the problem is solely with systemd.
In the OP, it's the opposite: the computer is more useful today than it was before thanks to systemd getting installed, so the problem is solely with something else. Which makes sense since a distro upgrade is not just systemd being upgraded, contrary to belief of non proficient people.
I was reading through the article's comments and saw this thread of discussion. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away. The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today.
perhaps he shuts them down because he specifically said that installing systemd solved his problem but he doesn't know why. Yet people with logic problems claim systemd is the problem, despite the fact that it wasn't installed on the systems experiencing the problem.
Systemd has been the most divisive force in the Linux community lately, and perhaps ever.
As it has been adopted by most distro, you're obviously wrong with your rhetoric. It has been one of the most cohesive force actually.
It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.
systemd doesn't have the power to force anyone to do anything, people that went to BSD did this on their own will. Debian community has not been torn by systemd but by trolls actually, systemd was the point used by the trolls. And usually, victims are unwilling to be victims, or so I heard.
Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.
I won't take your word for it on this, only time will tell but I'm pretty sure what you say is just plain hyperbole. Competent sysadmins actually have no problem with systemd, on the contrary.
Rolling your own 'Just like Linus did' may be a little extreme. I don't think you need a whole new kernel!
Just install Linux from scratch and don't put all that *kit, etc.. crap in it. I would imagine you could even get rid of udev and all that stuff if you are willing to run mknode yourself. Roll it like it's 1995.
You will lose out on some convenience if you are using a portable device such as a laptop but on a desktop with fairly static hardware everything should work just fine.
If having your own custom simple Linux isn't good enough for you then take it to the next step and start your own distro that leaves all that stuff out.
I've run my own Linux From Scratch like system since 2001, and I can say your advice is a very bad one. The problem is that the kernel provides dynamic interfaces since a long time. If you do what you say here, you will have a very limited setup that must not be a moving target, or take the risk of seeing your OS not boot very often, or even lose data (I had several of these problems before systemd). Your setup also has to be a very basic one. Even your network interfaces or your disks can appear too late for your script on a very basic setup. systemd is an answer to all this actually: it finally puts the dynamic parts in userspace needed to correctly handle the dynamic kernel.
The problems the OP is seeing, I've crashed into several years ago, and it's basically a documentation problem. Some of the plumbing tools used for DE (like polkit or accountsservice) are badly documented, sometimes badly designed, sometimes with incomplete options (fixed in the latest versions of accountsservice) and the worst is that there is no howto that I could find explaining the big picture of how it all works together: everything is buried in various development ML. I had to basically reverse engineer nearly everything to understand how it works, mostly because as I compile everything from upstream, the DE like Gnome and KDE would just not start without everything in the right place and well configured. Gnome 3 and KDE 4 were the worst upgrades for me, I delayed them a lot. So what the OP discovered is actually nothing new, and I agree but only for security related plumbing needed for DE and user sessions.
So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like/etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.
This/etc/network/interfaces which is distro specific that you talk about, is exactly one of the configuration for which a replacement is proposed by the systemd you talk about below:
The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!?
Yes, in systemd it exists, nowhere else for now.
It's called the kernel!
No it's not, you don't understand what you're talking about. The kernel doesn't configure your network interface for you, it just manages the device.
On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.
It sure enough removes complexity from the OS if you use every control systemd allows.
3-4 naysayers? More like the majority of the linux community. As for a new init process, sure , there's room for *improvement*. Systemd is not an improvement - its a bug ridden overly complex dogs dinner that is one mans ego trip being ridden roughshod through the whole linux/unix principal of KISS and do one thing well. Now you might not give a stuff about that principal but most of us do and we do not want to see this POS being installed by default.
Who is "us"? I sure enough am not part of the people you're talking about, and most of the Linux community, those that develop software and manage most distributions, have switched to systemd. If you care about the linux community, then you should come join us in the real world and quit your fantasy land. Linux never had this principal of doing one thing well, that's a laughable statement.Linux actually does lots of things well and even better, as is systemd. If Debian unstable is above your proficiency level, then wait for the stable releases. It's not even about Debian here, it's about upstream systemd, that you won't see before long unless you run your own OS and compile everything from upstream like I do, or use a distro like Gentoo which is very up to date.
Consider, RAID and similar are high availability features. Their whole reason to be is making sure the system is available even if a drive fails. Systemd single-handedly defeats that whole purpose by refusing to even try to mount the root filesystem.
At first reading, I was mislead by thinking you were talking about RAID and similar high availability features in general, which work far better with systemd and LVM than with sysvinit where it was a nightmare prone to break on any boot. Then I understood you were talking about these features inside btrfs. And that's where you're yet again one of these people spreading FUD on systemd by being ignorant, be it on purpose or not. How is software RAID and other features like it (like snapshots) handled on Linux? Yes, by one of several daemon, in the LVM package, that manage the state of the virtual devices. That's because, like was explained by the systemd developers, despite these features being implemented inside btrfs, the kernel still doesn't have enough states to give to userspace : the disk is either plugged or not. And this is not at all driven by systemd but by udev, which yes, is in the systemd repository. The issue here is that btrfs lacks the daemon to manage the virtual devices in userspace, and the kernel, if your btrfs RAID is degraded, say the disk is dead, thus why udev doesn't show the btrfs RAID as plugged, and thus why systemd doesn't mount it. All of this was explained, but you chose to spread FUD by blaming systemd as being shit and breaking userspace. It works with sysvinit because your script doesn't care for which disks are up or not, and will just break your setup any time some disk doesn't show up.
That's really a poor showing, but the insight it gives me into the project is even worse. It tells me that in spite of the importance of redundancy (some enterprises spend gadzillions on it) and the fact that it has worked well under SysVinit for over a decade, not one person on the systemd team even considered it.
This is a lie, btrfs didn't work well for a decade to begin with, btrfs is not even a decade old. This just shows up to what ends systemd haters are willing to go to spread FUD. And don't tell me RAID and SAN worked well with sysvinit, this would be another blatant lie.
Now that it has been brought to their attention, they can't even come up with a workaround for it (see what I said above about do what I say and do it now). All I need is an unconditional 'mount -a' and apparently it can't be done. In spite of that, the various systemd boosters refuse to admit the problem even exists. I have even had a few claim it's a feature meant to protect my data.
So there it is. It's not a matter of opinion, it's a simple boolean: "Did my system boot" and the objective answer is no. There is the followup, "how then, can I make systemd boot it" and the answer is [crickets].
I described the real situation up there, and everything can be found in ML archives, so everyone can see that eveything you wrote there are blatant lies. It's scary at this point. Even the situation you described is wrong. You actually asked "Did my broken system boot?" and the objective answer is no. A good btrfs RAID would have booted, then even if a disk failed, it would stay functional. But it wouldn't boot in degraded state, just as most hardware RAID by default in fact.
Now I'm starting to believe in a conspiracy against Free Software. I find it odd to see such nonsense written here, being modded up. Because what is described here (making the product closed source) is just not possible to do for Free Software like systemd, but is entirely possible (and has been done before and up to this day) with BSD. Yet, this explanation of why a free software liecensed init system (systemd) is like a closed source operating system (Windows) appears here, is based on nothing solid, but people seem to believe this nonsense nonetheless. And there have been a big amount of articles about moving from Linux to BSD since six months ago, and I'm now starting to believe this is astroturfing. Even the move to BSD because of an init system makes no sense to me.
What I'm sure about, is that to this day I'm unable to make my own Windows OS, but I'm still able to do my own Linux systems (all my Linux systems at home are custom made from upstream sources) even today despite having moved to systemd years ago. Though it's not a bad thing to go learn other OS out there for an admin, I more or less know most of the Unix and Windows systems, but not Mac OS.
Whether or not you like it, it's not unfair to classify systemd as being "forced" on its users.
Users of systemd include distribution builders, daemon makers and administrators. It's clearly wrong and unfair to say systemd has been forced on these people, unless they're incompetent. Actually, most of these people are happy with the change. Not all administrators obviously as it requires some work and learning to switch your init daemon and its accompanying system startup, shutdown and live management process.
For a start, it's wildly popular with distribution builders, but this doesn't mean jack with anyone else.
This is plain wrong, I've seen popularity and interests among daemon makers and administrators too : the only people that had to deal with sysvinit and suffered decades from its insanity, especially for low level stuff like network and storage management.
Secondly, for a while (thought they've promised to me that they're trying to and maybe have by now fixed it), GNOME had a hard dependency of systemd. Being the most popular desktop environment more or less forced the hand of many of the distro builders too.
Again a lie. Gnome has a hard dependancy on systemd-logind API, this is like that because Gnome asked for a replacement of consolekit for months, and there was two sides : those that did the work (only systemd) and those that said "You just have to do this" without any work done. The same applies with the console on userspace and the linux kernel.
To me, the whole thing seems odd. I've never seen a massive infrastructure change sweep so rapidly through the community of distributions. Especially such a major component, and double especially when things did actually work successfully before.
To me, what's odd is the time it took (15 years since I've seen the problem) for a solution to the problem to appear, and also the 5 years it took since I discovered systemd for it to be adopted. Things didn't work successfully before, the people believing that are those that never had to fight their way through init scripts for all these years. The massive adoption is not at all surprising to me, this was needed for years. An evidence is the fact that even those against systemd are afraid, among other things, of the cost of maintenance of init scripts, because they don't work successully to this day, are full of hacks, and so require lots of maintenance that "you just have to do" talk won't do.
It annoys me that someone like Poettering, who only had PulseAudio come into use because of the ability distributions had to easily change core operating system components (and wouldn't have had the existing audio-subsystem been entrenched), would then proceed to develop something specifically intended to lock down its own existence and prevent its replacement by something else. It's hypocritical.
While I totally understand why he did it -- nobody wants to put a great amount of time into something only to have it superseded -- it flies in the face of open source in general, where you contribute to an evolving 'thing', and that while your specific contribution may not exist in the future, you can be happy that you took part in the evolution of the whole, and not feel the need to stamp your face on it for perpetuity.
What flies in the face of open source is actually people like you that waste time whining about people that actually code open source. Complaining is all you're able to do, just go help the Devuan project instead. Since Devuan appeared, there's still lots of people complaining and others dedicating efforts to go to BSD, and these people love to advertise that they're moving to BSD. But we don't care ! Just move to BSD already and leave the people on Linux alone.
It also sets a dangerous precedent. What's going to be locked down next, in the name of stability, or speed, or whatever else (when it's really about someone trying to 'make their mark'?) Do we lock down the file system? Only one file system for Linux, full stop? Do we lock down the network transports? The window manager? The terminal? The command-line applications?
What's this hyperbolic nonsense ? Nothing has been locked down here. Actually with systemd, nothing is locked down at all, I even have more power over my Linux now than ever. These doom and gloom stories for Linux because of systemd are just ignorant rants. People that actually use and understand systemd don't care because these rants make no sense.
unless of course you want to start a script with a unit file but then are you sure that iptables is up?
In all my time using Linux, wondering if iptables had crashed has never been a problem I've had. I've had lots of problems, but never that one. Same with filesystems. Fstab has always just worked.
You have not really worked in heavy duty Linux environments then. I experienced fstab failures tons of time, be it because fstab is buggy, hard drive is dying, memory is dying, emergency shutdown,... I agree that the problem with iptables usually is not if it has crashed, it's rather things like path of executable or features parity with the kernel.
And an extra layer in front of iptables is the last thing I need. That is a huge negative. I don't even understand why anyone would think that's a good idea.
And yet, this library (libiptc) is available in the upstream iptables package. So you're saying that's a huge negative, despite it being provided upstream by the iptables developers, and you don't understand it just because you don't need it. So you're acknowledging you're incompetent as a sysadmin and developer, and how much you're not qualified to talk about this topic. Just like most haters who have nothing constructive to say here. I've yet to see any sane rebuttal to this, only angry people (you have the right to be angry, even on sth you demonstrably don't understand), especially since systemd-networkd is optional with systemd, and this feature is optional too in systemd-networkd. But all sane admins with systemd use it I believe, and threw away their old scripts, that were doing the job of setting up the network but worse.
Even worse, try requiring LDAP (not just making it an option when an account isn't found locally, actually requiring it) for logins on a system booting via SystemD. Have your recovery media handy, you'll have to boot from it in order to remove the LDAP requirement when SystemD can't su because the network isn't up yet (or, if the LDAP server is localhost, slapd hasn't started because, guess what, it needs to su to its configured user during its init process).
What is this nonsense ? I use LDAP since before adopting systemd in 2009, and I never had any of these problems on my own made Linux systems. Are you implying distributions are even worse than when I quit using them in 2000? Are you implying that distribution maintainers are incompetent? What I'm sure is that it's a distribution problem, not a systemd problem. I never had the problem you describe which doesn't even make sense, even before I used sssd, and my/etc/passwd contained only root and messagebus accounts (now it also has the new systemd accounts). And my systemd systems work just fine even when network is not up yet, localhost is always there and slapd as well as sssd listen on it.
Major issue affecting Ubuntu and, as far as I know, all Debian-based systems. The workaround should be simple: allow local account logins right up until TTYs actually become available, regardless of configuration. But, apparently, LDAP isn't considered important, so this has been an issue for as long as Debian has used SystemD and will likely remain so until Debian moves on to something else.
This is BS, I can't even believe Debian and Ubuntu maintainers are so bad, where's the bug report ?
The current "recommended" workaround is a pair of ifup/down scripts that requires LDAP when the interface is up and makes it optional when it interface is down, which is great until your system crashes or you lose power and the "optional" config doesn't get applied. Then, it's time to whip out the recovery media so you can manually change the config and have a bootable system again. Needless to say, I refuse to implement that hack of a fix.
So this must actually be a bug tied to sysv compatibility, as you're talking about these broken ifup/ifdown scripts. Granted, I instantly moved to full systemd configuration, it's not so easy for a distribution. Most of their problems seem to come from the compatibility layer. sysvinit scripts are so insane, I can't blame them for having problems with them. Surely it makes them maintainers push forward to quit using these sysvinit scripts as soon as possible, even faster than before.
As always, I see most Slashdot representative comments being completely wrong when it comes to Nintendo. It seems like some people wait for every news on Nintendo to spew all the ire and BS that keep them enraged inside.
I'm still wondering where people are seeing anything about "competing". Yet, a lot of posts act like he talked about competing with these mobile devices.
Fils-Aime, who is NOT CEO of Nintendo (which should give a clue as to how misleading this news is) is talking about the content, the games, and people's perception of value on games. It has nothing to do with graphics or animations or whatever problem people have with Nintendo, it's about content and its value to the consumer. He's saying it's dangerous for the industry to make people believe that whatever the content in a game, it has a very low value (and so a very low price). He doesn't even say it's threatening anyone right now, he says its a possible risk.
People on Slashdot, as with the DS or the Wii (or even the first iPod), are already talking like 3DS is dead on arrival and Nintendo is doomed (as always). Yet, it's for opposite reasons. $2 games would kill most HD console games types faster than any Wii or DS ones.
I think what Reggie said is more a warning to 3rd parties. We see lots of 3rd parties porting their already (or not) profitable games to mobile platforms, for a very cheap price, and sometimes it's exactly the same content. The problem is that a consumer who paid $40-$70 for a game, that sees the same one for $5 on his mobile, will not really be happy about ever paying the high price again. And if lots of them come to the same realization, you will see mostly western 3rd parties die left and right (worse than what we see today). Because most western 3rd party games (and lots of eastern ones too) rely on selling a lot at launch, and then quickly die. If they don't sell a lot at launch, you see the games with quick slashed prices. 3rd parties can do that because the cost of the game is already taken care of by the other platforms, but there are very few people (the hardcore) that will want to pay so much more to have the privilege of playing the game day 1.
Nintendo doesn't have this problem as their games sell with veeery long tail. Basically, 3rd parties (the big one) are shooting themselves in the foot if they go on, and less 3rd parties alive to make games for Nintendo platforms means less revenue for Nintendo. Apart from that, Reggie is not really complaining, not yet at least, as even the DS is right now more threatened by the 3DS than by any mobile device with games. They're not in direct competition like computer games (like flash games and all that existed for a long time) are not competing directly with console games (except for devs resources). Or that would mean consoles are winning...
I agree partly with you. It's true that consistent interface naming has just worked for years with multiple interfaces. The author is talking about races but they are not explained in his paper and are marked as thinks since 2009.
What this basically boils down to is that now distributions can streamline the naming of your interfaces without you having to go test them the first time you install your OS to know which is which. You'll now know immediately from your OS. This shouldn't upset anyone, except people that can't accept change. It will be a matter of accepting now to use lom0-X or em0-X instead of eth0-X.
People like me who are already using udev rules to change their network interface names won't be affected anyway, and you still can name your interfaces like you want as udev is still what renames these interfaces.
As has been mentioned above - you can tell from your comments you are just a home user.
Try writing OS-level software (stuff that is imaged onto the device) that depends on the NIC in position 1 on the PCI bus always being the management interface (IE, the first port in the chassis). Remember this software has to know IN ADVANCE which port it is, you can't use the MAC for this at all.
This has been a problem in Linux for years and one that developers have always had to hack and slash around. I am glad RedHat is finally fixing it. Hopefully other distributions will follow suit.
I don't understand what you're saying. If you wanted to do that, you could do it a since years with udev IN ADVANCE of your software you want to launch. Since YEARS udev has put persistent device naming so that what is said in the article is wrong, because you will always get the same name for your devices. Since years, I actually have my Ethernet interfaces which are not named eth0-X but sth else, which is based on any arbitrary value you want that is provided by udev, including PCI slot and what not. So what exactly are you talking about?
The sole difference I see there is that the distro will now do it upstream instead of you having to put your udev rules. Which seems to be a good thing since people like you who are not mere "home users" apparently don't know about these features and have missed these functionality for years. What's worse is that you're saying it's a problem with "Linux" whereas the sole problem comes from you being ignorant of the solution.
It's strange too that you talk about this being a problem with Linux and devs having to hack and slash, when the solution couldn't be done anywhere before because the specs weren't out (SMBIOS 2.6, now exposed through linux kernel since 2.6.36 some weeks ago, or ACPI or via biosdevname) and the solution proposed here is still the exact same kind of hacks you're talking about. FWIW, the sole difference here is the naming convention, as the solution is still implemented via udev rules, with the exact same mechanisms as before, mechanisms used for YEARS with the same hacks. The main difference compared to before, is that now the naming scheme can be streamlined by a distribution, while before it couldn't, because it would have no consistency.
Slashdot Mirror
But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.
Yes, these scripts are workaround for the deficient sysvinit, like trying to guard against environment tampering, managing user options without modifying the init script itself (often scattered over several locations), ...
systemd removes these nonsense scripts and replaces them with a simple configuration file (a unit) without any drawback. You can even modify the systemd units, with your modifications usually still valid after an upgrade (it won't work if your unit is renamed to something else than apache2).
This just shows how horrible init scripts were. It's even worse when you know you can manage isolation like chroot, or security features very useful for a web server like hiding filesystems or directories from the daemon.
Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.
This is correct, except for the bunch of people unfamiliar with modern OS operation. Their goal was to reduce this number, which doesn't solve any use case I know for big servers, except reduce attack surface at boot perhaps, this I can agree with.
For smaller servers and limited resources systems, like embedded systems, the efficiency is very welcome. My security frontends say thanks to systemd.
Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.
*Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.
Actually, systemd works far better with my use cases. It works far better with LVM2 for instance, than my shell scripts ever could.
Actually, it works every time now with systemd. mysql and apache works far better now, especially mysql which was a pain to start and especially to stop with the initscripts. Now with systemd it's far better.
I agree there's some tuning to do at first, but not the kind of bad hacks we had to use with init scripts.
The attack surface of init scripts was also huge, without any hope to discover it without constant monitoring. Some init scripts had 4 (yes four) different ways to configure them, each one could be exploited.
The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems.
There is no such "established-over-decades code in scripts" in the real world, which is why sysadmins around the world constantly had to tinker with these scripts. This is also the exact reason why if no one cares about them, these init scripts will wither and die.
The most important plumbing init scripts are flawed by design, init is flawed in a dynamic environment like the one created by the Linux kernel, which is why everyone wanted to flee it since a long time. But sysadmins and distro makers couldn't agree on anything until systemd.
Systemd is tying into everything from initial boot to how to configure your soundcard.
Actually, systemd doesn't tie into how to configure your soundcard, but if you don't understand what people are talking about, especially systemd opponents, I see why you would think that. You must believe pulseaudio is part of systemd I gather.
On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.
I don't understand why you're talking about Windows here as a party, you're not making any sense.
systemd is free software, so I assure you that you don't have to deal with undebuggable binaries, as the code to these binaries is readily available. Exactly like the source code of sysvinit or the numerous daemons launched by the scripts you're talking about.
Perhaps you believe the init scripts themselves were serving as daemons, but that's rarely the case : these scripts were just there to try (badly) to understand the context to then launch "undebuggable binaries".
It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.
I don't understand what is scary about that. Your system depends on lots of binaries working as expected, starting with your bootloader, your kernel, your daemons, ...
That's the job of a sysadmin, I can assure you they're not scared at all providing they know what they are doing.
I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.
Actually you can still do that with systemd, but even better than before, especially when your keyboard is not qwerty or your character encoding not ASCII.
On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.
Why? I'm on the second side and I do exactly as advertised, even better than with sysvinit.
More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.
This was always the case in Linux, like most of the Linux plumbing ecosystem, which is not a bad thing imho, as long as the projects are active.
If you have any reason to care how long it takes for your server to boot, you're already doing it wrong.
You are plain wrong added to the fact that you're not a good sysadmin then, or one with very little experience if any.
You need a threshold of time to know if your server will go up or not.
Guess what, a server won't always go up for various reasons, especially when you have init.d scripts patched everywhere with various timeouts, that can break at any reboot. You need to monitor your server startup, and it starts to become tedious when you have tens of server startup to monitor.
it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.
There is no so called "linux design principle" of do one thing and do it well, and even if there was, it would be the contrary of what you're saying as Linux (the kernel) has a monolithic design. In the case you were talking about GNU, systemd uses the same design as most GNU software, which is a "software collection".
There is no linux principle of "everything is a text file", this is pure nonsense as sure enough, not everything in Linux is a text file (just look at sockets or block devices).
There is a Unix principle that says everything is a file, but not a "text file". You're mixing several things without understanding the purpose of what you're talking about.
Anyway, guess what, outside the United States, often the classic log files are actually binary files. Because what you describe as "text files" are actually "ASCII files" which is an encoding, but if your kernel or tools don't support UTF-8 encoding which is mostly used on Linux, you will extract mostly garbage from log files (all of mine are UTF-8 files, and yes I have log files despite using systemd). But that's nitpicking, binary log files are not a problem with systemd as you can use classic "text files" juste the same with systemd.
Finally, there's no "single subsystem" that takes a large number of roles with systemd, each subsystem in systemd has one role.
In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.
Actually, systemd is an actual huge upgrade for system administrators who manage servers, in the actual world, not in an hypothetical one.
The problem is that actual administrators, to switch to systemd, will have to manage the more or less huge number of hacks they inserted into deficient init.d scripts, which can be a huge tasks depending on if they documented them or not. And probably most didn't...
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.
That is my understanding looking in from the outside.
Your understanding is wrong, but you're not to blame, it's understandable because those opposed to systemd have no other argument than to make you believe all the components you cited are integrated into one tool/process. Of course this is false. ...
systemd, the PID 1 process, manages initializing processes on bootup and scheduling jobs after boot-up, like sysvinit. It has lots of features to do these tasks even when the environment dynamically changes.
Maintaining logs is in another process, managing devices alo in another process, managing network devices in another process
So actually, if that's your definition of Unix "philosophy", systemd pretty much is adequate.
There is no Linux "philosophy", but you believe that because Unix "philosophy" (which has as many meanings as there are people using these words) is used to attack systemd, as if Linux and Unix were the same things. Actually, Linux (and GNU) by itself already detracts from Unix in lots of ways already.
It isn't just Linux; it's the nature of modern systems to become "too complex". Back in the days of my youth, it was possible for one person to grok an entire operating system, but it simply isn't possible anymore, unless it's a tightly-focused and built-to-purpose system.
And yet that's exactly what I'm doing today on my systems, which I build from scratch. And I grok the entire operating system, systemd was a god send tool for me.
I run in a setup where multiple graphical sessions run on one computer, which only Linux allow me to do very easily.
There is one exception though : polkit. It is the only tool on my systems that I never tried to completely understand. Now I don't even need to anymore with udev + systemd. And I bet that's where the op is having problems, as it was fixed by installing systemd.
The behaviour of "Linux" (all the distributions and kernels) as a whole is exactly the same behaviour you see in companies with poor management. Everyone is working on stuff, and maybe even working hard, but all those things don't add up to the whole. There's no 1 person over-seeing it all to ensure everyone is working smart, and in the same direction.
And the outcome is pretty good as Linux runs on every computer available to this day, be it embedded or phones or HPC. So I don't understand what you mean by poor management, are they able to do that in poor management companies?
To me, this is what is happening with Linux. Everyone has ideas, and some of those ideas are great, but when everyone can fork and create and merge without an overall management process, you end up with a bit of a mess and mass confusion for those on the "outside."
You're just new to this: Free Software is like that since it started, what you say is laughable to people used to FOSS. You talk like you just discovered FOSS.
This is both the advantage (choice) and disadvantage (lack of alignment) with Linux. Should I use Gnome or KDE or Unity? Do I even know what those are as a end-user? Should I?
What I get OSX, I know what I get. When I get Windows, it's the same.
Should you use Windows or OSX? Windows Vista, Windows 7, Windows 8, Windows Server 2008?
When you get Ubuntu, you know what you get just as much as when you get OSX, you even can test it without installing anything.
You're juste spewing fallacies here.
Everything (mostly) from the previous version will work with this version, the interface isn't some massive surprise, etc (which is partially why Windows 8 was such a fiasco; things WEREN'T compatible and the UI was totally different).
You must be young as what you say is patently false, especially in Windows. Nearly everything I learned in Windows 98 was made useless when Windows XP came, including most of my work environment. I can say the same with Windows NT to Windows Server 2003. While nearly everything I learned in school on Unix 20 years ago is still usable today on Linux which is not even Unix.
At the end of the day, what needs to happen is exactly what most Linux devs hate the most: a large corporation with 1 vision needs to come in and create a clean, uniform experience that allows consistency and compatibility for years/decades, and reduces "choice" to a degree in order to provide consistency.
To some degree, you can argue RedHat did this a bit, especially with packages, but everyone hates on them too now..
This is what distro do, it's nothing new, it's just you discovering it now, but everything you're saying has already been done and evolved since then.
Let's see what modern Linux does:
- Lots of binary stuff everywhere, where text would do
- You'll boot up faster with systemd, oooh yeah baby, totally rad!
It's funny you say that, as systemd is about putting back text (systemd units) instead of lots of binary stuff everywhere (init scripts).
- Oooh, and it's more integrated, one single process does everything!
Not on my Linux, and I use systemd. I mean it's integrated and I do not have one single process which does everything.
I would personally like to see three flavors of Linux:
Server - lean, NO systemd or plug-and-play crap, focus on security
So you will need systemd on your servers, especially if you want focus on security. The Linux kernel provides dynamic interfaces since a long time, and no one in userspace provided the tools to cope with it until systemd. Devices was done with udev and its predecessor devfs, but init was unable to cope with it before systemd, despite higher level tools trying to cope with the linux kernel dynamic nature.
When vague anecdotes start to pile up (and they do for systemd unreliability), they become facts in themselves.
No, anecdotes never lead to facts even if you have millions of them. You can't even say facts of what. Only analysis of anecdotes can lead to facts.
This is becoming ridiculous, pushing dogmatic thoughts like that is dangerous.
Add to that that systemd problems are exceptionally hard to debug (you have to look into complex C source code for many) and the development team is unhelpful
This is pure lie that can be debunked by just looking at the devel ML.
Why systemd haters always have to rely on lies?
The reason many, many people are reporting vague anecdotes about their system being unstable from systemd is not that they are lying, or fantasizing or on drugs, the reason is that systemd does indeed break reliability and on top is very hard to debug and fix.
No, the reason is that the unstable distro these people are using is really unstable, but they are too young to have experienced previous big breaks in GNU/Linux distro, like udev predecessor, kernel 2.2 to 2.4, 2.4 to 2.6, 2.6 to 3.0, 3.3 to 3.4, Gnome to Gnome 2, Gnome 2 to Gnome 3, ...
systemd is far from being the biggest change and challenge in Linux since I've worked with it starting in 1999, it's actually a breeze that no decent admin that know several Unix + Linux should trip on.
Some very old engineering failure analysis wisdom applies here: To really break things, you have to screw up in two major aspects. Systemd manages to do this easily by being unreliable and so hard to debug that most people fail at it. People are scared of it and angry at it, because they cannot master this complexity. And they are right to fight it: A decent OS has no business at all being complex in any place where it is avoidable and in particular, it has no business at all replacing simple things that work with complex ones, regardless of whether they work or not. If Linux is not kept free of high complexity in core components, it will implode.
When I read this I could be made to believe I'm a genius. This is wrong on so many levels, the first one being that things didn't work before, things were duct taped constantly by distro providers or by admins. Which is why the first thing systemd haters talk about is being able to tweak their initscripts, because the secret to unknowing people is that the basic distros just don't work with their setup, which has to be tweaked with ugly hacks for every specific environment.
It becomes a hell to maintain and every distro upgrade is at risk of failing very badly or erasing their change.
Usually what happens is that you forget about it, then when it blows up, blame the distro, and then quickly flee in shame when you realise it was all your fault to begin with. Now these admins blame systemd for their faults, the good ones come regularly to the ML to see their problem fixed.
Fortunately systemd is part of the fix for this mess.
>When a computer is less useful today than it was last year thanks to systemd getting installed, the problem is solely with systemd.
In the OP, it's the opposite: the computer is more useful today than it was before thanks to systemd getting installed, so the problem is solely with something else.
Which makes sense since a distro upgrade is not just systemd being upgraded, contrary to belief of non proficient people.
I was reading through the article's comments and saw this thread of discussion. Well, it's hard to call it a thread of discussion because John apparently put an end to it right away. The first comment in that thread is totally right though. It is systemd and Gnome 3 that are causing so many of these problems with Linux today.
perhaps he shuts them down because he specifically said that installing systemd solved his problem but he doesn't know why.
Yet people with logic problems claim systemd is the problem, despite the fact that it wasn't installed on the systems experiencing the problem.
Systemd has been the most divisive force in the Linux community lately, and perhaps ever.
As it has been adopted by most distro, you're obviously wrong with your rhetoric. It has been one of the most cohesive force actually.
It has been foisted upon many unwilling victims. It has torn apart the Debian community. It has forced many long-time Linux users to the BSDs, just so they can get systems that boot properly.
systemd doesn't have the power to force anyone to do anything, people that went to BSD did this on their own will.
Debian community has not been torn by systemd but by trolls actually, systemd was the point used by the trolls.
And usually, victims are unwilling to be victims, or so I heard.
Systemd has harmed the overall Linux community more than anything else has. Microsoft and SCO, for example, couldn't have dreamed of harming Linux as much as systemd has managed to do, and in such a short amount of time, too.
I won't take your word for it on this, only time will tell but I'm pretty sure what you say is just plain hyperbole.
Competent sysadmins actually have no problem with systemd, on the contrary.
Rolling your own 'Just like Linus did' may be a little extreme. I don't think you need a whole new kernel!
Just install Linux from scratch and don't put all that *kit, etc.. crap in it. I would imagine you could even get rid of udev and all that stuff if you are willing to run mknode yourself. Roll it like it's 1995.
You will lose out on some convenience if you are using a portable device such as a laptop but on a desktop with fairly static hardware everything should work just fine.
If having your own custom simple Linux isn't good enough for you then take it to the next step and start your own distro that leaves all that stuff out.
I've run my own Linux From Scratch like system since 2001, and I can say your advice is a very bad one.
The problem is that the kernel provides dynamic interfaces since a long time. If you do what you say here, you will have a very limited setup that must not be a moving target, or take the risk of seeing your OS not boot very often, or even lose data (I had several of these problems before systemd). Your setup also has to be a very basic one.
Even your network interfaces or your disks can appear too late for your script on a very basic setup.
systemd is an answer to all this actually: it finally puts the dynamic parts in userspace needed to correctly handle the dynamic kernel.
The problems the OP is seeing, I've crashed into several years ago, and it's basically a documentation problem.
Some of the plumbing tools used for DE (like polkit or accountsservice) are badly documented, sometimes badly designed, sometimes with incomplete options (fixed in the latest versions of accountsservice) and the worst is that there is no howto that I could find explaining the big picture of how it all works together: everything is buried in various development ML. I had to basically reverse engineer nearly everything to understand how it works, mostly because as I compile everything from upstream, the DE like Gnome and KDE would just not start without everything in the right place and well configured.
Gnome 3 and KDE 4 were the worst upgrades for me, I delayed them a lot.
So what the OP discovered is actually nothing new, and I agree but only for security related plumbing needed for DE and user sessions.
So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like /etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.
This /etc/network/interfaces which is distro specific that you talk about, is exactly one of the configuration for which a replacement is proposed by the systemd you talk about below:
The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!?
Yes, in systemd it exists, nowhere else for now.
It's called the kernel!
No it's not, you don't understand what you're talking about. The kernel doesn't configure your network interface for you, it just manages the device.
On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.
It sure enough removes complexity from the OS if you use every control systemd allows.
3-4 naysayers? More like the majority of the linux community. As for a new init process, sure , there's room for *improvement*. Systemd is not an improvement - its a bug ridden overly complex dogs dinner that is one mans ego trip being ridden roughshod through the whole linux/unix principal of KISS and do one thing well. Now you might not give a stuff about that principal but most of us do and we do not want to see this POS being installed by default.
Who is "us"?
I sure enough am not part of the people you're talking about, and most of the Linux community, those that develop software and manage most distributions, have switched to systemd. If you care about the linux community, then you should come join us in the real world and quit your fantasy land.
Linux never had this principal of doing one thing well, that's a laughable statement.Linux actually does lots of things well and even better, as is systemd.
If Debian unstable is above your proficiency level, then wait for the stable releases.
It's not even about Debian here, it's about upstream systemd, that you won't see before long unless you run your own OS and compile everything from upstream like I do, or use a distro like Gentoo which is very up to date.
Consider, RAID and similar are high availability features. Their whole reason to be is making sure the system is available even if a drive fails. Systemd single-handedly defeats that whole purpose by refusing to even try to mount the root filesystem.
At first reading, I was mislead by thinking you were talking about RAID and similar high availability features in general, which work far better with systemd and LVM than with sysvinit where it was a nightmare prone to break on any boot.
Then I understood you were talking about these features inside btrfs.
And that's where you're yet again one of these people spreading FUD on systemd by being ignorant, be it on purpose or not.
How is software RAID and other features like it (like snapshots) handled on Linux? Yes, by one of several daemon, in the LVM package, that manage the state of the virtual devices. That's because, like was explained by the systemd developers, despite these features being implemented inside btrfs, the kernel still doesn't have enough states to give to userspace : the disk is either plugged or not.
And this is not at all driven by systemd but by udev, which yes, is in the systemd repository.
The issue here is that btrfs lacks the daemon to manage the virtual devices in userspace, and the kernel, if your btrfs RAID is degraded, say the disk is dead, thus why udev doesn't show the btrfs RAID as plugged, and thus why systemd doesn't mount it.
All of this was explained, but you chose to spread FUD by blaming systemd as being shit and breaking userspace.
It works with sysvinit because your script doesn't care for which disks are up or not, and will just break your setup any time some disk doesn't show up.
That's really a poor showing, but the insight it gives me into the project is even worse. It tells me that in spite of the importance of redundancy (some enterprises spend gadzillions on it) and the fact that it has worked well under SysVinit for over a decade, not one person on the systemd team even considered it.
This is a lie, btrfs didn't work well for a decade to begin with, btrfs is not even a decade old.
This just shows up to what ends systemd haters are willing to go to spread FUD.
And don't tell me RAID and SAN worked well with sysvinit, this would be another blatant lie.
Now that it has been brought to their attention, they can't even come up with a workaround for it (see what I said above about do what I say and do it now). All I need is an unconditional 'mount -a' and apparently it can't be done. In spite of that, the various systemd boosters refuse to admit the problem even exists. I have even had a few claim it's a feature meant to protect my data.
So there it is. It's not a matter of opinion, it's a simple boolean: "Did my system boot" and the objective answer is no. There is the followup, "how then, can I make systemd boot it" and the answer is [crickets].
I described the real situation up there, and everything can be found in ML archives, so everyone can see that eveything you wrote there are blatant lies. It's scary at this point.
Even the situation you described is wrong. You actually asked "Did my broken system boot?" and the objective answer is no. A good btrfs RAID would have booted, then even if a disk failed, it would stay functional. But it wouldn't boot in degraded state, just as most hardware RAID by default in fact.
Now I'm starting to believe in a conspiracy against Free Software.
I find it odd to see such nonsense written here, being modded up.
Because what is described here (making the product closed source) is just not possible to do for Free Software like systemd, but is entirely possible (and has been done before and up to this day) with BSD.
Yet, this explanation of why a free software liecensed init system (systemd) is like a closed source operating system (Windows) appears here, is based on nothing solid, but people seem to believe this nonsense nonetheless.
And there have been a big amount of articles about moving from Linux to BSD since six months ago, and I'm now starting to believe this is astroturfing.
Even the move to BSD because of an init system makes no sense to me.
What I'm sure about, is that to this day I'm unable to make my own Windows OS, but I'm still able to do my own Linux systems (all my Linux systems at home are custom made from upstream sources) even today despite having moved to systemd years ago.
Though it's not a bad thing to go learn other OS out there for an admin, I more or less know most of the Unix and Windows systems, but not Mac OS.
Whether or not you like it, it's not unfair to classify systemd as being "forced" on its users.
Users of systemd include distribution builders, daemon makers and administrators. It's clearly wrong and unfair to say systemd has been forced on these people, unless they're incompetent. Actually, most of these people are happy with the change. Not all administrators obviously as it requires some work and learning to switch your init daemon and its accompanying system startup, shutdown and live management process.
For a start, it's wildly popular with distribution builders, but this doesn't mean jack with anyone else.
This is plain wrong, I've seen popularity and interests among daemon makers and administrators too : the only people that had to deal with sysvinit and suffered decades from its insanity, especially for low level stuff like network and storage management.
Secondly, for a while (thought they've promised to me that they're trying to and maybe have by now fixed it), GNOME had a hard dependency of systemd. Being the most popular desktop environment more or less forced the hand of many of the distro builders too.
Again a lie. Gnome has a hard dependancy on systemd-logind API, this is like that because Gnome asked for a replacement of consolekit for months, and there was two sides : those that did the work (only systemd) and those that said "You just have to do this" without any work done.
The same applies with the console on userspace and the linux kernel.
To me, the whole thing seems odd. I've never seen a massive infrastructure change sweep so rapidly through the community of distributions. Especially such a major component, and double especially when things did actually work successfully before.
To me, what's odd is the time it took (15 years since I've seen the problem) for a solution to the problem to appear, and also the 5 years it took since I discovered systemd for it to be adopted.
Things didn't work successfully before, the people believing that are those that never had to fight their way through init scripts for all these years. The massive adoption is not at all surprising to me, this was needed for years.
An evidence is the fact that even those against systemd are afraid, among other things, of the cost of maintenance of init scripts, because they don't work successully to this day, are full of hacks, and so require lots of maintenance that "you just have to do" talk won't do.
It annoys me that someone like Poettering, who only had PulseAudio come into use because of the ability distributions had to easily change core operating system components (and wouldn't have had the existing audio-subsystem been entrenched), would then proceed to develop something specifically intended to lock down its own existence and prevent its replacement by something else. It's hypocritical.
While I totally understand why he did it -- nobody wants to put a great amount of time into something only to have it superseded -- it flies in the face of open source in general, where you contribute to an evolving 'thing', and that while your specific contribution may not exist in the future, you can be happy that you took part in the evolution of the whole, and not feel the need to stamp your face on it for perpetuity.
What flies in the face of open source is actually people like you that waste time whining about people that actually code open source.
Complaining is all you're able to do, just go help the Devuan project instead.
Since Devuan appeared, there's still lots of people complaining and others dedicating efforts to go to BSD, and these people love to advertise that they're moving to BSD. But we don't care ! Just move to BSD already and leave the people on Linux alone.
It also sets a dangerous precedent. What's going to be locked down next, in the name of stability, or speed, or whatever else (when it's really about someone trying to 'make their mark'?) Do we lock down the file system? Only one file system for Linux, full stop? Do we lock down the network transports? The window manager? The terminal? The command-line applications?
What's this hyperbolic nonsense ? Nothing has been locked down here. Actually with systemd, nothing is locked down at all, I even have more power over my Linux now than ever. These doom and gloom stories for Linux because of systemd are just ignorant rants. People that actually use and understand systemd don't care because these rants make no sense.
unless of course you want to start a script with a unit file but then are you sure that iptables is up?
In all my time using Linux, wondering if iptables had crashed has never been a problem I've had. I've had lots of problems, but never that one. Same with filesystems. Fstab has always just worked.
You have not really worked in heavy duty Linux environments then. I experienced fstab failures tons of time, be it because fstab is buggy, hard drive is dying, memory is dying, emergency shutdown, ...
I agree that the problem with iptables usually is not if it has crashed, it's rather things like path of executable or features parity with the kernel.
And an extra layer in front of iptables is the last thing I need. That is a huge negative. I don't even understand why anyone would think that's a good idea.
And yet, this library (libiptc) is available in the upstream iptables package. So you're saying that's a huge negative, despite it being provided upstream by the iptables developers, and you don't understand it just because you don't need it. So you're acknowledging you're incompetent as a sysadmin and developer, and how much you're not qualified to talk about this topic. Just like most haters who have nothing constructive to say here. I've yet to see any sane rebuttal to this, only angry people (you have the right to be angry, even on sth you demonstrably don't understand), especially since systemd-networkd is optional with systemd, and this feature is optional too in systemd-networkd.
But all sane admins with systemd use it I believe, and threw away their old scripts, that were doing the job of setting up the network but worse.
Even worse, try requiring LDAP (not just making it an option when an account isn't found locally, actually requiring it) for logins on a system booting via SystemD. Have your recovery media handy, you'll have to boot from it in order to remove the LDAP requirement when SystemD can't su because the network isn't up yet (or, if the LDAP server is localhost, slapd hasn't started because, guess what, it needs to su to its configured user during its init process).
What is this nonsense ? I use LDAP since before adopting systemd in 2009, and I never had any of these problems on my own made Linux systems. /etc/passwd contained only root and messagebus accounts (now it also has the new systemd accounts).
Are you implying distributions are even worse than when I quit using them in 2000?
Are you implying that distribution maintainers are incompetent?
What I'm sure is that it's a distribution problem, not a systemd problem. I never had the problem you describe which doesn't even make sense, even before I used sssd, and my
And my systemd systems work just fine even when network is not up yet, localhost is always there and slapd as well as sssd listen on it.
Major issue affecting Ubuntu and, as far as I know, all Debian-based systems. The workaround should be simple: allow local account logins right up until TTYs actually become available, regardless of configuration. But, apparently, LDAP isn't considered important, so this has been an issue for as long as Debian has used SystemD and will likely remain so until Debian moves on to something else.
This is BS, I can't even believe Debian and Ubuntu maintainers are so bad, where's the bug report ?
The current "recommended" workaround is a pair of ifup/down scripts that requires LDAP when the interface is up and makes it optional when it interface is down, which is great until your system crashes or you lose power and the "optional" config doesn't get applied. Then, it's time to whip out the recovery media so you can manually change the config and have a bootable system again. Needless to say, I refuse to implement that hack of a fix.
So this must actually be a bug tied to sysv compatibility, as you're talking about these broken ifup/ifdown scripts.
Granted, I instantly moved to full systemd configuration, it's not so easy for a distribution. Most of their problems seem to come from the compatibility layer.
sysvinit scripts are so insane, I can't blame them for having problems with them. Surely it makes them maintainers push forward to quit using these sysvinit scripts as soon as possible, even faster than before.
As always, I see most Slashdot representative comments being completely wrong when it comes to Nintendo.
It seems like some people wait for every news on Nintendo to spew all the ire and BS that keep them enraged inside.
I'm still wondering where people are seeing anything about "competing". Yet, a lot of posts act like he talked about competing with these mobile devices.
Fils-Aime, who is NOT CEO of Nintendo (which should give a clue as to how misleading this news is) is talking about the content, the games, and people's perception of value on games. It has nothing to do with graphics or animations or whatever problem people have with Nintendo, it's about content and its value to the consumer. He's saying it's dangerous for the industry to make people believe that whatever the content in a game, it has a very low value (and so a very low price).
He doesn't even say it's threatening anyone right now, he says its a possible risk.
People on Slashdot, as with the DS or the Wii (or even the first iPod), are already talking like 3DS is dead on arrival and Nintendo is doomed (as always).
Yet, it's for opposite reasons. $2 games would kill most HD console games types faster than any Wii or DS ones.
I think what Reggie said is more a warning to 3rd parties. We see lots of 3rd parties porting their already (or not) profitable games to mobile platforms, for a very cheap price, and sometimes it's exactly the same content. The problem is that a consumer who paid $40-$70 for a game, that sees the same one for $5 on his mobile, will not really be happy about ever paying the high price again. And if lots of them come to the same realization, you will see mostly western 3rd parties die left and right (worse than what we see today). Because most western 3rd party games (and lots of eastern ones too) rely on selling a lot at launch, and then quickly die. If they don't sell a lot at launch, you see the games with quick slashed prices. 3rd parties can do that because the cost of the game is already taken care of by the other platforms, but there are very few people (the hardcore) that will want to pay so much more to have the privilege of playing the game day 1.
Nintendo doesn't have this problem as their games sell with veeery long tail. Basically, 3rd parties (the big one) are shooting themselves in the foot if they go on, and less 3rd parties alive to make games for Nintendo platforms means less revenue for Nintendo.
Apart from that, Reggie is not really complaining, not yet at least, as even the DS is right now more threatened by the 3DS than by any mobile device with games.
They're not in direct competition like computer games (like flash games and all that existed for a long time) are not competing directly with console games (except for devs resources). Or that would mean consoles are winning...
I agree partly with you.
It's true that consistent interface naming has just worked for years with multiple interfaces.
The author is talking about races but they are not explained in his paper and are marked as thinks since 2009.
What this basically boils down to is that now distributions can streamline the naming of your interfaces without you having to go test them the first time you install your OS to know which is which. You'll now know immediately from your OS.
This shouldn't upset anyone, except people that can't accept change. It will be a matter of accepting now to use lom0-X or em0-X instead of eth0-X.
People like me who are already using udev rules to change their network interface names won't be affected anyway, and you still can name your interfaces like you want as udev is still what renames these interfaces.
As has been mentioned above - you can tell from your comments you are just a home user.
Try writing OS-level software (stuff that is imaged onto the device) that depends on the NIC in position 1 on the PCI bus always being the management interface (IE, the first port in the chassis). Remember this software has to know IN ADVANCE which port it is, you can't use the MAC for this at all.
This has been a problem in Linux for years and one that developers have always had to hack and slash around. I am glad RedHat is finally fixing it. Hopefully other distributions will follow suit.
I don't understand what you're saying. If you wanted to do that, you could do it a since years with udev IN ADVANCE of your software you want to launch.
Since YEARS udev has put persistent device naming so that what is said in the article is wrong, because you will always get the same name for your devices.
Since years, I actually have my Ethernet interfaces which are not named eth0-X but sth else, which is based on any arbitrary value you want that is provided by udev, including PCI slot and what not.
So what exactly are you talking about?
The sole difference I see there is that the distro will now do it upstream instead of you having to put your udev rules.
Which seems to be a good thing since people like you who are not mere "home users" apparently don't know about these features and have missed these functionality for years. What's worse is that you're saying it's a problem with "Linux" whereas the sole problem comes from you being ignorant of the solution.
It's strange too that you talk about this being a problem with Linux and devs having to hack and slash, when the solution couldn't be done anywhere before because the specs weren't out (SMBIOS 2.6, now exposed through linux kernel since 2.6.36 some weeks ago, or ACPI or via biosdevname) and the solution proposed here is still the exact same kind of hacks you're talking about.
FWIW, the sole difference here is the naming convention, as the solution is still implemented via udev rules, with the exact same mechanisms as before, mechanisms used for YEARS with the same hacks.
The main difference compared to before, is that now the naming scheme can be streamlined by a distribution, while before it couldn't, because it would have no consistency.