GSOC Project Works To Emulate Systemd For OpenBSD

← Back to Stories (view on slashdot.org)

GSOC Project Works To Emulate Systemd For OpenBSD

Posted by timothy on Sunday September 7, 2014 @09:10PM from the everyone's-idea-of-a-good-time dept.

An anonymous reader writes Through a Google Summer of Code project this year was work to emulate systemd on OpenBSD. Upstream systemd remains uninterested in supporting non-Linux platforms so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls. The work achieved this summer was developing replacements for the systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities. The hope is to allow for systemd-dependent components like more recent versions of GNOME to now run on OpenBSD.

314 comments

Min score:

Reason:

Sort:

Oh well ... by Xolotl · 2014-09-07 21:15 · Score: 3, Funny

... there goes that refuge then ;)
1. Re:Oh well ... by Anonymous Coward · 2014-09-07 21:53 · Score: 5, Informative
  
  Not really.
  * This software is not going to end up in the base system but in ports. It will not have a big effect on the base system.
  * The goal of the project is not to import the systemd programs like the NTP daemon or the cron daemon. Instead, it implements some of the APIs so it will be easier to port software that depends on some systemd features.
  When the software is ready and ends up in OpenBSD ports, it will probably only be installed if you install a piece of software that depends on systemd (future gnome, for instance). So if you don't install these kinds of software, you don't even end up having "systembsd" on your computer.
  In what way is the refuge gone now?
2. Re:Oh well ... by Korgan · 2014-09-07 22:19 · Score: 1
  
  Heh, funny you should say that. I've been trialing FreeBSD 10-RELEASE lately, primarily because of the whole systemd fiasco.
  So far, most of my apps look like they'll cope without a hassle. A few others while probably just have to be run in VMs on Slackware or something.
3. Re:Oh well ... by Kvorg · 2014-09-07 23:00 · Score: 4, Insightful
  
  Exactly, it would seem this will simply emulate the behaviour for applications that expect it, sitting on a DBUS interface. Since it now seems the whole systemd mess will not go away, I would assume this is the "correct" approach to manage it.
  I can only wish non-RH GNU/Linux distrost adopted the same approach.
  
  --
  -Kvorg
4. Re:Oh well ... by Anonymous Coward · 2014-09-08 00:56 · Score: 1
  
  The ecosystem, linux and bsd, is now going to become an order of magnitude more confusing than it already is. When you have to pick and choose a distro by it's initilization process, and whether the software you intend to use requires a specific package with regard to that, in the long term it becomes a self-defeating proposition. In the world of dist's , it's the ones with the most community support that reach the top. This is the introduction of the worst type of fragmentation for dist's.
  As for systemd? Sorry, but it's benefits DO NOT outweigh the negatives with it's introduction. There is no argument that it is better across the board and NEEDS to happen.
  But as you said. BSD will still be 'whole' because it's the ports that will be effected. Right? And I guess I still have LFS. I mean, until everything stop using OpenRC, and sysv/init. And then I'm forced to used systemd or be years behind. I guess if the community wanted it, systemd WOULD'NT have the traction it does. After all, the users control it, right?
5. Re:Oh well ... by dpilot · 2014-09-08 01:09 · Score: 4, Insightful
  
  I see systemd as the product of a culture clash between old and old-school Linux users/developers and new Linux users/developers.
  Linux was really derived from Unix, and in a very important way RMS has always been correct in insisting it be called GNU/Linux. Because "GNU's Not Unix" only in the licensing aspect. Philosophically, GNU really IS Unix.
  A few years back, Linus and Linux started getting a lot of attention in the computing and even general press. Linux started becoming cool and interesting. It started attracting new users, a new wave of early adopters, and since early adopters also tend to be developers, Linux attracted a new wave of developers.
  But these developers has a key difference - they had no Unix background. They largely came from Windows, simply because that's the largest source of developers, by simple demographics. But they weren't "fleeing Windows", they were attracted to Linux. They also brought their background, attitudes and preferences with them, and that includes a heave dose of "The Windows Way" and little to nothing of "The Unix Way."
  The result is systemd - the Windows Way ported on top of the Linux kernel.
  Then there is the demographics issue. The classical Linux market share has been so small and Windows so big that it doesn't take many Windows users/developers to swamp out the old school Linux/Unix camp. We're bing "conquered by demographics." They don't see anything wrong with systemd because it fits their background and world view perfectly - in fact it's a better fit for them than SysV Init is. There's also a bit of the Windows "One Way" attitude at work, attempting to push systemd across the board.
  Fortunately there are a few never-newbie distributions still around, and it seems that the old-school Unix users are congregating there and will keep them alive. Or there are always the BSDs..
  
  --
  The living have better things to do than to continue hating the dead.
6. Re:Oh well ... by Anonymous Coward · 2014-09-08 01:50 · Score: 0
  
  Except no one wants MS Windows methods of doing stuff. They've been trying to invent UNIX since the DOS days. Their latest OS is utter hell, so why do a tiny amount of Windows centric NIH kids get to fuck up almost every distro?
  This is the biggest fuck up in Linux history, and it will force a mass migration to a BSD.
7. Re:Oh well ... by Anonymous Coward · 2014-09-08 01:55 · Score: 0
  
  I worry that you are right. As one of those who did flee from Windows to Linux, I have been considering the possible need to flee to FreeBSD some day in the future, since the Arch Linux systemd fiasco. For now, I'm running Slackware, and I do hope that Slackware will be a safe holdout until FreeBSD is able to run Steam (including the games).
8. Re:Oh well ... by dpilot · 2014-09-08 02:11 · Score: 1, Interesting
  
  But you see, Windows has the lion's share of the market, and many of them are happy there. We tend to look with our Linux/Unix blinders on can't imaging that anyone could be happy there, but there are.
  Once upon a time Miguel De Icaza spoke of trying to make Gnome "Windows Done Right". That's what I think people are trying to do with systemd - Windows Done Right - on the Linux kernel. Except that because they came from Windows and were happy with Windows, they may also think that systemd is Linux Done Right.
  Any mass migration to BSD is not "mass" when compared to the WIndows userbase. Depending on how many Windows users and developers have already moved to Linux, it may not even be that big a number compared to the current Linux userbase, any more.
  
  --
  The living have better things to do than to continue hating the dead.
9. Re:Oh well ... by dpilot · 2014-09-08 02:41 · Score: 2
  
  I didn't name it by name in my original post, but I believe Slackware will be one of those safe distributions. Nor do I ever see a need to go off of Linux.
  I simply predict that in the future there will be two platforms - GNU/Linux and SystemD/Linux. The latter will have the lion's share of the users, and will indeed achieve World Domination. The former will continue to have something under 1% of market share, just where we've always been.
  In this respect, BSD will not be any safer port in the storm than the old-school-Linux distributions. We all use pretty much the same userspace - we have to just hope that SystemD/Linux doesn't fiddle with that userspace so badly that we can't use it. As long as things are reasonable orthogonal - part of the Unix WAy - we're OK. But we know the new crowd has no respect for that, and indeed feels that it's part of what is holding Linux back.
  
  --
  The living have better things to do than to continue hating the dead.
10. Re:Oh well ... by Anonymous Coward · 2014-09-08 02:50 · Score: 0
  
  I see it a culture clash between programs who understand the importance of modularity and the others who did poorly in class or didn't bother to go.
11. Re:Oh well ... by Dcnjoe60 · 2014-09-08 03:13 · Score: 1
  
  Exactly, it would seem this will simply emulate the behaviour for applications that expect it, sitting on a DBUS interface. Since it now seems the whole systemd mess will not go away, I would assume this is the "correct" approach to manage it.
  I can only wish non-RH GNU/Linux distrost adopted the same approach.
  There is no need to emulate. Any distro can implement what portions of systemd to include or to exclude by simply clicking on the portions they want and off the portions they don't want. Systemd isn't an all or nothing choice. The distros can use as much or as little of it as they please.
12. Re:Oh well ... by Dcnjoe60 · 2014-09-08 03:22 · Score: 1
  
  Except no one wants MS Windows methods of doing stuff. They've been trying to invent UNIX since the DOS days. Their latest OS is utter hell, so why do a tiny amount of Windows centric NIH kids get to fuck up almost every distro?
  This is the biggest fuck up in Linux history, and it will force a mass migration to a BSD.
  That's fine, because systemd is not the "windows" way and anybody claiming it is is just blowing smoke. While I prefer upstart to systemd, the reality is systemd is a bunch of individual modules (you know the linux way of one program for one task) that work together. However, when compiling it, you just set switches for the pieces you want to use. You don't have to use all of the modules and those that you do use will coexist with upstart and other init scripts.
  There is a lot of fud about systemd, and like I said, it isn't my preference, but it isn't the end of the world that many people want you to believe.
13. Re:Oh well ... by dpilot · 2014-09-08 03:55 · Score: 3, Insightful
  
  > the reality is systemd is a bunch of individual modules
  I disagree. Technically you are correct, but the same modularity argument can be made for practically any piece of code bigger than "Hello World". However in practice systemd is shipped as a monolith. I just checked, and even on Genoo with its uber-flexible USE flags and compilation from source, you can't shut off individual features like logging, dhcp, ntp, etc. Most people just install the binaries.
  No, systemd is not the end of the world. But it would be the end of running my machines the way I wish to - at least without spending more time and effort keeping it fenced in as you suggest.
  
  --
  The living have better things to do than to continue hating the dead.
14. Re:Oh well ... by phantomfive · 2014-09-08 04:09 · Score: 1
  
  I would assume this is the "correct" approach to manage it.
  Encapsulate the ugliness and move on. Sometimes it's all you can do.
  
  --
  "First they came for the slanderers and i said nothing."
15. Re:Oh well ... by Anonymous Coward · 2014-09-08 04:30 · Score: 0
  
  "I see systemd as the product of a culture clash between old and old-school Linux users/developers and new Linux users/developers."
  More like a culture clash between *nix users and computer users. Unix users/developers use Unix because they like Unix. People who use *nix because "it didn't cost anything" or "we want to have a OS to make money and it has to be automagic like Windows" are not *nix users/developers; they are computer users.
16. Re:Oh well ... by weilawei · 2014-09-08 04:35 · Score: 3, Interesting
  
  Not much chance of successful management when his idea of ignoring log corruption is to IGNORE it. Yes, literally, ignore it. Feature, not bug. In Poettering's own words,
  
  Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence.
  This guy shouldn't be allowed anywhere NEAR system software!
17. Re:Oh well ... by weilawei · 2014-09-08 04:36 · Score: 1
  
  s/ignoring log corruption/fixing log corruption/
18. Re:Oh well ... by BadDreamer · 2014-09-08 04:51 · Score: 3, Insightful
  
  You have the "linux way" (it is actually the Unix philosophy) completely wrong. It is not "one program for one task". It is:
  "Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable."
  -- Eric S. Raymond
  "Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended."
  -- Eric S. Raymond
  "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
  -- Doug McIlroy
  What systemd does wrong is abandoning this and using API's internally - API's it does not even lock down. It's a morass.
  "Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design â" you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option."
  -- Doug McIlroy
  "Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes."
  -- Eric S. Raymond
  Yes, systemd IS the end of the world that many people want you to believe.
19. Re:Oh well ... by Anonymous Coward · 2014-09-08 05:06 · Score: 0
  
  I think you're spot on. It almost feels as if Poettering should've gone out and written his own OS, but he wasn't going to get paid by RedHat for that and nobody in their right mind would adopt. RH, however, has been happy to shove it down our throats as "Linux".
20. Re:Oh well ... by Anonymous Coward · 2014-09-08 05:19 · Score: 0
  
  The result is systemd - the Windows Way ported on top of the Linux kernel.
  That's the most absurd thing I've heard about systemd to date, congratulations.
  The UNIX way has always been doing one thing well. Years ago we thought that sysvinit was doing one thing well (starting processes on boot), but nowadays that doesn't hold. The goal that PID 1 has right now, and that systemd fulfills is managing the whole boot to shutdown life cycle. Sysvinit was doing much more than what it claimed to do, but did it poorly.
  The only thing that might look like windows is using a binary file to store logs, but that's the most optional thing of systemd. You can actually use systemd to enhance the classic syslog with messages from early boot.
21. Re:Oh well ... by dpilot · 2014-09-08 05:35 · Score: 1
  
  Wow, this is really fascinating!
  One set of systemd advocates suggests that the Unix Way is obsolete, holding Linux back, and is overdue to be discarded.
  Now another systemd advocate suggests that systemd is fulfilling the Unix Way better than SysV Init.
  I will say now, as I said months ago, that systemd would be much less controversial if it had been packaged differently. I'm not the only one making that statement, and yet for all of its claimed modularity at compile time, systemd is still one package.
  
  --
  The living have better things to do than to continue hating the dead.
22. Re: Oh well ... by Anonymous Coward · 2014-09-08 05:41 · Score: 0
  
  And how does syslog handle corrupted logs? Yes, not at all. Imagine that...
23. Re: Oh well ... by Anonymous Coward · 2014-09-08 05:53 · Score: 0
  
  And how does syslog handle corrupted logs? Yes, not at all. Imagine that...
  And how often have you seen a corrupted syslog log file?
24. Re:Oh well ... by Dcnjoe60 · 2014-09-08 06:56 · Score: 1
  
  > the reality is systemd is a bunch of individual modules
  I disagree. Technically you are correct, but the same modularity argument can be made for practically any piece of code bigger than "Hello World". However in practice systemd is shipped as a monolith. I just checked, and even on Genoo with its uber-flexible USE flags and compilation from source, you can't shut off individual features like logging, dhcp, ntp, etc. Most people just install the binaries.
  No, systemd is not the end of the world. But it would be the end of running my machines the way I wish to - at least without spending more time and effort keeping it fenced in as you suggest.
  Systemd has a configure system similar to the kernel. Like the kernel, where some distros use a "full" kernel and others use a stripped down version, it is up to the distro to decide what fits its need. The same is true with systemd. Take distros running late versions of gnome-shell, which requires the logind module of systemd, all they are including is logind, not all of systemd. Even Ubuntu is using logind with upstart and also sys init scripts.
  Nobody is forcing a distro to adopt systemd. If the distro developers do and it impacts you, the complaint should be with the distro developers, not systemd. Maybe the developers have good reason for making the change. Most of them are community based, so it is doubtful that they are doing it just because Redhat is doing it (although Centos and Scientific would most likely change to maintain compatibility).
  Even if your distro of choice does change, it shouldn't force you to stop running your machines the way you want too. You can freely mix systemd, upstart and init scripts, using whatever pieces you want for whatever need you have. That applies whether your system is a desktop, server, embedded or whatever.
25. Re:Oh well ... by Anonymous Coward · 2014-09-08 07:45 · Score: 0
  
  Not quite. other than an early flirtation with a Z80 system with a whopping 8kB of RAM, I entered I.T. via WFW 3.11/MS-DOS and went to the Windows 95 launch event, and so on and so forth. I'd heard fo UNIX but never used it. Then I heard of Linux and learned the UNIX way.
  
  Systemd is wrong for three main reasons:
  
  1. It violates the UNIX way, which is based on sound engineering principles, (something sorely lacking in programming education for a while now).
  2. It is Red Hat's version of the "embrace, extend, extinguish" play.
  3. Leannart Poettering is the software equivalent of islamic fundamentalists. Systemd is his "final solution".
26. Re:Oh well ... by gweihir · 2014-09-08 11:07 · Score: 3, Interesting
  
  Actually, systemd is all-or-nothing. If you let even a tiny bit in, countless things will break unless you take the whole POS. The developers are very keen on making sure of that.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
27. Re:Oh well ... by gweihir · 2014-09-08 11:09 · Score: 2
  
  The fascinating thing is that despite numerous public demonstrations of incompetence and arrogance by the systemd team, their trash is still hailed as the second coming by many people. Has stupidity really become that mainstream in IT?
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
28. Re:Oh well ... by gweihir · 2014-09-08 11:12 · Score: 2
  
  Well said. I personally hope that at least Gentoo will remain immune. That Debian caved is utterly pathetic and I will definitely migrate away from them as soon as they try to force systemd on me.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
29. Re:Oh well ... by gweihir · 2014-09-08 11:14 · Score: 1
  
  Are you stupid? Modules compiled together are not a "modular" system in the UNIX philosophy at all. They are one program.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
30. Re:Oh well ... by gweihir · 2014-09-08 11:20 · Score: 2
  
  I have absolutely no problem with being in the 1%. There are hardly more than 1% competent IT users anyways, so I will feel right at home there. And the plus side, I recently did some development work on Linux that then also worked fine on Solaris (2 or 3 minor changes dues to different error handling) and Cygwin. So my guess is being in the 1% wil not result in any kind of lock-in, just a far saner environment to work in.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
31. Re:Oh well ... by gweihir · 2014-09-08 11:21 · Score: 1
  
  Well said.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
32. Re:Oh well ... by gweihir · 2014-09-08 11:29 · Score: 2
  
  Well said.
  1. Ignoring sound engineering practices has a tendency to be hugely expensive later on. I hope that Linux has enough competent folks, that they will eventually decide to leave the cretinistic systemd crowd behind. The Kernel seems to be unaffected so far. And while Gentoo has had to come up with eudev, it seems to be relatively easy to do without systemd. Of course Gnome has just one place these days: In the trash.
  2. Clearly, yes. And maybe also addressing a "not enough vulnerabilities" complaint by the NSA.
  3. I think he believes he is Linus reincarnated. As that does not really work, he tries to encapsulate the kernel instead.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
33. Re:Oh well ... by Dcnjoe60 · 2014-09-08 11:48 · Score: 1
  
  Actually, systemd is all-or-nothing. If you let even a tiny bit in, countless things will break unless you take the whole POS. The developers are very keen on making sure of that.
  That is simply false.
