GSOC Project Works To Emulate Systemd For OpenBSD

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.

Comments

Oh well ...

[Xolotl]

... there goes that refuge then ;)

Re:Oh well ...

[Anonymous Coward]

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?

Re:Oh well ...

[Korgan]

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.

Re:Oh well ...

[Kvorg]

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.

Re:Oh well ...

[Anonymous Coward]

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?

Re:Oh well ...

[dpilot]

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..

Re:Oh well ...

[dpilot]

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.

Re:Oh well ...

[dpilot]

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.

Re:Oh well ...

[Dcnjoe60]

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.

Re:Oh well ...

[Dcnjoe60]

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.

Re:Oh well ...

[dpilot]

> 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.

Re:Oh well ...

[phantomfive]

I would assume this is the "correct" approach to manage it.

Encapsulate the ugliness and move on. Sometimes it's all you can do.

Re:Oh well ...

[weilawei]

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!

Re:Oh well ...

[weilawei]

s/ignoring log corruption/fixing log corruption/

Re:Oh well ...

[BadDreamer]

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.

Re:Oh well ...

[dpilot]

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.

Re:Oh well ...

[Dcnjoe60]

> 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.

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[gweihir]

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?

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[gweihir]

Are you stupid? Modules compiled together are not a "modular" system in the UNIX philosophy at all. They are one program.

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[gweihir]

Well said.

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[Dcnjoe60]

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.

Re:Oh well ...

[Dcnjoe60]

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?

Re:Oh well ...

[knorthern knight]

>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

Re: Oh well ...

[shutdown -p now]

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.

Re:Oh well ...

[Endymion]

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.

Re:Oh well ...

[Endymion]

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.

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[Dcnjoe60]

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.

Re:Oh well ...

[gweihir]

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.

Re:Oh well ...

[Dcnjoe60]

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.

Re:Oh well ...

[fenwar]

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.

Er?

[lisaparratt]

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?

Re:Er?

[Noryungi]

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.

Re:Er?

[ThePhilips]

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.

Re:Er?

[rmstar]

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.

Re:Er?

[koinu]

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?

Re:Er?

[Zocalo]

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.

Re: Er?

[Anonymous Coward]

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?

Re:Er?

[Anonymous Coward]

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.

Re:Er?

[ThePhilips]

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?)

Re:Er?

[koinu]

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.

Re:Er?

[tepples]

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.

Re:Er?

[Eunuchswear]

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".

Re:Er?

[Eunuchswear]

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"?

Re:Er?

[chihowa]

"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.

Re:Er?

[LordLimecat]

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.

Re:Er?

[Dcnjoe60]

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?

Re:Er?

[Dcnjoe60]

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.

Re: Er?

[zakkudo]

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.

Re:Er?

[Dcnjoe60]

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.

Re:Er?

[phantomfive]

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

Re: Er?

[ThePhilips]

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.

Re: Er?

[Blaskowicz]

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.

Re: Er?

[zakkudo]

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.

Re:Er?

[Blaskowicz]

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.

Re:Er?

[Zocalo]

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. ?

Re:Er?

[SepticPig]

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.

Re:Er?

[Anonymous Coward]

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?

Re:Er?

[sjames]

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.

Re:Er?

[Blakey Rat]

I've never seen a more blatant example of You Don't Need That in my life.

Re:Er?

[CaptnZilog]

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.

Re:Er?

[shutdown -p now]

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).

Re:Er?

[koinu]

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.

Re:Er?

[phantomfive]

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).

Re:Er?

[LordLimecat]

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.

Re: Er?

[iggymanz]

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

[Anonymous Coward]

Why in God's name would you want to infect well designed OSs with Systemd ?
That's unbelievably stupid.

Re:Stupid, stupid stupid

[Noryungi]

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.

Re:Stupid, stupid stupid

[LordLimecat]

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.

Re:Stupid, stupid stupid

[armanox]

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

Re:Stupid, stupid stupid

[jythie]

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.

Re:Stupid, stupid stupid

[MareLooke]

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

Re:Stupid, stupid stupid

[dagarath]

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.

Re:Stupid, stupid stupid

[LordLimecat]

: 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.

Re:Stupid, stupid stupid

[fnj]

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.

Re:Stupid, stupid stupid

[LordLimecat]

c) get rid of GNOME for any of the million other DEs
d) provide a compatibility layer
e) fork GNOME

Re:Stupid, stupid stupid

[multimediavt]

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!

Re:Stupid, stupid stupid

[armanox]

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.

Re:Stupid, stupid stupid

[armanox]

I think you might be right on that one. It was a Debian decision.

Re:Stupid, stupid stupid

[HiThere]

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.

Re:Stupid, stupid stupid

[CaptnZilog]

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.

Ye Gods!

[jawtheshark]

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.

Re:Ye Gods!

