Slashdot Mirror
Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?
New submitter yeupou writes: Early this year, David Edmundson from KDE, concluded that "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". A perfectly sensible explanation. But, then, one might wonder to which point KDE would remain usable without systemd?
Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the "Debian fork" I'm using to "ripe out" systemd without "coming with any of the supported solutions Plasma provides". I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.
While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit". So, is it likely that we'll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?
Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the "Debian fork" I'm using to "ripe out" systemd without "coming with any of the supported solutions Plasma provides". I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.
While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit". So, is it likely that we'll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?
Just use Windows.
Zips up flame-proof suit. Dons shaded goggles.
Yes, if you roll your own.
Linux is not just a DE
It is the kernel, the file system, the desktop environment, the package management.
OS X
I am Slashdot. Are you Slashdot as well?
Software developers make .service files with their packages these days.
Of course not. Lennart's not going to be happy until he controls the whole OS.
As we've all learned from Apple: No half-assed shit. Do or don't do. No place for inbetween stuff.
systemd has downsided but it also has upsides. We should stick with the upsides and patch the downsides until they're basically a non-issue.
I don't do much init-fiddling although I do like the text based init/runlevel thing, and I would guess that plug-and-play - one of systemd's strong areas - should be a userspace problem, but that's just me not really know what's going on in the init process.
However, since all major distros have moved to systemd it can't be that bad as some people make it out to be. I trust the debian and ubuntu crew to know what they are doing at init-level.
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance. Seriously, who cares? It's mostly Linux left, right and center these days anyway. The BSD people will be fine with whatever they choose as init process, as usual, and no one gives a damn about other non-FOSS unixes anymore anyway. Unix basically is Linux these days.
But, as I said at the beginning: There is no use going systemd, but only kinda so-so. If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
My 0.5 eurocents.
We suffer more in our imagination than in reality. - Seneca
They don't. If you don't like the way Linux distros are evolving, then try out another OS that uses X11. Who knows, maybe a push towards FreeBSD will help speed up support for more hardware there. There's of course some certain apps (GParted for example) or limited features in a Desktop Environment that depend solely on Linux, but I find that to be generally rare, especially when looking at what FreeBSD Ports supports.
My oldie-but-goodie Slackware Linux is still staying away from systemd, so I'm glad about that.
> Post the issue to your distribution not the systemd group.
It's a problem with almost every distro, right? Like what doesn't have systemd, slack?
Die Systemd! I prefer my log files in text format.
I chose. I went back to windows. I use BSD as a linux replacement where linux was best at the job (being a router and fileserver). However, with systemd, linux makes for a poor desktop environment, so I went back to the second best one (which is now the best).
I have free will. I just decided not to switch to BSD.
I hope that the influx of users to windows doesn't harm linux's chance at the desktop, but users have free will and aren't forced to run any certain software. Also, by that measure, nobody is forced to improve video drivers for linux or port video games there. Which will not happen when more and more people choose windows.
But hey, haters gonna hate, and I don't care about linux's ecosystem anymore. Let it burn. Perhaps the flames will get hot enough to drive the evil out? I won't know, I'm pretty happy with windows 10 and once again relegating unix to the servers. Yes, I'm being serious. I could be satisfied if it stays this way forever.
I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system. Why does the desktop care who's booted it up?
More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
is no longer the ancient monolithic beast you learned to love
Don't you mean "is becoming the monolithic beast we moved away from when we first wiped our Windows install"?
Modularity with a standard interface and substitutable glue - i.e. small tools which each do one job well, always with alternative implementations - were the hallmark of Unix. Now the alternatives are Lennart's software or clones of Lennart's software, and a BUG is something which doesn't work exactly like Lennart's software.
No, the reason for systemd isn't that it's better. systemd has been chosen for the same reason almost everyone votes Democrat or Republican, spending ages arguing over minor details but failing to see that there's no real choice at all: if you boil the frog slowly enough and distract them hard enough with shiny, people stop paying attention to what's going on.
Linux the kernel goes from strength to strength, but GNU/Linux the desktop operating system is over, and Linux servers are fast becoming Lennartix. Is this good? IDK, is the cathedral model of software development good? It worked for OS X. But it's not the same system at all.
If you're allergic to trimming your neckbeard and running a modern init,
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
"First they came for the slanderers and i said nothing."
That was a very nice post and all, but I really lost focus after reading "Do or don't do" instead of "do or do not".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I don't do much init-fiddling although I do like the text based init/runlevel thing,
It's pretty clear that if KDE depends on one particular init system, that systemd is no longer just an init system.
"First they came for the slanderers and i said nothing."
To build Linux from scratch, you must first invent the universe.
Will you be able to run a modern Linux desktop without systemd in 2016? Yes. Will you be able to run all modern Linux desktops in 2016 without systemd? Probably not.
KDE and GNOME appear set to fully adopt systemd as a dependency, but most other desktops probably will not. Cinnamon is developed by the Mint team and they still use SysV init. Lumina is cross platform and developed by PC-BSD, so they will never depend on systemd, Xfce is still developed and probably won't adopt systemd as a hard dependency in the near future...
As we've all learned from Apple: No half-assed shit. Do or don't do.
I believe that was taught by Yoda, not Apple.
For Linux, I am afraid the battle is lost... systemd has become exactly what its distractors were afraid of: an operating system on top of the kernel (and, in some cases, in replacement to bits of the kernel). As systemd continues to consume other functions, it will be even more entwined and harder to rip out.
All this is kind of sad because it really shows what focused corporate interests can really push onto a community, no matter how much a community complains about it. For me, this is what I am most "anti" systemd about. Yeah, it's a large, monolithic target; yeah the people behind it are mostly control freaks with really moderate skills; yeah, it replaces a small messed-up implementation with a significantly larger and more messed-up on... all these things and more could be forgiven. What can't be is the abuse of power and privilege that allowed this to happen.
Correct. Systemd is not about a modern init system. There are tons of modern init systems being worked out now.
Systemd is pretty clearly an init system. It's just that if you don't use that system, you can't use a lot of other stuff.
The kernel is much more complex than an init system, and we've mostly figured out how to swap that out without difficulty. Swapping out an init system should be relatively simple in comparison.
"First they came for the slanderers and i said nothing."
Take a look at antiX Linux and MX Linux. They are both modern distros with fairly modern desktops and they don't use systemd.
We don't see the world as it is, we see it as we are.
-- Anais Nin
To fork or write your own desktop environment if you don't like it, that is the point of open source; not the ability to force other people to kowtow your arbitrary system choices.
It makes sense that KDE would like systemd. They both are bloated and do far more than they need to.
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. :)
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. That'd be tolerable in a consumer OS, or even in a consumer-targeted Linux distort like Mint, but not in bloody RHEL and Debian!
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.
Imagine all the people...
Keep systemd, kick out Poettering.
????
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
$subj is another part breaking modern Linux OSes which we should get rid of. Each month a new breakage, this month it is USB speakers invisible to software playing via pulseaudio while still addressable as an ALSA device.
So now there's no Gnome or KDE on anything but Linux.
That is Lennart's plan. Here's what he says::
"I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore."
"First they came for the slanderers and i said nothing."
its because systemd provides features that are normally root only, and delegates them through dbus and a permission system through to logged in users. This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation. If they were to support all inits, they would have to reimplement a lot of the parts of systemd. They used to do just that. They have both decided to stop doing that and just let systemd do it. GNOME/KDE are doing the right thing IMHO.
If the other init systems want to gain support, they have to support this same kind of functionality somehow.
kde or gnome as they are desktop environments not window managers.
What difference does that make to the current discussion? I'll happily concede that point if you stay on topic. Neither KDE nor Gnome should depend on a particular init system.
"First they came for the slanderers and i said nothing."
The problem is that it's *not* a modern init system. In fact, I'm not really sure how to describe systemd apart from, "An overreaching solution to a problem that never actually existed". I don't think there is a single thing I can do with a systemd enabled system that I couldn't do in a 2008 version of Ubuntu. So, apart from complexity and a variation of vendor lockin, what has the linux world gained by moving to systemd?
Without Systemd Wiki: http://without-systemd.org/wik...
But the Tab Window Manager is a window manager, not a desktop environment.
If this is going to be the case, then we need a Systemd specification or RFC maintained by a widely respected committee and multiple implementations should be available.
Sigh.
First, only an idiot would want a monoculture, particularly in the Linux world, so to those saying "just to systemd full bore or go to (someplace else)" the rest of us need to respond with a very loud and resounding: Fuck You.
That said, things aren't nearly as dire as this post implies. Reading from the responses to the bug he himself linked to, I find the following:
> Unless KDE is prepared to make a statement that it depends on systemd
of course not. Powerdevil recently also gained support for ConsoleKit2, see: http://commits.kde.org/powerde...
Which turns it into a distro problem. Your distribution configured the system in a way that suspend/hibernate is broken. It doesn't come with any of the supported solutions Plasma provides. Which makes it a distro problem. The distro integrates various parts of the software stack. This includes it's the distro's task to ensure that components work together. It failed here by ripping out systemd and replace it with well nothing.
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).
The Future of Human Evolution: Autonomy
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.
"First they came for the slanderers and i said nothing."
A Window Manager doesn't mess with power management, or sound, or input devices, or screen resolutions, or... it just manages windows. Once you want to start dealing with all that other stuff mandatory to a modern desktop environment, then you're way beyond "window manager". Or does the relatively miniscule window manager component of KDE or Gnome depend on systemd? I'll admit ignorance on that.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
> Post the issue to your distribution not the systemd group.
It's a problem with almost every distro, right? Like what doesn't have systemd, slack?
Yes, Slackware does not have systemd. And, as far as I know, has no plans to integrate it in the future (which is one of the reasons I love it).
On the other hand, OpenBSD systemd "shim" looks better every day, as it allows Gnome to work without systemd. Make of that what you will.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system.
"First they came for the slanderers and i said nothing."
> "don't look behind the curtain, just trust us that it'll work"
Except when it doesn't and since it swallows stderr and a lot of syslog messages, you can't troubleshoot. Something that would take 30 seconds with Sys V init scripts can take hours since you have to resort to using strace with systemd to try to find problems by looking through hundreds of thousands of lines of output.
The questioner has it the wrong way around.
The systemd team didn't create those dependencies, the DE maintainers did. All of these DEs ran just fine without systemd and they still could if someone was interested in doing so. In fact given the maturity of the old interfaces, and the code already existing in previous releases it should be much easier to maintain say, KDE or Gnome, without systemd that it is for the team trying to add it in. There is nothing stopping people from forking the existing code and running their own project, we have seen this happen in the open-source world dozens of times. If there is a lot of demand for systemd less distros, the community will make them.
The question isn't "Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?". The question is "Where are all the systemd-free projects?".
Linus said talk is cheap show me the code. So where is it? For all the complaining, flamewars, and cries of fleeing to *BSD you would expect systemd-free projects to be springing up left and right. So where are they? If Red Hat is making such a huge mistake switching to systemd, then surely their competitors at SUSE, Cannonical, and Mandriva will capitalize on that mistake in the name of profits no? It isn't surprising that seemingly everyone is adopting systemd. systemd is solving problems and implementing feature that people want. That is easy to explain.
What is remarkable here is the massive disconnect between the amount of outcry about systemd and the amount of code being written to avoid it.
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
All of your questions are easily answered by reading the link provided at the top of the article:
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Why does the desktop care who's booted it up?
The Init System "We don't care. It doesn't affect us."
logind Allows KDE to provide user-switching features.
Device Management Allows KDE to have access to your mouse and keyboard without root access and without random applications being able to sniff your keystrokes.
Inhibitor Locks Allows KDE to react to notifications like "the system is about to go down" and delay until a condition is met (example: delay a suspend until the lock screen is displayed and all your desktop windows are hidden behind the lock screen).
timedated and Friends Allows KDE to set time and date without root; allows KDE apps to be notified if time and date gets changed. (KDE currently runs a daemon just to watch for time and date changes, and they would like to get rid of this daemon and simplify their code.)
User Units If KDE takes advantage of the "units" in systemd, then when any part of KDE crashes or hangs, systemd will restart the misbehaving part.
that implies they won't work on *BSD at all. Right?
"Projects like [SystemBSD] bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features."
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
I encourage you to read the whole article and see what big things you are missing.
I don't know about you, but when I read that article I didn't think "Man those KDE guys are idiots, why would they want any of that." It all makes sense to me.
It's easier for me to believe that SystemD has some merit than to believe that all the Debian core developers are idiots, plus all the Ubuntu developers, and now all the KDE developers and for that matter the Gnome developers.
My biggest concerns with systemd are the monoculture of it all, so projects like UselessD and SystemBSD sound great to me. Force the SystemD guys to document and justify everything, and provide alternatives.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Can you implement it outside of an init system? Please do if you can, and good luck. :) so far, they have been the only attempt that seems to work properly.
KDE is NOT bloated. It was once, but it hasn't been in a long time. People keep carrying on this myth and making people miss out on a really great desktop.
I was going to do a line count on various calculators source code, but I think just the size of the source packages fropm ubuntu wily tell it like it is:
out of kcalc (KDE), gnome-calculator (GNOME) and galculator (LXDE), KDE's Kcalc is the smallest.
152022 kcalc_15.08.2-0ubuntu1_amd64.deb
261882 gnome-calculator_3.16.2-1ubuntu1_amd64.deb
159468 galculator_2.1.4-1_amd64.deb
This actually requires people to write replacements that use similar interfaces to systemd.
That probably isn't too hard, but no one does it.
The systemd camp say they do not want to write code for systemd and then write another implementation for those avoiding systemd. And that is fair for them.
Those complaining about it need to step up and write the code - the desktops are using defined interfaces and if other software provided the same interfaces, they would use it.
Systemd never was, and never will be, just an init system. The init system is just a small part of systemd. The init system isn't the part the desktops are depending on. It's the interfaces to other subsystems the desktops are depending on, such as the power management interface and the hotplug interface.
This is your sig. There are thousands more, but this one is yours.
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
"First they came for the slanderers and i said nothing."
If you're allergic to trimming your neckbeard and running a modern init,
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
Correct. But KDE isn't just a Window Manager. There is no reason why a Window Manager should interact with power management.
As I understand it, as someone who could care less one way or the other, systemd isn't a solution for end-users, which is why you don't see any substantial changes. Its a solution for *developers*, freeing them from having to deal with the mountain of hacks, kludges, and assorted ugliness necessary to provide modern desktop-environment features through the decades of cruft and "ideologically pure" compartmentalization provided by the lower levels of Linux.
It doesn't offer new functionality - it just removes a maintenance nightmare for Desktop Environment developers, allowing them to focus on actually working on a good DE, rather than all the ugly backend stuff behind the scenes. The big issue, aside from ideological purity, is that in systemd massively redesigning that backend stuff there was inevitably a lot of lost functionality - you can't replicate the functionality of decades of accumulated cruft overnight. And major DEs don't want to wait until there's complete functional parity to adopt it, for a couple big reasons (and probably many more I haven't thought of):
1) Waste: if they plan to adopt the project eventually, then the longer they wait, the more wasted work they do maintaining deprecated systems.
2) Momentum: you want to adopt a project when it's both "good enough" and has a thriving developer community in order to help maintain its momentum. A project no one uses is eventually going to start shedding developers, and may never reach functional parity at all (see GNU Hurd, etc.)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I use & like Lumina, but they recently made some changes to their user interface. The pull down menu for exiting was at the top right, and they suddenly shifted it to the top left. They need to realize that a consistent look & feel across versions is important. It's not that I can't go to the top left - it's just that after a habit is formed, to have to change it in a new version is disruptive.
I would like PC-BSD to own the Wayland implementation of FreeBSD, since the latter seems to be more focussed on the OS services - from things like portsng to Capsicum. Right now, when you install the OS, if you want to install any DEs, FreeBSD prompts you to install PC-BSD. So make the Wayland implementation in FreeBSD a part of the PC-BSD project, just like PBI and usability issues. I'd also like to see what, if anything, is FreeBSD doing as a succession for system init.
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.
There is a basic principle that drives the evolution of Libre Software, or at least the majority of it that is developed by a community:
Developers have the final say.
Developers make technical decisions based on technical merits and usability decisions based on their own use of the software, because they usually use their own software. They do not kowtow to the whims of a client or a commercial director.
Arguably, systemd itself is developed under the aegis of a single company, not a community. But KDE is undoubtedly a community project, and so are Debian and the other distributions that chose to switch to systemd. They did so not because they were compelled nor because Lennart Poettering brainwashed them them, but because, from the height of their technical expertise, they consider that systemd makes their task easier while respecting, or possibly even furthering, their usability goals.
As for the anti-systemd crowd Well, I know a few that develop and promote radically different system monitoring architectures, and they have valid arguments against systemd. As for the others, show us the code.
I just uninstalled GNOME 3.16 from my system due to its systemd dependencies: it is too slow in loading in PC-BSD. However, KDE is usable, if resource heavy.
But I do think that PC-BSD should have a plan on Wayland.
If any other init system + provided the features necessary for the modern desktop environments, then I'm sure they would not hesitate to support it
The init system should not be providing those features. That is entirely the problem.
and no one other then systemd has bothered to create a viable solution to the destkop environments problems.
What was wrong with Powerdevil and pm-utils?
"First they came for the slanderers and i said nothing."
KDE was heavy at the beginning, but I disabled Nepomunk and Akonadi, and haven't had any issues since
Speaking of which, if one can figure out a way to install emacs on systemd, one has the perfect system - no need to worry about linux vs bsd if all emacs needs to use are services provided by systemd
If someone doesn't want their modern desktop to run with modern underpinnings they should fork it. I'm sure KDE wouldn't mind - in fact they might welcome it since it simplifies their code base. They can make systemd a core dependency on Linux, remove heaps of cruft and refer the objectors in the direction of the fork.
Yeah and no. As pointed out in the article, the culprit is upower. But upower is mandatory for KDE power management. So it does not really matter whether it is Powerdevil that requires systemd or upower. ConsoleKit2 recently gained support? Was ConsoleKit2 actually been packaged? Does upower supporting ConsoleKit2 been packaged? If not, user experience wise, that is not palatable. And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd? 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? Just as a reminder, ConsoleKit2 exists "because there isnâ(TM)t currently a standard for system actions like suspend/hibernate anymore. We use these features in Xfce and it would be nice to keep the session manager and power manager in sync (i.e. you inhibit something and the session manager doesnâ(TM)t see it). Obviously thereâ(TM)s systembsd in the works, so this is a stop gap until that matures (however long that may be). But Iâ(TM)ll happily continue to maintain and support ConsoleKit2 as long as someone finds it useful". https://erickoegel.wordpress.c... 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. Hence the question: will KDE be still usable in 2016 without systemd.
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance.
Not that systemd affects POSIX compliance (and not that Linux is certified as POSIX-compliant; I haven't found it to be significantly worse than any other UN*X in terms of "annoyingly different from everybody else" - frankly, if there isn't at least one thing your UN*X-family OS does annoyingly differently from all the other UN*X-family OSes, it can't really call itself a UN*X :-)).
Yeah, once Slackware gets better on my arm SBC I'll be switching to it too!
Obviously. And that's covered in chapter 0.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Except when it doesn't and since it swallows stderr
A sane background/daemon process launcher sends stdout and stderr somewhere where it gets logged. Are you saying systemd just sends the standard output and error of stuff it launches to /dev/null, or that it sends them somewhere that's not easy to process? (Launchd sends them to the Apple System Log mechanism, which, yes, does have a binary log database, but ASL also sends stuff, including the stdout/stderr from launchd-launched processes, to the Boring Old Text File /var/log/system.log.)
So now there's no Gnome or KDE on anything but Linux.
There are many of us made happy by that. One less thing to remove from our systems.
To the original question, though: the answer is yes, you can run anything you want on a system with no systemd. That's the point of open source; you can do whatever you want. If systemd really bugs you that much, just build yourself a system without it.
I guess the point is: KDE isn't a "window manager" - instead it's a desktop environment, which includes functionality for power management. And it's reasonable architecture for power management controls to depend upon power managing daemons.
The kernel is much more complex than an init system
For now, it is. Just give the Systemd team a little more time, and that may change.
Go on, citizen, stamp the vote card. R or D, your choice.
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?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
If you're allergic to trimming your neckbeard and running a modern init, just switch to *BSD where they adopted the features that people are whining about decades ago. ;)
Haters hate, but do they know why? Do they have a choice? Do they have Free Will, or were they born unable to tell the difference between choosing software they want to run, and being forced to run software that... they chose?
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...
- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...
- 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/...
- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...
- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi...
- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys...
- Enabling the kernel "debug" command line option results in boot storage being filled with thousands of dmesg log entries per second from Systemd, and a non-booting system results
https://bugs.freedesktop.org/s...
- Systemd disables SysRq keys to ensure data loss after any of the many many instances it is coded to fail under
https://lists.debian.org/debia...
That's a very level headed pro-systemd argument and, while I understand the sentiment, I can't agree with the approach that systemd has taken to accomplish this. In particular, letting an init system, strongly controlled by a single party, morph into an abstraction layer of the OS to such an extent that it's impossible to avoid it.
Mod this guy up. Finally, somebody who knows what they're talking about.
The real question is, "Will self-driving Uber cars use systemd when Elon Musk takes them to Mars?"
You are welcome on my lawn.
And they don't - one of the main complaints people have, unless I'm mistaken, is that systemd isn't just an init system, it also wraps up a whole lot of things into a "low level system manager". You can certainly complain against that on grounds of ideological purity - but that's a completely different conversation.
So we have something-that's-far-more-than-a-window-manager depending on something-that's--far-more-than-an-init-system. There's certainly arguments to be had about design decisions, but they can't be had if you insist on using irrelevant terminology.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Do they have Free Will...
I read that as "Do they have Free WiFi?".
I must have spent too much time in hotel lobbies lately...
That is your brain fighting back against the "$99 wifi available now" subliminal messaging. There is hope for you, but I recommend a tin-lined wig, just to be safe and blend in.
>Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate.
You know what the problem with that is? Why on earth does KDE even includes power management? And network manager and and and. All those should be just deamons or command line utilities common to all the distros.
Linux is so fragmented it's not even funny. Forked to oblivion.
I fear the day where Apple finally makes OSX as dumb as iOS is. As since Ubuntu switched to unity there's basically no real alternative. It's so sad how fast it went all downhill since what, 2012 or something. Crazy.
And systemd is just another nail in the coffin.
I guess the point is: KDE isn't a "window manager" - instead it's a desktop environment, which includes functionality for power management
Yes, I think you are right.
And it's reasonable architecture for power management controls to depend upon power managing daemons.
But it's not reasonable for it to depend on a particular init system.
"First they came for the slanderers and i said nothing."
I think you missed the simple fact that everything was working fine before, without cramming everything in the init process. Power management, in this case, existed before systemd came, and everyone was using that just fine.
The system was flexible, allowed for easy replacement and customization at every step. Only downside? Beyond basic use, you had to touch the config by hand. Now this option simply doesn't exist anymore, and a lot of people believe that whatever systemd does now, it's the only way and that without them nothing would work.
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
Modern desktops aren't just window managers... They are increasingly tightly integrated with ever more aspects of your computer, ranging from power management to device discovery, wifi and network. In the future with xdg-app, we'll see package management becoming part of the desktop environment.
A few years ago one of the gnome devs told me that he really wanted gnome to develop an entire distribution, so they could control all the layers of the stack. In his opinion it was the only way to make a proper PC experience. I think there is something to that...
Why should major desktop cater to power users who wants to compose their own desktop, if the linux desktop is to compete with OSX and windows, they need to create a more tightly integrated desktop. And they are working towards this.
Honestly, I think it'll be great! All the ranting against systemd seems unfounded.
You'll have to ask the GP, I was quoting him/her.
"First they came for the slanderers and i said nothing."
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. :)
The question here is: What's with serverhosts these days? They are either embeded/integrated or virtualised. No one screws around (literally) with hardware anymore - not in a time where soc pcs cost less than 10$ a pop. So there is no need to fumble with init on that level. I haven't touched init or even runlevels for just about 10 years now - and I do lots of server stuff.
These days im running all my services in VirtualBox and copy, booting and ditching entire VMs at my whim. Fiddling with init would be a waste of time.
If you have a stripped down serverconfig that you have to distribute and scale, I doubt systemd will seriously get in your way. Yes, you have to hook your init stuff somewhere and yes you'll have to read about how systemd does things at this level, but on a dedicated server that might aswell happen in userspace or somewhere late in systemd boot. I'm sure systemd offers hooks for quick late-boot custom fiddling of some sort.
Bottom line:
If finally all the Linux proggers get on the same page I'm all for it. If that page happes to be systemd, so be it. Simply the benefits of all getting behind systemd will move Linux forward faster than ever - that's my newest prediction anyway.
We suffer more in our imagination than in reality. - Seneca
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
Because the whiners don't have a use-case. systemd is modular, but it tends to come with all the modules packaged together. They could simply move the non-init functionality (which is the parts that these other packages depend on) into their own package, and just install that. But I guess their fingers would get contaminated by re-packing those parts of the source?
If you read the link in the post you responded to, it explains most of this stuff. It is modular, but the people managing it are using all the modules, so the default distribution contains them all. But you can use just the parts you need, and replace the parts you don't. It just requires simple grunt-work to manage packages the way you want. Thousands of loud whiners, but none that actually have a reason to need a different set of the modules, or the ability to do a simple repackage.
The only reason that the distros don't repackage those parts to be separate is that there is no reason articulated to do so. Whiners just whine, but they don't say words that would have any chance of convincing professionals that they have a differing use-case. We understand they're unhappy, but they don't identify reasons that are technical and real, but rather their reasons are aesthetic and arbitrary. By arbitrary I mean, everything they're doing with their computer still works; all their software still works; all their use cases still work, but they're unhappy for entirely optional reasons. They're choosing to be unhappy, but there is nothing actually wrong. Which from an engineering perspective appears to be entirely "user error." They're using it wrong; if they want to be happy while they use it, they just need to smile more. It is not actually biting them, or making them cold, or eating their cheesy poofs.
It's not clear what you mean by "tight integration."
But it's not necessary to have a monolithic system in order to make something good.....to avoid it you need to make clear interfaces.
As mentioned, the kernel has to deal with much more integral and disparate pieces than systemd does, and yet it is still relatively simple to swap one kernel for another. If the kernels can do it, then there is no excuse for systemd.
"First they came for the slanderers and i said nothing."
Systemd is the reason Linus is now using FreeBSD at home.
Forgive me for asking but, what is systemd's main benefit? If i don't mind that my system boots up slower and in a sequential order, how does that affect the systemd's benefits for other users?
I really don't understand that statement. It sounds like nonsense to me. Please tell me because I honestly don't know what the snot he is talking about.
If systemd's main benefit was to obscure the boot process to prevent users from knowing what was going on during the boot process in order to squeeze in weird or unwanted code, then it would make sense that they don't want any users to know about that potentially questionable stuff so letting them use init would be detrimental to their efforts.
I can't see how that benefits me though. I don't care about what benefits them. If i'm trying to build a secure, manageable system, i'm looking for something that benefits me.
Mr. Steven Burn of Malwarebytes
Speaking of Mr. Steven Burn of Malwarebytes, he also said this in that same thread:
Thanks for letting me know. I'll have a word with him.
That's in regard to you spamming Slashdot comments, and he posted that in February. How did that conversation go? Because in this story from yesterday, you posted this exact text 9 different times in those comments, and since it's the end of the day before a holiday and no one is getting anything done anyway, I went ahead and found no less than 39 comments from you in that one story alone. There are only 101 comments total, 39 of them are yours, and 9 of those are that same wall of text advertising your software. That is the very definition of spam. You also posted this text, the one referencing Steven Burn, 4 different times in that comment thread. You are spamming a Slashdot comment thread with a link to a guy saying that he's going to talk to you about spamming Slashdot comment threads. What's going on here? Why is it necessary to go into the comments for certain stories and see tens of posts by you with either the exact same text or you arguing with other people about spamming? Why do we have to endure that on Slashdot? More importantly, do you think that makes you look good? Do you think it makes people want to try your software? What's the point? Why isn't it enough to post a single ad for your software, even though that would still be considered spam? Why do you need to do it 9 times? Can you give it a rest for the sake of everyone else?
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
So now there's no Gnome or KDE on anything but Linux.
There are many of us made happy by that. One less thing to remove from our systems.
To the original question, though: the answer is yes, you can run anything you want on a system with no systemd. That's the point of open source; you can do whatever you want. If systemd really bugs you that much, just build yourself a system without it.
There is always an army of people who are happy about things that are untrue.
If it affected you as much as you imply by referencing removing things from system, which implies being a technical decision-maker, don't you think you would look foolish to have inaccurate beliefs about those things that are affecting you?
The answer isn't just "you can run anything you want." That is a good thing to keep in mind, since nobody is running systemd except by choice. But more to the point here, you can still run gnome or kde anywhere that they ran before. This does not affect that choice, though it might effect installation of specific packages to get specific features on specific non-systemd systems. And of course on linux you can install just the parts of systemd that are used by Gnome or KDE, there is no need to run the init system. People who claim it is monolithic should really learn the *nix commands cd and make.
And honestly if you're using some non-linux OS and have to remove Gnome or KDE, I'd just like to point out that you probably could have just chose to not install it in the first place. Installing a bunch of crap you don't need so that you can hold your nose in the air while uninstalling it... I don't think that is going to impress the BSD crowd very much. Not that anything does. ;)
I would say an important question is, did the morphing happen before or after widespread adoption? And as I recall it happened well before. In which case I would argue that the starting point is really fairly irrelevant, and the actual "crimes" are:
1) calling an OS abstraction layer an init system when it clearly is far more than that (that seems to be perpetrated primarily by the detractors)
2) allowing a single party to tightly control the abstraction layer (though it does seem that such large-scale projects do need some sort of a singular "choke point" in order to ensure widespread compatability)
3) the discarding of lots of low-level components with large fan communities.
4) Having an OSAL at all? Though frankly, I think it's long overdue - one of my greatest annoyances with Linux is that practically every piece of nontrivial software seems to need to include explicit support and custom binaries for every major distro branch it runs on. That's a huge drain on developer time and energy, and one of the main reasons I've never done much Linux programming. Contrast to Windows where, with some fairly modest self restraint you can create a single binary that will run on everything from Windows95 to Windows10, and even Linux via WINE.
Frankly (2) is the only one I see as a real problem, and I'm uncertain how big of a problem it actually is. After all systemd is still fairly modular, just incompatible with most of the pre-existing modules already out there. And the individual modules are mostly under the control of other groups. And it's still GPL, so if the systemd group proves excessively abusive of their power there's nothing stopping the downstream distros from forking the project, provided they're willing to re-adopt all the maintenance headaches they adopted systemd to escape.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Last I checked, init system policy is still a hotly debated topic in the Debian community. https://wiki.debian.org/Debate... From my reading, the extremes tend toward "it makes everything easier, using anything else is a waste of everyone's time" on one end and "it's a short-sighted and wrong solution that's toxic for the community" on the other.
If you don't like systemd, use Freebsd. systems without cannot be considered Linux, developers should remove compatabilty for non-systemd Linux asap. "systemd... not just an init system anymore, but the basic userspace building block to build an OS from" "building a simple OS based on systemd will involve much fewer packages than a traditional Linux did. Fewer packages makes it easier to build your system, gets rid of interdependencies and of much of the different behaviour of every component involved." Source: http://0pointer.de/blog/projec...
"They" first used KDE around 1998.
One day power management appeared and "they" found that very cool indeed.
Then systemd appeared. "They" adopted it early in 2012. But "they" recently decided to stop using it because it failed to do stuff that worked without since decades (like mounting NFS shares and stuff at the proper time and many other miserable issues regarding) and found out actually easier to do without.
But suddenly "they" found out that parts of KDE where stopping to function properly. Things that worked since long before.
So you may not have any sympathy from where you sit. I did not start using GNU/Linux or KDE because I wanted to use a system as designed by developers. I think that is exactly because GNU/Linux enabled me to go beyond what the developers had in mind first that I liked it.
Now, I just wonder if KDE wont be too much work for not enough benefits in the long run.
Yii! That sounds extremely dangerous, as in local malware == root control.
I had been apathetic (disliking, but apathetic) about systemd, but now I'm thinking I should switch to something that doesn't have it.
I think we've pushed this "anyone can grow up to be president" thing too far.
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).
What changed under Obama? Nothing Good
For the average user, don't worry about the difference. ;)
From the perspective of a *nix power user, people choose the desktop environment separately from the window manager. So they provide very different features. The Window Manager draws the window borders, placement, stacking, etc. The desktop environment does a bunch of other stuff, like managing the video settings, the inputs, cross-application features like cut/paste, print dialogs, and also often provides a GUI "control panel" for managing the whole OS.
Also, if you read the article, you absolutely do not need the systemd init system to use the new features. That is just another myth that the non-readers are circulating and repeating. The article goes into the specific features and what and why questions. It isn't the window manager functions that are involved, but things like the GUI login screen that comes with the desktop environment.
For example, in the old days we didn't have desktop environments. We only had window managers. So instead of being able to start Gnome or KDE from the system and receive a login screen, you'd login to your user account from the text terminal, run a script like "startx" that would have your preferred window manager and settings in it, and that would start the X Window System (which would manage the mouse/keyboard directly) and then it would start your window manager, and a few default applications that probably includes a task bar and some sort of app launcher. Copy/paste usually only worked for apps that used the basic terminal paste capabilities; apps that had more advanced cut/paste capabilities were generally incompatible with each other. And not only was their no common sort of print dialog, there wasn't even a layer in the system to hang it on. Print and copy/paste are the killer features that pushed the creation of a "desktop environment," because there needed to be a layer to attach that stuff to. It needed to be closer to the app than the X Window System, because nobody wanted to add bloat in that layer, and it needed to be closer to X than to the window manager, because people used a lot of different window managers. App developers who wanted portable copy/paste were adding support for individual window managers already, which worked poorly, so there clearly had to be another layer between that and X. Also, when you wanted a GUI login, you had to run that as a separate app to replace the startx script, which made those use cases really klunky and error-prone.
So the desktop environment is designed to run a GUI login screen as a system user, manage the related hardware configuration, allow the user to select their window manager (most gnome environments come with a bunch of different window managers) and then after it is all running, it manages the mouse and keyboard, and provides a unified cut/paste clipboard and printer dialog. It also manages lock screens, etc. Window managers have no idea if you want to lock the screen or not; they're just painting windows after all. In the old days we had background processes spying on your keyboard and mouse directly in order to decide when to launch a screensaver, and lock screens were a screensaver feature. This ties into one of the things finally getting fixed at the desktop level; using non-init parts of systemd to allow the desktop environment to monitor the user inputs, but without giving any old user process access to spy the keyboard and mouse. If that singes somebody's neckbeard it isn't going to stop me from enjoying the improved security.
I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system.
Well since systemd is not an init system, if KDE and GNOME do depend on it then they are not depending on an init system right?
Couldn't journald be modified to output text?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
vtwm, baby, vtwm. Ther's a github repo with SRPM tools over at github, and is stunningly lighter and faster than any of the "desktop environments".
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.
i dedicated three years of my life - without proper financial recognition - to breaking the NT Domains monopoly, saving companies world-wide billions of dollars in the process. it is also not very well-known that i dedicated another year reverse-engineering the Exchange 5.5 protocol.
this dedication gave people a choice: they could choose to remain on monoculture monopolistic insecure proprietary and expensive per-seat-licensed servers, or they could choose to move over to software libre on any number of POSIX-compliant OSes including HPUX, AIX, Solaris, BSDs and GNU/Linux OSes - the *exact* opposite of a monopolistic monoculture. they could also choose to move to any number of proprietary solutions from companies such as Tarantella, Honeywell, Network Appliances and many more - all companies who got together because i pioneered the reverse-engineering (and wasn't murdered for doing so) which forced Microsoft to start doing proper documentation, and to sponsor CIFS conferences.
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.
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.
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
You're right. KDE is not depending on an init system. It's depending on an upstream system management daemon for functionality on pretty much everything except it's ability to boot your system. Honestly if you still think systemd is an init system then you really should just step out of the discussion.
> Because the whiners don't have a use-case. systemd is modular, but it tends to come with all the modules packaged together
I'm afraid it's not. The dependencies among components are very strong, and it's quite difficult to segregate out one component for de-activation or non-installation unless you compile with that feature de-activated, in which case you must recompile to re-enable the future. It's very difficult to install only the components you want due to the interdependencies.
Systemd is pretty clearly an init system. It's just that if you don't use that system, you can't use a lot of other stuff.
No. Systemd is a system management daemon that happens to also take care of the init process.
> 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.
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.
Actually not a single person in the world wants to see that. It's just your hatred against those people who don't have a problem and actually see the upsides to redesigning the back end of Linux.
hate on hater.
You're right. KDE is not depending on an init system.
You're wrong......the "system management" portions don't work without the init system. For example, logind depends on systemd quite clearly, look at the function execute_shutdown_or_sleep().
People have tried to separate the system management portions from the init portions of systemd, but it was rather more difficult than you'd expect and they gave up.
"First they came for the slanderers and i said nothing."
This is confirmed, along with the difficulty of unfurling the systemd init tools to try and start the fractured daemon cleanly in a debugger.
How portable is the shim? I'd welcome backports of some contemporary Linux daemons to run on older Linux systems without systemd.
For the average user, don't worry about the difference. ;)
The average user is happy with Windows, let's be honest.
Also, if you read the article, you absolutely do not need the systemd init system to use the new features.
I don't know what article you're talking about specifically, but it looks like to get it to work, you need to use an older version of uPower. And it isn't a new feature, it's a feature that's been there for a while a long time, but now depends on systemd.
using non-init parts of systemd to allow the desktop environment to monitor the user inputs
The non-init parts of systemd aren't separable from the init parts. I discussed part of the issue here.
As many skilled people as possible need to start thinking about the init problem, so we end up with something good.
"First they came for the slanderers and i said nothing."
I have never understood why the Devuan fork needed to be made to address the issue of systemd dependence in Debian. All that group of people needed to do was commit to maintain non-systemd packages in Debian then they'd have the best of both worlds.
SURELY NOT!!!!!
Original text:
At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit
A sane edit:
At the same time, systems that worked for years without systemd no longer work, since, as pointed out by Edunson, "[adding systemd as an] optional extra defeats its main benefit"
Bodhi Linux www.bodhilinux.com has a few options for legacy and modern hardware support with no Systemd (Ubuntu 14.04) iirc.
http://www.bodhilinux.com/down... and the info on the images http://www.bodhilinux.com/w/se...
Domestic spying is now "Benign Information Gathering"
> Because the whiners don't have a use-case. systemd is modular, but it tends to come with all the modules packaged together
I'm afraid it's not. The dependencies among components are very strong, and it's quite difficult to segregate out one component for de-activation or non-installation unless you compile with that feature de-activated, in which case you must recompile to re-enable the future. It's very difficult to install only the components you want due to the interdependencies.
Horse shit. I'm not talking about the end user recompiling it. I'm talking about the know-it-all whiners recompiling with those features set the way they need to satisfy their delicate personalities, and then offering those choices as packages for like-minded users. 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.
And no, there are not a bunch of cross-dependencies. That is just ignorance. If you turned off the features that use the other part, it will not still be a dependency. That is how dependencies work in a modern build system. That the whiners we have would not be able to successfully identify and turn off the features they claim are oppressing them is a totally different problem. They don't know how to hoe their own row, so they can just sit and cry about it, maybe walk around and kick some rocks.
Slackware runs KDE or xfce and stays up to date. They are working on a new release, no systemd in sight.
In the USA, we like stuff watered down, like beer, television, and freedom.
Is it not possible to just write a standard interface that would have it working with any init system?
That's the right idea, because the interfaces are more important than the code. It's more complex than just an "init interface," but clearly there needs to be a division between the init system and the "system manager demon."
"First they came for the slanderers and i said nothing."
If you don't use systemd as your init system, you can't use other parts of systemd, like logind. So you can call it whatever you want, the init system is inseparable.
"First they came for the slanderers and i said nothing."
So it's turtles all the way down then? Show me where KDE directly depends on the init system, upstream problems don't count as the fundamental functionality of logind doesn't depend on the init system either, only the specific package currently in use does. Why not write a wrapper that implements the function of KDE is looking for without requiring systemd? I mean it's not like KDE didn't work up until now is it?
When did open source change from being of the "fork and fix it" mentality to become "whine and do nothing".
Perhaps he's one of the people that have tried Linux, and wasn't impressed. It *is* possible to decide that, and despite what the neckbeards of Slashdot proclaim it's a perfectly permissible personal decision. Either way, I suspect you'll be okay. If not, that's okay as well.
FWIW, I have not seen any advantages to systemd, and I have not heard of any advantages that I would personally find advantageous. And there do seem to be potential problems.
E,g, faster boot times don't impress me at all. I'd be more impressed by longer up times. I find binary logs dubious, and many people have reported problems with them. Etc.
I have not personally had any actual problems with systemd, but it's not clear how I'd resolve them were they to occur.
So I'm both dubious about the advantages and worried about possible disadvantages. Sufficiently so that if a BSD supported the ext4 file system I would have a test installation running. But not yet sufficiently to reformat my file systems.
I think we've pushed this "anyone can grow up to be president" thing too far.
I went down the same road, and sometime circa 2005 I switched to Gentoo and never looked back.
And I've personally compiled and installed non-init parts of systemd.
Which parts? Do tell.
LOL no amount of trolling the links will get me interesting in reading your slashdot journal, and no, writing an essay does not replace discussion. Nobody is going to go read that shit. You're generally expected to type in new comments as part of a discussion, and to formulate them for the current context.
Are you capable of discussing things without insulting? So far the answer is no.
"First they came for the slanderers and i said nothing."
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. :)
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. That'd be tolerable in a consumer OS, or even in a consumer-targeted Linux distort like Mint, but not in bloody RHEL and Debian!
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.
Name one commercial version of Unix that still is supported that uses init?
Sco Unixware is the only thing that comes close but I do not htink it is supported anymore.
Solaris left init in 2008
Apple left init in 2006
NetBSD left init for object oriented macros in init for a hybrid approach around 2007
If Init is so great why is everyone leaving?
The reason is init was not designed for desktops or servers with more than a dozen applications. What if your laptop goes to sleep and wakes up on a different network? How can init with 200 lines of if/fi scripts handle something liek this? WHat if your network goes down on your server? What if your web server is hacked? What if your Oracle RDMS takes a dive?
Writting every possible conceivable combination of events with nested if/fi statements is luducrious! An event driven system makes sense.
FYI Init is not a glorified autoexec.bat for starting up. Something needs to tell the kernel which daemons to start and which arguments to pass on. Those who say otherwise do not know what Init does or it's intended use.
So Apple went 1st and everyone but Linux followed.
http://saveie6.com/
Name one commercial version of Unix that still is supported that uses init?
Sco Unixware is the only thing that comes close but I do not think it is supported anymore.
Solaris left init in 2008
Apple left init in 2006
NetBSD left init for object oriented macros in init for a hybrid approach around 2007
If Init is so great why is everyone leaving?
The reason is init was not designed for desktops or servers with more than a dozen applications. What if your laptop goes to sleep and wakes up on a different network? How can init with 200 lines of if/fi scripts handle something liek this? WHat if your network goes down on your server? What if your web server is hacked? What if your Oracle RDMS takes a dive?
Writting every possible conceivable combination of events with nested if/fi statements is luducrious! An event driven system makes sense.
FYI Init is not a glorified autoexec.bat for starting up. Something needs to tell the kernel which daemons to start and which arguments to pass on. Those who say otherwise do not know what Init does or it's intended use.
So Apple went 1st and everyone but Linux followed.
http://saveie6.com/
> 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... .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 make good arguments and if I could, I'd mod you up even though I don't agree with you. One of the reasons that linux has been popular as a server OS is that you could easily distill it down to just the parts you needed. If you didn't like a particular component you could swap it out with a component more to your liking or even write a replacement. From a security standpoint, you were presenting a smaller attack surface by running a small number of heterogeneous components from different sources. From a maintainability standpoint you could easily read and understand the impact that updates might have. Sure, there were kludges and hacks and, if you wanted to argue that X-Windows is the most prolific kludge in the history of computing, I probably wouldn't argue with you.
The small, modular, "do what I want" nature of linux is basically the thing that makes linux, linux. If you wanted an opaque box that included everything but the kitchen sink, you could just use Windows. 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.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users. Sysadmins value stability, simplicity and the ability to understand the system they are running. Systemd effectively removes all those features from the OS. 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). Which is made even more bizarre in that it's primary developed by Red Hat: Practically the champion of linux as a mainstream server OS.
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).
"... systemd isn't a solution for end-users, which is why you don't see any substantial changes. Its a solution for *developers*, freeing them from having to deal with the mountain of hacks, kludges..."
As an end user with desktop, laptop and a home server I notice systemd has proven to be useful. The transition from sysv to systemd in Debian testing was not much fun to experience but the end result is great. I get obviously faster boot times and also faster shutdowns. Occasionally I compile from source and install something I want to run at boot. Getting sysv init scripts just right was not always easy. I expected systemd to be similarly arcane; in fact it is really easy to write a systemd unit file and to add your daemon to the system startup.
For example to add a calibre ebook server to my home server init system I just added the following to /lib/systemd/system/calibre.service and then ran `systemctl enable calibre.service`
"[Unit]
Description=Calibre Service
After=network.target
[Service]
User=julian
Group=julian
Type=forking
PIDFile=/home/julian/calibre-server.pid
ExecStart=/usr/bin/calibre-server \
--daemonize \
--username=julian \
--pidfile=/home/julian/calibre-server.pid \
--with-library=/home/julian/Books/
[Install]
WantedBy=multi-user.target"
I think to any *nix user who has even a rudimentary understanding of how processes are described/presented in *nix and how command line options and arguments are input then this is *very* easy to understand. Just by looking at an existing service file of a familiar application you can understand how to integrate something new. It's all there in plain text. That feels very unix-like to me.
Anyway I'm fine with systemd. I hated it for a little while while running a testing system which was gradually moving from sysv to systemd but now I really can't complain.
And to any whiners: it's free software so the answer is not to complain but to contribute to an alternative or even just continue to use an OS which allows you to choose something else. Gentoo and Funtoo come to mind and would seem to be ideal for people who are insufferably picky and always right (no offence to gentoo or funtoo, I like them a lot, but I think I would enjoy watching people who are never, ever wrong and always know exactly what they need trying them out).
That's interesting. In the past, KDE has tried to make their software not dependent on linux functionality so that KDE can work in other places, like BSD and -- god help us -- Windows.
Since I only used KDE on linux, that's kind of frustrating. E.g. KDE refused to use FUSE (Filesystem in Userspace) to access remote files because FUSE wouldn't work on all their platforms (back in 2006). Instead, KDE rolls its own remote access solution which only truly works with KDE-aware applications. In contrast, GNOME uses FUSE behind the scenes so that non-GNOME can seamlessly access the remote files.
So, KDE refused to use FUSE because that was too linux specific (at the time) but now requires systemd? Ugh.
I don't have a problem with systemd, and I'm all for focusing on functionality for the setups that most users actually use (e.g. Windows' lack of FUSE shouldn't stop KDE from using FUSE on Linux, BSD, etc.), but they should come up with a consistent policy for when they rely on an external dependency and when they don't.
(Aside: I wish there was some way users could fund fixes for specific bugs/implementation of specific features on KDE. That way we wouldn't have to wait a decade to get features users have been clamoring for.)
Bullshit. It merely required systemd to play nice and use similar interfaces to the perfectly-good existing software it's trying to replace!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
How hardware friendly are they?
The only thing keeping me on linux is the thought of going back to the days of having to check if hardware worked before buying it ( plus all the hardware I have now ).
What are you exactly talking about when you mention "the old days when we did not have desktop environment", and how it is relevant to systemd?
I still have a valid ~/.xsession, startx still works. /var/log/Xorg.0.log I can still check that the X Window System (well, Xorg now) actually "manage the mouse/keyboard directly", even though desktop environment can adjust it.
In
What does even mean starting GNOME/KDE "from the system"? "From the system"? From a graphical desktop manager you mean? Well, before kdm and gdm, there was obviously xdm. Initial release october 1988. By the "old days", you mean before 1988?
I'm quite sure any so called environment was quite limited then, mainly a window manager obviously - handling desk, list of running apps, a panel, that was already a lot considering the hardware.
Window Maker was part of GNUStep, with already in mind of doing an environment. GNUStep dates from ~1995. Is that too young?
When KDE and GNOME made their first release, they were a desktop environment because they attempted to provide a consistent set of applications, with a consistent graphical user interface. There was some gcalc, kcalc, konqueror, etc. It was a graphical layer on top of the system.
What is your point about the good old days? That desktop environment are now better than when they did not existed? That progress has been made over years? That all the idea behind systemd are not bad? And then what?
How does this reply to this specific topic: "Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system."?
>Couldn't journald be modified to output text?
Not really. But what would be the point in that? If you want unindexed text logs just direct journald to forward all log-messages to syslog, and turn off the binary journald logs. All that it requires is a trivial change in journald.conf
The problems with journald outputting text logs are several: /dev/ksmg (kernel) and /dev/log. That is why the kernel stores all its early boot logs in binary form in the kernel ring-buffer that are then later extracted by special tools like dmesg.
The most important thing is that it is more or less impossible to do right during early boot where journald is receiving messages from both
Another problem is Linux kernel limitations on handling devices. Only one program at a time can read from /dev/log, or messages will lost and randomly misdirected. That means that journald that collects logs from /dev/log before rootfs is mounted and Rsyslog running, can't later hand over control of /dev/log to Rsyslog without losing log messages.
The rather ingenious thing about journald is that it can collect and collate /dev/log info from earliest boot and in initrd, to after the rootfs has been unmounted. You can also have full logging available in initrd which is rather nice if you have to debug from there.
If you want "metal-to-metal" logging something designed like journald is a good idea: If you made journald to be a super-syslog client with text output, you would prevent end-users in choosing between Rsyslog or Syslog-NG or whatever they can use with journald now. Same if they cooperated with the Rsyslog team so Rsyslog could collect from early boot and pivot back and forth from initrd like journald can. Then you couldn't use syslog-ng etc.
As systemd's journald is designed you can choose any syslog(3) compatible logger to work with journald. You can freely choose between either binary or text logs for e.g. legacy scripts to work.
"1) calling an OS abstraction layer an init system when it clearly is far more than that (that seems to be perpetrated primarily by the detractors)"
That is interesting.
So, we have a kernel that is an abstraction layer with the hardware.
We have systemd that is an abstraction layer between the kernel and the desktop environments.
Do we actually need two abstraction layers? Detractors talks about an init system, because it is obvious we need one. But one extra layer, do we?
"4) Having an OSAL at all? Though frankly, I think it's long overdue - one of my greatest annoyances with Linux is that practically every piece of nontrivial software seems to need to include explicit support and custom binaries for every major distro branch it runs on. That's a huge drain on developer time and energy [...]"
So systemd is an operating system in itself, in this view. Why not. Not sure that how it has been sold, though.
The problem the non-systemd distros are facing with running a modern desktop are entirely their own fault. Gnome and KDE developers pleaded for years that non-systemd distros or anybody else should start to maintain ConsoleKit which now have been abandonware for almost 4 years.
The non-systemd distros ought to realize that it is entirely up to them to maintain their own alternative software stack, and even help out upstreams projects like KDE to support them.
At the moment only a single guy is maintaining CK2 and sending patches to KDE so KDE will work with CK2.
People whine about "Linux is all about choice", but when it comes to maintain those choices they all shy away with a "I am not a programmer", "No time", "No money" etc.
So if you want to run a modern desktop in 2016 on a non-systemd distro, you better start contributing towards it.
The same thing goes for OS containers, the new cgroups API and what not. If you want that stuff, don't expect it to magically being made by benevolent pixies nor developers from systemd-distros.
You're likely being forced into systemd because the powers that be want to make sure they will have access to your systems.
I use Linux because I am free to use it the way I want and it is trusted because source is available.
I expect DRM will get wedged into systemd so you can't avoid Big Brother.
Linux will then be a "Trusted OS" because proprietary DRM code will be running underneath everything we do.
You will not be able to stop it without breaking all the applications which play video, music, download files, etc.
I do not trust Hollywood to be in my system, watching my every move.
If everything is tied together in a binary it can't be avoided.
Go well
>More specifically, systemd is Linux-only.
So what. It is hardly a problem that Linux developers financed by Linux money develops Linux software. BSD/Solaris/AIX does exactly the same.
In this case BSD and non-systemd distros will have to make their own tiny contributions to upstream projects like KDE on order make things work. Sure, they would like the systemd-developers to work for free for them, but that won't happen.
The BSD alternative to the systemd software stack called "systemBSD" is of course totally incompatible with Linux.
Basically the non-systemd distros and BSD are getting a full DE for free. All they have to do is to provide the rather minimal infrastructure and OS services that the DE's require, just like the systemd-distros does.
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Probably because almost nobody is working on non-systemd distros. Their entire OS plumbing layer from ConsoleKit to power-management has been bit-rotting for years with the non-systemd distros totally ignoring the pleading from upstream projects.
It is hard for upstream projects to support the non-systemd distros when they ignore or outright refuse to do any work.
I think there is roughly one non-systemd developer (the CK2 maintainer) that submit patches to KDE so KDE can have basic functionality on non-systemd distros.
But sure, just blame systemd for the non-systemd distros total apathy for maintaining their own software.
>I chose. I went back to windows.
Yes, because MS Windows is totally "Unix Philosophy" and is all about choice and modularity.
I'm the AC and I've been using linux since it was in beta. I simply find this wholesale decision by all major distributions to go to systemd sucks. I've used windows more often than not, so, frankly, it's simple for me to just drop linux on the desktop. My day job is a linux sysadmin and I'll deal with systemd there because for money I can put up with it. It's not like it's a heinous crime against humanity or something. I just file it in with all the typical shitty proprietary software I end up having to install in linux: Learn about it, feed it, keep it running, and know better than to ever use it for fun. :)
So, yeah. I've watched desktop windows go from being okay-ish (windows 3.1 days) to being shitty (win 95) to better (win 95 OSR2) to great, for the time (win 98 & 98SE), to bad (win me), to good (win xp), to bad (vista), to good (win 7), to bad (win 8), and windows 10, well, is mediocre.
But I'll take mediocre over using systemd. Unless you want to pay me, which they do, so I have learned systemd. Enough about it to know why I don't want anything to do with it unless there's a nice fat paycheque in it. I figure with how bad I think systemd is, I'll have a job for another 10 years because of it, which is great, because I hope to retire in 15-20.
There's just no need to use linux on the desktop. It was a passing fancy I had at one time, but linux distros decided to get shitty and I'm no longer interested. Windows does the job for me as a desktop OS. BSD, for me personally, does a great job as a server. And, to make money, I'll deal with linux (not as many BSD jobs out there...).
Perhaps he's one of the people that have tried Linux, and wasn't impressed.
Haha. You sound like a teenage girl defending her boyfriend. Did you do the little finger snap thing as you wrote that? I'm sorry. I just had to laugh. Rock on.
The soylentnews experiment has been a dismal failure.
Well I bothered to check your first bug, "Systemd contains an unchecked null reference pointer that segfaults PID 1"
Executive summary, systemd does not work on kernels without cgroups. Well duh.
Don't install it then, you have an ancient unsupported Linux kernel.
I stopped checking after that.
Do you know what you're posting about?
I use both freebsd, and linux, and IMO, freebsd is superior in many ways.
Although, Linux works with more hardware.
Why throw away POSIX and the UNIX philosophy?
FreeBSD works like all hell. No wonder Red Hat is trying to pulling the old "call non-believers luddites" stunt.
I run MATE because it sucks less than KDE, or Gnome - a lot less.
What is not "modern" about MATE? What am I missing?
Features for the sake of features do not interest me. What functional aspect of a DE would actually help me be more productive, that I don't have with MATE?
Don't get me wrong, there are other good desktops, just not KDE or Gnome.
I think you missed the simple fact that everything was working fine before, without cramming everything in the init process.
Has everything been crammed into the init process? In what may have been a bad PR move, the systemd people use "systemd" both to refer to the init process and to their whole suite of daemons, most of which run as processes separate from process 1, so "systemd does XXX" doesn't necessarily mean "XXX has been crammed into the init process".
> Yes, because MS Windows is totally "Unix Philosophy" and is all about choice and modularity.'
Because it the runs the apps.
Windows does the job. It works with the hardware, and runs the software. Why make a religion of it? It's like making a huge fuss over what kind of copier machine you use.
I agree with original poster. The promise of Linux is gone. Now it's just another Microsoft.
So why fight it? Microsoft is kludgy as hell. But MS basically does what you need it to do.
A fair point, and I do agree that systemd is likely much better suited to desktops than servers. Perhaps it's finally time to begin to fork the two at a lower level, since that very variety seems to be the source of much of the difficulty Linux has offering a competitive desktop experience. Basically consider systemd to specifically be a low-level component of desktop environments and other "shrinkwrapped" distros.
As for the smaller attack surface - as I understand it systemd is actually very modular, and you can leave out most of it in your distro if you so choose. The real problem is (I think, I'm pushing beyond the point that I've paid much attention to) is in the customizability. It seems like systemd expects its modules to operate in a very specific way, which would seem to drastically reduce the options for substantially different implementations.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Except the kernel really isn't that - maybe you could argue that it abstracts the CPU and some basic I/O functionality - but sound subsystems, sophisticate plug-and-play support, power management, networking, etc,etc,etc... do you really want all that rolled into the kernel? There's a LOT of stuff that gets piled on top of the kernel before you get to the desktop environment, what's wrong with putting an abstraction layer between the GUI itself and all the gooey goodness it depends on. As a developer I tend to find such abstraction layers, well positioned, can dramatically simplify the conceptual space I'm working in and let me focus on actually improving things, rather than managing the hodge-podge of modules doing the work behind the scenes. .
--- Most topics have many sides worth arguing, allow me to take one opposite you.
"I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system."
Well, if KDE or GNOME shouldn't depend on an init system and systemd is not an init system, what's the problem with KDE or GNOME depending on systemd, you mister sophist?
"For example, in the old days we didn't have desktop environments. We only had window managers. So instead of being able to start Gnome or KDE from the system and receive a login screen, you'd login to your user account from the text terminal, run a script like "startx" that would have your preferred window manager and settings in it, and that would start the X Window System"
Uh... your id is lower enough to be around here by that time, but you don't seem to have been using Unix/Linux back then. XDM was first presented in 1988 and it was certainly part of the X Window System, nothing related to desktop managers (KDE is from 1996 and Gnome from 1997).
"when you wanted a GUI login, you had to run that as a separate app to replace the startx script, which made those use cases really klunky and error-prone."
Funny you say that. I only started to have problems with display managers (i.e.: remote session selection) when systems started to move away from XMD in favour of gdm and kdm.
"And not only was their no common sort of print dialog"
Yes, there was.
"Copy/paste usually only worked for apps that used the basic terminal paste capabilities; apps that had more advanced cut/paste capabilities were generally incompatible with each other"
Just like now. Apps always had access to the X Window buffer; it was non-well-behavioured apps those that didn't work (usually with roots coming out from Unix).
You made a seemingly cogent argument, only one that is not so much tied to historical facts.
I agree and strongly prefer using systemd unit files to init scripts. Also the place to put your local unit files is /etc/systemd/system according to systemd.unit(5). /lib/systemd/system is for units provided by packages.
I'm just waiting for the first major security hole in systemd due to the case that it's trying to do everything.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It may remove some work for some people but it adds a lot of work for system managers by new binary logs in formats that can't be processed without special tools and a headache when it has to be reconfigured to suit the specific environment it's going to be used in.
And still there are people swearing by systemd - probably because they never have to provide support on the production systems that runs it.
Another contributing factor is that if it's hard to configure right then there will be security holes causing a lot of headache for system administrators. In most cases as long as you get something working you are satisfied even if you don't know why it's working - and then you may have a security gap the size of Grand Canyon in place as well.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Unfortunately systemd isn't solving anything, it is a elephant sized turd that introduces too many ways to be misconfigured and causing security problems.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
HP-UX.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Looks like we have a nuke installed in our system that's just waiting to explode under the right circumstances.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It's still a bug in systemd, there's no excuse.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Might be the choice of distro that I'll go for next install then.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
No, you are definitely wrong. Systemd is only sold into the larger distros and forced down on sysadmins all over the world. Not unlike how Windows was pushed.
Systemd != Linux and Linux != Systemd.
Systemd is very much like a prison that locks up users into a closed community. Very much like Windows.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Yes, because MS Windows is totally "Unix Philosophy" and is all about choice and modularity.
No, the "UNIX philosophy" has nothing to do with it. It is about choice but not about modularity but that is because choice in applications is what is most important to computer users. Do I care what desktop environment or init system is running behind Maya or Photoshop or Solidworks? Of course not, it's completely irrelevant. But I certainly care about whether the operating system can run those applications.
Choice in applications is the most important thing to the vast majority of users, Microsoft themselves are finding this out the hard way with their mobile platform.
If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call /sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface. Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.
It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.
I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
As a developer, I find systemd much harder to interact with than the previous "hacks". So I guess it failed there.
So... it's better to outright crash than return a message that it depends on a feature that's not available?
And let's not forget that systemd destroys high availability by refusing to mount btrfs degraded if one of the drives fails even if it's set up as RAID1. It refuses to even try the mount commend and drops to the shell (eventually). If you issue the mount manually from there, it mounts right up. They apparently don't know what high availability is all about.
It has its charms.
Subsystem for UNIX-based Applications Overview
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.
Seems reminiscent of "embrace and extend" in spirit.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
So now there's no Gnome or KDE on anything but Linux.
That is Lennart's plan. Here's what he says::
"I
think we need to ask ourselves the question if we do ourselves any good
if we continue to support all kinds of kernels that simply cannot keep
up with Linux anymore."
I guess we'll see how writing non-portable *nix code as a strategy works out in the long run. I'm not a fan of the idea. It certainly makes for some big trade-offs. I like having the same desktop available on multiple platforms (and different Linux distros don't count for that).
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Clearly it should be extensible in Lisp .... and include an editor .... and be bootable apart from the operating system ..... hmm .. that sounds familiar.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
it is modular, there are only 3 components that are required to depend, systemd, journald and udev. you can replace every other optional component with your own version. LP even produced a shim library for Gnome to run logind without systemd but gnome decided not to use it. glibc is a bigger dependency for all linux software but no-one calls that monolithic.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"difficulty with binary log formats" - maybe you need more practice with "journalctl" or perhaps install the latest versions of syslog or rsyslog as they now extract logs from the journal themselves and you don't have to rely on configuring journald to forward them
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
And it's reasonable architecture for power management controls to depend upon power managing daemons.
But it's not reasonable for it to depend on a particular init system.
that's the choice of the developer/maintainer how sh/she codes their software
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
but yet the kernel is monolithic and the systemd project is not. Debian seems to have ways of swapping out systemd.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
but you can write your own version logind to exclude those calls - the choice is yours. LP himself wrote a shim library for Gnome to use logind without systemd but they chose not to use it.
The choices are out there, its time to stop whining and make them
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
4) Having an OSAL at all? Though frankly, I think it's long overdue - one of my greatest annoyances with Linux is that practically every piece of nontrivial software seems to need to include explicit support and custom binaries for every major distro branch it runs on.
That's rubbish. Just package it with all the libraries it links to or statically compile it. It'll run anywhere, provided you don't depend on new kernel features and try to run it on an old system.
Mostly this claim (and the following claim you mad about windows) comes from deep misunderstanding of how software is customarily developed on Linux as compared to Windows.
SJW n. One who posts facts.
I stopped checking after that.
Typical systemd fanboi attitude.
If you read on, you'll find it was a modern kernel, but an error in a container config that caused cgroups to not be mounted. And that caused a segfault.
So your insanely smug "don't try it with an ancient unsupported kernel" becomes "don't make config errors".
SJW n. One who posts facts.
As the response to your bug report says:
This is free software: scratch your own itch. Don't expect that others scratch your itch.
Devuan doesn't support any of the interfaces that KDE needs, that can be fixed by either:
1. the KDE team adding special support for Devuan
or
2. Devuan adding any of the packages KDE needs to support power management.
RESOLVED, DOWNSTREAM seems perfectly reasonable.
I'd expect the VUA's to have a fix for Devuan in short order.
Watch this Heartland Institute video
you need to stop confusing systemd (the binary) and systemd (the project) - it certainly was a mistake to call them both the same name and has caused tons of confusion which trolls use to post crap.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
How portable is the shim? I'd welcome backports of some contemporary Linux daemons to run on older Linux systems without systemd.
I already asked that question on OpenBSD Journal. The answer was interesting and detailed.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
why not do some research before typing? Don't rely on what any poster says. Try here as a start http://0pointer.de/blog/projec...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Just use the latest syslog/rsyslog, they extract all the logs from the journal themselves these days without journald being configured to forward them. Try using journalctl to read the journal, its a powerful tool
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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
And we also have decades of experience with Linux no-culture. It failed to gain more than 1% of the total market. Perhaps it's time to try something else?
An init system shouldn't be doing that stuff.
Then who should?
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.
Yes you can. It's a SMOP. That nobody else can be bothered to do the programming isn't systemd's fault.
Watch this Heartland Institute video
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
No. powerdevil uses upower to do that. upower now uses systemd. KDE has made no change whatsoever (that's why the KDE devs don't see this as a KDE bug).
Watch this Heartland Institute video
Yii! That sounds extremely dangerous, as in local malware == root control.
I had been apathetic (disliking, but apathetic) about systemd, but now I'm thinking I should switch to something that doesn't have it.
And you'll remove the sudo(1) and su(1) commands?
Watch this Heartland Institute video
You could use Windows or MacOS. Both don't have systemd.
Entia non sunt multiplicanda praeter necessitatem.
An init system shouldn't be doing that stuff.
The init system doesn't. None of that is run as a process in PID1.
Systemd is a set of many intertwined packages. It seems most people complain about the fact that they are written by a common team. They never seemed to complain about X the same way though.
Lack of upstream support is not a bug. Or can I complain that KDE throws an error if I don't have an X window system as well?
I can't really agree that a bunch of highly interdependent chunks, glued together by an ever-morphing API, are in any way, shape or form "fairly modular". And that is the main problem.
No. But you can complain if KDE segfaults if you don't have an X window system.
To quote Mr Tovalds himself:
You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
The result of a direct question which skirted around saying systemd only a few months ago.
What does an init system have to do with desktop session management? Nothing. How can the same stupid subsystem (systemd) control behavior of both these separate subsystems. Systemd is broken by design, it is trying to be a sub OS between the real kernel and user apps.
Or one of the many BSDs.
That's going to be tricky.
The key point is that the poster wanted a *modern desktop environment*.
So probably Gnome 3, KDE Plasma 5, Unity 8, or whatever the newer versions that are going to show up in 2016.
And most of these desktop try not to reinvent the wheel, but re-use the building blocks that systemd (I mean not only PID1, but all the various other tools that are hosted under the same umbrella) provides.
(e.g.: Cgroups handling, automatic on-the-go creation of isolation silos, hardware management, etc.)
Linux is much more than plain old POSIX. It provides tons of really useful advanced features (containers, capabilities, etc.) that where'nt part of posix. Systemd (project umbrella) provides tons of tools to leverage these function, that where simply completely underused back at the era of "cobbled together convoluted shell scripts". These functionality are useful, and together with the level of automation that systemd provides, makes life of desktop environment maker much easier.
BSD is also much more than plain old POSIX. But it's *differently* more so (jails instead of containers, different API for capabilities, etc.)
Handling these OSes would require either tons of API-specific code and wrappers, next to the simple systemd-leveraging (i.e.: what TFA complain against)
or requires that BSD also progressively migrates toward some higher level tools the simplify the handling of these functionnailties (i.e.: the various systemd alternatives that some time pop out. But still nothing concrete as of yet).
So probably, in 2016:
- you could either use Linux with KDE/Gnome/etc. but have a hard dependency on at least a dozen of deamons handled by the systemd project.
- or you could use one of the niche Linux distro with a unusual very geeky desktop environment (e.g.: some obscure tiling windows manager, and emacs with tons of plugin as the default browser/email client/file manager)
- or you could use BSD but you'll get an oldish release of MATE / KDE sunset.
And only the first of the three above get the best hardware (and, e.g., suspend/resume) support, due to having the most paid developpers working on it.
But, probably around 2018:
- you could use BSD with their very own "systemB" (project that give the same kind of abstractions) with the latest Gnome 4, KDE Plasma 6, Unity 9 (now running on Wayland), etc.
- or you could one of the less mainstream Linux distribution that swaps the component of systemd project with component of alternatives giving the same advanced features.
- or actually hope that by then systemd will have been reviewed enough and cleaned. (One of my hopes, given how widespread it is going to be. On the other hand openssl *WAS* widespread when Heartbleed happened)
- or cheer for the OpenBSD guys as you follow them on a "Valhalla Rampage" blog about "LibreSyD" (like systemd, but with all the weird pieces of code removed).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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...
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.
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.
Saying this merely proves that you don't know what svchost.exe or systemd are.
Watch this Heartland Institute video
From the source tree's README.tmp, I don't see anything to handle the actual init scripts.
> https://uglyman.kremlin.cc/git...
It could turn out well, and I wish the authors well with their work.
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.
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.
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.
My bad, I took a shortcut there. Still, how is what systemd provide now better than what was provided before by different projects?
I.E. he has a 3 digit uid, newbie.
Watch this Heartland Institute video
You're talking to lunatic trolls.
systemd sends stdout/stderr where you tell it to, by default to the journal.
Watch this Heartland Institute video
And of those extremes "it makes everything easier" comes from the people actually doing work and "it's a short-sighted and wrong solution that's toxic for the community" comes from a bunch of trolls.
Watch this Heartland Institute video
Modern operating systems, like MS-Windows, or OSX, run far more apps, and work with far more hardware.
Systemd Linux is for pompous neck-beards.
Just something the Red Hat shills might want to think about before they try to shame FreeBSD users into submission.
1) All the major stakeholders seem to have agreed that systemd is "good enough", that's exactly the problem, isn't it? The end users (minor stakeholders) aren't happy with the decision of the major stakeholders upstream.
2) absolutely, no argument.
3) the coupling is now between systemd and other software, where previously it was with "all the alternate implementations of the subsystems this software depends on could be implemented". I'm not seeing how the second is an advantage.
4) agreed. But we do have a pretty good idea of what a "desktop" and a "server" look like. The biggest down side I see is that a lot of those alternative modules that might be handy for random alternative hardware will lose much of their developer pools.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Yeah, Microsoft knows Unix(tm). They where once a major Unix(tm) vendor with their MicroSoft Xenix. They later sold it to SCO Unix. Charming fellahs all around I am sure.
>I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
Nope. CK is still dead and has been for almost 4 years. While CK2 is a fork, it has dropped the old CK API (and code) in favor of the systemd-login API, just like systemBSD. That means you can't use CK2 as a direct replacement for CK. The old upstream code in the DE's simply don't work.
While CK was dead, there where of course still lots of development going in the DE's, but since only systemd-login was actually maintained, they could only add support for that in the new code.
And the KDE and Gnome developers never got any help for the hard work they are doing with supporting basically un-supportable distros that ignore each and every request they have. Not even a "thank you" are they getting. Instead they are getting shit kicked in their faces by fanatic systemd-haters.
Systemd is a set of many intertwined packages.
That's the problem. You can't run those systems without using the init system, therefore they depend on the init system.
They never seemed to complain about X the same way though.
Pay more attention. People have called X a cludge for many years.
"First they came for the slanderers and i said nothing."
I guess we'll see how writing non-portable *nix code as a strategy works out in the long run.
Overall it hasn't worked well in the past. I discuss one reason why I think that is here: in short, code doesn't last, but interfaces do.
"First they came for the slanderers and i said nothing."
I don't care if you think MS products are better for you, hey if it works for you why should I disagree about your choice. You probably never really cared about Linux and Open Source in the first place, so systemd is probably a great excuse for no longer using Linux.
It's a distinction that doesn't matter when you can't run the tools without systemd having control of pid 1.
"First they came for the slanderers and i said nothing."
Lennart Poettering has been actively pushing other projects to depend on systemd. Here's one example from the Gnome mailing lists.
"First they came for the slanderers and i said nothing."
That's true, upower switched over to systemd.
"First they came for the slanderers and i said nothing."
Yes you can. It's a SMOP. That nobody else can be bothered to do the programming isn't systemd's fault.
That the systemd team writes crap code is their fault, and I do blame them for it.
"First they came for the slanderers and i said nothing."
Bad standards do not encourage varied implementations. E.g. systemd. Good standards do e.g. POSIX.
No one is talking about security of systemd vs init scripts. They are talking about security of systemd as a process manager. Which is not only not proven, some people do not like the design wrt security.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
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.
Bad standards do not encourage varied implementations. E.g. systemd. Good standards do
Well said.
"First they came for the slanderers and i said nothing."
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.
You didn't address any of my questions, just more trolling flamebait.
APK, don't you see the irony? You developed a piece of security software, yeah? And how have you chosen to market your security software? By making yourself a spammer. Surely you can see the irony.
Steven Burn sees the irony, because he already removed the forum thread that you're spamming. Keep up the same behavior and I think you'll find that he no longer sees it worthwhile to host the software of an abusive spammer. He would be correct also.
Face facts: Nothing you trolling worms can do can affect me - get it?
I'll be happy to email Steven Burn again. He already removed your thread, what happens if 100 people from Slashdot send him a message complaining about your abuse? Should I write up a post describing how to contact him and follow you around when you post your spam 9 times in a comment thread? Is that seriously what needs to happen for you to decide that maybe you shouldn't be a spammer?
I'll just burn you out of your modpoints (I've done so literally 175++ @ a time, lol) - so keep it up! I figure it this way - I can easily repost as much as I like & when you're all spent?
Awesome, APK. A threat to abuse the moderation system of Slashdot so that you can continue spamming. That is totally going to help your cause.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
> 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 think the linux ecosystem looks more and more like enterprise software because more and more, it is controlled by enterprise companies (RedHat, Oracle, IBM....)
"First they came for the slanderers and i said nothing."
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.
There code is so crap nobody can write an alternative?
I cannot understand your "logic".
Watch this Heartland Institute video
> 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.
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.
What you are missing is verb tenses. The decision to move to more modern architectures was being made around 2007. The specifics then got rolled out in 2010. Now the effects are being felt. The choice isn't starting to be taken away, that happened a long time ago.
There is going to be choice among modern configuration but not the choice to use "modern" software in 1990s style configurations. Same thing that happened to CP/M users.
You've been around this debate to know that systemd isn't an init system. One of the many systems it is replacing is an init system.
How exactly has a binary log format cost you time unless you are making it painful on yourself? If you can get to the filesystem you just read it using any number of tools that understand the binary format.
I'll give you something you couldn't do in 2008 but can do today that I've been able to do on mainframes for 2 decades. Start running a process, take the node running that process and yank the plug, keep all session data fully intact as the process moves to another node. What systemd is doing is creating the application hooks so that this becomes possible in most rather than just a few applications.
The primary use cases for Linux are embedded systems and very large server farms. Niche system admins running 1-100 boxes are an important constituency but not even 1% of 1% of the Linux out there. Linux as a cloud based OS is more important than Linux as a strictly hardware based OS. I don't agree that systemd creates problems for hardware, as you mention it is popular on desktop. But if ultimately one of the other has to go overboard...
We wouldn't if the kernel provided sophisticated process management, logging... But since it doesn't yes you do need that.
It has. Pottering has always said that he wants systemd to be the interface for userspace the way the kernel is for kernel space. Every application that doesn't need low level interfaces with the kernel should would be using systemd to provide services. Effectively Linux kernel + systemd + X11/Wayland... become the OS.
How is that a bug in systemd? That's a dependency. Having dependencies isn't a bug. Any program can be deliberately broken by tricking it.
That sounds more like a kernel problem. You make a config error you get a boot problem. Systemd doesn't know what you are did. Change the config outside the VM and try again. How is that any different than throwing an error?
High availability never runs raw on X86 hardware. The hardware isn't reliable enough for HA. They aren't the ones who don't know about HA.
That sounds more like a kernel problem.
No, it was a failure to mount the cgroups virtual filesystem. The kernel has cgroups, but the VM was not set up to have access.
You make a config error you get a boot problem. Systemd doesn't know what you are did. Change the config outside the VM and try again. How is that any different than throwing an error?
Are you honestly saying there's no difference between throwing an error with proper logging, sensible message, error handling and etc and dereferencing a null pointer and segfaulting?
With friends like you, systemd barely needs enemies!
SJW n. One who posts facts.
My sudoers file is empty. (I suppose I *could* remove it, but it's already unusable.) su is necessary. This is an unnecessary hole.
I think we've pushed this "anyone can grow up to be president" thing too far.
No I'm saying that there is no difference between non sensible error messaging resulting in a crash and and just crashing. Obviously full error handling is better. But no system survives every possible case. Cases get logged they get fixed. That takes time and all software is vulnerable to being tricked into failing to boot properly.
As for the VM. If the VM doesn't have access and systemd is running on the VM then you are missing a hard dependency for your boot system. You wouldn't expect the kernel to boot without ram installed.
It is in several parts (so not monolithic)
OK, you don't know what monolithic means. The problem with systemd isn't that it adds features, features are cool. The problem with systemd is the architecture is bad. Unfortunately that isn't something I can discuss with you, because you lack expertise in the area, but if you are interested in learned more, I discussed it in depth here.
"First they came for the slanderers and i said nothing."
You've been around this debate to know that systemd isn't an init system.
Of course. I think I even stated something similar elsewhere. I wasn't trying to imply that it is only an init system.
My complaints are not the features provided by systemd, but rather the architecture of systemd. Being unable to separate the init from the rest of the system is merely one obvious symptom of the larger problem.
"First they came for the slanderers and i said nothing."
I cannot understand your "logic".
I'm not surprised, your reading comprehension is lousy.
The reason I don't write a replacement is because I'm lazy. I take full blame and responsibility for that.
I give full blame and responsibility to the systemd team for writing lousy code. These two things are not exclusive. Both can be true.
Does that makes sense to you now?
"First they came for the slanderers and i said nothing."
System D sounds like it's was a stop gap fix for a old issue that everyone liked so much they jest kept it... except for for 3 files (Autoexec.bat,config.sys command.com dos can have any number of files added or removed to set it up the way you want it... why can't linux do that?
It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.
Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried. Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.
Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.
I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.
Cases get logged they get fixed.
You missed the part where Lennart cheerfully refused to fix it.
That takes time and all software is vulnerable to being tricked into failing to boot properly.
Are you deliberately trying to misrepresent the arguments here? No one's saying it should have booted successfully. What me and the other guy are saying is unchecked segfaults are bad and should be fixed. Unlike Lennart's claim this is demonstrably not a problem which only affects old kernels. It affects new ones, and missing checks and refusing to fix them is just poor practice.
Seriously, why do people come up with the most lame defenses of systemd? People would rip MS a new one if such a piece of code was found in Windows.
SJW n. One who posts facts.
First, Linux isn't restricted to x86 hardware (you knew that right?). Second, HA isn't all or nothing. Very few (very expensive) machines go all in on HA. By far, the most common case is RAID (which is implemented on x86 hardware all the time).
Honestly, the RAID thing is a brown paper bug for systemd that should never have made it into a distro and should have resulted in a crash program to fix that in days. It should not have resulted in claims of "not a bug".
I must say, though I have to endure it by browsing at -1, all of his useless spam does make it MUCH easier to find the posts of the people he is trying to harass. As a result, I have up-modded several posts by Coren22 that I otherwise would never have found. And I am no closer to installing apk's Hosts software, so I don't think he is really having anything resembling the desired effect.
I recognize he might (probably) have a mental condition of some kind that causes him to act in this way, but this kind of preoccupying anger cannot be good for the guy. There has to be a healthier, or more productive outlet to express his stunning hostility.
I can't force him to stop, and I won't try, but I have to wonder if there is some professional help he could be getting. The spam is certainly a blight on the comments of this site and I can't imagine a healthy person would do this if he had some other choice.
I'm referring to classic desktops. Linux failed miserably there. On the other hand, Android is a smashing hit - it's the most widely deployed OS in the world now.
And no, I don't buy the "pre-installed in BestBuy" argument anymore - lots of companies (Dell included) tried to sell pre-installed Linux.
Again think of systemd as a process manager. Once you have process management you don't want an init system. Why would you want to distinguish the move from init to everything running from other process management? Whether you want a process manager or just want an init system is a different question than being able to break apart a process manager.
He didn't cheerfully refuse to fix it:
Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.
Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...
Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.
He's happy to accept a fix the segfault. He will take a patch or just have systemd refuse to boot. You were misrepresenting his position by saying he refused to fix the segfault.
I wouldn't call RAID in and of itself HA. So I'm going to strongly disagree with a characterization of saying this "destroys HA". It does nothing of the kind. If you are using x86 non clustered you aren't HA. So at best it destroys booting by default a non-HA system on a damaged RAID.
In any case systemd is designed to handle error conditions. You tell it what to do on errors. In this case there is a flag to tell systemd to mount a degraded raid that can be added so you change the default behavior. I can see the argument that this is perhaps not the best default to just drop you to emergency shell, but I can also imagine the other side where systemd feels it is too dangerous to allow the system to risk total data loss by continuing to run. Pick the default you like.
Maybe the existing interfaces don't provide the flexibility required.
It's not monolithic, but it has leaky abstraction and high coupling among the services, not to mention highly coupled to Linux specific APIs. If you make your program for SystemD, it is no longer portable.
I would say it's a 90% solution if you have RAID and dual power supplies on separate circuits (this is common in x86 servers these days). Add in dual network connections and you're certainly on the threshold of diminishing returns.
It at the very least reduces the chances of a 3A.M. server down emergency to a very small figure if it's in a decent datacenter with proper electrical backup. I have seen a fair number of power supply failures and a LOT of HD failures, but few machines go down for other failures.
Sure, for only 100x more money you could get a non-stop like solution but few applications justify that outlay.
I know you desperately want to minimize one of systemd's most embarrassing failures, but it just doesn't ring true. I have servers with dual power supplies and RAID (I'm testing brtfs w/ raid1) and I want them to boot in degraded mode if that's what it takes. Systemd is absolutely contraindicated for that application.
Sorry for the double reply, but what option is needed to convince systemd to mount a btrfs filesystem with a missing disk?
No "people" are angry about this nonexistent "bug", only anonymous trolls.
Watch this Heartland Institute video
What is an unnecessary hole? Allowing the user at the console to hibernate the machine?
Watch this Heartland Institute video
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.
> Post the issue to your distribution not the systemd group.
It's a problem with almost every distro, right? Like what doesn't have systemd, slack?
No, it's only a problem for distros that don't have systemd. The problem is that newer versions of upower need systemd to do hibernate/suspend, and KDE uses upower.
The bug is a packaging error made by Devuan. I can't imagine why somebody decided to report the bug to the KDE team.
Watch this Heartland Institute video
http://slashdot.org/comments.p...
Maybe not for long.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
http://slashdot.org/comments.p...
Not sure if it really is him, but as you noted the thread is gone, so he may have had enough of it.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
There's a conspicuous lack of replies from APK, so hopefully Steve got through to him. I suppose there's something to learn here. If he continues to spam his application then the best course of action is to probably contact the people he's citing and let them know how their reputation is being used.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
ok, let me think about that.
"First they came for the slanderers and i said nothing."
I just figured he was in a turkey coma, it will be interesting though if there are still no posts on Monday, I will feel anonymous again without all the replies. :)
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
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
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.
And if the network to that location goes down? If the location loses power for an extended period? If there is a fire?
I've seen lots of machines go down from an upstream network problem. 50k+ servers go down because of a configuration error in a in a telco router during a routine upgrade that takes the system down for hours.
Mainframes aren't 100x more money.
Simply not true. .add rootflags=degraded in GRUB_CMDLINE_LINUX
> No, it's only a problem for distros that don't have systemd.
Ok, so it's not a distro problem at all.
> The problem is that newer versions of upower need systemd to do hibernate/suspend, and KDE uses upower.
So it is a KDE problem, because they started requiring systemd. Hopefully they work that out soon.
If you frame it as a Devuan packaging error, that means that including KDE is a packaging error?
Actually, the degraded option does NOT work for BTRFS or at least hasn't when I've tried it. I still ended up in the shell. I checked the changelog for systemd from present back to the date of that report and there is no mention of it at all. Once in the shell, mount -odegraded / will work just fine. If systemd' wasn't too mind-bogglingly stupid to just try the mount command nobody would have to get out of bed at 3AM just to type that. But if I just rip systemd out and use the supposedly old and broken down sysV init, it works every time. If systemd had a sane configuration, I'd just poke that mount commend in as an explicit action and it would just work, but in all of that tangled spaghetti just below the surface, there appears to be no way to do that.
For md devices, they get around the problem by having a regular old script in the initrd go ahead and assemble the RAID before systemd gets a chance to get the vapors and refuse.
Mainframes certainly DO cost 100x more than (for example), a supermicro server.
Sure, networks do go down, but in those cases, you're either dual homed or no amount of non-stop can help you. Again, take the 90% solution or be prepared to start paying a lot more. I did say it should be in a good datecenter with backup power. If that fails, again, no amount of non-stop can help you.
tbh I don't think it makes a difference. You should be able to use KDE, whether you want to use systemd for process management or djb daemon tools for process management. The WindowManager should not be dependent on a particular process management system.
"First they came for the slanderers and i said nothing."
I like systemd, it's better than every distro having their own slightly different init system, and there are lots of benefits over any of the previously popular init systems.
So it is a KDE problem, because they started requiring systemd.
No, upower started needing systemd. KDE changed nothing, that's why they don't see why they should "fix" it.
If you frame it as a Devuan packaging error, that means that including KDE is a packaging error?
Including a version of upower that only works with systemd, and not including systemd, is clearly a packaging error by Devuan.
Watch this Heartland Institute video
A simple window manager wouldn't be dependent on a process manager. A GUI however is going to be dependent on a process manager. Kwin and Mutter don't require systemd, KDE and Gnome do. GUIs need many processes to be running and communicating with each other. Which means when things go wrong they need to resolve it. A GUI needs to provide process management. Modern GUIs in particular, where there is an expectation of dozens of processes running notifying the user require quite sophisticated process management. Arguably the thing that drove the biggest change in Gnome 3 / KDE 4 from Gnome 2 / KDE 3 was introducing a framework dependent on much more sophisticated process management because they wanted notification to work well.
So for Linux either:
a) Each GUI provides process management and most applications can't be cross GUI
b) The GUIs agree to share a process management framework and then there is a hard dependency between the GUI and this process management framework.
In the days of Gnome 1, KDE 1/2 the world looked more like (a) where neither GUI had a desire for the other GUIs apps to run well. Linux was then in the process of forking into two incompatible operating systems. The customer base however objected to this fork and since then the move has been towards (b). There is no reason in 2015 to object to process management while using a modern GUI. FVWM, Fluxbox, Sawfish etc... never claimed to provide this kind of service so of course those window manager are likely to continue to run fine on distributions that don't use systemd. As time goes on the less sophisticated Linux products are going to need to provide viable means of running large numbers of processes that have dependencies on one another and resolving dependency issues in real time. Non process managed systems are simply not going to be supported.
> upower started needing systemd. KDE changed nothing, that's why they don't see why they should "fix" it.
It sounds like KDE should have moved to supporting pm-utils instead of sticking with upower only:
http://nlug.ml1.co.uk/2014/06/...
Random elements of Linux randomly adopting systemd as a prereq to working is, in fact, the thing that Devuan is fighting, right? From their perspective, anything that requires systemd is itself a problem that needs to be exposed and repaired (or forked, as they were willing to do with Debian).
It's not a packaging error. It's yet another systemd issue, and it's totally legit to lay it on KDE for allowing one of their subcomponents to add a hugely unrelated and unpopular requirement to their functionality. Opposing this nonstop systemd creep is literally the entire reason Devuan exists. Not a packing error, a systemd error.
APK, scroll up and read through my posts again. Notice how they don't contain any personal attacks against you. Still, you respond like a child to anyone who questions anything you say.
I'll leave it at this: if you continue to spam Slashdot with your advertisements for software that blocks advertisements, then I'll put together a contact list that others can use to reach out to all of the people that you cite so that those people can hear from everyone who has to wade through your spam in order to find the discussions they're looking for on Slashdot. Those people deserve to hear how you're using their reputations. Your posts to others such as myself are obviously abusive in nature, you admit that you are willing to have your posts down-modded only to post the same content again, you demonstrably try to pick fights with anyone who questions any of your claims or asks you to stop spamming, and the people that you depend on for endorsements deserve to know how their endorsements are being used. You're welcome to call me whatever names you want, I can handle that, but at some point your ridiculous behavior has to stop.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
A GUI needs to provide process management. Modern GUIs in particular, where there is an expectation of dozens of processes running notifying the user require quite sophisticated process management. Arguably the thing that drove the biggest change in Gnome 3 / KDE 4 from Gnome 2 / KDE 3 was introducing a framework dependent on much more sophisticated process management because they wanted notification to work well.
ok, let me look into that.
Non process managed systems are simply not going to be supported.
Unsupported by who? Who gets to decide what is supported and what is not?
"First they came for the slanderers and i said nothing."
The GUI developers. Developers are who get to decide what OS components are going to be dependencies for their software. Debian changed because there were strong signs that developers were starting to introduce hard dependencies for systemd. While those could be overcome for Jessie, the feeling of the Debian people is that in 2 1/2 years there wouldn't be a choice. And while the switch in 2014/5 introduced some bugs the switch in 2017 would be much worse. The anti-systemd people (who are mainly low end system admins) refused to accept that developers don't want to deal with the ever increasing complexity managing complex process management using init. The issue was upstream from Debian, having the argument with Debian was living in denial.
As hardware gets more complex making a more complex uses possible, the underlying OS needs to become more complex to support it. There was a very disruptive change in PCs when people moved from single tasking to multi-tasking. It destroyed Amiga. It cost Microsoft something like $8b. It essentially destroyed Apple. Lots of people argued that task switching was good enough and much less disruptive. But ultimately everyone (excluding some embedded systems) switched to vastly more complex systems which had kernels with more in common mini computer kernels from a decade earlier than the CP/M, DOS and simple Unix kernels of a decade earlier. Notification is the beginning, but once notification works you are 80% of the way there to really exciting features. 10 years from now the idea of a human trying to manage service dependency will be as quant as writing assembler is today.
It seems you just don't understand its application.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
You sound like an emotional clueless person, not like a developer.
Yup, an ad hominem always wins your argument for you!
I've fixed several long time invisible misconfigurations by myself thanks to it.
Taking a cue from above, you must be a shitty system administrator because I have never seen any invisible misconfigurations myself
Why are you (a) misconfiguring your servers and then (b) hiding those misconfigurations? Sounds like you are trying to create job security for yourself.
A man who wants nothing is invincible
There code is so crap nobody can write an alternative?
I cannot understand your "logic".
Watch this Heartland Institute video [youtube.com]
LOL, logic isn't exactly strong in you, young padawan, because anybody who links to video defending climate change deniers isn't being "logical":
claims of scientific certainty and predictions of climate catastrophes are based on "post-normal science," which substitutes claims of consensus for the scientific method. This choice has had terrible consequences for science and society.
Yup, 99 out of 100 scientists have reached a consensus that climate change is real and no amount of propaganda from the oil industry will change that.
Unless there is evidence first, that is how the scientific method works. Show us your evidence that climate change does not exist or you are responding emotionally in a knee-jerk fashion.
Kinda like how the defenders of systemd do as they accuse their opponents of doing exactly that same thing.
A man who wants nothing is invincible
As hardware gets more complex making a more complex uses possible, the underlying OS needs to become more complex to support it. There was a very disruptive change in PCs when people moved from single tasking to multi-tasking. It destroyed Amiga. It cost Microsoft something like $8b. It essentially destroyed Apple.
Looks over at the stock market, Apple's stock price this fine Sunday morning is $117.81.
If that is your definition of "essentially destroyed" then there is absolutely no reason to take advice about systemd from you because someone so willing to demonstrate their lack of clue proves that they don't really know what they are going on about..
A man who wants nothing is invincible
I suspect though that most of them are actually running windoze, because they're gamerz, and their *nix flag-waving is purely theoretical.
Now try to make your argument without the ad hominems.
Since you enjoy hurling personal attacks it must be OK for your others to do so too:
Do you enjoy sucking LP's tiny penis?
A man who wants nothing is invincible
"LAMP stacks" aren't affected at all here. Apache or whatever your webserver is should already be running. I run LAMP stacks, and so I know systemd has nothing to fucking do with that shit, at all.
So systemd is not going to restart Apache when it goes down? If it does that proves you are lying, either because you are trying to cloud everything in FUD or because you don't know what the hell you are talking about.
A man who wants nothing is invincible
Apple in 2015 isn't going through a OS restructuring that started almost 20 years ago. The company survived the transition. Look at the stock price in the mid 1990s through early 2000s. Counting the splits around $.60-$1.50.
So as for lack of clue....
Debian changed because there were strong signs that developers were starting to introduce hard dependencies for systemd. While those could be overcome for Jessie, the feeling of the Debian people is that in 2 1/2 years there wouldn't be a choice.
Do you have a citation for this? I've been trying to collect this kind of information.
"First they came for the slanderers and i said nothing."
LOL, logic isn't exactly strong in you, young padawan, because anybody who links to video defending climate change deniers isn't being "logical":
You didn't watch the video, did you?
Scott Denning absolutely destroys the idiot climate change deniers at "ICCC6", ending with a cry of "are you cowards?". The whole talk is by someone who is disgusted by the way deniers attempt to rubbish the science because they don't like some of the policy implications.
Watch this Heartland Institute video
Except that I did nothing of the sort. Someone else must have if it wasn't him, but I did not. I didn't even log in on Thursday, which was Thanksgiving, and as I have a family, and better things to do than argue with more people who act like children.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
APK, grow up. Not every post disagreeing with you is by me. I don't run any sockpuppets (though you do exactly the same thing with no account). I didn't post this AC reply, but clearly you post impersonating anonymous third parties, so it is a method you know quite well, so I can see how your demented mind would place the blame on someone else, as how else could I have someone agreeing with me if not for me faking it? I don't need to use these tactics, people agree with me quite often without me having to trick anyone.
As to my signature, what does that have to do with anything, my signature points out the hypocrisy of a person being against advertising while spamming the shit out of an online forum. This is clearly fact, so why do you continue to point out my signature like it is some kind of sin?
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
Yeah, right, you aren't APK, and I am the Pope.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
Your post is a big tell that you are completely clueless about the issue you're trying to write about: you don't even understand what your own writing!
It sounds like KDE should have moved to supporting pm-utils instead of sticking with upower only:
http://nlug.ml1.co.uk/2014/06/...
No it doesn't sound like that at all. "Support" is WORK! XFCE chose to make the work to support an obsolete unmaintained piece of code. Gentoo, a distribution, like Devuan, made the work to support the same piece of code. KDE chose not to lose time supporting it.
Notice that Gentoo, a distribution that can be run without systemd, made it so that their user could still use new functionality in KDE, because it's the distro's responsability. Notice that Devuan didn't do what it should have done.
Random elements of Linux randomly adopting systemd as a prereq to working is, in fact, the thing that Devuan is fighting, right?
Wrong! Elements of Linux that have to manage the plumbing of Linux are predictably adopting systemd, there is nothing random at all about all of this, only for the clueless. That's what Devuan say they're fighting. They're say they fight the logical thing, so they're completely illogical, so it's only a dogma, or politics. Unfortunately, I don't see the fighting, which could be apparent through code, lots of it.
From their perspective, anything that requires systemd is itself a problem that needs to be exposed and repaired (or forked, as they were willing to do with Debian).
They didn't make Upower work. It requirs code, see? Full functionality of neest Upower requires systemd, so they should have provided the new Upower without requiring systemd (good luck!). It requires a package, so it's clearly a packaging error...
It's not a packaging error. It's yet another systemd issue, and it's totally legit to lay it on KDE for allowing one of their subcomponents to add a hugely unrelated and unpopular requirement to their functionality. Opposing this nonstop systemd creep is literally the entire reason Devuan exists. Not a packing error, a systemd error.
Yet you didn't understand this and say it's not a packaging error, lol! You don't even understand what you're writing!
You say it's a systemd issue, but Upower works perfectly with systemd! You don't even understand what you're writing!
KDE people don't owe you anti-systemd zealot anything, and your distro, Devuan, should have done the work like Gentoo instead of its users complaining upstream.
Your distro should be your primary source of help, not upstream, unless it's a very shitty distro that doesn't provide any support.
Repeating wrong things like "Not a packing error, a systemd error." won't make them true. You're in FLOSS environment here, not in politics.
Temper tantrums just won't work.
I've fixed several long time invisible misconfigurations by myself thanks to it.
Taking a cue from above, you must be a shitty system administrator because I have never seen any invisible misconfigurations myself
Why are you (a) misconfiguring your servers and then (b) hiding those misconfigurations? Sounds like you are trying to create job security for yourself.
I'm not hiding them, they were hidden by shitty sysvinit like inits and not strict enough tools. Lots of people have been bitten by them you know. Migrations problems towards systemd are mostly caused by this and init scripts.
This doesn't mean the configurations didn't work, just that they weren't correct but tolerated before systemd, and could be security issue.
But it's obvious you didn't understand the issue, as is telling by the fact that you believe sysadmins always make perfectly correct configurations everytime.
A working configuration doesn't mean it's correct, but I lose my time explaining that to someone that clearly has no knowledge or understanding of sysadmin work.
All I can say is you've either never looked at the systemd code, or you don't know what monolithic is. The problem, of course, is that you can't have things like logind without using systemd init.
I don't need to look at the code, I just have to look at the different process ID running all these tools to immediately understand that they are not one monolithic thing.
And what you call a problem is actually a good thing, as it's necessary for security's sake.
I understand that to you security is a problem, that doesn't mean it should be. Security should be a major concern to any sysadmin, and systemd is a huge improvement compared to any other Linux init in this area.
OK, you don't know what monolithic means. The problem with systemd isn't that it adds features, features are cool. The problem with systemd is the architecture is bad. Unfortunately that isn't something I can discuss with you, because you lack expertise in the area, but if you are interested in learned more, I discussed it in depth here.
Bad architecture doesn't mean monolithic at all. Or did you change the subject?
Anyway, none of this (bad architecture or monolithic) is a problem with systemd. Linux has a bad architecture and is monolithic too, and people have complained about it too. It's specialists masturbating over nonsense. Because to this day, none of these people were able to implement a good architecture and non monolithic alternative to Linux that works at least as well. And it's exactly the same with systemd, which follows development practices of the kernel in this regard.
Looks over at the stock market, Apple's stock price this fine Sunday morning is $117.81.
If that is your definition of "essentially destroyed" then there is absolutely no reason to take advice about systemd from you because someone so willing to demonstrate their lack of clue proves that they don't really know what they are going on about..
Removing in the equation the huge stock buybacks of Apple ($30 B just recently) is a very convenient thing to do.
You shouldn't look at the current stock in a vacuum, it's very misleading.
If systemd didn't use butt-ugly APIs, it would be a lot easier to mix and match. For exampl, you want to suspend? Call /sbin/suspend which might be an suid binary, or might use a private interface to a daemon running as root (depending on need). That constitutes a nice standard interface.
A nice standard interface with lots of "might" in the definition? suid binary (insecure things we're trying to avoid at all costs)? /sbin/suspend, of which you're not even sure it's there or of its path?
And you called systemd API butt-ugly? Was that a joke post?
Want to manage a daemon? Run a manager and pass it the path to the daemon it should manage. Again, a standard interface that can be used by any init system to provide more advanced functionality.
It seems that everywhere there is a choice between a goofball tangled mess and a simple and easy to use interface, systemd is all over the former.
At least it works, I didn't see your code contributions to resolve these issues.
It's not a matter of the init scripts. It's not that my apps are not compatible with systemd. Systemd is not compatible with my system.
Unless you mean that Linux is not compatible with your system, you're wrong. Now I'm pretty sure you're clueless or at least inexperienced.
Systemd depends on features which I can't give it in my environment. My environment is an unprivileged container. In this environment you CANNOT have use of prctl for security isolation (kinda sucks, yeah), you CANNOT have /dev as a tmpfs, and you CANNOT have access to the control groups at the kind of granularity. Systemd will not work without these features - I've tried.
So you're definitely clueless. You don't understand what you're talking about. You are in an unprivileged container, but you STILL need a privileged manager in this container, and that manager is systemd. That doesn't mean everything else is privileged. Your system just won't work without a privileged equivalent to PID 1. /dev as a tmpfs (you can even lock its size) and you won't have access to CG as systemd will take care of them.
prctl is not a systemd prerequisite. Nothing prevents you from using
Basically, having your prerequisites doesn't prevent you from running a systemd in a OS container or force you to remove systemd features, as that's not what you're asking for. You're asking for an unprivileged container, which doesn't mean at all that the systemd inside the container has to have anything removed.
Now, nothing prevents you from running systemd containers with sth else than systemd, you'll just lose eveything systemd brings to the table in the process.
Were this a sysvinit system I'd just edit the init script to remove the bits I don't need. With systemd I need to recompile a binary and deal with the troubleshooting that results.
This doesn't make sense: you want systemd within a OS container without systemd dependencies. Use sth else, then! No one is stopping you, you can still use your sysvinit + init scripts, you're on your own anyway with your custom needs.
Now, these are based on my usage of CentOS 7 which is already 2 years old on top of the release delays. I'm sure newer versions make the situation better. But at this very moment systemd has made a VERY bad first impression (there's more, but I'm not going to go into that) and left me with no practical solution. All the other things like "binary logging" just make me even more irritated.
You are making a bad impression of yourself actually, what you wrote shows you don't know what you're doing, or what is really asked of you.
I hate to reply to myself, but I realized a technical error or two. You can use /dev as tmpfs with extra effort, but if you read systemd's standpoint on containers they talk about dropping mknod support being discourage/unsupported. Unprivileged containers aren't allowed to use mknod so that's already out the window.
You still show you don't even understand what you're reading. /dev as tmpfs yourself, which you don't need to do and shouldn't do, as systemd is already managing that for all your services. /dev, which you should not touch. But in a container, the /dev is isolated from the base OS, and you have to be able to make nodes in it one way or another, and this is by using a process that have the CAP_MKNOD capability. That's because everything in your container is unprivileged. Or else you will have an empty /dev, so a container that won't work with a Linux kernel. As I said earlier, you don't understand what was asked of you in a unprivileged container, which is exactly what systemd will provide to you. But you have to understand the link you've given to know that.
Apparently you try to use
And they're not talking about dropping mknod unsupported, but about dropping the CAPABILITY being unsupported. Which makes perfect sense, as in devtmpfs, the kernel is making the nodes in your
My bad, I took a shortcut there. Still, how is what systemd provide now better than what was provided before by different projects?
It's explained in the link provided in the OP. Do your homework before spouting nonsense.
How does this reply to this specific topic: "Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system."?
Your problem is that there is nothing to discuss, as everyone can say up to this day that KDE or GNOME don't depend on a particular init system.
I can compile a complete KDE or a complete GNOME without any dependency on a particular system.
Of course, I'll lose some features if I lack some dependencies. And I'll lose some without systemd.
But that's a distribution problem.
On my hand made systems for example, I lost the geolocalisation tied features of GNOME as I didn't install these dependencies when they required me to install 2 different major versions of these libraries.
Another example is that I lost the ability to use XScreenSaver in GNOME or KDE a long time ago, as at one point in time, it became more complicated to make it run on top of these DE, as it became unsupported. Some distros still support it though, but I made the painful choice to move along. I still use it with my XFCE desktop which I rarely use anyway.
It may remove some work for some people but it adds a lot of work for system managers by new binary logs in formats that can't be processed without special tools and a headache when it has to be reconfigured to suit the specific environment it's going to be used in.
And still there are people swearing by systemd - probably because they never have to provide support on the production systems that runs it.
Another contributing factor is that if it's hard to configure right then there will be security holes causing a lot of headache for system administrators. In most cases as long as you get something working you are satisfied even if you don't know why it's working - and then you may have a security gap the size of Grand Canyon in place as well.
Fortunately systemd arrived for the lots of bad sysadmins like you. That's one big reason why I'm glad systemd will be the default in most enterprise distributions.
Clueless admins like you must have tons of security holes in their custom made init scripts and when they use even the provided ones: that's my experience seeing clueless sysadmins working, they didn't understand anything about their revered Unix and how it works, starting with sessions.
And what you wrote show a complete lack of understanding of init scripts and systemd: what you described is actually reversed, init scripts are the far less secure things. And not even knowing that you can still have your usual log files with systemd takes the cake in cluelessness.
systemd will either remove or force improvement of all the bad Linux sysadmins out there, which is all for the better, and will lead to better secured Linux systems in the wild.
Unfortunately systemd is what can cause a huge security hole, not solve it. The reason is that it's so hard to penetrate fully that it's possible to misconfigure while the init scripts are easy to understand and set up if you are familiar with the usage of "su".
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
A nice standard interface with lots of "might" in the definition?
You do realize I wasn't trying to define the one true API there, but just highlighting a few sane alternatives, right?
I'm not sure why you think a confused deputy is more secure than an suid binary. Of course, you can use fscaps to grant the binary only the priveleges it needs which is safer still.
I don't need to look at the code, I just have to look at the different process ID running all these tools to immediately understand that they are not one monolithic thing.
No, you're wrong. An architecture can be tightly entwined and still be divided into different processes. In some cases it can be running on different machines and still be monolithic.
Basically you're clueless about software architecture, but you seem to like systemd. Maybe you like the systemd features or something. There's nothing wrong with that.
"First they came for the slanderers and i said nothing."
You could do a websearch on these 4 files. They were key to the discussion:
http://anfo.slavino.sk/libpam-...
> http://anfo.slavino.sk/libsyst...
> http://anfo.slavino.sk/libsyst...
> http://anfo.slavino.sk/libsyst...
Cool, thx, I'll check it out.
"First they came for the slanderers and i said nothing."
you need to stop confusing systemd (the binary) and systemd (the project) - it certainly was intentional to call them both the same name and has caused tons of confusion...
FTFY.
I'd love to give the benefit of the doubt, but no one who's been involved in any sort of technological, engineering, or business project in a larger ecosystem could possibly fail to recognize the "embrace and extend", vendor lock-in pattern that happened there.
The systemd of today would have been rejected had it been (fully) proposed as a unified whole in Fedora 14. Leaving the true agenda unstated, or implying that there'd be no pressure to adopt the rest of the systemd "platform" was exactly what you'd do if you wanted to get your foot in the door. To assume that wasn't intentional is to assume that Poettering is an idiot and doesn't understand how the Linux community works. After his previous software contributions, I fail to see how that could be the case.
Hire a Linux system administrator, systems engineer,