34. Re:Oh well ... by Dcnjoe60 · 2014-09-08 11:53 · Score: 2
  
  Are you stupid? Modules compiled together are not a "modular" system in the UNIX philosophy at all. They are one program.
  Except the separate systemd modules are all seperately functioning executables. That's why if you want to run gnome-shell, you can simply include the logind daemon from systemd along with whatever init system you want to use. Even if you choose to compile all of systemd, it only uses the daemons you turn on. How is that not modular?
35. Re:Oh well ... by knorthern+knight · 2014-09-08 12:31 · Score: 1
  
  >I simply predict that in the future there will be two platforms -
  > GNU/Linux and SystemD/Linux.
  Actually, they should be called GNU/Linu-x and GNOME/Lenna-x
  
  --
  
  I'm not repeating myself
  I'm an X window user; I'm an ex-Windows user
36. Re: Oh well ... by shutdown+-p+now · 2014-09-08 15:05 · Score: 1
  
  The nice thing about text logs is that, even if they are corrupted at some point, the rest of the log is still perfectly readable.
37. Re:Oh well ... by Endymion · 2014-09-08 20:22 · Score: 3, Informative
  
  The thing the inexperienced systemd developers (but I repeat myself) do not understand is that "modular" isn't about some technical detail such as how you compile various features. For example, busybox intentionally compiles everything into one big binary. The features it provides, on the other hand, are still very modular in the UNIX sense. The key difference is that the tools busybox provides ("cat", "wc", "mkdir", "dd", and many others) all implement well defined APIs.
  What is an Application Programming Interface (API)? It's not some function you can call, or the fact that a program understands some option ("--foo"). It is not even the documentation that may or may not be provided that describes how to use some feature. So what is it?
  An API is a PROMISE .
  It is a social feature, not a technical one. The functions, options, and documentation are just the technical implementation of that promise. The key part of an API is that it is a promise by the developer that if you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, the promised API will be stable and reliable.
  The problem with systemd is exactly this. Pulling a n00b move and agglutinating various features into one project is annoying and not recommended, but it is not, on its ownn, a reason to avoid systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs. His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable", specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.
  A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.
  The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.
  If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.
  So go ahead an prove that you don't know what you're talking about and assert that systemd is in any way "modular", when non-modularity was an explicit goal behind systemd. The rest of us are choosing to not go along with Poettering's attempt to embrace and extend Linux into a cheap, buggy, feature-free windows clone.
  
  --
  Ce n'est pas une signature automatique.
38. Re:Oh well ... by Anonymous Coward · 2014-09-09 01:50 · Score: 0
  
  It's this ever-changing nature of systemd that makes me realize that distros like Debian have really bitten off a lot to chew because they whored for systemd. Once the Jessie freeze comes, they're going to find that they are maintaining a separate fork of systemd--and that figuring out how to apply critical patches to it will be a nightmare.
39. Re:Oh well ... by Anonymous Coward · 2014-09-09 05:55 · Score: 0
  
  Can Logind run without pid1? Can journald? Can udev?
  That is the kind of modularity people are wondering about, not if they can do --disable-x and be "just pid1".
  That is, can i drop Logind on top of a existing install like i could Consolekit and not have to replace whatever already functioning init i have?
40. Re:Oh well ... by Endymion · 2014-09-09 23:24 · Score: 1
  
  This would be hilarious if it didn't imply such a terrible future for Debian. In the infamous debian-ctte arguments, one of the big reasons the systemd advocates insisted it was so important to only use systemd was their claim that maintaining multiple options would be far too much work.
  I think it was only Ian Jackson that truly recognized that this wasn't a complaint about workload - it was a threat that systemd would become a moving target should Debian fail to conform.
  
  --
  Ce n'est pas une signature automatique.
41. Re:Oh well ... by gweihir · 2014-09-10 03:33 · Score: 1
  
  There is absolutely nothing simple here. Also, you are either lying directly or completely ignoring the given circumstances (i.e. lying by omission). No surprise, this behavior is typical for SystemD advocates. Unfortunately for you, some people are not that easy to fool.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
42. Re:Oh well ... by Dcnjoe60 · 2014-09-10 07:33 · Score: 1
  
  There is absolutely nothing simple here. Also, you are either lying directly or completely ignoring the given circumstances (i.e. lying by omission). No surprise, this behavior is typical for SystemD advocates. Unfortunately for you, some people are not that easy to fool.
  If you re-read my posts, you will see that I am not a systemd advocate. I prefer upstart. As such, I am not a fan-boy of systemd and I am not fooled by it. That said, I think that if a different personality had developed it and it was being pushed by somebody other than RH, there wouldn't be so much animosity towards it.
43. Re:Oh well ... by gweihir · 2014-09-10 16:21 · Score: 1
  
  90% of the animosity I have seen originates on the architectural level, mine has too. Originally, I read about it, decided it was not anything worthwhile to have and an enormous KISS violation. That was it. Many others have had the same experience. That has absolutely nothing to do with RH or the developers of it. It just fails elementary architectural principles.
  That people who then complain find out that the systemd crowd is mostly condescending assholes without a clue is a secondary effect. And that this monstrosity is getting pushed into nearly everything.
  Incidentally, there is one fascinating things about almost all open or camouflaged systemd-advocates: They ignore being insulted. Right out of the psyops manual: Keep the dialog going, you may still have a chance to manipulate the opponent. That is why I am now pretty sure you are a systemd advocate. The not so subtle insinuation that systemd-critics are technologically incompetent and just do not like the developers is also pretty telling.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
44. Re:Oh well ... by Dcnjoe60 · 2014-09-11 00:44 · Score: 1
  
  I think the architectural problems and the developers are interrelated. systemd started as an init system, like upstart. However, where upstart remained an init system, systemd has been really expanded into having its fingers in all sorts of system areas. That said, when I have to use systemd, and I have the option, I usually just re-compile it with the specific functionality required. Not all of it is bad, it just suffers from feature creep, or maybe feature over-reach.
  I really am not a closet systemd advocate. I do contract work and very often systems are pre-defined that have systemd components in them. For instance, I will be doing a conversion for a firm to RH7. I don't have the option of telling the customer to not use systemd, instead, I have to convert their existing init scripts to work with it.
  Is systemd my first choice, no, not at all. If anything, I am init agnostic. Ultimately, I will install/work with what my customer specs.
45. Re:Oh well ... by fenwar · 2014-09-13 23:13 · Score: 1
  
  An API is a PROMISE .
  It is a social feature, not a technical one.
  Thanks for this post, you've expressed very succinctly the reason for the general unease with systemd which I've felt all along, but had been unable to pin down to a specific argument.
New Gnome? no thanks. by DMJC · 2014-09-07 21:15 · Score: 0, Flamebait

Frankly I don't see much in the new Gnome that makes it worth bringing to any platform. I just wish the same effort being put into making broken UI concepts work on various gnu projects was put into GNUstep and GNU projects.
1. Re:New Gnome? no thanks. by drinkypoo · 2014-09-08 03:35 · Score: 1
  
  Frankly I don't see much in the new Gnome that makes it worth bringing to any platform.
  it's a bummer to me because I love gnome 2, but I also want to have current support from the mainline. I may just jump ship to KDE land, and spend my time trying to stuff the widgets back into their packaging.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
2. Re:New Gnome? no thanks. by shutdown+-p+now · 2014-09-08 15:10 · Score: 2
  
  MATE? Xfce? LXQt?
3. Re:New Gnome? no thanks. by drinkypoo · 2014-09-08 21:59 · Score: 1
  
  MATE has been disappointing, I've found it buggy. Xfce has a very poor file manager. LXDE, likewise. Haven't tried LXQt yet, so I guess I will try that next. Thanks.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Er? by lisaparratt · 2014-09-07 21:16 · Score: 1, Flamebait

I would have expected that BSD would be deliriously happy that the evil gaze of Poettering hadn't alighted upon their operating system. Why would you voluntarily infest your system with his daemon spawn?
1. Re:Er? by Noryungi · 2014-09-07 21:28 · Score: 4, Insightful
  
  I would have expected that BSD would be deliriously happy that the evil gaze of Poettering hadn't alighted upon their operating system. Why would you voluntarily infest your system with his daemon spawn?
  Because bloody systemd will be needed if you want to run some brain-dead Linux-only piece of crap software. That's why.
  Emulating systemd allows that software to work on OpenBSD. On the other hand, emulating it means that (a) its working may remain somewhat on the sane side and (b) that emulation will only be installed if the port requires it, therefore limiting the damage.
  And, FYI, OpenBSD could not care less about Poettering and his evil gaze.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
2. Re:Er? by ThePhilips · 2014-09-07 22:13 · Score: 5, Informative
  
  The three services are actually needed.
  The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
  The systemd-timedated does almost the same for the date and time.
  And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
  The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
  In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.
  
  --
  All hope abandon ye who enter here.
3. Re:Er? by rmstar · 2014-09-07 22:50 · Score: 2
  
  The three services are actually needed. [...] centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
  Ah no, you are bringing facts into this discussion? How dare you! :-)
  Thank you, actually.
4. Re:Er? by koinu · 2014-09-07 23:13 · Score: 5, Insightful
  
  The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
  Locale settings are fine without system-level settings. What is wrong with application-specific LC_xxx settings? And why should I be interested in changing locale in the middle of a desktop session?
  
  The systemd-timedated does almost the same for the date and time.
  What?! Who the hell changes time on computers? This is not a $5 digital watch! Every reasonable system has got ntpd installed and is set to UTC. The rest is done by selecting the time zone you are in. And stay away from changing time zones by adjusting time! We are not in Windows world where time handling has been fucked up entirely.
  
  And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
  Why do I need a daemon to log out from a session?
5. Re:Er? by LordLimecat · 2014-09-07 23:27 · Score: 0
  
  Im not totally up on the systemd debate, but most of the objections I've seen are philosophical, and not actually addressing whether it is necessary. For example, this discussion; the 2nd poster acknowledges that the current init doesnt meet his current needs, and everyone seems to agree that systemd is faster, but the objection seems to be that its different and therefore bad.
  Its much like arguments I've seen against binary log files, which is absurd because at the end of the day all log files are binary, you're just arguing about the encoding. As long as you have widely supported, stable, widely available tools for reading them-- who cares? If systemd does everything init did and more, faster, and becomes the new stable default, who cares if its not "classic linux"?
6. Re:Er? by Zocalo · 2014-09-08 00:27 · Score: 4, Insightful
  
  I have three main issues with SystemD that might help you understand where some of us are coming from:
  
  1. It effectively works as a monolithic replacement for several daemons, contra to core UNIX design tenets, and even though some of those sub-daemons can be swapped out with an alternative, often that works by running the second daemon in parallel - you can't actually disable the SystemD equivalent, let alone remove it altogether. This makes troubleshooting much more complicated when something goes wrong, especially if you have booted a system from a recovery disk to troubleshoot after a crash, compromise, or whatever and can no longer directly access several of the key sources of information necessary to do that.
  
  2. Because of the growing number of packages that depend on SystemD, and vice-versa, it's creating a huge mess of package inter-dependencies that mean that it's getting almost impossible to build a stripped down and hardened server. Ballmer might have been right with his "Cancer" comment, he just wasn't specific enough: Gnome requires SystemD, $distro wants to bundle Gnome, therefore $distro adopts SystemD - and forces the default install of all the other package dependencies that go with it, thereby increasing the attack surface of the system. So much for hardening systems by removing all superflous code, huh?
  
  3. All that cruft seems to be bogging the system down. We are currently migrating a large number (much larger than planned after initial results) of systems from RHEL to BSD - a decision taken due to general unhappiness with RHEL6, but SystemD pushed us towards BSD rather than another Linux distro - and in some cases are seeing throughput gains of greater than 10% on what should be equivalent Linux and BSD server builds. The re-learning curve wasn't as steep as we expected, general system stability seems to be better too, and BSD's security reputation goes without saying.
  
  That said assuming that it "just works" a SystemD based desktop with everything from a desktop application down to the kernel talking through the same set of core services does sound like a nice idea. The problem is that most of us are not actually running Linux desktops; we're running servers and would just like the OS to mostly get the hell out of the way so we can get on with running whatever server daemons we are using. If SystemD were better architected - say a core PID1 init replacement, then a bunch of optional packages I don't even need to install if I want to use an alternative or not bother with at all, plus a massive clean up of the dependency hell that it has introduced - then I'd be a lot happier with it, but as it stands I just can't see including it on a hardened Internet facing server as being a remotely sane thing to do.
  
  --
  UNIX? They're not even circumcised! Savages!
7. Re: Er? by Anonymous Coward · 2014-09-08 00:38 · Score: 1
  
  Can't people who want to do totally stupid things on OpenBSD just run wine and then Internet Explorer 6 on top of Wine? Or is the active-x plugin support on wine broken?
8. Re:Er? by Anonymous Coward · 2014-09-08 00:41 · Score: 5, Informative
  
  The three services are actually needed.
  For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
  
  The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
  Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones. The system itself always ran on UTC. UTC is not supposed to change. Users changing their locale need to log out and back in again. That works well enough for the expected frequency of such changes occurring and doesn't need lots of code to notify every running process AND lots of code in every running process to deal with the change.
  As an engineering tradeoff, the Unix way makes sense to me. The poetterix way, not so much. So I don't really buy your "long overdue", no.
9. Re:Er? by ThePhilips · 2014-09-08 01:03 · Score: 1
  
  The three services are actually needed.
  For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
  For applications. To handle properly when user changes the system settings.
  These daemons are primitive at best. There were more comments written about them then there is source code lines in them.
  Note, I'm in no favor of systemd itself. Debian in the past exemplified that you can actually use GNOME on a system without systemd, with only slightly patched up systemd-*d daemons. Which makes a lot of sense to me. But their maintainer is Poeterring, and he merged that all into the systemd, and there is no replacement for the daemons, so...
  
  The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
  Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones.
  Nobody dismisses the multi-user-ness of the *NIX. In fact, the services should improve that by allowing a user to easily change his own locale/time zone without the need for log-out/log-in cycle.
  The blank the services are filling is allowing application to perform application-specific tasks *when* user changes the locale or time zone. Editing a text config, and then restarting everything is, sorry, but horribly outdated. (We can update kernel on the fly - but not locale!? WTF?)
  
  --
  All hope abandon ye who enter here.
10. Re:Er? by koinu · 2014-09-08 01:05 · Score: 1
  
  And if time is sufficiently off from the ntpd server(s), it will refuse to correct and will continue to drift.
  Only if you have it configured in this way. The default configuration writes ntp.drift and logs the drifting behavior to correct the clock adequately without time skipping (or worse: moving backwards), which should never happen on a server.
  You can use ntpdate of course, but don't use it regularly.
11. Re:Er? by Anonymous Coward · 2014-09-08 01:22 · Score: 0
  
  And you are an idiot if you don't think there is a difference b/w binary logs and plain text logs.
12. Re:Er? by tepples · 2014-09-08 01:47 · Score: 1
  
  And why should I be interested in changing locale in the middle of a desktop session?
  That depends on what you mean by "desktop". I was thinking close your laptop's lid to put it on suspend, get off the airplane, step into a new locale, open the lid change your laptop's locale to match.
13. Re:Er? by Eunuchswear · 2014-09-08 02:16 · Score: 1
  
  I was thinking close your laptop's lid to put it on suspend, get off the airplane, step into a new locale, open the lid change your laptop's locale to match.
  I think you don't know what "locale" means. (In an internationalisation/localisation context).
  You seem to be confusing it with "timezone".
  
  --
  Watch this Heartland Institute video
14. Re:Er? by Eunuchswear · 2014-09-08 02:21 · Score: 1
  
  All that cruft seems to be bogging the system down. We are currently migrating a large number (much larger than planned after initial results) of systems from RHEL to BSD - a decision taken due to general unhappiness with RHEL6, but SystemD pushed us towards BSD rather than another Linux distro - and in some cases are seeing throughput gains of greater than 10% on what should be equivalent Linux and BSD server builds.
  
  As far as I know RHEL6 uses upstart, not systemd. Am I wrong?
  So what "cruft" is slowing your systems down?
  And how are you measuring "throughput"?
  
  --
  Watch this Heartland Institute video
15. Re:Er? by Anonymous Coward · 2014-09-08 02:43 · Score: 0
  
  Which BSD did you choose? (A former colleague swore by FreeBSD, but recent changes by the core developers were starting to push him towards OpenBSD.)
16. Re:Er? by chihowa · 2014-09-08 02:47 · Score: 1
  
  "Locale" refers to language, keyboard layout, period/comma decimal notion, and such. Flying from the US to Paris and having your desktop session change to French menus and AZERTY keyboard layout is not something you'd likely ever want.
  
  --
  If you want a vision of the future, imagine a youtube comments section scrolling - forever.
17. Re:Er? by Anonymous Coward · 2014-09-08 02:54 · Score: 0
  
  Psshht Don't bother him with facts! How is he suppost to inaptly rant and whine if you bother him with facts?!
  Seriously; nice one. If one is claming to "migrate large number of systems from RHEL to BSD", one should at least do the homework and use a valid fake reason.
18. Re:Er? by antientropic · 2014-09-08 02:55 · Score: 0, Flamebait
  
  Your post captures what most anti-systemd posts have in common: it spouts reasonably-sounding slogans ("Unix philosophy!", "dependency hell bad!") - which have nothing to do with how systemd actually works.
  Take the supposed dependency hell. In reality, systemd has a fairly small number of dependencies, almost all of which are already ubiquitous on a modern Linux system (e.g. libacl), and many of which are optional (e.g. PAM). Gnome depending on systemd is hardly systemd's fault - if systemd provides useful functionality that Gnome wants to use, then why does that count against systemd? In any case, it's irrelevant for your "stripped down and hardened server", because surely you're not running Gnome there.
  Or take the Unix philosophy. I'd say systemd (as in the PID 1 program) exemplifies the Unix philosophy: it does one thing, namely managing system services, and it does it really well. Now, systemd the *package* contains lots of other stuff, but most of it is optional. For instance, it does contain an NTP client now, but you don't have to use it. In fact, there even is a configure flag to disable it at build time. Also, the existence of systemd-timesyncd in no way prevents you from running whatever NTP client you want under systemd.
  The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone. It cannot even tell me if a service is currently running.) Systemd can. It cannot imagine going back to a situation where I can't do "systemctl" or "systemd-cgls" to get an overview of what is running on a system, or do "systemctl status " to see the status of a service, including its most recent log messages.