[Noryungi]

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.

Re:Ye Gods!

[Noryungi]

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.

Re:Ye Gods!

[cold fjord]

Talk about the tail wagging the dog.

Re:Ye Gods!

[Barsteward]

Have you had a read of this? Myth buster for systemd. http://0pointer.de/blog/projec...

Re:Ye Gods!

[Spit]

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.

Re:Ye Gods!

[Sique]

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.

Re:Ye Gods!

[Anonymous Coward]

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.

Re:Ye Gods!

[Rich0]

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."

Re:Ye Gods!

[prsephton]

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.

Re:Ye Gods!

[prsephton]

That, my dear fellow, is simply horrible. Ever heard about how the use of whitespace improves readability?

Re:Ye Gods!

[Eunuchswear]

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.

Re:Ye Gods!

[BadDreamer]

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.

Re:Ye Gods!

[Rich0]

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. :)

Re:Ye Gods!

[Rich0]

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?

Re:Ye Gods!

[BadDreamer]

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.

Re:Ye Gods!

[Rich0]

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.

Re:Ye Gods!

[BadDreamer]

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.

Huh?

[Richard_at_work]

Why the hell is a GUI system dependent on a low level system control daemon?

Re:Huh?

[Noryungi]

Thank you, you have just summed up the abomination that is systemd for all of us.

Re:Huh?

[Anonymous Coward]

> 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?

Re:Huh?

[qbast]

Because GNOME.

Re:Huh?

[Barsteward]

No, thats an abomination of Gnome, thats not systemd's fault.

Re:Huh?

[Anonymous Coward]

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.

Re:Huh?

[StormReaver]

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.

Re:Huh?

[Anonymous Coward]

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?

Re:Huh?

[Anonymous Coward]

they use the logind API for it (sponsored by NSA).

Fixed that for you.

Re:Huh?

[Unknown Lamer]

Because utmp totally does not exist.

Re:Huh?

[evilviper]

Ignorance is not a counter-argument.

Re:Huh?

[Peter H.S.]

"

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.

Re:Huh?

[drinkypoo]

Ignorance is not a counter-argument.

Ignorance of why Unix is done the way it is done is also not an argument for systemd.

Re:Huh?

[tyggna]

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.

Re:Huh?

[fnj]

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?

Re:Huh?

[drinkypoo]

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.

Re:Huh?

[phantomfive]

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

Re:Huh?

[CaptnZilog]

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.

Re:Huh?

[sjames]

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

Re:Huh?

[sjames]

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.

Re:Huh?

[sjames]

Sure they can. They can either be in the right group or use a simple helper daemon that is not PID 1.

Re:Huh?

[gweihir]

Stupidity. There is no other explanation, except maybe coercion.

Re:Huh?

[prsephton]

It's not, actually, The kernel is statically linked and has no dependency on glibc after it is compiled.

/etc/inittab

[MrKaos]

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?

Re:/etc/inittab

[Anonymous Coward]

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')

Re:/etc/inittab

[Anonymous Coward]

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.

Re:/etc/inittab

[Barsteward]

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

Re:/etc/inittab

[antientropic]

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.

Re:/etc/inittab

[jythie]

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.

Re:/etc/inittab

[Anonymous Coward]

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.

Re:/etc/inittab

[BadDreamer]

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.

Re:/etc/inittab

[Rich0]

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.

Re:/etc/inittab

[MrKaos]

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.

Re:/etc/inittab

[drinkypoo]

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.

Re:/etc/inittab

[MrKaos]

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?

Re:/etc/inittab

[phantomfive]

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.

Re:/etc/inittab

[MrKaos]

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.

Re:/etc/inittab

[BadDreamer]

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.

Re:/etc/inittab

[BadDreamer]

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?

Re:/etc/inittab

[MrKaos]

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.

Re:/etc/inittab

[Rich0]

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.

Re:/etc/inittab

[rb12345]

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.

Re:/etc/inittab

[CaptnZilog]

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").

Re:/etc/inittab

[CaptnZilog]

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.

Re:/etc/inittab

[CaptnZilog]

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."

Re:/etc/inittab

[CaptnZilog]

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.

Re:/etc/inittab

[Kabukiwookie]

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.

Re:/etc/inittab

[sjames]

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?

Re:/etc/inittab

[phantomfive]

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."

Re:/etc/inittab

[Rich0]

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.

Re:/etc/inittab

[Rich0]

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.

Re:/etc/inittab

[Barsteward]

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.

Re:/etc/inittab

[Barsteward]

Thats your choice, don't use it.

Re:/etc/inittab

[Barsteward]

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

Re:/etc/inittab

[Barsteward]

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

Re:/etc/inittab

[Barsteward]

He says freedesktop.org is just a repository for code and documentation, i can't find your reference

Re:/etc/inittab

[drinkypoo]

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.

