You sound like a stupid and ignorant troll, not at all like a top programmer. A top programmer would already know everything he needs to know to begin programming a systemd alternative, as eveyrhing is documented on LP site. People like you are very easy to spot, sorry.
Nice. And how can I disable journald completly and use only syslog?
Thanks
Why do you want to know how to do sth that you have no reason to do and no knowledge how to do ? Your question doesn't make sense: if you had the proficiency to have a use case for what you're asking, that also mean you could do it yourself. Only a fool would ask how to do such a thing, as you then would be unable to support such a setup yourself. BTW, such a setup would only make your life painful without any benefit at all.
The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.
I must be pretty efficient then, as at home (and sometimes at work) I run all my servers with my own LFS-like systems all made from scratch, and I don't spend anymore an afternoon building a tool. Setting up everything took its time, but I do this since 15+ years and have no intention of going back to any distro, no one could answer my needs, not even Gentoo. I master everything that is on my setups, which are so complicated (not really) that distros only recently started giving some features I use for more than a decade. And I jumped to systemd since the beginning, I abandoned the security and usability nightmare that was init scripts from the start 15+ years ago. The distros have no choice, because they must try to cater to every situation (which is impossible to do) with their scripts for people that are no sysadmins. When you have your custom systems, it's far easier to tidy everything, but init scripts are still a security nightmare.
When opponents to sth have to lie through their teeth, hoping that noone will go read and understand their links, they're immediately disqualified in my view. You clearly are not qualified to understand what you're talking about, but at least you made the work to fool people that won't ever read the links provided because they're not qualified either. Unfortunately for you, some people will read them. And they'll see your lies, which explains why you posted as AC.
Let's run down the list of "why":
- Systemd contains an unchecked null reference pointer that segfaults PID 1. Lennart Poettering states he won't fix it https://bugs.freedesktop.org/s...
No, systemd doesn't have such a thing, and LP never said what you're saying. The link show a very non civil hater (the systemd devs kept their cool), that wants the devs to tackle at high priority an unsupported setup, which became badly handled by systemd because of a kernel change. One thing that is legitimate, is that systemd should at least gracefully quit when in such an unsupported setup. Which has been done and fixed by the systemd devs. They asked for a patch from the guys who insist on using an unsupported setup, and of course, never got anyhting, and had to do it themselves. Classic "the setup you told me won't work, that's what I want to use, or systemd is crap". Why a sysadmin would do that, I can't understand.
- Systemd and Gnome allow bypassing gnome-shell password prompts granting root Left unfixed for over a year http://www.phoronix.com/scan.p...
Another big lie, systemd has nothing to do with this problem, it's only Gnome Shell that is the problem in some distro setups, and that was introduced because users were locked out of their desktop. To sum it up, Gnome-shell made a kludge to remove the security systemd provides, so as not to lockup users.
- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it. https://bugzilla.opensuse.org/... https://utcc.utoronto.ca/~cks/...
Yet, the true sysadmins that reported it managed to provide logs and debug the systemd-208 version, which is the version we're talking about here, which is an arbitrary version that some distros took as a supported one in their distro. LP never said anything of what you're lying about here, especially as what you say makes no sense when PID one segfaults, then the core deump is important, and that's one of the thing that has been provided by competent sysadmins, not by incompetent whiners. This bug has been fixed in the 208 version used by this distro, using true debug means recommended by systemd devs or distro maintainers, not your nonsense. The upgrade was also fixed by the distros, as they were in charge of supporting the version, with the help of systemd devs. And yes, it happened once with a systemd version, that it crashed on live updating itself.
Actually that's not true at all, it will boot just fine. It's just a clueless user there that tuned his laptop with an antiquated configuration that is static instead of dynamic, and perhaps that's Debian's fault. There must be a long timeout, but eventually, he would have arrived to emergency console. Systemd is dynamic if you use its native tools, not if you use the compatibility static tools of Debian. But it boots
And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.
So if that's why people hate on systemd, then that means "Windows-like" is well defined. Could you explain what it means, because I've absolutely no clue at all at what it means. Then I'll be able to understand better what systemd haters want exactly of systemd, and if it's legitimate.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users.
I don't know if that's true, but one thing is true: DE didn't gained popularity from sysadmins but from developers or desktop users. Do you imply DE have no place on Linux, and that people hate them as much as systemd?
Sysadmins value stability, simplicity and the ability to understand the system they are running.
Exactly, that's why sysadmins hate sysvinit and init scripts.
Systemd effectively removes all those features from the OS.
No, you're mistaken. If that's what you believe when you're using systemd, it's not actually systemd the problem, it's you that is not a real sysadmin like you thought you were. I understand it's a terrible realisation and why it would make people hate systemd. A system with systemd is actually more stable, simpler and with a better ability to understand the system. The problem is that lots of people that thought they were sysadmins never took time to get the ability to understand the system. Now, the migration to systemd shows them how little they know about system administration.
Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users).
So you really hate desktop users (and Desktop Environments) and you don't want to see them on Linux. Fortunately for freedom and other Linux users, you have no power in this matter. I didn't understand the link between your thirst sentence and the second one: how does making it easier for desktop environment developers undermine the primary use-case of Linux? I don't see it myself, and I don't even know if server is the primary use-case of Linux, though it may be true. My servers work far better than before with systemd, and my desktops too. I didn't know improving both was mutually exclusive.
Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).
I'm a Linux user (and more) and I agree with you, that's why I use systemd on GNU/Linux.
And I've personally compiled and installed non-init parts of systemd.
Which parts? Do tell.
Every single part of systemd can be installed on any system. Make them work correctly without systemd as PID1 is another story. Some will work, some won't.
> That is a good thing to keep in mind, since nobody is running systemd except by choice.
I'm afraid that's nonsense. systemd has been a penalty in work I do. If I could have more contemporary versions of Linux based daemsns and packages without systemd, such as entire LAMP stacks, I'd accept them in a moment. Debugging failed daemon startups with systemd has repeatedly proven painful, due to the binary log formats and the difficulty of deducing the actual daemon startup commands to run them in a debugger.
What you say can only mean two things: either you're making up things, or you're incompetent at what you try to do. The fact that you're very vague about your problems, not at all like a sysadmin would be, makes me lean towards the second option.
changing the system time & date without root or sudo? HELLO? How is that a good idea? ntpdate then ntpd for that and the user can set the TZ environment variable in.profile if they want to.
not that the old ways are perfect, how many years have we gone without support for UTC or just no daylight savings adjustment?
Really, you people are a joke. We're talking about changing the local time through a DE, and your answer is: there is no problem, just change an environment variable (so not in the DE and the DE's session won't be aware of it) that need you to restart the DE session to be effective, or just let ntpdate then ntpd do the thing (so has nothing to with the DE, requires elevated privilege and knowledge far outside manipulating a DE UI). HELLO? Are you understanding what people are asking here? Oh OK, your answer to the DE is that we've gone many years without support for UTC (what nonsense is that?) so they don't need any of the thing they're asking for, you know better than them of course.
It doesn't matter how many pieces something is if the pieces are more or less inseparable. There's a reason all of those things are developed under the "systemd" banner. If you decide that you absolutely must have systemd without the crap you don't want, your only option is to configure and compile it yourself. If that's "modular" or "not monolithic", then I guess Windows is too.
If it were truly not monolithic, then I'd be able to install systemd's non-init stuff on a sysvinit system and vice-versa.
Thanks a lot, I just realized everything I compile on my OS is monolithic. Actually, there's not a single package on a Linux system that is not monolithic. I'm not even talking about my DE which combine several monolithic packages. Even sysvinit was monolithic actually. So systemd actually merges perfectly in all this monolithic mess of a system that Linux is. Or perhaps you're wrong, because I can install systemd non-init stuff on a sysvinit system just fine.
3. Screen locker reports back that the screen is locked
4. DE then puts the computer to sleep.
Same strengths and weaknesses without ever going outside the DE except to tell the system to suspend.
.
Oh my god, reading the various links would have told you that your 2, 3 and 4 points are kludges today that don't work well, if at all. Systemd solves every single one of the problems listed in points 2, 3 and 4.
This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.
First, is it the regular user account or the DE itself which essentially gets its privileges escalated? Either way, that sounds inherently dangerous -- if you want the DE to be all powerfull, just login as root (there are good reasons not to login as root of course, but if systemD is doing it for you anyway, why even bother with the distinction between root and user accounts).
Because what is being talked about flew right above your head. Ironically, the mechanism you describe was the one used until systemd appeared. Which is ironic because you weren't even aware of how insecure your sysvinit setup was. Systemd does it better: it does not escalate your priviledges, it keeps control of how the function is executed, you never gain control of the how. You only gain the rights to ask for a system change to be made. For example, you can be given the right to change the server hostname (which can break your DBUS and DE) or the desktop clock. But you are not actually executing setuid binaries. Or another example, you can be a step above allowing every user to use the sound card when you have multi seat or multi sessions setups (like I do). If you can't understand the distinction between the two ways of doing things, as is apparent in your post, try not to talk about it, your post made me cringe with the cluelessness.
> Yes, it is too hard for the actual whiners we have, but it would be easy, beyond simply "trivial," for any Jr Sysadmin or even a Jr Software Developer if they've ever used make
I'm afraid that's not true. Take a look at the Fedora work going on right now to try to segregate systemd components, described at http://news.softpedia.com/news....
Oh my, you say it's not true, then post a link that proves you wrong. Are you even understanding what you're talking about? The problem Fedora faces with their two sub packages, is that they have to add functionalities that then would not be in the default systemd package. If they were already in the main systemd package, their sub packages would not make sense anymore, it would defat their purpose.
These are components that should never have been integrated into an over sized and aggressive systemd in the first place. I've taken a few stabs at segregating systemd components myself, and it's a very large octopus of dependent code.
You sound like an emotional clueless person, not like a developer. What is an over sized systemd? What is an aggressive systemd? Systemd reduced the size of my hand made systems (I've removed at least sysvinit + tons of scripts and several binary helpers + xinetd + dhcpcd at least) so to me it is not over sized, and it has never actually been aggressive to me, on the contrary, I've fixed several long time invisible misconfigurations by myself thanks to it.
This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.
An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic?" That is what they are talking about: you can't get that stuff separately from your init system.
Then people saying that are wrong, as this functionality is not in the init system. It is in several parts (so not monolithic), logind being one, and logind is assisted in the task by dbus and systemd init, which themselves are assisted by the Linux kernel. This assistance and dependencies are necessary to assure a minimum of security.
The problem is, for years now, we have been assured that Open Source was the cure for problems.
Wrong, that's you rewriting history from your dreams. Nobody assured that.
Just notify someone, and wait, and your problem will be fixed. I had it happen so many times in the old days. Now, developers apparently have stopped caring about this and care only about developing products for themselves.
It was always developers scratching their own itch. And if you couldn't develop, you could pay someone to do it for you. It always was this deal, you changed "pay someone" to "notify someone" in your delusions.
Sad, but what are you going to do? The concepts that made Open Source a big hit are being abandoned. Open Source isn't going away but it is definitely becoming less popular. Good news for commercial software companies that listen to their customers.
Oh, I didn't understand right away that you were a proprietary software shill, my bad, it should have been obvious, no true Free Software actor could be so deluded and so clueless.
It is strange that you talk about "non-systemd distros" as if they were defined until then by this.
What are the "non-systemd distros" that are crumbling? If anything is crumbling, it would be more "systemd distros" that get considerable amount of developers forking, founders resigning, etc, not to mention users looking toward BSDs.
FUD is a proprietary OS shill tactic. If you don't understand why distros are separated in systemd ones and non-systemd ones in this thread, you're hopeless.
Also, was it obvious since years that systemd would go in so many direction and that, wherever it goes, code would be throw away? What is then to support?
It was not obvious, because often, the code thrown away is because the underlying plumbing component is abandoned for years, or not supported anymore by anyone. systemd devs are actually maintaining lots of code nobody wants to maintain anymore.
Isnt it a joke in the end, to support alternative to systemd that actually have to do exactly what systemd does in order to be actually any good?
Yes, I agree it's really stupid. Besides, the people that say systemd features are useless, or that systemd doesn't have any upside, it makes them look plain stupid and clueless.
pm-utils is the example. Was it obvious that upower would throw support for pm-utils? Why was it discarded? Wasn't it discarded because, as pointed at by Edmunson "adding it [systemd] as an optional extra defeats the main benefit"? So what is the joke about writing alternatives when it is clearly that systemd cannot be optional (meaning that alternative must really be systemd compatible, and not the contrary)
It's not like that at all. It's rather that systemd proposes a systemd API for several things. There are a lot of field where systemd is the sole provider of an API, so is the de facto standard. And why is systemd the sole APi provider in some areas? Because while DE were asking for these API, systemd was listening and providing them, while others were not listening and busy telling systemd these features are useless.
It is not really as if we were in a situation where desktop environment on GNU/Linux mattered much. It is not desktop environment that made GNU/Linux popular. At all. There are practically inexistant, if you really loves facing realities. They have a bunch of users. Nothing else. If they can afford too loose more of this bunch in the name of "reality", why not. I'm not sure it is for their benefit.
See your cop out? This is the problem with non-systemd distro: no problem is solved, only cop out, whining, complaining, but you never solved anything, just wasted time. Systemd opponents are mostly like that, that's why I can't take them seriously. I've followed systemd since the beginning, I've seen the amount of work done and the attitude towards users (DE, sysadmins, distros...), and I've seen the work done by those opposed to it. Given this knowledge, up to this day, I predict complete failure of systemd opponents on Linux.
I started using KDE with KDE 1. But I also used Enlightenment, GNOME 1, WindowMaker, Fluxbox, XFCE and many other, I dont feel tied. There are parts of KDE I like and I'd enjoy being able to continue using it and continue to recommend it to other users. I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic. I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is
And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd?
They removed pm-utils because it didn't work well and was abandoned since 5 years. People mostly complain about systemd taking over active management of things long abandoned by everybody else. It's a dogma it seems, a self destructive one, to bash systemd for good things, which is even worse.
Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not? If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative?
Most of the time, it's either removing a useful systemd feature entirely and going back several years in time and functionality, or reimplement in true NIH style what systemd already provides. Sometimes, the reimplementation fails along the road when the "amount of work required" bar goes above the "hate systemd feeling" bar.
The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won't do. And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers.
Which is an exemple of what I said above, with a probable failure as outcome.
Hence the question: will KDE be still usable in 2016 without systemd.
So while I'm sure the systemd zealots would love to see KDE, Gnome3, etc. only work with systemd and drop support for all other distros, this doesn't appear to be happening. In the case of KDE, ConsoleKit2 is supported (and therefor Funtoo, Gentoo, Arch with OpenRC, etc. will continue to work just fine).
There lies the problem, you anti-systemd zealot are taking an antagonistic stance to all this, assuming that what you call "systemd zealots" would love to see KDE work only with systemd. That makes no sense at all, and that would mean DE devs are "systemd zealots". But all the DEs communication and actions points to you being completely wrong. Thay actually work instead of complaining uselessly and spouting antagonist nonsense about systemd.
With documentation like that I tend to wonder whether idiot is the correct term, or whether malice should be assumed.
Taking an AC on Slashdot as your source, I wonder whether idiotic is the correct term, or whether malice should be assumed. A real concerned developer would have already started there http://www.freedesktop.org/wik... and looked at "Documentation for Developers".
If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
by taking over and forcing out all other options, it becomes a monoculture. and that, as we know from decades of experience where monoculture OSes have created cartels and monopolies, is incredibly dangerous.
So POSIX is incredibly dangerous? Your argument is flawed from the start. systemd provides a standard API, and nothing about a standard API is dangerous, a standard prevents the creation of cartels and monopolies, so what you say is already the contrary to the probable outcome.
now i am witnessing a process by which everyone in the GNU/Linux community, by working in a totally dedicated way in "their corner" that has to be respected precisely *because* it is so dedicated, yet as a whole *all* of us have gone "hmmm, i'm working in my corner, the global problem isn't my problem: i'm making local decisions, here, which make my life easy and i'm doing what i think is best", totally forgetting that the overall consequences are like a shoal of fish: EVERYBODY has "flipped" - all at once - and the direction is a dangerous one that no one person has any responsibility or control over, because we are *not* a company, we do *not* have a "Board of Directors who can give us orders that we are required to follow or be fired", we are a bazaar - a self-organised group of self-organised individuals with independent free will and highly-focussed responsibilities.
the "flip" is to a dangerous monoculture position with, as we are now witnessing, absolutely zero choice (bad choices are no choice at all) - which i've warned about well over a year ago, and was told, basically, to "fuck off". well... now we begin to see the consequences.
What is this nonsense about? I've seen nothing of the like, and I make all my OS from source since 15+ years.
i am running fvwm2 - i have been for 20 years - and i am using angband.pl's recompiled versions of critical dependencies (udevd and others) all of which have "--no-systemd" in the configure.ac files. so i will not be concerned about trojans that attack vulnerabilities in systemd, exploiting the new features such as allowing the firewall to be disabled and much, much more. but you - all you who trust the systemd authors and the desktop environments that now operate exclusively on systemd? you should be concerned.
Talking about security in systemd compared to sysvinit shell scripts is just laughable. Fortunately you've not been 20 years in the security IT field. Just look at most trojans and rootkits, before saying nonsense like that. sysvinit scripts are a security nightmare in themselves, and are impossible to audit. BTW most of them don't work anymore in systemd, especially if you've hardened your systemd service files.
This is confirmed, along with the difficulty of unfurling the systemd init tools to try and start the fractured daemon cleanly in a debugger.
What is confirmed? systemd by default sends stdout and stderr to the journal, contrary to daemon launch with init shell scripts. The AC is repeating sth false, as several of them do in every systemd thread. I don't know what their agenda is.
What's even better, the system default for this behaviour is configurable, and it's also configurable per service.
I agree with binary log files having some serious issues, and I can easily imagine that replacing the logging system with it's predecessor is an ugly hack.
I wonder though how difficult it would be to replace journald with an interface-compatible logger that actually outputs good old fashioned text logs instead? Knowing nothing about journald or it's interfaces, it seems like it shouldn't be a huge problem - just fork off journald_txt, changing only the actual file output components. I would assume all the relevant data still enters the logging system, I mean there *is* a dedicated journald log reader, right?
Why are you believing nobody else thought of that in the first place? If it's because you're clueless, why are you criticizing a topic you have no knowledge about? Of course there is a dedicated journald log reader, it's called journalctl, this is the most basic thing to know about journald before even attempting to criticize it. Just installing another syslog daemon (like rsyslog) is enough to removes all these concerns, because yes, several people (serious ones) have already done the work instead of complaining based on ignorance.
I disagree on the "full-throttle" part. That's be fine on consumer desktops. But Linux is mostly about production servers. Yes, yes... I know... mainstream Linux on the desktop is "just around the corner" and all that.:)
Why are you disagreeing on something that you say is irrelevant to your servers?
I have no great love for sysV init scripts. Getting rid of them would break a few things in my world. But really, those things could probably stand a new look and update anyway. But my second-to-main issue with systemd is that it's just somewhat half-baked and obtuse. There's a lot of "don't look behind the curtain, just trust us that it'll work" to it.
So your world is improving, as sysvinit is even more "don't look behind the curtain, just trust us that it'll work". So much so that you also have to believe that for any distribution that used sysvinit, as every one of them had to implement the "behind the curtain" part, and was saying to you "just trut us that it'll work". Duplicated functionality in every distro, that have now disappeared for a big part. So now it's far better, in every kind of GNU OS on Linux use case, even on non GNU ones.
My biggest gripe about systemd, though, is its counterpart in crime: journald. Binary log files are the work of the devil and journald needs to die in a fire. And no one... not even a couple of Red Hat engineers I've spoken with... has been able to give be a non-hackish, production-worthy, way of ripping journald out of the thing and replacing it with syslog.
syslogd is antiquated, no distribution uses that by default anymore on Linux distros (LFS is not a distro). They use syslog-ng or rsyslog, and they plug without any problem with journald. Ripping out journald makes no sense and actually would put you back to the bad days of logging before systemd: no automatic logging of stdout and stderr, loss of kernel boot messages, no display of last messages from your services, impersonation of other processes possible in logs...
So that means systemd is not the esuivalent to scm in Windows, it would be at least equivalent to smss + scm. And in fact it's much more, even if you're talking about only PID 1 systemd.
Slashdot Mirror
You sound like a stupid and ignorant troll, not at all like a top programmer.
A top programmer would already know everything he needs to know to begin programming a systemd alternative, as eveyrhing is documented on LP site.
People like you are very easy to spot, sorry.
Nice. And how can I disable journald completly and use only syslog?
Thanks
Why do you want to know how to do sth that you have no reason to do and no knowledge how to do ?
Your question doesn't make sense: if you had the proficiency to have a use case for what you're asking, that also mean you could do it yourself.
Only a fool would ask how to do such a thing, as you then would be unable to support such a setup yourself.
BTW, such a setup would only make your life painful without any benefit at all.
The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.
I must be pretty efficient then, as at home (and sometimes at work) I run all my servers with my own LFS-like systems all made from scratch, and I don't spend anymore an afternoon building a tool. Setting up everything took its time, but I do this since 15+ years and have no intention of going back to any distro, no one could answer my needs, not even Gentoo.
I master everything that is on my setups, which are so complicated (not really) that distros only recently started giving some features I use for more than a decade.
And I jumped to systemd since the beginning, I abandoned the security and usability nightmare that was init scripts from the start 15+ years ago.
The distros have no choice, because they must try to cater to every situation (which is impossible to do) with their scripts for people that are no sysadmins.
When you have your custom systems, it's far easier to tidy everything, but init scripts are still a security nightmare.
When opponents to sth have to lie through their teeth, hoping that noone will go read and understand their links, they're immediately disqualified in my view.
You clearly are not qualified to understand what you're talking about, but at least you made the work to fool people that won't ever read the links provided because they're not qualified either. Unfortunately for you, some people will read them. And they'll see your lies, which explains why you posted as AC.
Let's run down the list of "why":
- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s...
No, systemd doesn't have such a thing, and LP never said what you're saying. The link show a very non civil hater (the systemd devs kept their cool), that wants the devs to tackle at high priority an unsupported setup, which became badly handled by systemd because of a kernel change. One thing that is legitimate, is that systemd should at least gracefully quit when in such an unsupported setup. Which has been done and fixed by the systemd devs. They asked for a patch from the guys who insist on using an unsupported setup, and of course, never got anyhting, and had to do it themselves. Classic "the setup you told me won't work, that's what I want to use, or systemd is crap". Why a sysadmin would do that, I can't understand.
- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...
Another big lie, systemd has nothing to do with this problem, it's only Gnome Shell that is the problem in some distro setups, and that was introduced because users were locked out of their desktop. To sum it up, Gnome-shell made a kludge to remove the security systemd provides, so as not to lockup users.
- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/...
https://utcc.utoronto.ca/~cks/...
Yet, the true sysadmins that reported it managed to provide logs and debug the systemd-208 version, which is the version we're talking about here, which is an arbitrary version that some distros took as a supported one in their distro. LP never said anything of what you're lying about here, especially as what you say makes no sense when PID one segfaults, then the core deump is important, and that's one of the thing that has been provided by competent sysadmins, not by incompetent whiners. This bug has been fixed in the 208 version used by this distro, using true debug means recommended by systemd devs or distro maintainers, not your nonsense. The upgrade was also fixed by the distros, as they were in charge of supporting the version, with the help of systemd devs.
And yes, it happened once with a systemd version, that it crashed on live updating itself.
- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...
Actually that's not true at all, it will boot just fine. It's just a clueless user there that tuned his laptop with an antiquated configuration that is static instead of dynamic, and perhaps that's Debian's fault. There must be a long timeout, but eventually, he would have arrived to emergency console.
Systemd is dynamic if you use its native tools, not if you use the compatibility static tools of Debian. But it boots
And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.
So if that's why people hate on systemd, then that means "Windows-like" is well defined. Could you explain what it means, because I've absolutely no clue at all at what it means. Then I'll be able to understand better what systemd haters want exactly of systemd, and if it's legitimate.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users.
I don't know if that's true, but one thing is true: DE didn't gained popularity from sysadmins but from developers or desktop users.
Do you imply DE have no place on Linux, and that people hate them as much as systemd?
Sysadmins value stability, simplicity and the ability to understand the system they are running.
Exactly, that's why sysadmins hate sysvinit and init scripts.
Systemd effectively removes all those features from the OS.
No, you're mistaken. If that's what you believe when you're using systemd, it's not actually systemd the problem, it's you that is not a real sysadmin like you thought you were. I understand it's a terrible realisation and why it would make people hate systemd.
A system with systemd is actually more stable, simpler and with a better ability to understand the system.
The problem is that lots of people that thought they were sysadmins never took time to get the ability to understand the system.
Now, the migration to systemd shows them how little they know about system administration.
Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users).
So you really hate desktop users (and Desktop Environments) and you don't want to see them on Linux. Fortunately for freedom and other Linux users, you have no power in this matter. I didn't understand the link between your thirst sentence and the second one: how does making it easier for desktop environment developers undermine the primary use-case of Linux? I don't see it myself, and I don't even know if server is the primary use-case of Linux, though it may be true. My servers work far better than before with systemd, and my desktops too. I didn't know improving both was mutually exclusive.
Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).
I'm a Linux user (and more) and I agree with you, that's why I use systemd on GNU/Linux.
And I've personally compiled and installed non-init parts of systemd.
Which parts? Do tell.
Every single part of systemd can be installed on any system. Make them work correctly without systemd as PID1 is another story. Some will work, some won't.
Seems reminiscent of "embrace and extend" in spirit.
Embrace and extends doesn't worrk with Free Software, so you don't understand what Embrace and Extend is.
> That is a good thing to keep in mind, since nobody is running systemd except by choice.
I'm afraid that's nonsense. systemd has been a penalty in work I do. If I could have more contemporary versions of Linux based daemsns and packages without systemd, such as entire LAMP stacks, I'd accept them in a moment. Debugging failed daemon startups with systemd has repeatedly proven painful, due to the binary log formats and the difficulty of deducing the actual daemon startup commands to run them in a debugger.
What you say can only mean two things: either you're making up things, or you're incompetent at what you try to do.
The fact that you're very vague about your problems, not at all like a sysadmin would be, makes me lean towards the second option.
changing the system time & date without root or sudo? HELLO? How is that a good idea? ntpdate then ntpd for that and the user can set the TZ environment variable in .profile if they want to.
not that the old ways are perfect, how many years have we gone without support for UTC or just no daylight savings adjustment?
Really, you people are a joke. We're talking about changing the local time through a DE, and your answer is: there is no problem, just change an environment variable (so not in the DE and the DE's session won't be aware of it) that need you to restart the DE session to be effective, or just let ntpdate then ntpd do the thing (so has nothing to with the DE, requires elevated privilege and knowledge far outside manipulating a DE UI).
HELLO? Are you understanding what people are asking here?
Oh OK, your answer to the DE is that we've gone many years without support for UTC (what nonsense is that?) so they don't need any of the thing they're asking for, you know better than them of course.
It doesn't matter how many pieces something is if the pieces are more or less inseparable. There's a reason all of those things are developed under the "systemd" banner. If you decide that you absolutely must have systemd without the crap you don't want, your only option is to configure and compile it yourself. If that's "modular" or "not monolithic", then I guess Windows is too.
If it were truly not monolithic, then I'd be able to install systemd's non-init stuff on a sysvinit system and vice-versa.
Thanks a lot, I just realized everything I compile on my OS is monolithic. Actually, there's not a single package on a Linux system that is not monolithic.
I'm not even talking about my DE which combine several monolithic packages. Even sysvinit was monolithic actually.
So systemd actually merges perfectly in all this monolithic mess of a system that Linux is.
Or perhaps you're wrong, because I can install systemd non-init stuff on a sysvinit system just fine.
Much, much easier solution to this problem:
1. You press suspend button
2. DE's hotkey handler catches this, tells screen locker to lock
3. Screen locker reports back that the screen is locked
4. DE then puts the computer to sleep.
Same strengths and weaknesses without ever going outside the DE except to tell the system to suspend.
.
Oh my god, reading the various links would have told you that your 2, 3 and 4 points are kludges today that don't work well, if at all.
Systemd solves every single one of the problems listed in points 2, 3 and 4.
First, is it the regular user account or the DE itself which essentially gets its privileges escalated? Either way, that sounds inherently dangerous -- if you want the DE to be all powerfull, just login as root (there are good reasons not to login as root of course, but if systemD is doing it for you anyway, why even bother with the distinction between root and user accounts).
Because what is being talked about flew right above your head. Ironically, the mechanism you describe was the one used until systemd appeared.
Which is ironic because you weren't even aware of how insecure your sysvinit setup was.
Systemd does it better: it does not escalate your priviledges, it keeps control of how the function is executed, you never gain control of the how. You only gain the rights to ask for a system change to be made.
For example, you can be given the right to change the server hostname (which can break your DBUS and DE) or the desktop clock. But you are not actually executing setuid binaries. Or another example, you can be a step above allowing every user to use the sound card when you have multi seat or multi sessions setups (like I do).
If you can't understand the distinction between the two ways of doing things, as is apparent in your post, try not to talk about it, your post made me cringe with the cluelessness.
> Yes, it is too hard for the actual whiners we have, but it would be easy, beyond simply "trivial," for any Jr Sysadmin or even a Jr Software Developer if they've ever used make
I'm afraid that's not true. Take a look at the Fedora work going on right now to try to segregate systemd components, described at http://news.softpedia.com/news... .
Oh my, you say it's not true, then post a link that proves you wrong.
Are you even understanding what you're talking about?
The problem Fedora faces with their two sub packages, is that they have to add functionalities that then would not be in the default systemd package.
If they were already in the main systemd package, their sub packages would not make sense anymore, it would defat their purpose.
These are components that should never have been integrated into an over sized and aggressive systemd in the first place. I've taken a few stabs at segregating systemd components myself, and it's a very large octopus of dependent code.
You sound like an emotional clueless person, not like a developer. What is an over sized systemd? What is an aggressive systemd?
Systemd reduced the size of my hand made systems (I've removed at least sysvinit + tons of scripts and several binary helpers + xinetd + dhcpcd at least) so to me it is not over sized, and it has never actually been aggressive to me, on the contrary, I've fixed several long time invisible misconfigurations by myself thanks to it.
I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
No, the problem is you can't read and mixed CK and CK2. So the GP is correct, and you are still wrong.
This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.
An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic?" That is what they are talking about: you can't get that stuff separately from your init system.
Then people saying that are wrong, as this functionality is not in the init system. It is in several parts (so not monolithic), logind being one, and logind is assisted in the task by dbus and systemd init, which themselves are assisted by the Linux kernel.
This assistance and dependencies are necessary to assure a minimum of security.
The problem is, for years now, we have been assured that Open Source was the cure for problems.
Wrong, that's you rewriting history from your dreams. Nobody assured that.
Just notify someone, and wait, and your problem will be fixed. I had it happen so many times in the old days. Now, developers apparently have stopped caring about this and care only about developing products for themselves.
It was always developers scratching their own itch. And if you couldn't develop, you could pay someone to do it for you.
It always was this deal, you changed "pay someone" to "notify someone" in your delusions.
Sad, but what are you going to do? The concepts that made Open Source a big hit are being abandoned. Open Source isn't going away but it is definitely becoming less popular. Good news for commercial software companies that listen to their customers.
Oh, I didn't understand right away that you were a proprietary software shill, my bad, it should have been obvious, no true Free Software actor could be so deluded and so clueless.
It is strange that you talk about "non-systemd distros" as if they were defined until then by this.
What are the "non-systemd distros" that are crumbling? If anything is crumbling, it would be more "systemd distros" that get considerable amount of developers forking, founders resigning, etc, not to mention users looking toward BSDs.
FUD is a proprietary OS shill tactic. If you don't understand why distros are separated in systemd ones and non-systemd ones in this thread, you're hopeless.
Also, was it obvious since years that systemd would go in so many direction and that, wherever it goes, code would be throw away? What is then to support?
It was not obvious, because often, the code thrown away is because the underlying plumbing component is abandoned for years, or not supported anymore by anyone.
systemd devs are actually maintaining lots of code nobody wants to maintain anymore.
Isnt it a joke in the end, to support alternative to systemd that actually have to do exactly what systemd does in order to be actually any good?
Yes, I agree it's really stupid. Besides, the people that say systemd features are useless, or that systemd doesn't have any upside, it makes them look plain stupid and clueless.
pm-utils is the example. Was it obvious that upower would throw support for pm-utils? Why was it discarded? Wasn't it discarded because, as pointed at by Edmunson "adding it [systemd] as an optional extra defeats the main benefit"? So what is the joke about writing alternatives when it is clearly that systemd cannot be optional (meaning that alternative must really be systemd compatible, and not the contrary)
It's not like that at all. It's rather that systemd proposes a systemd API for several things. There are a lot of field where systemd is the sole provider of an API, so is the de facto standard. And why is systemd the sole APi provider in some areas? Because while DE were asking for these API, systemd was listening and providing them, while others were not listening and busy telling systemd these features are useless.
It is not really as if we were in a situation where desktop environment on GNU/Linux mattered much. It is not desktop environment that made GNU/Linux popular. At all. There are practically inexistant, if you really loves facing realities. They have a bunch of users. Nothing else. If they can afford too loose more of this bunch in the name of "reality", why not. I'm not sure it is for their benefit.
See your cop out? This is the problem with non-systemd distro: no problem is solved, only cop out, whining, complaining, but you never solved anything, just wasted time. Systemd opponents are mostly like that, that's why I can't take them seriously. I've followed systemd since the beginning, I've seen the amount of work done and the attitude towards users (DE, sysadmins, distros...), and I've seen the work done by those opposed to it. Given this knowledge, up to this day, I predict complete failure of systemd opponents on Linux.
I started using KDE with KDE 1. But I also used Enlightenment, GNOME 1, WindowMaker, Fluxbox, XFCE and many other, I dont feel tied. There are parts of KDE I like and I'd enjoy being able to continue using it and continue to recommend it to other users.
I'm not sure it will be actually possible because, you see, I'm facing the reality, that systemd alternative right now is another systemd. Hence today topic.
I had hopes that Devuan could be enough. Now, after one year, I'm suspecting it could not. Not because of the "non-systemd distros" people, as you name it. But because if the game is rigged. "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit": it says it all. Thrown away code, no benefit if optional. It is
And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd?
They removed pm-utils because it didn't work well and was abandoned since 5 years.
People mostly complain about systemd taking over active management of things long abandoned by everybody else.
It's a dogma it seems, a self destructive one, to bash systemd for good things, which is even worse.
Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not?
If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative?
Most of the time, it's either removing a useful systemd feature entirely and going back several years in time and functionality, or reimplement in true NIH style what systemd already provides.
Sometimes, the reimplementation fails along the road when the "amount of work required" bar goes above the "hate systemd feeling" bar.
The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won't do.
And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers.
Which is an exemple of what I said above, with a probable failure as outcome.
Hence the question: will KDE be still usable in 2016 without systemd.
That's actually a very good question.
So while I'm sure the systemd zealots would love to see KDE, Gnome3, etc. only work with systemd and drop support for all other distros, this doesn't appear to be happening. In the case of KDE, ConsoleKit2 is supported (and therefor Funtoo, Gentoo, Arch with OpenRC, etc. will continue to work just fine).
There lies the problem, you anti-systemd zealot are taking an antagonistic stance to all this, assuming that what you call "systemd zealots" would love to see KDE work only with systemd. That makes no sense at all, and that would mean DE devs are "systemd zealots". But all the DEs communication and actions points to you being completely wrong.
Thay actually work instead of complaining uselessly and spouting antagonist nonsense about systemd.
With documentation like that I tend to wonder whether idiot is the correct term, or whether malice should be assumed.
Taking an AC on Slashdot as your source, I wonder whether idiotic is the correct term, or whether malice should be assumed.
A real concerned developer would have already started there http://www.freedesktop.org/wik... and looked at "Documentation for Developers".
What's the upsides?
The major downsides are that it's impossible to figure out what's going on and that the log files are binary instead of using syslog.
Don't worry, you can go play with your favorite DE, real sysadmins are taking care of systemd for you.
If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
by taking over and forcing out all other options, it becomes a monoculture. and that, as we know from decades of experience where monoculture OSes have created cartels and monopolies, is incredibly dangerous.
So POSIX is incredibly dangerous? Your argument is flawed from the start.
systemd provides a standard API, and nothing about a standard API is dangerous, a standard prevents the creation of cartels and monopolies, so what you say is already the contrary to the probable outcome.
now i am witnessing a process by which everyone in the GNU/Linux community, by working in a totally dedicated way in "their corner" that has to be respected precisely *because* it is so dedicated, yet as a whole *all* of us have gone "hmmm, i'm working in my corner, the global problem isn't my problem: i'm making local decisions, here, which make my life easy and i'm doing what i think is best", totally forgetting that the overall consequences are like a shoal of fish: EVERYBODY has "flipped" - all at once - and the direction is a dangerous one that no one person has any responsibility or control over, because we are *not* a company, we do *not* have a "Board of Directors who can give us orders that we are required to follow or be fired", we are a bazaar - a self-organised group of self-organised individuals with independent free will and highly-focussed responsibilities.
the "flip" is to a dangerous monoculture position with, as we are now witnessing, absolutely zero choice (bad choices are no choice at all) - which i've warned about well over a year ago, and was told, basically, to "fuck off". well... now we begin to see the consequences.
What is this nonsense about? I've seen nothing of the like, and I make all my OS from source since 15+ years.
i am running fvwm2 - i have been for 20 years - and i am using angband.pl's recompiled versions of critical dependencies (udevd and others) all of which have "--no-systemd" in the configure.ac files. so i will not be concerned about trojans that attack vulnerabilities in systemd, exploiting the new features such as allowing the firewall to be disabled and much, much more. but you - all you who trust the systemd authors and the desktop environments that now operate exclusively on systemd? you should be concerned.
Talking about security in systemd compared to sysvinit shell scripts is just laughable. Fortunately you've not been 20 years in the security IT field.
Just look at most trojans and rootkits, before saying nonsense like that. sysvinit scripts are a security nightmare in themselves, and are impossible to audit.
BTW most of them don't work anymore in systemd, especially if you've hardened your systemd service files.
This is confirmed, along with the difficulty of unfurling the systemd init tools to try and start the fractured daemon cleanly in a debugger.
What is confirmed?
systemd by default sends stdout and stderr to the journal, contrary to daemon launch with init shell scripts.
The AC is repeating sth false, as several of them do in every systemd thread.
I don't know what their agenda is.
What's even better, the system default for this behaviour is configurable, and it's also configurable per service.
I agree with binary log files having some serious issues, and I can easily imagine that replacing the logging system with it's predecessor is an ugly hack.
I wonder though how difficult it would be to replace journald with an interface-compatible logger that actually outputs good old fashioned text logs instead? Knowing nothing about journald or it's interfaces, it seems like it shouldn't be a huge problem - just fork off journald_txt, changing only the actual file output components. I would assume all the relevant data still enters the logging system, I mean there *is* a dedicated journald log reader, right?
Why are you believing nobody else thought of that in the first place? If it's because you're clueless, why are you criticizing a topic you have no knowledge about?
Of course there is a dedicated journald log reader, it's called journalctl, this is the most basic thing to know about journald before even attempting to criticize it.
Just installing another syslog daemon (like rsyslog) is enough to removes all these concerns, because yes, several people (serious ones) have already done the work instead of complaining based on ignorance.
I disagree on the "full-throttle" part. That's be fine on consumer desktops. But Linux is mostly about production servers. Yes, yes... I know... mainstream Linux on the desktop is "just around the corner" and all that. :)
Why are you disagreeing on something that you say is irrelevant to your servers?
I have no great love for sysV init scripts. Getting rid of them would break a few things in my world. But really, those things could probably stand a new look and update anyway. But my second-to-main issue with systemd is that it's just somewhat half-baked and obtuse. There's a lot of "don't look behind the curtain, just trust us that it'll work" to it.
So your world is improving, as sysvinit is even more "don't look behind the curtain, just trust us that it'll work". So much so that you also have to believe that for any distribution that used sysvinit, as every one of them had to implement the "behind the curtain" part, and was saying to you "just trut us that it'll work". Duplicated functionality in every distro, that have now disappeared for a big part. So now it's far better, in every kind of GNU OS on Linux use case, even on non GNU ones.
My biggest gripe about systemd, though, is its counterpart in crime: journald. Binary log files are the work of the devil and journald needs to die in a fire. And no one... not even a couple of Red Hat engineers I've spoken with... has been able to give be a non-hackish, production-worthy, way of ripping journald out of the thing and replacing it with syslog.
syslogd is antiquated, no distribution uses that by default anymore on Linux distros (LFS is not a distro). They use syslog-ng or rsyslog, and they plug without any problem with journald. Ripping out journald makes no sense and actually would put you back to the bad days of logging before systemd: no automatic logging of stdout and stderr, loss of kernel boot messages, no display of last messages from your services, impersonation of other processes possible in logs...
So that means systemd is not the esuivalent to scm in Windows, it would be at least equivalent to smss + scm. And in fact it's much more, even if you're talking about only PID 1 systemd.