19. Re:Er? by LordLimecat · 2014-09-08 03:11 · Score: 2, Interesting
  
  The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
  Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
  Again: I dont really have a horse in this race, but if systemd truly can guarantee that a service stops when it says it does, thats where Im placing my bets. Its absurd that the service system in Linux fails so badly in that regard.
20. Re:Er? by Anonymous Coward · 2014-09-08 03:18 · Score: 0
  
  The usefulness of this is immediately apparent to me as a Windows developer having to deal with localization issues. When developing a piece of software on Windows targeting international customers, the capability to switch the locale on the fly is handy. But, someone else pointed out there are application-specific locale settings. I suppose the unix-only crowd's point is that this should be such an infrequent system-wide change that the onus of having to logout is an irrelevant excuse. And, NTP takes care of sync'ing date/time so there isn't a need to be concerned with the user fooling around with that anyways. Unless you had a system not connected to the internet.
21. Re:Er? by Anonymous Coward · 2014-09-08 03:18 · Score: 0
  
  Aren't the three daemons in the port only needed by GUI applications? If so, why on Earth are you installing a GUI on a *NIX server to begin with? I can see putting it on head nodes and clients, but certainly nothing that's just serving data or doing computation.
22. Re:Er? by Dcnjoe60 · 2014-09-08 03:30 · Score: 1
  
  I would have expected that BSD would be deliriously happy that the evil gaze of Poettering hadn't alighted upon their operating system. Why would you voluntarily infest your system with his daemon spawn?
  Because bloody systemd will be needed if you want to run some brain-dead Linux-only piece of crap software. That's why.
  Emulating systemd allows that software to work on OpenBSD. On the other hand, emulating it means that (a) its working may remain somewhat on the sane side and (b) that emulation will only be installed if the port requires it, therefore limiting the damage.
  And, FYI, OpenBSD could not care less about Poettering and his evil gaze.
  Chances are that is false. What is much more likely is that one of the systemd modules, say logind might be required, but not all of systemd. Isn't that how software development is supposed to be -- use an existing library that provides the required functionality instead of everybody building their own version?
23. Re:Er? by Dcnjoe60 · 2014-09-08 03:37 · Score: 1
  
  The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
  Locale settings are fine without system-level settings. What is wrong with application-specific LC_xxx settings? And why should I be interested in changing locale in the middle of a desktop session?
  
  The systemd-timedated does almost the same for the date and time.
  What?! Who the hell changes time on computers? This is not a $5 digital watch! Every reasonable system has got ntpd installed and is set to UTC. The rest is done by selecting the time zone you are in. And stay away from changing time zones by adjusting time! We are not in Windows world where time handling has been fucked up entirely.
  
  And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
  Why do I need a daemon to log out from a session?
  Think outside the box. Maybe your linux system is embeded in the flight systems of an airliner or vehicle that really does need the capability of changing timezones. Maybe your linux system needs to communicate with other devices that don't deal with system clocks the same way or don't use UTC. And, as for logging out or shutdown, maybe you don't need it, but surely, it is foreseeable that some applications might benefit from it instead of having to each role their own solution.
  Look at it this way, some use cases don't need cron, either, but it doesn't mean it isn't useful for those use cases that really do need it.
24. Re: Er? by zakkudo · 2014-09-08 03:39 · Score: 1
  
  Isn't it painful changing the language of your whole OS to test localization in on program? LANG=Japanese appname in the terminal makes so much more sense. On top of that when you switch windows to non-english mode it tends to bug out in the ways you expect from amature software. (Text flickering between languages on shutdown? Really?) Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.
25. Re:Er? by Dcnjoe60 · 2014-09-08 03:40 · Score: 1
  
  The three services are actually needed.
  For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
  
  The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
  Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones. The system itself always ran on UTC. UTC is not supposed to change. Users changing their locale need to log out and back in again. That works well enough for the expected frequency of such changes occurring and doesn't need lots of code to notify every running process AND lots of code in every running process to deal with the change.
  As an engineering tradeoff, the Unix way makes sense to me. The poetterix way, not so much. So I don't really buy your "long overdue", no.
  Maybe those three services are included because they were replicating the functionality that both upstart and other init methods already provided. Dealing with time zones, system clocks and login/shutdown wasn't something that only became available with systemd. If these three daemons are problematic, then it goes back much further than systemd.
26. Re:Er? by Dcnjoe60 · 2014-09-08 03:49 · Score: 0, Troll
  
  It seems most of your problems are just repeated myths about systemd. For instance http://0pointer.de/blog/projec... debunks all of them and there are numerous other sites that do likewise. While I am not a big fan of systemd, I do understand what they are trying to do and it isn't the end of the world like people want to make it out to be.
27. Re:Er? by phantomfive · 2014-09-08 04:13 · Score: 1
  
  to correct the clock adequately without time skipping (or worse: moving backwards), which should never happen on a server.
  Hopefully your server software all uses monotonically increasing clocks, instead of relying on human-formatted info
  
  --
  "First they came for the slanderers and i said nothing."
28. Re: Er? by ThePhilips · 2014-09-08 04:14 · Score: 1
  
  LANG=Japanese appname in the terminal makes so much more sense.
  The problem with that, is that very few applications are now isolated these days. You typically have a DB back-end, data export/import and RPC to other system services. Setting a different locale is error prone since some data might be simply misinterpreted and end up corrupted. And that is real problem, since lots of user data are actually stored in textual form (even in DB!).
  IME, the per-application locale has its uses, but in real world it causes more problems than it solves. In fact, since most Linux distros support quick account switching, the cheapest solution right now is to use two accounts with different locales.
  
  Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.
  There is no sane way to solve that problem on the level of OS. (Even "primary language; secondary language" is not enough, since for example I have to deal daily with three languages (Russian, English, German).) Most of the time this ends up being in the responsibility of the application developers: if they care enough, they offer a possibility to use a language different from the system one.
  Think of the flip-side: you might accidentally force all Japanese and all English iPhones to download both English and Japanese locale data. And this is pretty large amount of the data to just sit around idly, just in case when user might once decide to hear the street names in different language.
  
  --
  All hope abandon ye who enter here.
29. Re: Er? by Blaskowicz · 2014-09-08 05:09 · Score: 1
  
  I had the same problem with Steam : Counter Strike's radio voices were in French, and I happen to find them horrendous, not suited to the game , wrong tone etc. (and in fact they were a pack made by an amateur before then!, when HL/CS were non-Steam). To get the english voices you needed to set the entire Steam in English, which would download all English content for the other games (at least when you launch them), so Half-Life was now in English instead of French and significant amount of audio data was downloaded.
  Many years later (after a long period of not using Steam) I found out they got that fixed and now you can have a language setting per game.
30. Re: Er? by zakkudo · 2014-09-08 05:16 · Score: 1
  
  When you're driving and need navigation information, more data is always better than less. I have my android set for japanese and I installed the english text to speech sofware separately to see it it would help google maps. Does nothing. The space argument concidering how much google maps streams (and even siri) does not impress me at all.
31. Re:Er? by Blaskowicz · 2014-09-08 05:25 · Score: 1
  
  Maybe not really locale-related, but there's a really shitty issues with games on linux (moreso native ones that those on Wine, maybe). Most tend to assume you have a qwerty keyboard, e.g. they rely on WASD to move but I need ZQSD. Such stuff can be remedied with the chore of shifting some key input definitions in the game options, but sometimes I'm stuck, e.g. unable to switch to the melee weapon in Open Arena, or to open the console (but shift + that upper left key above TAB might be able to open the console if you know about it).
  In the DOS/Windows world you always had qwerty games, but they would read the keyboard "raw" so no problem, keyboard behaves as if you really had a qwerty one. In Linux to play qwerty games I need to create a script that does setxkbmap us, launches the game, setkxbmap fr, and then create a desktop shortcut (which I think sucks) or a bash alias (nice, but you don't get to see a graphical list of games and their icons)
  So.. I think I'd need a daemon that changes keyboard layout on the fly when I'm inputting to a qwerty game.
32. Re:Er? by Zocalo · 2014-09-08 05:32 · Score: 2
  
  Where, exactly, do I state that I am putting a GUI on a server? Perhaps you got confused when I mentioned Gnome requiring SystemD as an example of how applications making SystemD a dependency was forcing distros into a Hobson's Choice of either adopting SystemD whether they want to or not, or going through a lot of pain to replace it with an alternative when it breaks major dependencies like Gnome? RHEL, like many distros, includes Gnome - but how many of those distros have adopted SystemD mostly as a result of this, not because it is better or worse than the alternatives?
  
  Note also that I point out that the dependencies work in *both* directions; as antientropic points out Gnome requiring SystemD is absolutely an issue with the Gnome team and nothing to do with SystemD, but it does have implications in that it helps build a mess of inter-dependencies that is making it increasingly hard to strip systems down to the minimum. RHEL's insistance on NetworkManager by default, with all the baggage that brings, doesn't inspire confidence either, as this is apparently one of the next daemon in SystemD's sights - maybe SystemD can improve it, but I'm not holding my breath.
  
  Anyway, regardless of that, we've made our choice and moved to BSD; SystemD played a significant part in that, but it definitely wasn't the only factor, as I noted in my OP. ?
  
  --
  UNIX? They're not even circumcised! Savages!
33. Re:Er? by Anonymous Coward · 2014-09-08 06:38 · Score: 0
  
  The unix-only crowd's point is fuck the user. The average Linux/BSD developer would shit themselves if they ever used a system like OS X where "things just work."
34. Re:Er? by SepticPig · 2014-09-08 07:49 · Score: 1
  
  Think outside the box. Maybe your linux system is embeded in the flight systems of an airliner or vehicle that really does need the capability of changing timezones..
  You are having a giggle ?
  The flight system is the very place that should never change timezone, sure the passenger area wall clock but please not ever the flight system, that's just layering complexity and danger into a critical system.
  If the Linux desktop needs a pretty clock then let the desktop handle that, let the core subsystems be synchronised with core subsystems around the world.
  UTC and ntp work just fine for that.
35. Re:Er? by Anonymous Coward · 2014-09-08 07:52 · Score: 2, Insightful
  
  So you point to the "debunk" written by Lennart? He's hardly a fucking unbiased source. Do you use Fox News for your refernces in other sphere's of life?
36. Re:Er? by Anonymous Coward · 2014-09-08 07:55 · Score: 0
  
  Well I don't know about him, but GUI's often have pretty fucking awesome graphical visualisation tools that allow me to pin-point trouble spots a damn sight more easily than trying to eyeball-parse millions of lines of log files.
  
  Here's an idea sweetie, once you get out of Mummy's basement, you try analysing 100+TB's of network traffic data (like those of us in the big leagues have to deal with) by eyeballing log files.
37. Re:Er? by Anonymous Coward · 2014-09-08 08:02 · Score: 0
  
  We use our GUI for visualising relationships between hundreds of VM instances. Kinda hard to do at the CLI. Sometimes we do this at the server console because our workstation is on the other fucking side of the campus (or city/country).
  
  Gotta love the skiddies who post on /. like they know big iron workloads.
38. Re:Er? by Anonymous Coward · 2014-09-08 08:24 · Score: 0
  
  Huh, in your systemd-world the aeroplane avionics software changes system time based on the timezone the plane is currently at? Why on earth would anyone design such system? If the system eg. shows the estimated time of fuel expiration, it would be at current timezone even when flying over across an ocean?
39. Re:Er? by Anonymous Coward · 2014-09-08 08:39 · Score: 0
  
  The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
  Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
  So you're "fixing" a bad application by changing the OS?
40. Re:Er? by sjames · 2014-09-08 09:33 · Score: 1
  
  But note he indicates that he solved those needs with just a bit of customization. He then explained his objections to systemd. The rebuttal below reveals itself for what it is by claiming a laundry list of things the Swiss Army knife approach allows. All of those features already exist in systems using the old init.
  Note the many many existing and well understood tools for processing and manipulating text. Wouldn't it make sense to have the 'language' they speak (text) be the standard? Every suggestion for processing those logs seems to start with use X to convert them to text...So how about just make them text?
  The binary log files make as much sense as writing all English language web pages in Russian so the browser can translate them back to English for display.
  Here's your car analogy, You get a new car with all the bells and whistles. It's perfect except the cup holder won't accommodate your jumbo coffee cup, so you decide to replace it with one that holds one big cup instead of a small cup and spare change. But alas, you learn that the car won't start if you swap out any of the accessories. That is systemd.
41. Re:Er? by Blakey+Rat · 2014-09-08 10:53 · Score: 1
  
  I've never seen a more blatant example of You Don't Need That in my life.
  
  --
  Comment of the year
42. Re:Er? by CaptnZilog · 2014-09-08 11:43 · Score: 2
  
  The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
  Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
  So you're "fixing" a bad application by changing the OS?
  Apparently that's the "preferred solution" now... to me it seems to make far more sense to fix the application (BackupExec) to work the way it should, but that type of "logic" apparently doesn't apply to the systemd people who think that the "proper" way to fix that is to write a complex init system replacement and continue to allow people who write shitty service/daemon code to continue writing crappy code.
43. Re:Er? by shutdown+-p+now · 2014-09-08 15:13 · Score: 1
  
  Unless you have fairly narrow requirements, and want a generic Unix-like server or desktop, you'll almost certainly have best luck with FreeBSD (in terms of software availability, hardware support etc).
44. Re:Er? by koinu · 2014-09-08 20:46 · Score: 1
  
  Of course the clock is monotonic. This is also written very clearly in the ntpd man pages that the clock should slow down or tick faster to adjust time without any jumps. Humans should only touch the clock if it is awfully wrong (hours difference). But this is a critical system operation. It can even lead to aborts of important daemons which depend on monotonic clocks. You should avoid changing time at any cost and make sure that the clock is always in a sane state instead.
45. Re:Er? by phantomfive · 2014-09-09 04:55 · Score: 1
  
  lol check out clock_gettime(). There is no guarantee that the clock will be monotonically increasing, and I've seen the result of gettimeofday() go backwards slightly before proceeding fowards on some systems. Annoying. If you want your clock to be monotonically increasing, you need to use clock_gettime() (or equivalent on other systems).
  
  --
  "First they came for the slanderers and i said nothing."
46. Re:Er? by LordLimecat · 2014-09-10 00:24 · Score: 1
  
  The preferred solution is to solve problems, not worry about whose fault it is. If you have a system (computing or otherwise) that is technically correct but makes errors likely, would it be wrong to change that system?
  What if you tell your team used no newlines in if-then constructs as a convention? It would be technically correct, but at some point you might analyze whether continually fixing the broken code is the correct choice, or if its smarter to change the programming paradigm you've chosen that is making errors likely and common.
47. Re: Er? by iggymanz · 2014-09-13 13:36 · Score: 1
  
  Because people who prefer OpenBSD want to run Windows software on it? You are hilarious; in fact OpenBSD developers were chatting a bit about scrapping the Linux compat mode in the newsgroup recently since there is little demand or reasno for that
Stupid, stupid stupid by Anonymous Coward · 2014-09-07 21:18 · Score: 2, Insightful

Why in God's name would you want to infect well designed OSs with Systemd ?
That's unbelievably stupid.
1. Re:Stupid, stupid stupid by Noryungi · 2014-09-07 21:37 · Score: 2
  
  Go tell that to the GNOME dev, who adopted systemd and now require it on all platforms running Gnome.
  I don't run that piece of crap myself, but it has been ported under OpenBSD, and some people want to keep using it on OpenBSD.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
2. Re:Stupid, stupid stupid by Anonymous Coward · 2014-09-07 21:53 · Score: 0
  
  Why in God's name would you want to infect well designed OSs with Systemd ?
  They don't, that is why they "emulate" it by providing a systemd-style API for programs that aren't systemd but are written for an environment where systemd exist.
  Now when anyone claims that it is absolutely necessary to have a monolithic design like systemd it is possible to point at OpenBSD and show that you can get the same functionality with a better design and a wrapper API.
3. Re:Stupid, stupid stupid by LordLimecat · 2014-09-08 00:00 · Score: 1
  
  I honestly dont get the issue here.
  Linux is FOSS. Im not 100% up on the issue, but if distros are adopting something you have a philosophical objection to, use the ones that dont use Systemd. If everyone is using it, then clearly it solves their problem, and you can work with others like you to maintain an alternate solution.
4. Re:Stupid, stupid stupid by Anonymous Coward · 2014-09-08 00:24 · Score: 0
  
  Go tell that to the GNOME dev, who adopted systemd and now require it on all platforms running Gnome.
  Why in God's name would you want to infect well designed OSs with Gnome?
  That's unbelievably stupid.
5. Re:Stupid, stupid stupid by armanox · 2014-09-08 00:52 · Score: 1
  
  That's not how Linux works. A recent G+ post of mine:
  People don't understand how Linux works these days. I constantly hear "Oh, but you can fork it/use a different distro/make your own" in response to complaints about Linux problems (systemd, for example). But that's simply not true. There are really three distributions that matter: Ubuntu, Fedora, and SuSE. Ubuntu because it's the "common man's Linux." Fedora because it is what becomes Red Hat, which brings us to Red Hat and SuSE are what counts in the business world. No other distribution is significant in comparison - the majority of people that use Linux in the enterprise world must use Red Hat or SuSE. No other choice. Doesn't matter what Slackware or Mint or whoever does - they simply do not matter. So issues like systemd, GNOME 3, wayland, firewalld, etc; are much more significant then the average user or average OSS advocate seems to understand - when we fight and complain about something going into Fedora, complain because it breaks compatibility, etc; getting simply dismissed is not the appropriate response. Linux is not the infant OS project it once was, and the distro wars are over. What will happen, is some people will accept the changes, and others will leave for platforms that are less prone to random decisions
  
  --
  I'm starting to think GNU is the problem with "GNU/Linux" these days.
6. Re:Stupid, stupid stupid by jythie · 2014-09-08 00:53 · Score: 2
  
  Within FOSS there are still pragmatic realities and politics involved. The major distributions are not democracies, they have core groups who make the decisions regarding what goes in or stays out. Applications developers who want their stuff to work on major distros have to follow the direction and standards of the distro maintainers otherwise their projects lose ease and compatibility. Thus one's options can rapidly diminish, it is a bit of a cascade effect. While in theory since it is FOSS one can do whatever they want with it, but in practice unless one is going to devote all their time and resources to altering things one is going to have to use what other people are working with.
  
  Which gets to the second part of the problem, those core groups inside the major distributions tend to represent certain subsets of users and historically have not been all that open to listening about the needs of users outside their professional and social circles (a good example would be the friction between the server/desktop/web centric maintainers and embedded developers, which caused a lot of displeasure regarding GPLv3), so who's problem it solves is not nessearily a good metric.
7. Re:Stupid, stupid stupid by MareLooke · 2014-09-08 01:29 · Score: 1
  
  That's the theory yes. But unfortunately with systemd it didn't work out that way.
  See, the GNOME developers decided to make systemd a hard dependency, this pretty much means that (binary) distributions that want to keep offering GNOME to their users have two options:
  a) patch GNOME to work without systemd
  b) switch to systemd