Re:/etc/inittab

[BadDreamer]

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.

Re:/etc/inittab

[Barsteward]

What no longer runs?

Re:/etc/inittab

[Barsteward]

"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.

Re:/etc/inittab

[BadDreamer]

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.

Re:/etc/inittab

[phantomfive]

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.

Re:/etc/inittab

[badkarmadayaccount]

Run Gentoo and STFU. Debian lobotomized systemd pretty good if you can take a compromise, look at the Technical Comitee findings, mentioned elsewhere.

Re:/etc/inittab

[badkarmadayaccount]

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.

Re:/etc/inittab

[sjames]

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?

Re:/etc/inittab

[badkarmadayaccount]

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.

Re:/etc/inittab

[badkarmadayaccount]

Cgroups wouldn''t work, unless you containerise the systemd process tree, in which case what do you gain?

Re:/etc/inittab

[sjames]

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.

Re:ntp is the line in the sand

[ThePhilips]

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.

What?

[TranceThrust]

``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.

Re:What?

[prsephton]

Seriously, please do some editing before posing.

That just has to be a Freudian slip

Re:What?

[jeremyp]

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.

Re:What?

[Zembar]

Seriously, please do some editing before posing.

Posing for what?

Re:What?

[Barsteward]

is that "posing" or "posting"? :o)

Re:What?

[TranceThrust]

Hehe, quite possibly!

Re:ntp is the line in the sand

[jeremyp]

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!

Re:ntp is the line in the sand

[ThePhilips]

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.

Re:ntp is the line in the sand

[ThePhilips]

See previous reply to my comment.

The systemd-timedated is harmless - the systemd-timesyncd is a different story.

How about then backporting from BSD to Linux?

[Anonymous Coward]

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.

Re:How about then backporting from BSD to Linux?

[andydread]

THis a THOUSAND times.

Re:How about then backporting from BSD to Linux?

[Peter H.S.]

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.

Re:How about then backporting from BSD to Linux?

[Dcnjoe60]

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?

[ald_a]

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 :)

Re:ntp is the line in the sand

[jeremyp]

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.

Huh?

[Anonymous Coward]

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.

Re:ntp is the line in the sand

[gbjbaanb]

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.

Why Not?

[Anna Merikin]

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?

Re:Why Not?

[present_arms]

PCBSD, Slack, Gentoo and pclinuxos are systemd free :D pclinuxos user here

Re:Why Not?

[Dcnjoe60]

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.

Re:Why Not?

[fnj]

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.

Re:Why Not?

[sjames]

That was my first thought. Port it back to Linux so we can go back to regular old init.

Re:Why Not?

[gweihir]

I agree. There is no sane reason to do something this stupid engineering-wise, except a power-play.

Re:Why Not?

[gweihir]

Good idea.

Cool project

[BlackPignouf]

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.

Re:Cool project

[wed128]

Port it to what? I'm not sure you understand the article.

Needed by who?

[Anonymous Coward]

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.

Re:Needed by who?

[ThePhilips]

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.)

Troubleshoot log reader

[tepples]

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".

Re: ntp is the line in the sand

[jeremyp]

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.

Engineering for reliability, not philosophy

[Anonymous Coward]

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.

Re:Engineering for reliability, not philosophy

[Eunuchswear]

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?

Re:Engineering for reliability, not philosophy

[LordLimecat]

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.

Re:Engineering for reliability, not philosophy

[CaptnZilog]

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?

Re:Engineering for reliability, not philosophy

[LordLimecat]

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.

Re:ntp is the line in the sand

[jeremyp]

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.

Re: ntp is the line in the sand

[Eunuchswear]

Woooosh.

Re:New Gnome? no thanks.

[drinkypoo]

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.

Re:That guy just wasted his time

[Peter H.S.]

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.

Re:ntp is the line in the sand

[Peter H.S.]

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.

LOL Seriously?

[strikethree]

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

Re:ntp is the line in the sand

[gbjbaanb]

oh sorry - I didn't get the joke, I thought kdaemonhostd was a real thing! That's how bad this systemd thing has become :-(

Re:That guy just wasted his time

[volkerdi]

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.

Re:That guy just wasted his time

[Peter H.S.]

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.

Re:That guy just wasted his time

[Peter H.S.]

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.

Re:Er? (automatic locale?)

[shoor]

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.)

Re: ntp is the line in the sand

[CaptnZilog]

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? ;)

Re:ntp is the line in the sand

[gweihir]

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.

Re:Er? (automatic locale?)

[Dcnjoe60]

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.

Re:New Gnome? no thanks.

[shutdown -p now]

MATE? Xfce? LXQt?

Why is systemd bad?

[kbahey]

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!

Re:On the order of...

[Eunuchswear]

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)

Re:New Gnome? no thanks.

[drinkypoo]

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.