GSOC Project Works To Emulate Systemd For OpenBSD 314
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.
Oh well ... (Score:4, Funny)
Re:Oh well ... (Score:5, Informative)
Not really.
* This software is not going to end up in the base system but in ports. It will not have a big effect on the base system.
* The goal of the project is not to import the systemd programs like the NTP daemon or the cron daemon. Instead, it implements some of the APIs so it will be easier to port software that depends on some systemd features.
When the software is ready and ends up in OpenBSD ports, it will probably only be installed if you install a piece of software that depends on systemd (future gnome, for instance). So if you don't install these kinds of software, you don't even end up having "systembsd" on your computer.
In what way is the refuge gone now?
Re:Oh well ... (Score:5, Insightful)
Exactly, it would seem this will simply emulate the behaviour for applications that expect it, sitting on a DBUS interface. Since it now seems the whole systemd mess will not go away, I would assume this is the "correct" approach to manage it.
I can only wish non-RH GNU/Linux distrost adopted the same approach.
Why Not? (Score:4, Interesting)
Mebbe this will motivate some distro to do a similar; I, for one, would go for a distro without systemd nor Gnome, which I never use. Gnome is expendible. For those who like Gnome, why not do it this way?
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:3)
I agree. There is no sane reason to do something this stupid engineering-wise, except a power-play.
Re: (Score:3)
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.
Ju
Re: (Score:2)
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 ... (Score:4, Interesting)
Actually, systemd is all-or-nothing. If you let even a tiny bit in, countless things will break unless you take the whole POS. The developers are very keen on making sure of that.
Re:Oh well ... (Score:4, Interesting)
Not much chance of successful management when his idea of ignoring log corruption is to IGNORE it. Yes, literally, ignore it. Feature, not bug. In Poettering's own words [freedesktop.org],
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: (Score:3)
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 ... (Score:5, Insightful)
I see systemd as the product of a culture clash between old and old-school Linux users/developers and new Linux users/developers.
Linux was really derived from Unix, and in a very important way RMS has always been correct in insisting it be called GNU/Linux. Because "GNU's Not Unix" only in the licensing aspect. Philosophically, GNU really IS Unix.
A few years back, Linus and Linux started getting a lot of attention in the computing and even general press. Linux started becoming cool and interesting. It started attracting new users, a new wave of early adopters, and since early adopters also tend to be developers, Linux attracted a new wave of developers.
But these developers has a key difference - they had no Unix background. They largely came from Windows, simply because that's the largest source of developers, by simple demographics. But they weren't "fleeing Windows", they were attracted to Linux. They also brought their background, attitudes and preferences with them, and that includes a heave dose of "The Windows Way" and little to nothing of "The Unix Way."
The result is systemd - the Windows Way ported on top of the Linux kernel.
Then there is the demographics issue. The classical Linux market share has been so small and Windows so big that it doesn't take many Windows users/developers to swamp out the old school Linux/Unix camp. We're bing "conquered by demographics." They don't see anything wrong with systemd because it fits their background and world view perfectly - in fact it's a better fit for them than SysV Init is. There's also a bit of the Windows "One Way" attitude at work, attempting to push systemd across the board.
Fortunately there are a few never-newbie distributions still around, and it seems that the old-school Unix users are congregating there and will keep them alive. Or there are always the BSDs..
Re: (Score:3)
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: (Score:2, Interesting)
But you see, Windows has the lion's share of the market, and many of them are happy there. We tend to look with our Linux/Unix blinders on can't imaging that anyone could be happy there, but there are.
Once upon a time Miguel De Icaza spoke of trying to make Gnome "Windows Done Right". That's what I think people are trying to do with systemd - Windows Done Right - on the Linux kernel. Except that because they came from Windows and were happy with Windows, they may also think that systemd is Linux Done Rig
Re: (Score:2)
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
Re:Oh well ... (Score:4, Insightful)
> the reality is systemd is a bunch of individual modules
I disagree. Technically you are correct, but the same modularity argument can be made for practically any piece of code bigger than "Hello World". However in practice systemd is shipped as a monolith. I just checked, and even on Genoo with its uber-flexible USE flags and compilation from source, you can't shut off individual features like logging, dhcp, ntp, etc. Most people just install the binaries.
No, systemd is not the end of the world. But it would be the end of running my machines the way I wish to - at least without spending more time and effort keeping it fenced in as you suggest.
Re:Oh well ... (Score:4, Insightful)
You have the "linux way" (it is actually the Unix philosophy) completely wrong. It is not "one program for one task". It is:
"Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable."
-- Eric S. Raymond
"Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended."
-- Eric S. Raymond
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
-- Doug McIlroy
What systemd does wrong is abandoning this and using API's internally - API's it does not even lock down. It's a morass.
"Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design â" you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option."
-- Doug McIlroy
"Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes."
-- Eric S. Raymond
Yes, systemd IS the end of the world that many people want you to believe.
Re: (Score:3)
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 ... (Score:4, Informative)
The thing the inexperienced systemd developers (but I repeat myself) do not understand is that "modular" isn't about some technical detail such as how you compile various features. For example, busybox intentionally compiles everything into one big binary. The features it provides, on the other hand, are still very modular in the UNIX sense. The key difference is that the tools busybox provides ("cat", "wc", "mkdir", "dd", and many others) all implement well defined APIs.
What is an Application Programming Interface (API)? It's not some function you can call, or the fact that a program understands some option ("--foo"). It is not even the documentation that may or may not be provided that describes how to use some feature. So what is it?
An API is a PROMISE .
It is a social feature, not a technical one. The functions, options, and documentation are just the technical implementation of that promise. The key part of an API is that it is a promise by the developer that if you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, the promised API will be stable and reliable.
The problem with systemd is exactly this. Pulling a n00b move and agglutinating various features into one project is annoying and not recommended, but it is not, on its ownn, a reason to avoid systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs. His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable", specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.
A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.
The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.
If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.
So go ahead an prove that you don't know what you're talking about and assert that systemd is in any way "modular", when non-modularity was an explicit goal behind systemd. The rest of us are choosing to not go along with Poettering's attempt to embrace and extend [wikipedia.org] Linux into a cheap, buggy, feature-free windows clone.
Re: (Score:3)
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 t
Re: (Score:3)
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: (Score:3)
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
Re: (Score:2)
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.
Stupid, stupid stupid (Score:2, Insightful)
Why in God's name would you want to infect well designed OSs with Systemd ?
That's unbelievably stupid.
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 t
Re: (Score:2)
: 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 thing
Re: (Score:2)
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: (Score:3)
Re: (Score:2)
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: (Score:2)
c) get rid of GNOME for any of the million other DEs
d) provide a compatibility layer
e) fork GNOME
Huh? (Score:5, Insightful)
Why the hell is a GUI system dependent on a low level system control daemon?
Re:Huh? (Score:5, Insightful)
Thank you, you have just summed up the abomination that is systemd for all of us.
Re: (Score:3)
Re: (Score:2)
Ignorance is not a counter-argument.
Re: (Score:2)
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: (Score:2)
Re:Huh? (Score:5, Insightful)
Because the user of a GUI will want to touch hardware (mount a USB stick, use an audio device, suspend to RAM, configure a wireless network ...) and all of those interactions need some form of permissions broker. The current approach of having a hundred different command line utilities being called from the GUI (and then not working because their command line output has changed yet again) scales very badly and is the reason why linux has a (fairly well deserved) reputation at being hopeless for doing simple things like letting a desktop user use the usb stick they just put in, dealing with audio devices etc...
Fixing that requires an integrated approach. Layers of crappy shell scripts calling yet more layers of crappy shell scripts calling some binary that then calls some shell script that then pokes something into /sys IS the problem.
You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication. It's about consolidation of functions into one implementation that *does* work as opposed to 20 half-arsed implementations that do not. It's about providing what amounts to a library for daemons ... and libraries are deduplication are good things while reinventing wheels in every single application is bad, right?
For an application to effectively use these libraries and reduce the amount of code duplication across kde/gnome/xfce/lxde/... it has to actually have access to that code, which means that the thing that provides the code needs to be available. That means that the relevant systemd *component* is there -- and much of this is managed by logind.
Re: (Score:2)
Why do they need a permissions broker? Because somebody wants to make everyone submit to his personal OCD?
Re:Huh? (Score:4, Insightful)
Because the user of a GUI will want to touch hardware (mount a USB stick, use an audio device, suspend to RAM, configure a wireless network ...) and all of those interactions need some form of permissions broker.
Right. We have multiple capabilities-based security systems available for use with Linux, and we have a pluggable authentication system, and now we need another system to handle privilege management?
Fixing that requires an integrated approach.
That's what Unix gives you. Because the system is made up of small pieces, you can recombine them in different ways to achieve your goals. The pieces are designed to integrate with one another.
You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication.
We achieve that with shared libraries. There is no need for monolithic daemons which serve many purposes. Process creation is cheap on Unix.
You'll also find that systemd is indeed quite unix-like. It's about a reduction of code duplication. It's about consolidation of functions into one implementation that *does* work as opposed to 20 half-arsed implementations that do not.
But in fact it's one half-arsed implementation that only works sometimes instead of 10 really brilliant implementations that almost always work, and 10 mediocre ones.
For an application to effectively use these libraries and reduce the amount of code duplication across kde/gnome/xfce/lxde/... it has to actually have access to that code, which means that the thing that provides the code needs to be available.
Yeah, it's called a shared library.
No one has offered an explanation as to what systemd gives us that we did not have before. There is not one single thing. And what we've lost is simplicity. systemd is the opposite of the Unix way.
Huh? (Score:2, Informative)
because Desktop Environments DO interact with the lower systems.
They need access to the DRM and input device, they need access to things like reboot/shutdown/hibernate.
If I understand it correctly one goal of logind is to run the X-server and the Desktop Environment without root, so they cannot do this directly... they use the logind API for it.
Re: (Score:3)
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: (Score:2)
"
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 et
Re: (Score:2)
Because utmp [die.net] totally does not exist.
/etc/inittab (Score:5, Interesting)
Re: (Score:3, Insightful)
The problem it solves is that currently you don't always need to hire RedHat to manage your large Linux clusters.
While keeping hold of the top end, they are seeing the bottom end fall out from underneath them. And they have to do something to shore up that attrition of tomorrow's decision makers.
Re: (Score:3, Informative)
"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
Re: (Score:2)
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: (Score:3)
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 S [wikipedia.org]
Re: (Score:3)
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 (Score:5, Interesting)
It's so simple that it's broken. See for example http://utcc.utoronto.ca/~cks/s... [utoronto.ca] 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: (Score:3)
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: (Score:2)
Cool project (Score:2)
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:Er? (Score:5, Insightful)
I would have expected that BSD would be deliriously happy that the evil gaze of Poettering hadn't alighted upon their operating system. Why would you voluntarily infest your system with his daemon spawn?
Because bloody systemd will be needed if you want to run some brain-dead Linux-only piece of crap software. That's why.
Emulating systemd allows that software to work on OpenBSD. On the other hand, emulating it means that (a) its working may remain somewhat on the sane side and (b) that emulation will only be installed if the port requires it, therefore limiting the damage.
And, FYI, OpenBSD could not care less about Poettering and his evil gaze.
Re: (Score:2)
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? (Score:5, Informative)
The three services are actually needed.
The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
The systemd-timedated does almost the same for the date and time.
And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.
Re: (Score:3)
Ah no, you are bringing facts into this discussion? How dare you! :-)
Thank you, actually.
Re:Er? (Score:5, Insightful)
The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
Locale settings are fine without system-level settings. What is wrong with application-specific LC_xxx settings? And why should I be interested in changing locale in the middle of a desktop session?
The systemd-timedated does almost the same for the date and time.
What?! Who the hell changes time on computers? This is not a $5 digital watch! Every reasonable system has got ntpd installed and is set to UTC. The rest is done by selecting the time zone you are in. And stay away from changing time zones by adjusting time! We are not in Windows world where time handling has been fucked up entirely.
And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
Why do I need a daemon to log out from a session?
Re: (Score:2)
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: (Score:2)
"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? (Score:5, Informative)
The three services are actually needed.
For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones. The system itself always ran on UTC. UTC is not supposed to change. Users changing their locale need to log out and back in again. That works well enough for the expected frequency of such changes occurring and doesn't need lots of code to notify every running process AND lots of code in every running process to deal with the change.
As an engineering tradeoff, the Unix way makes sense to me. The poetterix way, not so much. So I don't really buy your "long overdue", no.
Re: (Score:2)
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 re
Re: (Score:3)
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
How about then backporting from BSD to Linux? (Score:5, Insightful)
If BSD's emulation of those Linux systemd APIs is done in a reasonably portable manner, we could then backport the code over to Linux and gain the benefits without being dependent for those functions on the engineering disaster that Lennart has put into process slot 1.
The BSD folks aren't succumbing to systemd's problematic "kitchen sink in slot 1" approach, so their work could be valuable for those Linux distros that are fighting to keep systemd out of their hair.
Re: (Score:3)
Re: (Score:2)
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
Re:Er? (Score:5, Insightful)
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: (Score:3, Interesting)
The idea that systemd is only relevent on the desktop could not be further from the truth. I would say it's even more relevant on servers, where I expect services to be managed reliably. SysV init cannot do that. (E.g., there is no guarantee that after "/etc/init.d/httpd stop" all httpd processes are really gone
Anyone who has ever tried running BackupExec Linux agents is well familiar with stopping the service 32 times while the process merrily continues running in a borked state, only fixed with a "killall' command.
Again: I dont really have a horse in this race, but if systemd truly can guarantee that a service stops when it says it does, thats where Im placing my bets. Its absurd that the service system in Linux fails so badly in that regard.
Re: (Score:3)
Troubleshoot log reader (Score:2)
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: (Score:2)
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 wher
Re:Ye Gods! (Score:5, Insightful)
Again, this an emulation of systemd - not the real ugly mess.
This means that the normal configuration files will probably stay, but will probably be parsed on-the-fly (smartly, one hope) to provide some emulation.
The reason this is interesting is that it may prove an escape hatch not just for OpenBSD, the other BSDs, but also for some (sane) Linux distributions that refuse to adopt systemd such as Slackware.
Re: (Score:2)
Re: (Score:2)
Biggest myths of systemd:
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 logfil
Re: (Score:2)
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: (Score:3)
Read them and weep: http://www.reddit.com/r/linux/... [reddit.com]
TL;DR? Essentially, KDE may end up switching to systemd. Because Gnome (and every other Linux fan-boi) does it.
Re: (Score:2)
Talk about the tail wagging the dog.
Re:Ye Gods! (Score:4, Interesting)
Re: (Score:3)
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 a
Re: (Score:2)
The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
None of the chunks in systemd do one thing, do it will and provide a UNIXy way to assemble them together. They're a huge blob of interdependent API's.
And yes, if it wasn't part of this API infested mess people would indeed be arguing that systemd should be more like it. But
Re: (Score:2)
The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
Because systemd now has a replacement [freedesktop.org] for ntpd [die.net].
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: (Score:3)
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: (Score:3)
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.
Re:ntp is the line in the sand (Score:4, Interesting)
Its actually a very old way to run services. Windows has been doing it this way for years.
Run process explorer on Windows, click on a svchost.exe process and see what services its running. It made more sense on Windows as a Windows process is more heavy than a Linux one, this is the same reason threads are more common on Windows compared to Linux's spawning processes to provide the same solution.
Anyway, one issue is reliability - if you want to restart a borked Apache, you can tell it to restart, and if it doesn't you can kill it. Systemd, you'll have to kill the daemonhost that hosts the Apache service, and kill all the other running services too. Assuming the security model allows you to do that.
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
See previous reply to my comment.
The systemd-timedated is harmless - the systemd-timesyncd is a different story.
Re: (Score:2)
Seriously, please do some editing before posing.
That just has to be a Freudian slip
Re: (Score:2)
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: (Score:2)
Re: (Score:3)
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: (Score:3)
MATE? Xfce? LXQt?