8. Re:Stupid, stupid stupid by Anonymous Coward · 2014-09-08 01:31 · Score: 0
  
  Because they want to run recent Gnome, of course.
9. Re:Stupid, stupid stupid by Anonymous Coward · 2014-09-08 01:38 · Score: 0
  
  That's okay, but doesn't systemd-shim do the same thing? Why reinvent the wheel?
10. Re:Stupid, stupid stupid by dagarath · 2014-09-08 02:49 · Score: 1
  
  I think your list is slightly off, Debian, Redhat, SuSE. I think the systemd situation clearly demonstrates that Debian is the dog wagging the Ubuntu tail.
11. Re:Stupid, stupid stupid by LordLimecat · 2014-09-08 03:07 · Score: 1
  
  : Ubuntu, Fedora, and SuSE
  You mean Debian (the upstream from Ubuntu, which doesnt have a lot of the crap Ubuntu does), Red Hat (which drives Fedora), and Suse.
  Plus others like Arch, Slackware, and Gentoo-- Im not sure what qualifies as "mattering", but Im not clear why it should matter to an Arch user what the Ubuntu world is doing.
  
  the majority of people that use Linux in the enterprise world must use Red Hat or SuSE.
  You mean Red Hat (or CentOS! which can always fork!) or Debian.
  Complaining about Fedora is dumb. It's show is run by a company who has specific goals, and if you dont like them there's CentOS. If things get bad, fork CentOS-- from all the flak about systemd, surely there are enough folks onboard to do that.
12. Re:Stupid, stupid stupid by fnj · 2014-09-08 03:08 · Score: 1
  
  To the people who want to run Gnome3 on BSD: it sucks to have made a stupid choice. Wake up, kick it to hell and use a better DE or WM.
13. Re:Stupid, stupid stupid by LordLimecat · 2014-09-08 03:08 · Score: 1
  
  c) get rid of GNOME for any of the million other DEs
  d) provide a compatibility layer
  e) fork GNOME
14. Re:Stupid, stupid stupid by multimediavt · 2014-09-08 03:27 · Score: 1
  
  To the people who want to run Gnome3 on BSD: it sucks to have made a stupid choice. Wake up, kick it to hell and use a better DE or WM.
  Or, stick to a command line on a server! Few people run BSD as a desktop OS. Most are servers and get the fscking GUI OFF THE DAMN THING AS YOU LEAVE MY LAWN!
15. Re:Stupid, stupid stupid by armanox · 2014-09-08 03:34 · Score: 1
  
  Since Linux is widespread in enterprises, fringe distros have ceased to matter for most people. Not knowing how to use yum (or in rarer cases apt and yast) means that saying you know Linux isn't true. As much as I like Slackware, they're a minority that nobody cares about. Nobody that matters anyway. People use CentOS because it's compatible with RHEL, right down to the security holes. We're approaching the point that saying "I am a Linux admin" will mean you know systemd and firewalld.
  
  --
  I'm starting to think GNU is the problem with "GNU/Linux" these days.
16. Re:Stupid, stupid stupid by armanox · 2014-09-08 03:35 · Score: 1
  
  I think you might be right on that one. It was a Debian decision.
  
  --
  I'm starting to think GNU is the problem with "GNU/Linux" these days.
17. Re:Stupid, stupid stupid by HiThere · 2014-09-08 07:48 · Score: 1
  
  FWIW, the current notes seem to say that systemd is still optional in Debain Jessie (currently testing), though I think it gets installed by default, and I'm not sure how to avoid it.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
18. Re:Stupid, stupid stupid by CaptnZilog · 2014-09-08 08:02 · Score: 1
  
  Go tell that to the GNOME dev, who adopted systemd and now require it on all platforms running Gnome.
  Why in God's name would you want to infect well designed OSs with Gnome?
  That's unbelievably stupid.
  I gave up on Gnome long ago.
19. Re:Stupid, stupid stupid by Anonymous Coward · 2014-09-08 08:40 · Score: 0
  
  Since Linux is widespread in enterprises fringe distros have ceased to matter for most people.
  Interestingly, the 'fringe distros' running here are Debian and Slackware
  
  '...Not knowing how to use yum (or in rarer cases apt and yast) means that saying you know Linux isn't true...'
  Oh FFS!, I've never used yum or yast, maybe I don't know Linux..maybe I've not been here since SLS 0.99pl11A, maybe I've not run 'production' systems with custom (i.e. products of my deranged mind) kernel hacks to interface with outré hardware..maybe I didn't do the same thing with VME bus Suns (SunOS and Linux)..
  
  As much as I like Slackware, they're a minority that nobody cares about. Nobody that matters anyway.
  You keep thinking that...I'll just keep using Slackware* as the base distro for the custom IDS/Firewall (I originally pitched a better *BSD solution...but the L-word was buzzing at the time, so I ported the whole shebang..and lo, nobody that mattered was happy...the same nobody that was shown the dogturd that is/was/willbe Ubuntu and who called it thus..)
  
  We're approaching the point that saying "I am a Linux admin" will mean you know systemd and firewalld.
  We reached a point several years ago where wonks with bits of paper saying they were 'Redhat Certified' were out there causing mayhem in contractland..I don't know if this is still the case, as I saw the writing on the wall and jumped ship..so I suppose you have a point there as it's a logical extension of the rot that started setting in about a decade ago.
  Basically it means your average Linux sysadmin will be as clueless as your average Windows Administrator so..yaay Linux finally achieves parity with windows in a key area..
  *That is, until the day it has to include systemd as 'dependency hell' forces it upon them.
Ye Gods! by jawtheshark · 2014-09-07 21:19 · Score: 1

Ye Gods! No!
OpenBSD truly adheres to "KISS", especially regarding simple configuration files. Exactly of what systemd isn't. It may have (and I'm still not convinced) nice features, but for my uses what is presently being used suffices, both on Linux and especially on OpenBSD.

--
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
1. Re:Ye Gods! by Noryungi · 2014-09-07 21:31 · Score: 4, Insightful
  
  Again, this an emulation of systemd - not the real ugly mess.
  This means that the normal configuration files will probably stay, but will probably be parsed on-the-fly (smartly, one hope) to provide some emulation.
  The reason this is interesting is that it may prove an escape hatch not just for OpenBSD, the other BSDs, but also for some (sane) Linux distributions that refuse to adopt systemd such as Slackware.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
2. Re:Ye Gods! by Anonymous Coward · 2014-09-07 22:07 · Score: 0
  
  Again, this an emulation of systemd - not the real ugly mess.
  This means that the normal configuration files will probably stay, but will probably be parsed on-the-fly (smartly, one hope) to provide some emulation.
  The reason this is interesting is that it may prove an escape hatch not just for OpenBSD, the other BSDs, but also for some (sane) Linux distributions that refuse to adopt systemd such as Slackware.
  I can understand this, but seriously I think that it's time to simply throw Gnome away. Qt is multiplatform and vastly superior to Gnome in terms of documentation, software components etc... The only software that unfortunately needs Gnome is Gimp. Now how I wished there were a Gsoc project for throwing away the Gnome part of Gimp and rebuild it on Qt instead.
  Gnome is like a cancer. It rots everything it touches.
  People in that project don't know how to design a good software (not only in terms of GUI but in terms of engineering as well). I totally support Slackware's decision to not use Gnome in the base distribution.
3. Re:Ye Gods! by Noryungi · 2014-09-07 22:28 · Score: 2
  
  Read them and weep: http://www.reddit.com/r/linux/...
  TL;DR? Essentially, KDE may end up switching to systemd. Because Gnome (and every other Linux fan-boi) does it.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
4. Re:Ye Gods! by cold+fjord · 2014-09-07 22:33 · Score: 1
  
  Talk about the tail wagging the dog.
  
  --
  much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
5. Re:Ye Gods! by Barsteward · 2014-09-07 22:44 · Score: 1
  
  Have you had a read of this? Myth buster for systemd. http://0pointer.de/blog/projec...
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
6. Re:Ye Gods! by Spit · 2014-09-07 22:53 · Score: 1
  
  Yes, if this ever gains traction we may possibly end up with a systemd which doesn't suck and can just abandon that horse's ass.
  
  --
  POKE 36879,8
7. Re:Ye Gods! by Sique · 2014-09-07 23:15 · Score: 3, Interesting
  
  You know that Gnome is actually a result of The GIMP and not vice versa? Gnome builds on GTK, which stands for GIMP Toolkit (and not Gnome Toolkit). Gnome is basicly a standalone version of GIMPs UI widgets.
  
  --
  .sig: Sique *sigh*
8. Re:Ye Gods! by Anonymous Coward · 2014-09-07 23:35 · Score: 1
  
  That old propaganda page...
  It even starts out by claiming that systemd is not monolithic, but if it wasn't, people would be able to put systemd in a start-gnome script, and nobody would care about boycotting systemd. It would just be another gnome-process that gets started and shut down along with the rest of Gnome.
9. Re:Ye Gods! by Rich0 · 2014-09-07 23:42 · Score: 2
  
  OpenBSD truly adheres to "KISS", especially regarding simple configuration files. Exactly of what systemd isn't.
  Uh, what isn't simple about configuration in systemd?
  The article mentions logind. Here is my logind config:
  [Login]
  #NAutoVTs=6
  #ReserveVT=6
  #KillUserProcesses=no
  #KillOnlyUsers=
  #KillExcludeUsers=root
  #InhibitDelayMaxSec=5
  HandlePowerKey=ignore
  HandleSuspendKey=ignore
  HandleHibernateKey=ignore
  HandleLidSwitch=ignore
  #PowerKeyIgnoreInhibited=no
  #SuspendKeyIgnoreInhibited=no
  #HibernateKeyIgnoreInhibited=no
  #LidSwitchIgnoreInhibited=yes
  #IdleAction=ignore
  #IdleActionSec=30min
  #RuntimeDirectorySize=10%
  #RemoveIPC=yes
  Just what about that isn't simple? The defaults are basically how most unix-y systems behave anyway, and you can set things like what happens if a user logs out and leaves some processes behind, what happens if somebody pushes the power button, what happens if the console is idle, etc?
  And the functionality of this daemon seems like the definition of "do one thing well." If it didn't have systemd in the filename people would be arguing that "systemd should be more like this."
10. Re:Ye Gods! by prsephton · 2014-09-08 00:25 · Score: 2
  
  Biggest myths of systemd:
  Systemd is a necessary replacement for init.d
  Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).
  Systemd is a result of careful needs analysis and planning by a mature team of developers
  Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."
  In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.
  Systemd is similar to upstart
  Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.
  It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.
11. Re:Ye Gods! by prsephton · 2014-09-08 00:29 · Score: 1
  
  That, my dear fellow, is simply horrible. Ever heard about how the use of whitespace improves readability?
12. Re:Ye Gods! by Anonymous Coward · 2014-09-08 00:46 · Score: 0
  
  So let's now go through and analyse these some more...
  
  Systemd is a necessary replacement for init.d
  Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).
  The separation between rc.d and inetd was never sensible. The separation between starting daemons and handling hardware was never sensible. Plain text logs from syslog still exist unless you actively work to dissable them. Once you've looked at journalctl you realise it shits all over ad hoc grepping and other crappy solutions that aren't actually as good as what journalctrl just does ootb.
  
  Systemd is a result of careful needs analysis and planning by a mature team of developers
  Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."
  In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.
  You take a statement about what systemd is *now* and compare it to an initial announcement from 4½ years ago. Is there any chance that the list of names involved might have changed? Top of the class.
  
  Systemd is similar to upstart
  Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.
  None of the pages linked ever make that claim. Indeed, they contrast how the dependency model is an improvement over upstart.
  
  It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.
  Red herrings work both ways, kthnxbye.
13. Re:Ye Gods! by Anonymous Coward · 2014-09-08 01:09 · Score: 0
  
  That, my dear fellow, is simply horrible. Ever heard about how the use of whitespace improves readability?
  What an asshole you are
14. Re:Ye Gods! by Anonymous Coward · 2014-09-08 01:57 · Score: 0
  
  scanners no longer work in debian, thanks to systemd.
  debunk that.
15. Re:Ye Gods! by Eunuchswear · 2014-09-08 02:29 · Score: 1
  
  scanners no longer work in debian, thanks to systemd.
  You mean we are no longer at risk of having our heads explode!
  That seems a significant improvement to me.
  
  --
  Watch this Heartland Institute video
16. Re:Ye Gods! by BadDreamer · 2014-09-08 02:30 · Score: 2
  
  The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
  None of the chunks in systemd do one thing, do it will and provide a UNIXy way to assemble them together. They're a huge blob of interdependent API's.
  And yes, if it wasn't part of this API infested mess people would indeed be arguing that systemd should be more like it. But unfortunately that is not the case.
17. Re:Ye Gods! by Rich0 · 2014-09-08 02:37 · Score: 1
  
  The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
  Well, changing APIs reflects the immaturity of the project more than anything - I suspect it will tend to settle down.
  And the plan for Linux is for kdbus to be the preferred way for processes to communicate. That is how just about everything in systemd communicates. Sure, it isn't as elegant as sending one of 32 fixed signals (most of which already have intended uses leading to hacks like using SIGHUP for everything and its uncle) to everything to try to get it to do something, but it works. :)
18. Re:Ye Gods! by Rich0 · 2014-09-08 02:38 · Score: 1
  
  I'm sure patches to the default file are more than welcome. So, why aren't you contributing? Do you really expect anybody else to be able to do as good a job with it?
19. Re:Ye Gods! by BadDreamer · 2014-09-08 04:26 · Score: 1
  
  The point is that they're API's. That is what makes systemd a fragile monolith. And the solution to this is to not allow anything to replace a part of systemd; if you want an alternative it will run in parallel with the systemd equivalent.
  That is pasting over the fragility instead of fixing it. It's a huge mess. Sure, it was required, because it will make sure someone writes a sane solution instead, but right now it's a huge pain.
20. Re: Ye Gods! by Anonymous Coward · 2014-09-08 06:15 · Score: 0
  
  A message bus like kdbus is nothing lika an API. I get the feeling that you have no idea what so ever.
21. Re:Ye Gods! by Anonymous Coward · 2014-09-08 06:53 · Score: 0
  
  Have you had a read of this? Myth buster for systemd. http://0pointer.de/blog/projec...
  
  Please promote "the kool-aid" elsewhere.....
22. Re:Ye Gods! by Rich0 · 2014-09-08 13:25 · Score: 1
  
  The point is that they're API's. That is what makes systemd a fragile monolith. And the solution to this is to not allow anything to replace a part of systemd; if you want an alternative it will run in parallel with the systemd equivalent.
  Just what systemd components can't be replaced? If you enable the dhcpcd service, it will happily configure your network just like it would in sysvinit, and you don't need to run networkd/resolved/etc.
  About the only component that anybody is likely to run in parallel is journald, and if you set journald to non-persistant mode then you can view it as just a daemon that captures console output from daemons that would otherwise be lost, since it doesn't interfere with syslog at all.
23. Re:Ye Gods! by BadDreamer · 2014-09-08 16:44 · Score: 1
  
  Most of all, and most seriously and utterly broken, you can't replace journald. Ever. And you can't replaced udev. Or logind, if you wish to run Gnome.
  In fact, apart from networkd which isn't finished, I don't know of any part of systemd which you can replace with an alternative yet have systemd work with it as if systemd was actually a piece of UNIXy software.
  Mostly because systemd is not a piece of UNIXy software.
24. Re:Ye Gods! by Barsteward · 2014-09-08 19:40 · Score: 0
  
  Its answers the questions made by people who seem to know nothing about systemd but continue to trash it regardless.
  
  your idea of monolithic seems to be completely different to mine, systemd seems to be described as modular to me as it has 69 binaries. Monolithic to my mind is a single binary.
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
25. Re:Ye Gods! by Anonymous Coward · 2014-09-08 22:09 · Score: 0
  
  The GIMP is not and has not been the main driver for most of the GTK+ development for a long, long time. The acronym is outdated.
ntp is the line in the sand by Anonymous Coward · 2014-09-07 21:30 · Score: 0

ntp is where I draw the line in the sand.
I can put up with a lot, I've been putting up with NetworkManager already.
But replacing ntpd because NIH? Fuck that fuck them fuck all of this.
This needs to end. And this needs to end now.
Full props to the kid working on this though, the world can always use more duct tape even if we shouldn't build bridges out of the stuff.
1. Re:ntp is the line in the sand by ThePhilips · 2014-09-07 22:07 · Score: 1
  
  What any of that has to do with the network time protocol?
  FreeBSD folks do the same thing Debian did for some time before adopting the systemd: instead of the systemd, provide the teeny-tiny services, applications actually depend on.
  
  --
  All hope abandon ye who enter here.
2. Re:ntp is the line in the sand by Anonymous Coward · 2014-09-07 22:23 · Score: 0
  
  Guess what systemd-timedated is?
  They are coming for you next.
3. Re:ntp is the line in the sand by jeremyp · 2014-09-07 22:23 · Score: 1
  
  Because systemd now has a replacement for ntpd.
  The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
4. Re:ntp is the line in the sand by Anonymous Coward · 2014-09-07 22:25 · Score: 0
  
  The poster refers to the fact that systemd is replacing daemons regardless of whether there was a particular need to do so. As you say, the question is: "What does systemd have to do with the network time protocol". That answer should be "Nothing".
5. Re:ntp is the line in the sand by ThePhilips · 2014-09-07 22:34 · Score: 2
  
  So the rumors were true that in V2.0 systemd would finally offer integration with ntoskrnl.exe, along with rewrite to take full advantages of the CLR.
  
  --
  All hope abandon ye who enter here.
6. Re:ntp is the line in the sand by ThePhilips · 2014-09-07 22:35 · Score: 1
  
  See previous reply to my comment.
  The systemd-timedated is harmless - the systemd-timesyncd is a different story.
  
  --
  All hope abandon ye who enter here.
7. Re:ntp is the line in the sand by jeremyp · 2014-09-07 22:48 · Score: 2
  
  Not sure about that, but they are inventing a new way to run services. They will have a new program called daemonhostd which can host multiple services. All you have to do is recompile sendmail and apache as shared object libraries and daemonhostd will dynamically load and run them in the same process to save resources.
  As a further refinement, they are also writing kdaemonhostd which is exactly the same but it all runs in kernel space to improve performance.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
8. Re: ntp is the line in the sand by Anonymous Coward · 2014-09-07 23:00 · Score: 0
  
  Is there supposed to be some advantage in running Apache and Sendmail in the same process?
9. Re: ntp is the line in the sand by Anonymous Coward · 2014-09-07 23:17 · Score: 0
  
  Is there supposed to be some advantage in running Apache and Sendmail in the same process?
  Sure. A lot of websites sends various kinds of confirmation emails. Now you don't have to spawn a separate process to do that!
  Next up: mysqld
10. Re: ntp is the line in the sand by Anonymous Coward · 2014-09-07 23:29 · Score: 0
  
  You know that was a joke, right?
  Daemonhostd is clearly a play on Windows Service Host.
  Well, at least I HOPE it was a joke. With systemd, I'm not sure anymore.
11. Re:ntp is the line in the sand by gbjbaanb · 2014-09-08 00:14 · Score: 3, Interesting
  
  Its actually a very old way to run services. Windows has been doing it this way for years.
  Run process explorer on Windows, click on a svchost.exe process and see what services its running. It made more sense on Windows as a Windows process is more heavy than a Linux one, this is the same reason threads are more common on Windows compared to Linux's spawning processes to provide the same solution.
  Anyway, one issue is reliability - if you want to restart a borked Apache, you can tell it to restart, and if it doesn't you can kill it. Systemd, you'll have to kill the daemonhost that hosts the Apache service, and kill all the other running services too. Assuming the security model allows you to do that.
12. Re: ntp is the line in the sand by jeremyp · 2014-09-08 01:55 · Score: 1
  
  I did do a quick scan of the web site to make sure the idea is not real. However, it's possible that I missed it.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
13. Re:ntp is the line in the sand by jeremyp · 2014-09-08 02:23 · Score: 1
  
  Well of course you'd be absolutely insane to try to put sendmail and Apache in the same address space. In fact, sendmail forks (or at least used to fork when I last looked at it 10 years ago) to serve each incoming connection, so it's insane to try to restrict sendmail on its own to only one address space.
  I thought my mention of kdaemonhostd (sendmail in the kernel, yay!) plus the fact that daemonhostd is derived from svchost(.exe) would be enough to show the post is not entirely serious.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
14. Re: ntp is the line in the sand by Eunuchswear · 2014-09-08 02:32 · Score: 1
  
  Woooosh.
  
  --
  Watch this Heartland Institute video
15. Re:ntp is the line in the sand by Peter+H.S. · 2014-09-08 04:01 · Score: 1
  
  Because systemd now has a replacement for ntpd.
  The systemd people are (as far as I can tell) writing replacements for almost all the standard services that run on Linux because they want to take over the World bwahaha!
  Please notice that systemd-timesyncd is only a sNTP v4 client, not a full NTP server like NTPd.
  A main focus for systemd is OS containers, and this sNTP client, like the DHCP client, was especially made for such OS containers: When starting 5000 OS containers in parallel the usual sNTP and DHCP clients wouldn't work properly (like in fast enough).
  systemd's "timesync" isn't in any way mandatory, and it is easy to compile and run systemd without it.
16. Re:ntp is the line in the sand by gbjbaanb · 2014-09-08 05:35 · Score: 1
  
  oh sorry - I didn't get the joke, I thought kdaemonhostd was a real thing! That's how bad this systemd thing has become :-(
17. Re: ntp is the line in the sand by CaptnZilog · 2014-09-08 08:08 · Score: 1
  
  You know that was a joke, right?
  Daemonhostd is clearly a play on Windows Service Host.
  Well, at least I HOPE it was a joke. With systemd, I'm not sure anymore.
  You mean "daemonhostd.exe" right? ;)
18. Re:ntp is the line in the sand by gweihir · 2014-09-08 11:37 · Score: 1
  
  Clearly, they want to write replacements for anything that is connected to the network. My guess would be that the old stuff has gotten far to secure for the NSA's liking.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
19. Re:ntp is the line in the sand by Anonymous Coward · 2014-09-08 12:02 · Score: 0
  
  I thought my mention of kdaemonhostd (sendmail in the kernel, yay!) plus the fact that daemonhostd is derived from svchost(.exe) would be enough to show the post is not entirely serious.
  You might not be serious, but I wouldn't put it past the systemd developers to actually implement this.
20. Re: ntp is the line in the sand by Anonymous Coward · 2014-09-08 13:11 · Score: 0
  
  You know that was a joke, right?
  For now I'm relieved but I really wasn't sure.
Huh? by Richard_at_work · 2014-09-07 21:32 · Score: 5, Insightful

Why the hell is a GUI system dependent on a low level system control daemon?
1. Re:Huh? by Noryungi · 2014-09-07 21:43 · Score: 5, Insightful
  
  Thank you, you have just summed up the abomination that is systemd for all of us.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
2. Re:Huh? by Anonymous Coward · 2014-09-07 21:48 · Score: 1
  
  > Why the hell is a GUI system dependent on a low level system control daemon?
  Because someone has taken up "all your base is belong to us" as a business model.
  Seriously.
  The more unfortunate question is why the hell is a low level system control daemon making things dependent on a GUI system?
3. Re:Huh? by qbast · 2014-09-07 22:22 · Score: 1
  
  Because GNOME.
4. Re:Huh? by Barsteward · 2014-09-07 22:29 · Score: 2
  
  No, thats an abomination of Gnome, thats not systemd's fault.
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
5. Re:Huh? by Anonymous Coward · 2014-09-07 22:37 · Score: 0
  
  Because they need a common shared interface to access login information for the various users. Whether or not the user is logged in, last login time, etc.
6. Re:Huh? by Anonymous Coward · 2014-09-07 22:42 · Score: 5, Insightful
  
  Because the user of a GUI will want to touch hardware (mount a USB stick, use an audio device, suspend to RAM, configure a wireless network ...) and all of those interactions need some form of permissions broker. The current approach of having a hundred different command line utilities being called from the GUI (and then not working because their command line output has changed yet again) scales very badly and is the reason why linux has a (fairly well deserved) reputation at being hopeless for doing simple things like letting a desktop user use the usb stick they just put in, dealing with audio devices etc...
  Fixing that requires an integrated approach. Layers of crappy shell scripts calling yet more layers of crappy shell scripts calling some binary that then calls some shell script that then pokes something into /sys IS the problem.
  You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication. It's about consolidation of functions into one implementation that *does* work as opposed to 20 half-arsed implementations that do not. It's about providing what amounts to a library for daemons ... and libraries are deduplication are good things while reinventing wheels in every single application is bad, right?
  For an application to effectively use these libraries and reduce the amount of code duplication across kde/gnome/xfce/lxde/... it has to actually have access to that code, which means that the thing that provides the code needs to be available. That means that the relevant systemd *component* is there -- and much of this is managed by logind.
7. Re:Huh? by Anonymous Coward · 2014-09-07 22:57 · Score: 0
  
  And before you maniacs start crying like little babies how systemd abuses the "Unix philosophy"; systemd isn't a single binary, it's a whole set of binaries.
  You Slashdotters really start pissin' me off. Bunch of lazy whinos that don't ever try to get their facts straight.
8. Re:Huh? by Anonymous Coward · 2014-09-07 23:21 · Score: 0
  
  (and then not working because their command line output has changed yet again)
  Yeah! Something like that would NEVER happen with systemd. They have the most stable API EVAR!!!
9. Re:Huh? by Anonymous Coward · 2014-09-07 23:24 · Score: 0
  
  Fuck off, systemd shill.
10. Re:Huh? by StormReaver · 2014-09-07 23:43 · Score: 2
  
  Why the hell is a GUI system dependent on a low level system control daemon?
  Just a wild guess (and I may be wrong), but perhaps it's for better communication of events between the underlying system and the GUI.
11. Re:Huh? by Anonymous Coward · 2014-09-07 23:51 · Score: 1
  
  Why the hell is a GUI system dependent on a low level system control daemon?
  Ever heard of policikit? consolekit? multiseat support? vt-less consoles? suspend/resume features? network management?
  Since systemd provides all of this into one package, and no other system, as of today, provides multiseat support, and since consolekit last commit was 1.5 year ago, and the last tagged release for polkit was 1 year ago, it makes sense.
  Also, finally we have a centralized way of handling suspension and resume features, instead of every desktop environment reimplementing the whole damn thing (that breaks every daemon trying to do the same, btw).
  Frankly, I like systemd. It should be taken out of the hands of Lennard now, since I do not believe he is capable of handling such a project, but I like its features and what it means for linux.
  No other init system or distribution was capable of utilizing the features of the linux kernel so deeply until now.
  The good part about systemd is that it uses dbus for communications. DBUS is getting merged in the linux kernel *AND* in the freebsd kernel, so compatibility software like this can be used.
  Lennard did not realize that he had to separate 2 things: the DBUS API and systemd itself -- Have I already said the I don't think he is able to manage such a system?
12. Re:Huh? by Anonymous Coward · 2014-09-07 23:53 · Score: 1
  
  they use the logind API for it (sponsored by NSA).
  Fixed that for you.
13. Re:Huh? by Anonymous Coward · 2014-09-08 00:19 · Score: 0
  
  and that didn't already work beautifully by ubuntu 10.04?
14. Re:Huh? by Anonymous Coward · 2014-09-08 00:35 · Score: 0
  
  Perhaps you'd like to read over http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
15. Re:Huh? by Anonymous Coward · 2014-09-08 00:45 · Score: 0
  
  Well, I think the responsibility is partly shared here (for the worse, don't get me wrong):
  1. Gnome devs made it depend on logind, which kinda make sense at the time (I said *kinda*)
  2. logind devs decided to make systemd a hard dependency.
  And there came the Gnome dependency on systemd. Arguably, given that logind devs are also involved into systemd, Gnome devs had it coming. But hey you know the story that keeps repeating all over the place:
  
  Worry not, systemd is only optional for now, and we'll keep maintaining the other options in parallel. [a few months later] yes, we had enough maintaining these old scripts. They're broken now and nobody uses them anymore anyway.
  of course they omit to say that they're not used anymore because they broke them in the first place.
16. Re:Huh? by Unknown+Lamer · 2014-09-08 01:37 · Score: 1
  
  Because utmp totally does not exist.
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
17. Re:Huh? by Anonymous Coward · 2014-09-08 01:59 · Score: 0
  
  Gnome is not a GUI, it's a DE.
  A GUI is something you paste over a program (or a bunch of programs) that give you a graphical I/O. Gnome is something like that to you programs, to your sound hardware, to you printers, to your network, to your displays, to your storage devices and filesystems, and to your other devices.
  As such, it so happens it *is* dependent on lots of low level system control deamons or abstractions.
18. Re:Huh? by evilviper · 2014-09-08 02:26 · Score: 1
  
  Ignorance is not a counter-argument.
  
  --
  Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
19. Re:Huh? by Peter+H.S. · 2014-09-08 02:58 · Score: 1
  
  "
  
  Why the hell is a GUI system dependent on a low level system control daemon?
  1. Because the systemd project provides an nice distro agnostic compatability layer, so upstream projects can get information about the OS and do basic things like setting locale, time etc.
  2. User login and session managment. The OS ought to provide this. At the moment only systemd's "logind" is actively maintained and fully functional. The old "ConsoleKit" isn't maintained any more, and nobody in the Linux world seems to be working on a replacement. Without it stuff like multi-user systems, hibernation etc, root-less X.org, and lots more, won't function properly.
  3. The systemd project offers a lot of very attractive features for upstream projects to use, and no one in the Linux community seems to work on anything that could provide a non-systemd alternative to these functions (perhaps the exception being eudev, but that is a systemd fork).
  Upstream DE projects like Gnome have warned for years, that if no alternative to at least systemd's "logind" materialises, they will have severe problems supporting non-systemd platforms.
20. Re:Huh? by drinkypoo · 2014-09-08 03:23 · Score: 1
  
  Ignorance is not a counter-argument.
  Ignorance of why Unix is done the way it is done is also not an argument for systemd.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
21. Re:Huh? by tyggna · 2014-09-08 03:25 · Score: 1
  
  For that matter, why the hell is the kernel dependent on glibc!? Lets just throw out all dependencies and if your code doesn't work without it, then it's not simple or philosophically pure.
22. Re:Huh? by fnj · 2014-09-08 03:25 · Score: 1
  
  Because the user of a GUI will want to touch hardware ... and all of those interactions need some form of permissions broker.
  Why do they need a permissions broker? Because somebody wants to make everyone submit to his personal OCD?
23. Re:Huh? by drinkypoo · 2014-09-08 03:27 · Score: 3, Insightful
  
  Because the user of a GUI will want to touch hardware (mount a USB stick, use an audio device, suspend to RAM, configure a wireless network ...) and all of those interactions need some form of permissions broker.
  Right. We have multiple capabilities-based security systems available for use with Linux, and we have a pluggable authentication system, and now we need another system to handle privilege management?
  
  Fixing that requires an integrated approach.
  That's what Unix gives you. Because the system is made up of small pieces, you can recombine them in different ways to achieve your goals. The pieces are designed to integrate with one another.
  
  You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication.
  We achieve that with shared libraries. There is no need for monolithic daemons which serve many purposes. Process creation is cheap on Unix.
  
  You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication. It's about consolidation of functions into one implementation that *does* work as opposed to 20 half-arsed implementations that do not.
  But in fact it's one half-arsed implementation that only works sometimes instead of 10 really brilliant implementations that almost always work, and 10 mediocre ones.
  
  For an application to effectively use these libraries and reduce the amount of code duplication across kde/gnome/xfce/lxde/... it has to actually have access to that code, which means that the thing that provides the code needs to be available.
  Yeah, it's called a shared library.
  No one has offered an explanation as to what systemd gives us that we did not have before. There is not one single thing. And what we've lost is simplicity. systemd is the opposite of the Unix way.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
24. Re:Huh? by phantomfive · 2014-09-08 04:18 · Score: 1
  
  You'll also find that systemd is indeed quite unix-like......It's about consolidation of functions into one implementation
  ok, you failed to understand the unix way
  
  --
  "First they came for the slanderers and i said nothing."
25. Re:Huh? by CaptnZilog · 2014-09-08 08:12 · Score: 1
  
  You'll also find that systemd is indeed quite unix-like......It's about consolidation of functions into one implementation
  ok, you failed to understand the unix way
  Bingo. Sums it up quite nicely.
26. Re:Huh? by Anonymous Coward · 2014-09-08 09:08 · Score: 0
  
  Well, how would you do it, the other way around?
27. Re:Huh? by Anonymous Coward · 2014-09-08 09:22 · Score: 0
  
  .. User login and session managment. The OS ought to provide this. At the moment only systemd's "logind" is actively maintained and fully functional.......Without it stuff like multi-user systems, hibernation etc, root-less X.org, and lots more, won't function properly.
  Eh?
  'stuff like multi-user' so the Linux systems I've run with 50+ interactive shell users per box with up to a year uptime without recourse to systemd (indeed, the main culprit behind it still hadn't gotten round to fucking royally with Linux audio) are a figment of my imagination...I really thought they were functioning properly..I'm now enlightened.
  'hibernation' again, really? I thought I'd had that sussed even on poxy S*ny V*** laptops something like 15 years ago..I can't remember having to use anything called systemd to achieve this..I'll really have to see if the laptop I've got in a drawer somewhere still hibernates properly (assuming the battery still works), it's got an old Slackware release on it...hasn't been used for a couple of years..
28. Re:Huh? by sjames · 2014-09-08 09:50 · Score: 1
  
  Actually, it is. Pid 1 shouldn't have anything for the GUI to depend on.
  Systemd is a toddler with a tube of superglue and a house full of things that aren't bound together....YET
29. Re:Huh? by sjames · 2014-09-08 09:55 · Score: 1
  
  You plug in the USB stick, a file manager pops open. So dreadfully hard! Stick in a data cd and a file manager pops open. Plug in an audio disk and a player pops up. No systemd in sight. Next excuse please.
30. Re:Huh? by sjames · 2014-09-08 10:00 · Score: 1
  
  Sure they can. They can either be in the right group or use a simple helper daemon that is not PID 1.
31. Re:Huh? by gweihir · 2014-09-08 11:38 · Score: 1
  
  Stupidity. There is no other explanation, except maybe coercion.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
32. Re:Huh? by prsephton · 2014-09-08 20:05 · Score: 1
  
  It's not, actually, The kernel is statically linked and has no dependency on glibc after it is compiled.
33. Re:Huh? by Anonymous Coward · 2014-09-09 06:00 · Score: 0
  
  Because RH...
34. Re:Huh? by Anonymous Coward · 2014-09-09 06:04 · Score: 0
  
  That is a hell of a abuse of "agnostic". More like "you can get a Linux in any color, as long as it's systemd".
/etc/inittab by MrKaos · 2014-09-07 21:37 · Score: 4, Interesting

and rc.d it's so simple. I'm still struggling to understand why systemd is required - what problem it is actually solving. Am I missing something?

--
My ism, it's full of beliefs.
1. Re:/etc/inittab by Anonymous Coward · 2014-09-07 21:50 · Score: 1
  
  what problem it is actually solving
  The problem that some power-hungry insignificant turd with no fucking idea about how the existing systems worked didn't wasn't universally important yet.
  Captha: (an in-apt 'excels')
2. Re:/etc/inittab by Anonymous Coward · 2014-09-07 21:57 · Score: 3, Insightful
  
  The problem it solves is that currently you don't always need to hire RedHat to manage your large Linux clusters.
  While keeping hold of the top end, they are seeing the bottom end fall out from underneath them. And they have to do something to shore up that attrition of tomorrow's decision makers.
3. Re:/etc/inittab by Barsteward · 2014-09-07 23:04 · Score: 2, Informative
  
  you could try reading up on it. Here's a taster for you..
  
  "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. "
  
  and if you are in the mood for reading, here's a longer introduction.
  http://0pointer.de/blog/projec...
  
  its probably getting rid of SCO stuff from Linux as well as its a Linux specific project
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
4. Re:/etc/inittab by antientropic · 2014-09-07 23:22 · Score: 4, Interesting
  
  It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
5. Re:/etc/inittab by Anonymous Coward · 2014-09-07 23:26 · Score: 0
  
  "...It can work as a drop-in replacement for sysvinit."
  Even on kernels without e.g. cgroups?
6. Re:/etc/inittab by Anonymous Coward · 2014-09-07 23:27 · Score: 0
  
  It is a Linux specific process but Poettering recommends through freedesktop.org (not LinuxDesktop.org) that everything should depend on it.
7. Re:/etc/inittab by Anonymous Coward · 2014-09-07 23:58 · Score: 0
  
  and rc.d it's so simple.
  It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
  o, and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and... ... I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.
8. Re:/etc/inittab by Anonymous Coward · 2014-09-08 00:08 · Score: 0
  
  It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
  ....and the systemd developers won't rest until Linux behaves in the same manner!
9. Re:/etc/inittab by Anonymous Coward · 2014-09-08 00:27 · Score: 0
  
  I shouldn't feed the troll, but I also want to point out that the rc.d/init.d and freebsd script *were* the same before systemd.
  And now everything is at least more manageable and trackable thanks to containers -- which no one used for this before.
10. Re:/etc/inittab by jythie · 2014-09-08 01:08 · Score: 1
  
  It could be argued that such things are simply not the responsibility of the init system. I think that is where much of the complaints about systemd come from, the perception that it is taking the roles of other things and folding them into itself. Given how it has been expanding to include more and more services and has increased coupling, they kinda have a point. Many see systemd as solving problems that are philosophical in the first place as opposed to practical.
11. Re:/etc/inittab by Anonymous Coward · 2014-09-08 01:37 · Score: 0
  
  which no one used for this before
  ....for good reason!
12. Re:/etc/inittab by Anonymous Coward · 2014-09-08 01:42 · Score: 0
  
  What limitations? The world of UNIX and clones is rather successful. Our systems work just fine. This is just typical OSS disappearing up its own arse thanks to "sponsored" developers with an agenda.
13. Re:/etc/inittab by Anonymous Coward · 2014-09-08 01:56 · Score: 1
  
  It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
  And also, SysV init is not a pony. Which means it sucks, right?
  Seems like sysadmins have been trivially solving the things you're complaining about for decades now, with less effort than systemd currently requires from the sysadmin, and far less complexity.
  This systemd reminds me of grub vs lilo. Since everyone seems to have abandoned the simple and robust elegance of lilo (because it's impossibly hard to remember to run one cli command after a kernel recompile, apparently) for the bloated complexity of grub, I think history will repeat and systemd will win the day.
  The thing everyone complained about in lilo was actually already managed by package install scripts, of course, just like all the stuff that systemd supposedly manages was already well managed, but that won't stop the revolution.
14. Re:/etc/inittab by BadDreamer · 2014-09-08 02:23 · Score: 1
  
  It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
15. Re:/etc/inittab by Rich0 · 2014-09-08 02:43 · Score: 2
  
  It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
  What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
  If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
16. Re:/etc/inittab by MrKaos · 2014-09-08 03:01 · Score: 1
  
  you could try reading up on it. Here's a taster for you..
  
  I did. I've been using it - to give it a fair chance. I'm still struggling to understand if those benefits will manifest and why it's required.
  
  --
  My ism, it's full of beliefs.
17. Re:/etc/inittab by drinkypoo · 2014-09-08 03:34 · Score: 2
  
  systemd provides aggressive parallelization capabilities,
  which could be provided through some fairly simple tweaks to init scripts.
  
  uses socket and D-Bus activation for starting services
  We could do this before systemd.
  
  offers on-demand starting of daemons
  We could do this before systemd.
  
  keeps track of processes using Linux control groups
  We could do this before systemd.
  
  supports snapshotting and restoring of the system state
  What does that mean? We could hibernate and resume before. Do you mean, reboot and launch all the same daemons that are running?
  
  maintains mount and automount points
  We could do this before systemd.
  
  and implements an elaborate transactional dependency-based service control logic
  Oh good, elaborate. A simple system implemented with init script tweaks would do.
  
  It can work as a drop-in replacement for sysvinit
  We had several drop-in replacements for sysvinit before systemd.
  
  its probably getting rid of SCO stuff from Linux as well as its a Linux specific project
  Oh, you're just a troll. There's no SCO stuff in Linux. Further, SCO is (was) its own mutant Unix, with many of its own stupid daemons. Have you ever even run a SCO OS? Even seen one? No? Then please never mention SCO again unless you're making a reference to a lawsuit.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
18. Re:/etc/inittab by MrKaos · 2014-09-08 03:36 · Score: 1
  
  and rc.d it's so simple.
  It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
  Sounds like those issues are implementation based.
  
  and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and.
  Ok - well your talking about desktop stuff here, which is an interesting perspective that I didn't really consider, however I still think that is doable in inittab with much less effort. rc is only a runlevel solution, whereas inittab would be more relevant to desktop. I don't need to keep track of the process and it's children because init can maintain the parents state for me - if the parent isn't signalling it's children then we are back to implementation issues again.
  
  I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.
  jeeez. I'm just trying to figure it out. I'm not being a jerk about it, I'm trying to gauge other peoples experiences. I don't give a fuck about init if systemd is better - it's just another technology. But if it is better than shouldn't it be immediately apparent *WHY* it is better?
  
  --
  My ism, it's full of beliefs.
19. Re:/etc/inittab by phantomfive · 2014-09-08 04:24 · Score: 1
  
  the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
  This problem was solved over a decade ago by DJB's daemontools.
  
  --
  "First they came for the slanderers and i said nothing."
20. Re:/etc/inittab by MrKaos · 2014-09-08 04:26 · Score: 1
  
  It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
  Sorry friend, I read your link but it's immediately apparent that this guy hasn't even read the inittab manual. The answer to many of the statements made in that blog are answered in the subject line of this post. Others are implementation issues with the application.
  He may have a point with parallelism in the boot sequence, but I only care about boot speed if I am on a desktop - in which case I can just re-write how rc starts things. On a server rc's runlevel and service ordering K and S answer the question of service dependencies in a much easier and *transparent* way. And why are dependencies such a big deal - the application should be able to cope with a required service missing in an intelligent way. And if the dependency doesn't start it has a problem that systemd or init can't handle, so I'm back to wondering what systemd is actually doing for me.
  Please don't see this as me defending init. I am trying to see what the justification is in choosing to run systemd with my servers - which I am trialling. I'm finding the unnecessary complexity of systemd can put me in a bad situation when I am trying to control the uptime of commercial services.
  If you just want the system to boot faster - you can already achieve that with rc tweaks and implementing your service startup better instead of hacking it. The way I see it with systemd I now have three problems to deal with instead of one. 1. I still have crappy start-up implementations for services. 2. I have to now manage systemd's characteristics (obviously init isn't perfect) 3. When I have downtime I have to manage 1&2 at the worst time. Frankly operating init is so much faster and more transparent than systemd.
  I see no tangible benefit for the expenditure of effort I've sincerely made, so far and I'm still wondering if there is a compelling reason. I'd rather have a discussion based on merit of the two systems, however what is compelling is that many people haven't used init to it's full capacity.
  
  --
  My ism, it's full of beliefs.
21. Re:/etc/inittab by BadDreamer · 2014-09-08 04:36 · Score: 1
  
  I do not want parallelization; I hardly ever reboot my desktop/laptop systems, and on servers it makes no difference since the main time is spent waiting for IO to configure itself.
  I do not want socket and/or D-Bus to start the few services I need started. I see no point to that. And I most definitely do not want on-demand starting of daemons! That removes determinism from my system and will make bug hunting a chore.
  Ok, I want processes managed using control groups. But not by init. I want a daemon not connected to init to do that.
  I am completely unmoved by the "system state" snapshot talk, since if I wanted that I'd be on Xen or VMware. I don't have use for that.
  I have fstab for my mount points, and the only automount I do is the occasional USB stick which mounts from a specific user, using a simple script.
  I absolutely DO NOT need an "elaborate ... logic" for ANYTHING related to init!
  So far I have seen no reason to read any more about this, nor any reason why I'd want it anywhere near any of my systems.
22. Re:/etc/inittab by BadDreamer · 2014-09-08 04:44 · Score: 1
  
  Any daemon manager solves the problems you listed. And the whole point of having an init that basically does nothing is - that init does basically nothing. That is what it is SUPPOSED to do, hand over to other processes.
  And I do not want my daemon manager to do "all the stuff". I want it to obey my commands on starting and stopping daemons. Period. You may want yours to do more, and then you can use another daemon manager. That's what's called the UNIXy way. Ever hear of it?
23. Re:/etc/inittab by MrKaos · 2014-09-08 04:44 · Score: 1
  
  It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
  What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
  I spawn services from init. It works very well, on, off, once, respawn. It's very fast when it restarts a service and if a service flaps then it won't expend all of CPU restarting, it will just wait before attempting to restart the service and scream loudly in the meantime. I don't wonder if it is working because init is so responsive.
  Perhaps it's just easy for people to write bad init.d scripts and everything 'kinda' works?
  
  If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
  I've tried to make init crash in tests - it's very difficult. As a daemon manager, init works well.
  
  --
  My ism, it's full of beliefs.
24. Re:/etc/inittab by Anonymous Coward · 2014-09-08 05:32 · Score: 0
  
  Yep, and I trust his code a lot more than Poettering's...
25. Re:/etc/inittab by Rich0 · 2014-09-08 05:37 · Score: 1
  
  It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.
  What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
  I spawn services from init. It works very well, on, off, once, respawn. It's very fast when it restarts a service and if a service flaps then it won't expend all of CPU restarting, it will just wait before attempting to restart the service and scream loudly in the meantime. I don't wonder if it is working because init is so responsive.
  Perhaps it's just easy for people to write bad init.d scripts and everything 'kinda' works?
  The problems with this approach are outlined in the post above. It isn't easy for you to stop that service, and init can't guarantee that it gets everything even if you do set up multiple runlevels and use telinit (and in this configuration you don't have per-daemon control either). There is nothing like cgroup support. You are correct that init will respawn things if they die - I've done this myself back in the day. You also lose all console output as well, unless you stick some kind of a wrapper around your service.
  
  If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
  I've tried to make init crash in tests - it's very difficult. As a daemon manager, init works well.
  Sure, crashing init is very hard - it doesn't really do anything, and that is the whole point. Systemd is rather hard to crash as well. I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
  If you're happy with sysvinit, it isn't like the code is going to magically disappear. It hasn't changed in ages, and I'm sure it will still work on linux-4.5.0.
26. Re:/etc/inittab by rb12345 · 2014-09-08 07:22 · Score: 1
  
  It's still possible in daemontools to run a shell script wrapper from /etc/service/foo/run around some real server in Java/Erlang/whatever. Stopping the service with "svc -d /etc/service/foo" will then entirely fail to kill the server process. I would imagine that the systemd's cgroup suport would avoid this happening.
27. Re:/etc/inittab by CaptnZilog · 2014-09-08 08:19 · Score: 2
  
  It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... for a nice overview of all the limitations of SysV init, the most important being that it doesn't actually keep track of what services are running and what processes belong to what services.
  It's not supposed to - a *properly* written service would/could/should keep track of it's own processes, that isn't something init was ever supposed to do (be the 'micro-manager' of everything). If run the rc script to stop a service, and it doesn't stop all the associated processes, that is *NOT* a "problem with init", that is a problem of a poorly written/debugged service, and the code for the service should be fixed - not a whole new massively complex init system to "handle" it (or, in simpler terms, to continue to allow the people writing services to write shitty code because now "systemd will handle it").
28. Re:/etc/inittab by CaptnZilog · 2014-09-08 08:22 · Score: 1
  
  What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
  If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
  Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
29. Re:/etc/inittab by CaptnZilog · 2014-09-08 08:25 · Score: 1
  
  It could be argued that such things are simply not the responsibility of the init system. I think that is where much of the complaints about systemd come from, the perception that it is taking the roles of other things and folding them into itself. Given how it has been expanding to include more and more services and has increased coupling, they kinda have a point. Many see systemd as solving problems that are philosophical in the first place as opposed to practical.
  "One ring to rule them all."
30. Re:/etc/inittab by CaptnZilog · 2014-09-08 08:30 · Score: 1
  
  and rc.d it's so simple.
  It's so simple that half of the init scripts in FreeBSD are half unusable, do not check for stale pids, fail to correctly bring down the services....
  Sounds like those issues are implementation based.
  Yeah, sounds like some work needs to be done fixing the init scripts rather than writing a whole new init system to allow people to keep writing crappy scripts?
  
  and none of the rc.d scripts use containers, so resource management is impossible, because all of the daemons fork() and you lose track of the process and its children, and we have 3-4 daemons trying to manage suspend/resume features per each distribution, while the desktop managers try to override that, and.
  Ok - well your talking about desktop stuff here, which is an interesting perspective that I didn't really consider, however I still think that is doable in inittab with much less effort. rc is only a runlevel solution, whereas inittab would be more relevant to desktop. I don't need to keep track of the process and it's children because init can maintain the parents state for me - if the parent isn't signalling it's children then we are back to implementation issues again.
  Yup, instead of tackling the real problem - poorly written services - their "solution" is to try to write a new init system to allow crappily written services to be tracked/"controlled", ignoring the fact that the crappy modular services should be rewritten.
  
  I don't care if you don't like systemd, but saying that the rc.d systemd is simple, and implying that there is no problem whatsoever, is closing your eyes and ears while chanting LALALALALA like a kid.
  jeeez. I'm just trying to figure it out. I'm not being a jerk about it, I'm trying to gauge other peoples experiences. I don't give a fuck about init if systemd is better - it's just another technology. But if it is better than shouldn't it be immediately apparent *WHY* it is better?
  Yeah, and I don't see as it "fixes" anything other than adding a lot more complexity to "fix" things that it shouldn't have anything to do with.
31. Re:/etc/inittab by Kabukiwookie · 2014-09-08 09:17 · Score: 1
  
  I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
  If you like buggy, monolithic services, why don't you just run a Windows server instead of infecting Linux. I am getting more and more the feeling that systemd is being pushed to kill of Linux.
  
  --
  The mountains of madness have many little plateaus of sanity - Terry Pratchett.
32. Re:/etc/inittab by sjames · 2014-09-08 10:19 · Score: 1
  
  I would, but they don't answer any of my questions. For example, why must it be PID 1 to do those things? Why cant the service managers be in the form of optional helpers for the init scripts?
  And others like Why do you keep re-inventing the wheel and then welding your 'solution' in place? Shouldn't it be up to the user if they like your solution or someone else's better?
33. Re:/etc/inittab by phantomfive · 2014-09-08 12:52 · Score: 1
  
  You are probably right, but if the problem is, "there is a corner case in our tool that we need to solve," the answer isn't, "let's rewrite the whole thing with a giant monstrosity." The answer is, "let's fix the corner case."
  
  --
  "First they came for the slanderers and i said nothing."
34. Re:/etc/inittab by Rich0 · 2014-09-08 13:30 · Score: 1
  
  What daemon manager solves those problems? And what is the point of having an init that basically does nothing but spawn a daemon manager and a few gettys? Why not just move that code into the kernel (oh wait, it is already there - it launches init)?
  If your daemon manager really did do all the stuff you want it to do, and it dies, then the effects would be about the same as init crashing anyway.
  Indeed. When, pray tell, was the last time init crashed on you? 28yrs of unix sysadmin, I can't recall one.
  It never has crashed for me. What is your point?
  The argument was that init isn't supposed to be a daemon manager, since there are other daemon managers out there. I pointed out that those have problems too, and isolating that code from init doesn't really bring any benefits. If init dies your webserver goes down. If the daemon manager crashes and kills your webserver, your webserver goes down, but init will happily continue to run and do nothing like it usually does, except maybe wait for any exit codes so that the crashed processes don't become zombies.
  And, I've yet to see systemd crash either, but as I already said I'm more than willing to agree that this seems more likely than sysvinit crashing.
  The simplicity of sysvinit basically limits its usefulness, and once you start talking about using other processes to make up for its shortcomings, you lose all the benefits of your simple sysvinit whether that other process runs as PID 1 or not.
35. Re:/etc/inittab by Rich0 · 2014-09-08 13:35 · Score: 1
  
  I would agree that it is much more complex, and therefore much more vulnerable to bugs, but that is the price of actually having an init that does things.
  If you like buggy, monolithic services, why don't you just run a Windows server instead of infecting Linux. I am getting more and more the feeling that systemd is being pushed to kill of Linux.
  What is monolithic about systemd? It is a grouping of programs that can be run together or in isolation, with each one doing one thing well. In the case of systemd itself it executes processes and supervises them, which is more-or-less what init does via inittab except that systemd gives you a lot more control over how processes are run, is far easier to control/configure, and cleans up after itself.
  And nobody is infecting your linux. Don't install systemd on your machine, and it will work exactly the way it does today, forever. I'm sure whoever you're paying to keep your system up-to-date can keep it working without installing systemd.
36. Re:/etc/inittab by Barsteward · 2014-09-08 20:39 · Score: 1
  
  We have Unix before Linux so why not stick to Unix.
  All the "we had this before" arguments are pointless in an environment that moves on, "the old way" is always deemed the best is a nonsense argument. Should we still be riding horses to work, using steam trains, etc etc
  
  There is nothing to stop you going your own way if this kind of progress is an anathema to you, here's a site that might be interesting to you. http://www.linuxfromscratch.or...
  
  "System V Release 5 was developed in 1997 by the Santa Cruz Operation (SCO) as a merger of SCO OpenServer (an SVR3-derivative) and UnixWare, with a focus on large-scale servers" - thats from wikipedia as well. so the chances are there must be some code in SysV developed in the bowels of SCO which is GPL'd, and thats what i meant about getting rid of SCO code. And yes, i have worked on SCO servers albeit in the late 90's and early 2000s, we supported over 700 in remote sites, we tried pushing Linux as a replacement but the corporations were having none of it.
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
37. Re:/etc/inittab by Barsteward · 2014-09-08 20:40 · Score: 1
  
  Thats your choice, don't use it.
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
38. Re:/etc/inittab by Barsteward · 2014-09-08 20:41 · Score: 1
  
  I've no idea, why not email them directly as see if you can get an answer. I'm sure a lot of people would like to know the answer
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
39. Re:/etc/inittab by Barsteward · 2014-09-08 20:43 · Score: 1
  
  to be honest, i don;t care which system is on my desktop as long as it works and it gets better and faster. i'm long passed fiddling with system scripts, i just write scripts for personal things like backups etc
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
40. Re:/etc/inittab by Barsteward · 2014-09-08 20:46 · Score: 1
  
  He says freedesktop.org is just a repository for code and documentation, i can't find your reference
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
41. Re:/etc/inittab by Anonymous Coward · 2014-09-08 21:16 · Score: 0
  
  The corner case might actually be a systemic problem. I didn't particularly like systemd in the beginning either, but the more I learn and see the more appealing it becomes.
  Make no mistake, though, regardless of how you feel about systemd today, you will end up using it, no matter how much you complain and flail about it along the way.
  You would probably do yourself a favor if you just buckled up, got educated about systemd, and moved on.
  Then again, you might prefer to continue complaining about something that's inevitable.
  Your choice.
42. Re:/etc/inittab by drinkypoo · 2014-09-08 22:02 · Score: 1
  
  We have Unix before Linux so why not stick to Unix.
  All the "we had this before" arguments are pointless in an environment that moves on, "the old way" is always deemed the best is a nonsense argument.
  
  That's not the argument. You do not understand the Unix way. It is not the old way. It is the simple way, combining small and flexible tools to achieve complex results easily and with minimal component maintenance. I should not have to explain this to you.
  
  There is nothing to stop you going your own way if this kind of progress is an anathema to you
  It's not progress. It's regression. There were complex systems with monolithic services before Unix. Unix represents a better, newer way to write software. It's not the old way. It's the new way.
  
  so the chances are there must be some code in SysV developed in the bowels of SCO which is GPL'd, and thats what i meant about getting rid of SCO code.
  What, from SCO? Because the courts have solidly and conclusively disagreed with you. There is no code belonging to SCO in Linux, in spite of their many deceptive attempts to claim otherwise. The court was not deceived, but you were. That's pretty pathetic, because courts are tragically easy to deceive. Apparently, you are even easier.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
43. Re:/etc/inittab by BadDreamer · 2014-09-08 22:17 · Score: 2
  
  I don't. And that means a whole range of software does not run on my system.
  Which is the opposite of any UNIX way ever.
44. Re:/etc/inittab by Barsteward · 2014-09-09 01:56 · Score: 1
  
  What no longer runs?
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
45. Re:/etc/inittab by Barsteward · 2014-09-09 02:10 · Score: 1
  
  "It is not the old way. It is the simple way, combining small and flexible tools to achieve complex results easily and with minimal component maintenance. I should not have to explain this to you." - I do understand the Unix way but from what i see Linux is evolving into its own way. You can stick to the old Unix way on your own servers/desktops and fork linux accordingly if the new way doesn't suit you.
  
  "It's not progress. It's regression. " - and thats your opinion
  
  good grief, your misunderstanding of what i'm saying knows no bounds. Can you categorically prove to anyone that no-one at SCO ever contributed code to SYSV? I'm not arguing ownership of the code, just that SCO developers contributed code under GPL to SYSV development.
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
46. Re:/etc/inittab by BadDreamer · 2014-09-09 02:26 · Score: 1
  
  Gnome for one. And many software packages are now delivered with a hard dependency on parts of systemd, meaning I'd need to compile them myself if I do not want to use systemd.
  It's a cancer, eating away at the very core of Linux - choice and diversity. Yes, Poettering wants a monoculture, and any sane computer user should run as far away from that concept as possible. Any vulnerability will reach every system in a monoculture. Only the way the developers at the top deign to consider will get included in the choices available.
  If that is the future you want, you can have it. I'll have no part in it. And yes, I will say "told you so" when the systemd infested infrastructure gets pwnd.
47. Re:/etc/inittab by phantomfive · 2014-09-09 04:50 · Score: 1
  
  The corner case might actually be a systemic problem.
  It's not.
  
  Make no mistake, though, regardless of how you feel about systemd today, you will end up using it, no matter how much you complain and flail about it along the way.
  Nope. There are open source distros in this world that are still run by competent people.
  
  --
  "First they came for the slanderers and i said nothing."
48. Re:/etc/inittab by badkarmadayaccount · 2014-09-10 03:47 · Score: 1
  
  Run Gentoo and STFU. Debian lobotomized systemd pretty good if you can take a compromise, look at the Technical Comitee findings, mentioned elsewhere.
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
49. Re:/etc/inittab by badkarmadayaccount · 2014-09-10 03:49 · Score: 1
  
  Why do you think all of systemds' functionality is in one process or binary? The damn thing spawns like Postfix, as it should, you can compile it without a lot of crap, see Debian.
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
50. Re:/etc/inittab by sjames · 2014-09-10 03:57 · Score: 1
  
  I don't. I do note that it insists on occupying PID 1 though. Are you claiming it will be OK if I run regular old init and spawn systemd from there?
51. Re:/etc/inittab by badkarmadayaccount · 2014-09-10 06:31 · Score: 1
  
  Standard init scripts across distributions and cgroups are something you want on a server, and relying on intelligent handling of missing dependencies is inadvisable IMHO.
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
52. Re:/etc/inittab by badkarmadayaccount · 2014-09-10 06:34 · Score: 1
  
  Cgroups wouldn''t work, unless you containerise the systemd process tree, in which case what do you gain?
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
53. Re:/etc/inittab by sjames · 2014-09-10 08:28 · Score: 1
  
  Cgroups work just fine. Currently, they work for any pid at all through /sys/fs/cgroups (you must mount it first) so long as the standard permissions on the pseudo-files allow it..
  There is talk of limiting that to a particular pid and having it act as a service on dbus, but even then, that PID need not be 1.
What? by TranceThrust · 2014-09-07 22:17 · Score: 1

``Through a Google Summer of Code project this year was work to emulate systemd on OpenBSD.''
What?
``so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls.''
What?
``systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities''
The `d' at the end of each of those stands for `utilities'?
Seriously, please do some editing before posing.
1. Re:What? by prsephton · 2014-09-07 22:27 · Score: 2
  
  Seriously, please do some editing before posing.
  That just has to be a Freudian slip
2. Re:What? by jeremyp · 2014-09-07 22:28 · Score: 1
  
  But also,
  
  so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls
  A d too many.
  
  --
  All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
3. Re:What? by Zembar · 2014-09-07 22:28 · Score: 1
  
  Seriously, please do some editing before posing.
  Posing for what?
4. Re:What? by Barsteward · 2014-09-07 22:31 · Score: 1
  
  is that "posing" or "posting"? :o)
  
  --
  "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
5. Re:What? by Nikademus · 2014-09-07 22:46 · Score: 0
  
  What?
  ``systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities''
  The `d' at the end of each of those stands for `utilities'?
  Seriously, please do some editing before posing.
  Of course, because systemd will just redefine everything. Before systemd, d was for daemon, with systemd, d now means utility. Isn't life that much better with systemd?
  systemd: a poorly designed complex solution to problem which doesn't exist...
  
  --
  I gave up with the idea of an useful sig...
6. Re:What? by Anonymous Coward · 2014-09-07 22:48 · Score: 0
  
  Seriously, do your edicting before prosing.
7. Re:What? by TranceThrust · 2014-09-08 00:39 · Score: 1
  
  Hehe, quite possibly!
How about then backporting from BSD to Linux? by Anonymous Coward · 2014-09-07 22:45 · Score: 5, Insightful

If BSD's emulation of those Linux systemd APIs is done in a reasonably portable manner, we could then backport the code over to Linux and gain the benefits without being dependent for those functions on the engineering disaster that Lennart has put into process slot 1.
The BSD folks aren't succumbing to systemd's problematic "kitchen sink in slot 1" approach, so their work could be valuable for those Linux distros that are fighting to keep systemd out of their hair.
1. Re:How about then backporting from BSD to Linux? by andydread · 2014-09-08 00:34 · Score: 2
  
  THis a THOUSAND times.
2. Re:How about then backporting from BSD to Linux? by Peter+H.S. · 2014-09-08 03:31 · Score: 1
  
  It isn't trivial to port to Linux, since the executables are just wrappers that translate into OpenBSD calls. The only part that matters in this GsOC project is "logind", and it doesn't work yet, and it is very unlikely that it will ever be a drop in replacement for the real "logind" (Cgroups support, kernel IPC and all that).
  Anyway, if you don't want systemd, then cloning it is the worst possible strategic move to make. What upstream projects like Gnome and KDE have asked for, for years, is an alternative API and program to "logind", not a cloning attempt that pretends to be "systemd" while not supporting systemd features.
  I mean, just maintaining a fork of ConsoleKit, would resolve 90% of all short term problems for upstream projects in supporting non-systemd platforms, and many long term problems too.
3. Re:How about then backporting from BSD to Linux? by Dcnjoe60 · 2014-09-08 03:44 · Score: 1
  
  If BSD's emulation of those Linux systemd APIs is done in a reasonably portable manner, we could then backport the code over to Linux and gain the benefits without being dependent for those functions on the engineering disaster that Lennart has put into process slot 1.
  The BSD folks aren't succumbing to systemd's problematic "kitchen sink in slot 1" approach, so their work could be valuable for those Linux distros that are fighting to keep systemd out of their hair.
  The BSD "emulation" is a translation layer from linux kernel calls built into various parts of systemd to BSD kernel calls. If you are already running on a linux kernel, what would be the point of a translation layer. It would be like running Wine under Windows.
  It seems that the BSD developers are looking at just using the pieces that they think their incarnation of BSD needs. There is nothing to stop a linux distro from doing the same thing. Many already do by adding logind for Gnome while still using upstart or the old init system.
WHY? by ald_a · 2014-09-07 22:47 · Score: 1

Apart from all the useful stuff that one can do, why waste your time on this?
I gues this Poettring lad is aiming for the total world domination eh?
Maybe I should post a project next year to kill this systemd crap, donations are welcome :)
1. Re:WHY? by Anonymous Coward · 2014-09-07 23:05 · Score: 0
  
  Please do that!
2. Re:WHY? by Anonymous Coward · 2014-09-08 06:39 · Score: 0
  
  Apart from all the useful stuff that one can do, why waste your time on this?
  I gues this Poettring lad is aiming for the total world domination eh?
  Maybe I should post a project next year to kill this systemd crap, donations are welcome :)
  Not quite. Lennart has maintained that systemd would be a Linux-only development, in his view. That comment can be found somewhere on his web site. He has also maintained that others would have to port systemd from Linux to whatever OS they wanted; also a comment buried somewhere on his web site.
Huh? by Anonymous Coward · 2014-09-07 23:17 · Score: 2, Informative

because Desktop Environments DO interact with the lower systems.
They need access to the DRM and input device, they need access to things like reboot/shutdown/hibernate.
If I understand it correctly one goal of logind is to run the X-server and the Desktop Environment without root, so they cannot do this directly... they use the logind API for it.
That guy just wasted his time by water-and-sewer · 2014-09-07 23:17 · Score: 0

It was probably, intellectually, an interesting and challenging project. But that guy has just wasted his summer - and his code - building something no one actually wants. Have a look here - http://pipedot.org/story/2014-... where there's reporting about a growing systemd boycott taking place.
People don't like or want systemd and are increasingly organizing to avoid it. Non systemd distros - gentoo, slackware - plus FreeBSD, where I'll be migrating my home computer tonight after work - are starting to look pretty darned good to people again.
It's true there is a need for something more dynamic and responsive than the old init script system, but systemd is not it.

--
If this were Usenet, I'd killfile the lot of you.
1. Re:That guy just wasted his time by Peter+H.S. · 2014-09-08 03:48 · Score: 1
  
  Both Gentoo and Slackware support systemd, and at least Slackware is likely to change to systemd in the future. Patrick Volkerding is holding the conversion back in the hope that some alternative may appear. But at the moment there is almost zero Linux development outside systemd, so at some point they will change to systemd in order to get e.g. Wayland support etc.
2. Re:That guy just wasted his time by volkerdi · 2014-09-08 06:13 · Score: 2
  
  By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.
  I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.
3. Re:That guy just wasted his time by Peter+H.S. · 2014-09-08 06:46 · Score: 1
  
  By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.
  I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.
  Some Slackers have been working on making systemd work on Slackware. It is not official supported packages, but what is on Slackware.
  Patrick V. have clearly been expressing that he doesn't have a suicide pact with Slackware's init system, so he hasn't rejected shifting to systemd. Slackware is a tiny distro with few developers, it is totally unable to sustain itself when the rest of the Linux community have shifted to systemd. It is already clear, that without systemd there won't be any Wayland support, nor secure root-less X.org and more and more upstream projects are dropping e.g. ConsoleKit support.
  There seem to be no coordinated non-systemd development at the moment, so at one point in the future, Patrick will have to choose between an ever decaying distro or systemd.
  I am not in doubt that he will choose systemd, it is only software after all.
4. Re:That guy just wasted his time by Peter+H.S. · 2014-09-08 07:00 · Score: 1
  
  Whoosh! /blush/
  Excuse me Mr. Volkerding, didn't notice your user name. Cheers. Slackware on floppies was my first real distro, so I have a soft spot for Slackware (but not for floppies as a distro media :-).
  While I may not agree with some of your decisions on how to make a Linux distro, I respect your work very much. I think you are a smart guy, so I find it unavoidable that Slackware will change to systemd at some time in the future. Not perhaps as a first choice, but as a necessity, simply because no other real alternative seems to exist. Maybe some non-systemd community will emerge to make it possible for non-systemd Linux distros to survive on the long run, but it doesn't look like it at the moment.
5. Re:That guy just wasted his time by Anonymous Coward · 2014-09-08 07:34 · Score: 0
  
  Do you realize what user you are replying to right?
6. Re:That guy just wasted his time by Anonymous Coward · 2014-09-08 08:10 · Score: 0
  
  This is a shim to support applications that may require Systemd, it is not a BSD implementation of such. Plenty of folks at the start of these comments have said the same thing and for some strange reason you failed to read their comments before posting.
They would have had an easier time... by Anonymous Coward · 2014-09-07 23:25 · Score: 0

...trying to sell Microsoft on systemd than trying to sell Theo DeRaadt on systemd. And that's before you take licensing issues into account. :p
Why Not? by Anna+Merikin · 2014-09-08 00:26 · Score: 3, Interesting

Mebbe this will motivate some distro to do a similar; I, for one, would go for a distro without systemd nor Gnome, which I never use. Gnome is expendible. For those who like Gnome, why not do it this way?
1. Re:Why Not? by present_arms · 2014-09-08 00:29 · Score: 2
  
  PCBSD, Slack, Gentoo and pclinuxos are systemd free :D pclinuxos user here
  
  --
  http://chimpbox.us
2. Re:Why Not? by Dcnjoe60 · 2014-09-08 03:18 · Score: 2
  
  Mebbe this will motivate some distro to do a similar; I, for one, would go for a distro without systemd nor Gnome, which I never use. Gnome is expendible. For those who like Gnome, why not do it this way?
  There is no need on linux to a translation to system calls. Being built on the linux kernel it just makes the system calls it needs. As for Gnome requiring systemd, it doesn't. It uses logind which is just one part of it. People keep implying that systemd is this huge monolithic init system. It isn't. It is made up of numerous individual daemons that you are free to include or not. For instance, you can use all of your current init scripts or upstart and just include logind if you want to use gnome-shell.
  Just like distro's compile the kernel with what features they want to include or not, the same is true with systemd.
3. Re:Why Not? by fnj · 2014-09-08 03:35 · Score: 2
  
  PC-BSD is of course not a linux distro at all. It is FreeBSD plus some desktop GUI oriented packaging.
  Gentoo pulls in systemd if you run Gnome.
  So if you're right about the others, that leaves 2 linux distros out of how many hundred that are systemd free - FOR NOW. Enjoy the head in the sand approach while you still can. Linux has already been ruined. The revolution got subverted and pwned by the enemy. Systemd has conceptually a very real point. Where it goes off the rails is in being architecturally such a gigantic monolithic shitball, and subsuming all those other d's into its fat belly. There is absolutely no legitimate reason whatsoever to do so. It's a power play plain and simple.
4. Re:Why Not? by sjames · 2014-09-08 09:02 · Score: 1
  
  That was my first thought. Port it back to Linux so we can go back to regular old init.
5. Re:Why Not? by gweihir · 2014-09-08 11:04 · Score: 2
  
  I agree. There is no sane reason to do something this stupid engineering-wise, except a power-play.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
6. Re:Why Not? by gweihir · 2014-09-08 11:05 · Score: 1
  
  Good idea.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
7. Re:Why Not? by Anonymous Coward · 2014-09-09 01:04 · Score: 0
  
  Yes, there would be need for translation of syscalls. There are whole areas of crap I don't want enabled in my kernel, especially cgroups.
  I guess it remains to be seen how lightweight this shim would be compared with some other intended-for-Linux systemd shims are under development.
Cool project by BlackPignouf · 2014-09-08 01:06 · Score: 1

On the one hand, it sounds like a cool project.
On the other hand, if they don't port it, they'll get the benefit of having neither Gnome 3 nor Systemd on BSD.
1. Re:Cool project by wed128 · 2014-09-08 08:33 · Score: 1
  
  Port it to what? I'm not sure you understand the article.
Just because you can... by Anonymous Coward · 2014-09-08 01:36 · Score: 0

... doesn't mean you should.
Needed by who? by Anonymous Coward · 2014-09-08 01:48 · Score: 1

Wait, who actually needs to do those things?
And if the services do not depend on systemd, why are they part of the package?
Sounds like a made-up scenario and some bad packaging. Not a real-world need.
Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.
1. Re:Needed by who? by ThePhilips · 2014-09-08 02:31 · Score: 2
  
  Wait, who actually needs to do those things?
  Desktop applications.
  For example, you change time zone or locale in system settings and your organizer app automatically picks up the changes.
  
  And if the services do not depend on systemd, why are they part of the package?
  Pottering is maintainer of all of them. So he brought it under the systemd umbrella.
  
  Sounds like a made-up scenario and some bad packaging. Not a real-world need.
  Applications "need" the services. They do not care who provides the services. As was said many times, the daemons - with few irrelevant changes to the source code to remove hardcoded systemd depedency - run fine without systemd.
  
  Certainly fits the systemd reputation for taking over already-solved problems without any reason, though.
  Yes.
  Pottering also enjoys the confusion he has seeded with the organization of the systemd. He claims simultaneously (depending on the context; and to his advantage) that systemd is modular and monolithic. While in fact systemd has monolithic architecture and modular design. Pretty much the worst combination possible - prominently featured in the MSWindows, why comparison with Windows is highly relevant. (Ideally you want modular architecture, while design could be either monolithic (e.g. Linux kernel, optimized for performance) or modular (e.g. GIMP with the tons of the plug-ins, geared toward extensibility). But monolithic architecture is pretty much the worst thing you could ever do to a software project.)
  
  --
  All hope abandon ye who enter here.
Troubleshoot log reader by tepples · 2014-09-08 01:52 · Score: 1

As long as you have widely supported, stable, widely available tools for reading them-- who cares?
The answer to that question depends on what tool you would consider using to troubleshoot the "widely supported, stable, widely available tools for reading them".
Engineering for reliability, not philosophy by Anonymous Coward · 2014-09-08 01:57 · Score: 1

I'll just add to the other person's good reply that many of us are concerned not with maintaining Unix philosophy, but with maintaining the reliability that makes Unix such a good workhorse. That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1. (All the change happens elsewhere.)
For decades it has been the case that almost anything in a Unix system can die and can be restarted without the whole kaboodle collapsing, as long as the fault doesn't involve process 1. And because init has been so tiny and simple and unchanging, process 1 has been absolutely rock stable. All Unix-type operating systems have benefited enormously from this.
Systemd turns all that on its head and puts the kitchen sink in slot 1, a kitchen sink that is continuously undergoing change because so many complex subsystems have been built into it. It's not possible for it to reach stability even in principle, because the code for its complex functionality will necessarily have to evolve to keep abreast of security issues as well as the inevitable feature creep. There's no getting away from it.
And there's no getting away from the fact that large code size means bugs, and evolving code means unstable process 1, and unstable process 1 means unstable system. And as if that weren't enough, large complex code also means large attack surface. These are completely normal engineering considerations and tradeoffs that affect all systems, and systemd has lost sight of them.
In summary, among many of us with engineering backgrounds, the systemd debate is not about features nor boot speed nor certain developer's personalities, nor is it about Unix philosphy. It is however about preserving the key engineering element that gives Unix operating systems their high reliability, namely a KISS process 1. It's engineering vandalism to do otherwise.
1. Re:Engineering for reliability, not philosophy by Eunuchswear · 2014-09-08 02:25 · Score: 1
  
  Systemd turns all that on its head and puts the kitchen sink in slot 1, a kitchen sink that is continuously undergoing change because so many complex subsystems have been built into it. It's not possible for it to reach stability even in principle, because the code for its complex functionality will necessarily have to evolve to keep abreast of security issues as well as the inevitable feature creep. There's no getting away from it.
  Just how big do you think systemd is? How big is init?
  
  --
  Watch this Heartland Institute video
2. Re:Engineering for reliability, not philosophy by LordLimecat · 2014-09-08 03:17 · Score: 1
  
  That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1.
  I will be clear that I am not a seasoned linux sysadmin; I know bits of Linux, I can manage a small installation, but Im definately not an expert. Im also not a seasoned programmer; I understand programming.
  However I have had experience with a lot of badly written services on Linux where I've had to decipher the init scripts, or figure out why "service XX stop" doesnt actually stop the service, whatever stdout might claim.
  It seems to me that the approach you are advocating works really well in a world where badly written services simply die out due to people rejecting them; in reality you have badly written services all over the place that get screwed up all the time. Your philosophy could be extended to say "we'll also have the kernel just manage cpu, disk, and memory, and leave handling the filesystem up to individual programs." Which works, as an engineering principle, but in the real world you will end up with filesystem corruption on a daily basis because you are causing the entire system to have a net increase in complexity.
  From what Im gathering, systemd increases the base system complexity, but will (over time) ensure that those complex bits are stable (much like building FS support into the kernel). On the upside, it allows all of that complexity to be removed from all of the million other packages where 'building a stable init script" may have been priority 99 out of 100, and now they simply dont have to worry about that.
3. Re:Engineering for reliability, not philosophy by CaptnZilog · 2014-09-08 07:58 · Score: 1
  
  That reliability stems directly from the lack of bugs, lack of change, lack of dependencies, and lack of large attack surface in the traditionally tiny init process that lives in process 1.
  I will be clear that I am not a seasoned linux sysadmin; I know bits of Linux, I can manage a small installation, but Im definately not an expert. Im also not a seasoned programmer; I understand programming.
  However I have had experience with a lot of badly written services on Linux where I've had to decipher the init scripts, or figure out why "service XX stop" doesnt actually stop the service, whatever stdout might claim.
  It seems to me that the approach you are advocating works really well in a world where badly written services simply die out due to people rejecting them; in reality you have badly written services all over the place that get screwed up all the time. Your philosophy could be extended to say "we'll also have the kernel just manage cpu, disk, and memory, and leave handling the filesystem up to individual programs." Which works, as an engineering principle, but in the real world you will end up with filesystem corruption on a daily basis because you are causing the entire system to have a net increase in complexity.
  From what Im gathering, systemd increases the base system complexity, but will (over time) ensure that those complex bits are stable (much like building FS support into the kernel). On the upside, it allows all of that complexity to be removed from all of the million other packages where 'building a stable init script" may have been priority 99 out of 100, and now they simply dont have to worry about that.
  I see, so you are blaming the current minimalistic init process, that hasn't had any known/major bugs for decades really, for "badly written services all over the place"? Wouldn't that, instead, be something to push more for "better written services" about, rather than increasing the complexity of the init process?
  Yes, as an *experienced* sysadmin (28yrs of Unix, from Edition7/earlyBSD to Linux/SysV, on everything from "big iron" to PC servers) I've seen poorly written start/stop scripts that don't do what they should, don't handle 'failure to stop' properly, etc. I've almost always been able to deal with it manually, in the rare cases it happened (HPOV was one of the worst, randomly left stuff running) I could fix it manually w/o a reboot, and if needed I could fix the script fairly easily (or submit a bug report to the vendor - even though they rarely fixed things like that very promptly). I certainly didn't blame the fact that some programs rc script was poorly written, or its processes were poorly written pieces of crap, on the init process. Under *any* Unix derivative I've worked on, well written services rarely needed a restart in the first place.
  If the battery in your car dies, do you also launch an engineering team to redesign an entirely new car powered by a suitcase sized nuclear reactor, with all the increased danger that could involve if the 'unforeseen' happens, or do you just replace the faulty battery?
4. Re:Engineering for reliability, not philosophy by LordLimecat · 2014-09-08 15:08 · Score: 1
  
  If the battery in your car dies, do you also launch an engineering team to redesign an entirely new car powered by a suitcase sized nuclear reactor
  No, but if the battery in my car keeps dying I as a car manufacturer may want to reexamine whether theres something we can do on our end, whether or not part of the issue is that everyone makes crappy batteries.
  See, the goal isnt to pin blame. Its to solve problems and provide a working product.
flame by Anonymous Coward · 2014-09-08 02:15 · Score: 0

Couldn't they use their time more effectively making sure Windows viruses run on non-Windows platforms? At least someone, the virus writer, gets benefit from that.
Implementing systemd APIs on OpenBSD benefits no one. Go back to sysvinit or openrc. I switched to Gentoo Linux, where I had a CHOICE to use openrc instead of systemd, and am very happy with it.
the stupid, it burns! by Anonymous Coward · 2014-09-08 03:10 · Score: 0

Xenix is still remains unpolluted. SUCK IT, heathens!
Why? by Anonymous Coward · 2014-09-08 04:08 · Score: 0

What possible good can come from this? What can it do that init.d cannot? Another example of "can" rather than "should".
boycott systemd! by Anonymous Coward · 2014-09-08 04:28 · Score: 0

All you need to read is here: http://boycottsystemd.org
Better use OS X than linux with these sh*t(pulseaudio and now systemd), or for the ones feeling adventurous go the *BSD way...
LOL Seriously? by strikethree · 2014-09-08 04:32 · Score: 1

Is it April first? Theo will NEVER allow that monstrosity in. ROFLMAO

--
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
In the church of GPL by Anonymous Coward · 2014-09-08 05:02 · Score: 0

Upstream systemd remains uninterested in supporting non-Linux

BSDs are surfs to be exploited and stolen from then left to pick from our scraps
SystemD as PID non-1 by Anonymous Coward · 2014-09-08 07:07 · Score: 0

Could systemD be run as something else than pid 1?
It seems it has some nice process tracking features which could be used even if we do not uproot simple and reliable script-based boot process (at least on servers).
b.
Re:Er? (automatic locale?) by shoor · 2014-09-08 07:56 · Score: 1

Hmmm, it sounds like what's needed is a daemon that queries location from a GPS system as well as time, and automatically adjusts timezone and whatever (would you want it to change language? Seems like that's more of a user thing, and something you only change when you change users). Of course, it would require the system be hooked up to a GPS system, otherwise do things the old-fashioned manual way. There could be an app that puts up a map where you click on the location I suppose, instead of fiddling with configuration files.
I'm an old time unix user (going back to 4.2 BSD days). I like the idea of text configuration files for everything. But I wouldn't mind a front end app that was easier to use than constantly having to look at man pages on the formats of everything. A sort of IDE for all the text based config files the way an IDE is a helper for the text code files of a programming language. (But NOT a binary that bypasses the text configs! Which is what systemd seems to be doing, if I've been reading this right.)

--
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
On the order of... by Anonymous Coward · 2014-09-08 10:28 · Score: 0

megabytes and kilobytes by comparison.
1. Re:On the order of... by Eunuchswear · 2014-09-08 20:46 · Score: 2
  
  For small numbers of megabytes, and tens of kilobytes
  in text size the systemd executable is about 1Mb and init about 30Kb. (systemd is bigger in reality as it uses more shared libraries.)
  Running sizes: init (Debian, amd64)
  john@cedric:~$ ps -lyp 1 S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD S 0 1 0 0 80 0 532 2089 ? ? 00:00:32 init
  And systemd:
  john@celtic:~$ ps -lyp 1 S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD S 0 1 0 0 80 0 3816 48691 ? ? 00:00:15 systemd
  Systemd's resident size is less than 8 times init's.
  (Fucking slashdot - why won't you get the spacing right)
  
  --
  Watch this Heartland Institute video
Shared Init+glibc changes. by Anonymous Coward · 2014-09-08 11:02 · Score: 0

Crashed it quite often for me back in the late '90s/early '00s, but other than that, it's been pretty solid.
Re:Er? (automatic locale?) by Dcnjoe60 · 2014-09-08 11:57 · Score: 1

A sort of IDE for all the text based config files the way an IDE is a helper for the text code files of a programming language. (But NOT a binary that bypasses the text configs! Which is what systemd seems to be doing, if I've been reading this right.)
But you use a binary, even now to view the text files. Whether you us cat or less or vi or some other editor/viewer, human beings cannot read text files from a log without having to use a binary. That is because what we call text files are merely representational of a text file. Like a binary, though, they are just zeros and ones until some program interprets them for us.
Why is systemd bad? by kbahey · 2014-09-08 15:21 · Score: 1

Why is systemd bad?
The issues posed by adopting systemd to various distros are listed on the site: Boycott systemd.
Spread it around so people know ...
Mod this up!

--
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
systemd authors need mental help by Anonymous Coward · 2014-09-09 04:06 · Score: 0

It is amazing when I read all the crap that the systemd proponents claim is so wonderful about this software. This replacement for init.d has not only caused major disruptions in the re-write of Linux distributions, it is causing major head aches for system administrators and professionals. Init.d is elegant and simple. You can tell exactly when programs will start up or start. Everything is controlled by bash shell scripts. The directory /etc/init.d had a very simple way of launching and controlling deamons and background tasks. Actually, the quality of the scripts and how /etc/init.d was designed and laid out was the main factor in my decisions as to which Distro I would choose. Indeed, one reason I never pursued BSD as a distro of my choice is the lack of /etc/inittab and init.d. (although I've used it and ported it from scratch to hardware lacking unix). I prefer the systemV way.
Systemd is just simply goofy! First /etc/systemd which contains odd cofiguration files.
[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#CapabilityBoundingSet=
#DefaultStartLimitInterval=10s ... etc.. etc 40+ more lines.
What my complaint is, it's not at all clear what these parameters are for or what executable they will impact! In my distros I do not like secrets! user.conf, again it's not clear what it for, what executable it's modifying or how it impacts the system. In the case of user.conf it does get pulled in when the binary /usr/lib/systemd --user is run. Logind.conf is a real piece of work. Instead of spawning a /etc/getty this conf file controls how to turn on and off autoVTs.
Ok, but where are all the init.d scripts. Well they are still some for backward compatibility, but what makes systemd the total crap that it is is located in /usr/lib/systemd (why /usr/lib? What systemd controls the mounting of /usr/lib when the system is booting? Answer, that's in /lib/systemd! they are duplicates) So what's in /lib/systemd, /usr/lib/systemd? Binaries! Binaries! Lots and lots of binaries!
drwxr-xr-x 2 root root 28 Apr 25 11:21 catalog/
-rwxr-xr-x 1 root root 1237 Jan 22 2014 fedora-autorelabel*
-rwxr-xr-x 1 root root 464 Jan 22 2014 fedora-configure*
-rwxr-xr-x 1 root root 338 Jan 22 2014 fedora-import-state*
-rwxr-xr-x 1 root root 244 Jan 22 2014 fedora-loadmodules* ... etc... etc.
All told 43 BINARIES! Systemd advocates must love binaries. 43 binaries, each with their own options, man-pages and configuration files. How does that simplify anything? 43 unmodifie-able binaries. It's a damn nighmare and it really complicates the build, customize and install processes. This stuff should not be controlling the linux system. I really wonder what Linus thinks of this thing.
Then below the 43 binaries, in the system directory are the controlling parameter files where 1000's of spaghetti references to configuration files that end in .services .sockets .slice. mount .target .automount and .wants exists in this collage of crap. It's not clear at all what anything does other than guessing that rsync.service has something to do with running rsync. But what does initrd-switch-root.service, when and why does it run? Look at something as old school as getty. /usr/lib/systemd/system/getty@.service
Compare that to 1:2345:respawn:/sbin/mingetty tty1 in /etc/inittab. Or sysinit runs /etc/rc.d/rc.sysinit for system init.
The bottom line is systemd is a odious smelly piece of software that serves no purpose other than to feed the egos of the twit coders that created it. So far every systemd machine I've used has been SLOW, daemon saturated, and unstable. Systemd needs a major redesign with the KISS principles, flexibility and removal of the of complexity that burdens systems adminstrators with more and more error prone crap.