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.
The integrated face system is a mandatory components of all Desktop environments, including TWM.
OS X
I am Slashdot. Are you Slashdot as well?
Yes.
Software developers make .service files with their packages these days.
We kill the systemdman.
Of course not. Lennart's not going to be happy until he controls the whole OS.
Just use an operating system that has proper quality assurance.
The systemd cabal has won.
Give up trying to fight the moralistic fight. UN*X is no longer the ancient monolithic beast you learned to love in the 80's.
I'm sad as well. Heck, I'm even using network mangler on servers theses days. (10 million kittens probably just died).
Posting anon for obvious reasons (I'm a kitten murder).
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
unless you spend a few years doing your own 2016 is the YEAR OF SYSTEMD. BOW BEFORE US STUPID UNIXER.
Post the issue to your distribution not the systemd group. 1D10T
Linux GUI environments are not reliable. The best example of a reliable GUI is indisputably Apple's OS X, which uses launchd. I use Linux extensively thru shell environments from OS X GUI. Cant get any better.
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.
Die Systemd! I prefer my log files in text format.
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...
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.
Here was my original post to contribute to starting the flamewar:
"Never heard of Windows or OS X? Or by "modern desktop" you mean "experience lagging the mainstream concept of modernity by about five years" ?
PS Using some random hipster linux distro because a bunch of trolls on slashdot told you to do so, and then expecting to get excellent support from the developers is the very definition of insanity."
I have never been prouder of the Slashdot community that this sentiment was already covered by all the comments that showed up before I could post.
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.
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
These distros have been moving further and further away from their UNIX roots for years.
Slackware and Gentoo are major Linux distros and still over a non-systemd middleware.
Run KDE on FreeBSD if you don't like Systemd. It works you know.
Slackware FOREVER !!!!!!!!!!
SystemD == Linux at this point. You will not be able to run any modern and supported (by either active/large community or corporation) Linux without it.
Is that good or is that bad? I would say it is immaterial. Until now we had good old fashion init, what that good or bad? Answer: Both. Just like Systemd.
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."
Correct. Systemd is not about a modern init system. There are tons of modern init systems being worked out now. Systemd is a takeover of everything above the kernel level.
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."
I've got a green tan from my 80x25 CRT monitor. Lynx is nice and fast. Who needs Javascript and Java? Command line it!
I downloaded void linux live LXQT, previously I have been months on void E19 but I don't like its file manager. Install went ok, suspend/resume went ok, boots FAST installs/removes packages FAST, the init scripts of runit are one liners, I witness no quirks which plague systemd-distros at the moment. YMMV, but I question your destination.
Captcha : passages
your right, no window manager should depend on it, but your wrong about kde or gnome as they are desktop environments not window managers.
> As we've all learned from Apple: No half-assed shit. Do or don't do.
I'd excuse a higher UID for this statement, but yours is too low. Apparently you weren't around in OSX 10.0 and 10.1?
It might work if large portions of the community didn't defect if people said so.
I've pointed out the monopolistic behaviours (charging millions to cell companies to just have their phones), false advertising, and the 30% tax that applies for all in-app purchases (literally, you can pop into a web browser and get the same thing for cheaper; it's why bigger stores like amazon don't have apps you can buy from), hell even APL straight out calling their users unreasonable (see lawsuit "no reasonable person would believe our advertising" when people link like mad their advertising) ... Even a few complain about not having money, then blow an extra $500+ on a 512GB SSD when they barely use 128GB (this was a few years ago when SSD prices were on the expensive side).
Absolutely no-one has moved away, despite complaining about other services being more expensive than needed or monopolistic. The reasons provided for continuing range from "it's pretty" to outright dismissal, from regular everyday people to tech nerds.
As much as I don't want to be that "fanboi hater", everything I see points to extreme, blind, dedication.
Now if SystemD had that same core audience, I can guarantee you that the devs would move over instantly and not care. However, since this is a community-contributed project, a sudden move will cause massive defections (as per this guy) and the project would die.
If APL did the same thing, they wouldn't care because their remaining userbase is effectively funding everything necessary due to their high margins from those who stay - they'll just make a lot of money instead of obscene amounts.
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
> 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.
Which means ripping _everything_ out which the Holy Poettering decided to be a good idea to put into SystemD that doesn't belong there.
Json parser in SystemD, wtfm8.
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*
Same AC. ... SystemDinux/SystemD Kernel or something like that.
If Lennart continues like this, he might as well attach the whole linux kernel to SystemD and call it a fork
$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...
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.
A Plasma(which sucks ass) advocate thinks that systemd(which also sucks ass) is the way of the future.
The real question in my mind is; can Linux survive this trip down the wrong road and get back on track, or is this systemd diversion going to be the end of Linux?
Remember when Upstart was the only way forward? That turned out to be a trip down the wrong road. But not every distro jumped on Upstart, it didn't replace the logging system or break workflows, and Desktop Environments didn't contemplate chucking large sections of their own code to then rely on it.
No matter how smart you think you are; there comes a point where people are sufficiently sick of your shit that they will act against their own interests to get the fuck away from you
You posted as AC. Try again.
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.
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.
Linux on the desktop is irrelevant, just like Linux is becoming irrelevant because of this continued systemd faggotry.
Who the fuck is going to run servers with systemd? Centos 7 is not an upgrade path that is acceptable for anyone.
The reasons are obvious.
Not a anti systemd troll. Fact: systemd is designed by an incompetent, stupid, and arrogant cunt who:
- isn't a system administrator
- probably doesn't use Linux for shit besides developing systemd.
The time has come to hire someone who isn't an incompetent cunt to write an init system.
Big deal. GNOME got forked as well: check out the Mate project, forked from GNOME 2 before the "let's remove all configurability" push. Mate's terminal emulator is nearly perfect, whereas GNOME's is barely usable.
That's Free Software for you. As always, the connoisseur must look at options besides the ones Red Hat etc. would offer.
Because desktop environments need closer integration to the hardware/kernel/root only things then a window manager will ever need. They should provide user interface integration for handling things like usb devices coming and going, cdroms, suspend/resume events and triggering, etc.
The kernel folks believe userspace should deal with that, and only root should. For better or worse, systemd has provided the necessary integration with the kernel and exposed it to the rest of userspace, including the desktop environments. Its not ideal, but its the best thing so far I've seen that attempts to addresses the problem.
Some more details here:
http://linux.slashdot.org/comments.pl?sid=8387451&cid=51003969
1) you seem to view complexity as something bad that was foisted onto this project. It is not, it is an inavoidable fact of all systems.
2) variation of vendor lockin? Well, when it's open source code you're getting for free, I don't know how you can call it that. But ok, granted.
3) what has the linux world gained? What is the "Linux World" anyway? If you define it as "people who like linux but hate systemd", well then I guess the answer is already obvious.
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.
But stderr is an out of date concept. You should use the binary journal since it is much more powerful.
I think its pretty obvious what it is...its SVCHOSTS for Linux, a once simple idea that continued to grow until more and more of the system is running it and won't run without it.
Considering how all Red Hat talks about now is virtualization and the cloud? Mark my words Linux will be nothing but a VM running on SystemD in 5 years, I wonder if Linus will stick around when Linux is a second class citizen running on top of a system he has zero control over or input in?
ACs don't waste your time replying, your posts are never seen by me.
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. At present, no other viable solution has been forthcoming, hence the implied dependency on a particular init system. Its not an explicit dependency, its an implied by features one. Your right, that its not ideal. but its not like they are purposefully trying to tie to systemd, they are just trying to get their job done, and no one other then systemd has bothered to create a viable solution to the destkop environments problems. That means, systemd does provide features that people want over what other init systems provide.
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."
Neckbeards dominate windows 10 posts and I have more cred than the lot of them. Upgrade to windows now rather than later and free yourselves from tools who think that hijacking your boot is okay.
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.
Because desktop environments need closer integration to the hardware/kernel/root
Nope. The kernel is there to insulate the user (and anything the user runs) from the hardware layer. OS Design Principles 101.
integration for handling things like usb devices coming and going, cdroms,
Already done. Without systemd.
suspend/resume events
Didn't even read TFS, did you? This is what the submitter complained about. Suspend and hibernate are broken (thanks, systemd) and the response to his report was basically the software support equivalent of "Fuck you!"
Have gnu, will travel.
Run KDE on FreeBSD if you don't like Systemd. It works you know.
It won't continue to work for too much longer.
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.
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."
That point has been discussed and is irrelevant to the discussion.
"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!
... Environment In 2016 Without the Kernel?
Why the fuck should I care? So many electrons have been wasted by complainers complaining about systemd when they could be coding up an amazing alternative that simultaneously solves all the same real problems that systemd solves but in a better way that would prove how incompetent the systemd folks supposedly are.
Sadly as usual, the systemd situation is proof positive that code talks and bullshit walks.
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.)
"First, only an idiot would want a monoculture, particularly in the Linux world..."
Like a monolithic kernel?
"So while I'm sure the systemd zealots..."
You are the only zealot. Everyone else who is actually a linux programmer and knows what systemd has to offer has already moved on.
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.
systemd doesn't send it to the journal, so I assume I assume it is just lost.
KDE was heavy at the beginning, but I disabled Nepomunk and Akonadi, and haven't had any issues since
At the beginning there was neither Nepomuk nor Akonadi. KDE1/2 was quite bloatless.
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.
A patch that fixes the downsides of systemd basically removes it.
If you're going to stick to the upsides of systemd, install Windows.
systemd is not an init system. Sure, it does that too, but what it really is is a complete change in how Linux systems are managed, and by extension is extremely Linux centric making it very hard for other OS to use free software that more and more depends on systemd. OpenBSD had a GSoC project to write systemd wrappers, or emulation layers if you will, to give the big desktop environments a chance to still work on non-systemd platforms. systemd is a total disaster. It represents everything the Unix philosophy is not. Do everything and do it poorly.
The real question is, "Will self-driving Uber cars use systemd when Elon Musk takes them to Mars?"
You are welcome on my lawn.
Until the Linux kernel requires systemd to boot, things really are not that bad. There are lots of tools for managing your system that are DE independent. If KDE is making a choice that you can't live with, maybe its time you broke-up with it. Give it enough time and the only way to access your system core will be via an html/css/javascript/php interface or something like that. I remember the move from Win 98 to XP. You could still use the CLI, just not without your windowing environment. Imagine if the big distros fell into a trap like that one day. The code divide would be much larger. You'd still be able to run the Linux kernel without using a main distro including such insanity. But just imagine that world.
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.
Normally, I'd agree with you, but with Lennart being in charge of it, it'll be half-assed like everything else he's touched. Therein lies the problem it...isn't...designed. There's no sense of "mission critical" with this man, and systemd SHOWS IT. Just like Avahi was and PulseAudio before it. Sorry, the concept is needed, what is getting executed isn't.
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.
they decided to not use the system as designed by the desktop environment writers, and accept the "if it breaks, you get to keep the pieces" risk, and it broke, and they are complaining. Very little sympathy from where i sit.
If the other init systems want to gain support, they have to support this same kind of functionality somehow.
LOL no they just need to cry louder and louder until the world loses patience and goes back to SysV Hell!!! Just ask slashdot, and you'll see. ;)
I suspect though that most of them are actually running windoze, because they're gamerz, and their *nix flag-waving is purely theoretical. If I'm right it means they won't eventually switch to the *nix flavor they like and shut up, but instead will keep blathering about it for decades.
I personally really appreciate the changes. dbus is the network-aware IPC solution of modern *nix. It already replaced the SysV IPC crap that many of us were still stuck coding for just a few years ago. Moving those advantages into the system level is natural, and a hell of a lot more pleasant than the "enterprise" crap that had the same network management capabilities but were shoehorned piecemeal on top of various directory services, databases, or (shudders) SNMP. Not that SNMP is bad, it is great at the monitoring side. But it is not very pleasant as a control mechanism or bidirectional communication medium.
The ordinary installation.
There are tons of modern init systems being worked out now.
Where? Which ones? Given, as per your statement, that there are "tons" of them, can you provide a list of examples for us who are not as familiar with them as you are?
Dropping syslog messages shows how inexperienced the systemd guys are. syslog has been critical for running servers for decades.
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.
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.
These arguments always remind me of a line from a U2 song: What you thought was freedom was just 'free'."
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
Because that's for losers. Real computer users get with the program and use systemd for everything. Or they'll get made fun of when they complain about the stuff they want to run depending on systemd when there is no rational reason for it to do so.
Because that's for losers. Real computer users don't cause what they want to exist, they just demand that somebody write the software they want. Pathetic newbs use what others write, or write what they want to use. Real computer users understand the value of convenience, and maximize the efficiency of their uses by waiting for others to do all the work first. And if they don't get what they want, they know it is more efficient to complain loudly and persistently for years until somebody writes what they want, than to write it now, or learn how.
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.
You understand that if you substituted Linux for Windows 10 in his post, that's exactly how Slashdot has been forever?
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...
Modern desktops aren't just window managers... They are increasingly tightly integrated with ever more aspects of your computer
I think that's what OP meant when he said it's a clear sign of poor software architecture.
+10000
Solaris works beautifully, is more stable, better features and actually works, whereas Linux kernel based operating systems are unstable, buggy as hell and doesn't have a real memory manager. Linux kernel based operating systems are left with the "let me guess" memory manager and "oh hell, I fucked up, let me kill something and hope you don't notice - oom killer".
Someday, perhaps 30 or 40 years from now Linux kernel based operating systems will be as stable as Solaris was back in the late 90s (SunOS 2.6) and maybe even the early 2000s (SunOS 5.8), but I'm not going to hold my breath.
"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.
just change the default settings... journald works quite well but the default are retarded, they look like they were choose to sell rehl7 support or certification
Not that I have any idea what I am talking about, but...
Is it not possible to just write a standard interface that would have it working with any init system? or Maybe write an interface module to make a different init system work in place of systemd? Basically I guess there would have to be a standard that is written that the other conforms to to provide all of the functionality or atleast a way to provide extra functionality through other sources. Then if your chosen init system lacked something then a separate module could be used to manage just that, but the bull seems to be coming to an agreement as to what should be there and getting everyone to agree on it.
+10000 again
> 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.
Tight integrated system , thats complete bollocks.
Use almost any unix desktops 'control panel' / 'settings manager' or whatever flavour is this week and about the only thing you can configure is the desktop
your lucky if it admits to a computer underneith it.
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.
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"
Thanks for the interesting posts!
You wrote:
I have the exact opposite experience. I am going to guess that you write end-user accessible software? I write deep infrastructure that goes on servers nobody logs in to. It's always been easier on linux than windows, by rather a lot.
Having to write to a layer that only exists to provide services to end users adds needless complexity to deep infrastructure. Complexity is the enemy of both reliability and security. So while I don't care what is done to support end users - more power to them, I say! - I don't want to run systemd on my servers which nobody ever, ever logs in to. It's the same reason I don't want to run pre-nano windows servers.
But now that Snover and Russinovich have given me nanoserver, and linux is increasingly dependent on systemd, maybe it's time to abandon linux in the server room. Red Hat costs more than Windows anyway at this point in raw server license costs; the cost of RHEL has already driven us out of OpenLDAP and samba and RHEVM, we replaced all that with Windows server2012 when Microsoft offered us the same services at half the cost.
It doesn't seem like servers are the target environment for linux any more... it seems like the new target is college student laptops, where systemd makes perfect sense and provides great features.
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."
LOL you know that you can still read a "binary log format" (were the old ones analog? do the new ones lack text?) using text tools, right? And that you can simply leave the old logs turned on, and still read them?
Did you know that all the old SysV scripts are still supported? Did you know that most daemons don't even have new systemd style startup binaries? And if one does, you can simply delete it, and go back to the SysV script? It isn't like giving up the crufty SysV init process means that you can't still use the init scripts.
"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. You're trying to dick-wave, but you're waving a plastic dildo. You're full of shit that systemd is harming your work in the ways you describe, and if you did that work you'd understand why. Binary logs, are fucking joking? You can't read a log anymore? Guess what, you misunderstood the complaints about binary logs when fabricating your story. In real life, logs are still readable.
What we've learned from Apple is that they've totally abandoned the enterprise market.
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.
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.
And I've personally compiled and installed non-init parts of systemd. You're not going to convince me that I dreamt it; it is actually a well-known myth about systemd that it is modular. Repeating the myth does not make separate compilation or operation of the parts difficult.
I personally don't care about light and fast. If I wanted fast I would just use tty2. I have an exorbitant amount of resources available on a modern system. I use KDE because I want a flashy EXTREMELY customizable GUI... something that makes use of those resources. Systemd/Init.d should be an option just like the desktop. Why does it have to be one or the other? I wouldn't expect to be able to use either at boot, but why not prompt at installation time? It would probably require another abstraction layer though.
Seriously, FreeBSD is so far behind Linux it doesn't matter any more. It's just a hobby OS.
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).
Why does the on-disk storage format of the log file matter when you can read the log just fine? Type journalctl instead of cat. If you're a bit stuck, try man journalctl.
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.)
Oh, and the actual daemon startup commands are stored in plain text config files called things like ntpd.service and httpd.service. They are much easier to read than 150-line init scripts full of boilerplate code and daemon launch commands concatenated from 7 different string variables.
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
The worst example of that is MongoDB. When you have the lock file, it outputs this clear message to stderr:
old lock file: /var/lib/mongo/mongod.lock. probably means unclean shutdown recommend removing file and running --repair
You know exactly what the problem is and what actions to take. With systemd, that message is swallowed so you're left guessing as to why it didn't start. There is no message saved in the console.
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.
Monolithic is not a synonym for Modern.
"Unix basically is Linux these days."
BSD is Unix these days. Linux is trying to be the new Windows.
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
> since nobody is running systemd except by choice
That's an incredibly political and untrue statement. It OBVIOUSLY isn't true for any useful definition of "choice" - I'm running it and I myself made absolutely no choice, it just happened in an upgrade and got decided for me. Now I am forced to choose whether to keep or move. Unless you think I could have "chosen" not to upgrade, or "chosen" to write my own OS, which are clearly non-choices for a busy person.
My main objection is the absolutely asshole-ish nature of the comments made by the pro-systemd folks. They sound like people who would do their own thing regardless of anything much - very clannish and defensive and "we know best" - and I remain to be convinced that people with that attitude would make wise technical decisions. Inspire confidence they don't. I can't get away from the feeling that nobody involved is older than twelve.
And can I make the point that your derogatory posts aren't helping. I'm sure you aren't an asshole, but you might want to know that you certainly are managing to come across as one.
>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.
Why suggest that someone controls systemd development? Its an open source project with a copyleft license and full source code available via git. Its about as open as any other project. If distributions didn't like it they could easily fork or adjust it as they please. This hasn't happened. No need to get upset with the choices made by people who've developed the software.
I read somewhere recently that Debian was going to maintain both a systemd and non-systemd os. I also think I read where Slachware is non-systend.
>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. 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.
Yeah, jerkoff. He "tried" Linux and then went back to Windows. Because of systemd. Because. Of. Systemd. Kill yourself and rid humanity of your stupidity.
There used to be only gnome and KDE as desktop environments for Linux. We now have gnome, kde, cinnamon, mate, unity, xfce and lxde. The last two can be considered more light-weight than the first five.
Gnome depends on systemd. KDE is considering it. Unity will depend on systemd, if it doesn't already. Xfce will probably not have a mandatory systemd dependency in the future. The main question is basically what cinnamon and mate will decide to do. Does anyone have an overview of the roadmap of these projects?
My apologies to people who use window managers or less known DEs.
despite what the neckbeards of Slashdot proclaim
Oh. Neckbeard. Never heard that one before. Do you get paid to troll that hard?
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.
Or maybe your autism is keeping you from discerning the latest in a long line of anti-systemd trolling.
Every Linux distribution is bullshit. I just tried to install Krita and it fucking wants to install PulseAudio. What the fuck does audio have anything to do with Krita? Bunch of stupid fucks at Debian and Ubuntu.
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.
Systemd sure isn't for the users. I don't even think it is for developers. I mean, who in their right mind would design a program to work only with a certain init system? Before systemd, applications worked with different init systems.
I think systemd is for the distro builders/maintainers. It allows them to put the responsibility of creating the service scripts on the developers instead of each distro maintainer creating init scripts for their own distro. Apparently distros these days don't care so much for users, only seem to care about lessening their workload.
I'm guessing Debian Jessie (ARM arch) and CentOS 6 (x86_64) is about as far as I can go with those distros without having to deal with systemd. If their aren't any distros that suit me after that, I'll move along to the BSDs. Already got one running in a VM and learning lots about it. I figure if I have to learn a whole heap of new stuff, then I'd rather learn about BSD than systemd.
after spending a few bucks on a Software defined radio and researching the apps available for SDRs and trying both Linux and windows and building from source on Linux VS installing binaries it has come to light that it dont matter if you build from source or install binaries from package managers SDR on Linux SUCKS!, and on windows it performs better (not great but better) and i dont have the time or inclination to roll my own anymore, so i became operating system agnostic, i dont care anymore if it is Linux or windows, whatever OS has the apps pre-rolled that work the best is all i are about, and so far WIndows wins in the SDR dept, but i still do all my general purpose computing on Linux for the time being = the love affair with linux is over, i dont have the time to fiddlefuck with Linux anymore, so whatever OS has the right app for the job gets the job, if not it gets pushed to the back burner
Politics is Treachery, Religion is Brainwashing
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.
stderr and stdout are all present in the journal.
I actually remove those packages and others after an install to
make KDE use less resources. I also turn off lots of systemd bloat.
I cannot get systemd to boot into runlevel 3 using its interface (something like default.target sym link). It keeps changing back
to runlevel 5. So now I use the kernel boot parameter 3.
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.
A fellow vtwm person, yes vtwm is great and works on any system that has X, all the way r5 I believe. Posted Anonymous and from vtwm so I can mod you up.
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".
But Gnome3 sure sucks. So does KDE.
> 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.
If Linus or someone adult enough to not pretend an angry "go off and die somewhere" is a serious death threat was running the project there would be little or no fuss.
However systemd is not about consistency, it's about rapid expansion before the existing parts are truly finished. There is no real benefit to one team being responsible for most of linux infrastructure if it's full of ad-hoc bits glued on as best as they can fit.
The community doesn't get a say. It's a small team with RedHat using it's market share to impose it on the community. The lack of depth and small size of that team really shows with things like the "su" stupidity recently - the project has extended far beyond their competence while instead of dealing with that by getting help or collaborating they are actively pushing other developers away.
It's just like Pulseaudio before Lennart left to work on other things, or NetworkManager before Lennart left to work on other things. Rapid expansion and moving target inflicted on users as "stable" when it is no such thing.
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.
Saying "binary log format" is perfectly acceptable . The difference is that a "text format" is limited to ASCII and it's been used broadly since the 1970s. Binary means that a byte in the file can contain any value in the range of 0-255 and, semantically, the content of the file can represent an image, executable, etc. Unicode has made the distinction somewhat greyer but the meaning is still valid.
Don't know exactly how that clump of sand got into your vagina but you may want to wash it out. Best of luck.
Absolutely. I'm already working on getting DBus out of my system, one dependency at a time. If I can handle that, the SystemD isn't even a question.
So not testing for null pointers before dereferencing is an acceptable programming practice to you? No professional programmer would ever concede that.
Facepalm.
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?
Going for emotion instead of reason I see.
Somehow students are able to deal with that horror show you are describing. What should that tell us about how difficult the problem really is?
Leonard? Is that you?
"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.
Boo hoo waah waah change wahh boo hoo I'm old boo hoo change waahh wahh boo hoo.
Everything I did worked fine in DOS, so I guess there was no point to Windows 3.1 either.
AIX had the Subsystem Resource Controller (SRC) before all of these.
Think about how the systemd-haters would be shitting their pants if Linux adopted AIX's ODM...
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.
Most systemd critics recognize sysvinit's shortcomings and wish to have it replaced. The argument is not over whether it needs to be replaced, but over *how* to replace it, and *what* to replace it with. The very author you replied to says he wants sysvinit replaced. NO ONE SAID init is great. You are arguing against a position no one holds.
It's easy to take POSIX compliance for granted, but it's better to at least "aim toward it" than give it up completely. I, for one, am not ready to give up completely on portability, which, by the way, is what the systemd developers are doing.
or, your method of Suspend and Hibernate are no longer supported, we do it this way now.
oh sorry, didn't mean to interrupt your rant, please continue
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.
Lol, but what about FreeBSD and such, then ? I can tell KDE hase a HUGE user basis among the (still many) users of this system. So what then ? Because I am sure that the FreeBSD devs will never ever start adopting systemd ...
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.
Perhaps he's one of the people that have tried Linux, and wasn't impressed. It *is* possible to decide that
No, no it is not. You can see from the other replies to your post that you clearly must be a troll or a Microsoft shill because everybody knows that Linux is perfect and it is impossible to not be impressed by it. That 98% of users that don't use Linux on the desktop? Dont worry we have plenty of conspiracy theories and stories of oppression that explain all of that without having to admit any failing on the part of Linux or ourselves.
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.
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?
I see you never got underneath the hood of your *buntu system. There were shitty kludges all over the place. Sure it was great if you had a desktop system with wired internet connection. But I remember having to go in an mess with sysconfig to get wireless working the way it should because of crap integration.
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.
Then separate the systemd parts into multiple, independent, programs. That way, I can run init-scripts, kdbus and new versions of KDE in the same system.
There are two reasons why I will not run systemd on my computer:
* it consists of multiple highly-coupled programs
* some of those programs are terribly low quality
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
Thanks! Upvote! I come to Slashdot to avoid that sort of spammy crap. This APK guy really is the pits.
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)
I'm surprised no one has mentioned Slackware - one of the oldest and most stable distros out there. I know the "stable" branch hasn't been updated in a while, the but the "unstable" (-current) branch is as stable as most other distros "stable" releases, and presently nearing a new release. This is being typed on a 64 bit - current system!
OK, the official version only has KDE4, but packages for KDE 5 are available, if you want it, along with just about any other desktop environment you could want. It boots just as fast as any systemd distro ( I use Mageia for "quick and dirty" installs), without all the aggro associated with systemd. Its clean, its simple and it works!
If KDE becomes dependent on systemd, then I shall simply switch to xfce.
My hardware, my choice!
--
Pete
I'm very happy to see the Devuan project progressing!
As a long-time Linux user, albeit a layman, I was very frustrated to find apt-get upgrade resulted in a 60 second system stall at every boot time, as systemd tried to interfere with my network adapter. Call me old fashioned but if it ain't broke don't fix it! Besides it's all about freedom of choice right?
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)
Thanks for pointing out exactly why using systemd has a downside. The whole idea of one monolithic project that wants to do everything is wrong, wrong, wrong.
Why don't the systemd people just go build their own OS? I'd have no objection to that. Instead, they piss all over the tried and true engineering practices which brought open source and linux where it is today, or at least a couple of years ago. If linux had started with systemd 20 years ago, we'd all be using a BSD variant.
The early Linux hackers were smart to make the heterogeneous choices they did, it made linux distros dependable and evolvable. System components were independent, which meant you could replace faulty ones, and you could incrementally improve working ones without impacting anyone else. Now? Not so much. And that's bad, because Linux is losing the ability to evolve due to the ball and chain that is systemd.
Systemd is like a virus eating linux distros from the inside out. When it's replaced 90% of the services any one application might need, it will be game over. We'll have one single, bloated, all in one OS that won't run on anything but the beefiest hardware and will require constant reboots to fix "issues" nobody will be able to diagnose. We the community will have to rebuild a new alternative open source ecosystem from scratch, wasting the good work everyone put into Linux since the 90s.
Meh, now I'm depressed.
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)
There's no benefit in getting the community behind systemd, it should just die. Try installing a Linux with systemd on a low powered smartwatch. What? Systemd doesn't support doing that? That in a nutshell IS the problem. Linux distros that only run on a standard virtual system that pretends to be a desktop PC are the past, not the future.
You really need an on-line hobby.
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?
They deserve to die. Kill them.
Or fork everything.
You should atleast beat the shit out of them.
Killing them would be good.
Reiser wasn't above killing.
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
The morphing is effectively "bait and switch". It causes problems where there weren't any, which is exactly why so many people are complaining. Sure, with enough effort and dedication, all problems can be addressed. But they are unnecessary in the first place.
1) An OS abstraction layer is sufficiently important that it should not be adopted without all major stakeholders agreeing on the standards. Systemd is an ill conceived design that evolves according to the developers' fancy. That's bad, and it's not a good engineering approach for a world class system that millions depend upon.
2) For every example of a project where a benevolent dictator has managed it successfully, there's an example of a project where a benevolent dictator has run it to the ground. One thing that matters is if the dictator is a better engineer than most of the contributors and has their respect, this is clearly not the case for Poettering.
3) This causes unnecessary coupling in the software engineering sense, which is incidentally the complaint from TFA.
4) We don't know what a modern OS is supposed to do in the next 10 years. It might run on a little stick computer which you wear behind your ear, communicating with you via a combination of head movements and listening to the vibrations from when you subvocalizalize commands to it. Who knows? Having one party go it alone in inventing an OSAL suitable for the desktop environments we were running 10 years ago is idiotic today.
All worthwhile major software engineering projects that are pitched to be the foundation of other engineering projects that piggyback on top of them have some form of standards body, and design processes that take years before a single line of code is even written.
If only there were any honest people who like systemd. It's hard to take the alleged positive aspects of systemd seriously, when no honest person ever has made a positive claim about systemd.
You and all the other informed systemd defenders know very well that when people complain about lack of modularity, the parts they want to get rid of is either systemd pid 1, or journald. Yet, you keep answering with the same crap about systemd being modular, except in every way related to the modularity discussion - with the last part often left out.
This is done so often that nowadays, even the clueless systemd fans keep repeating it.
You could use Windows or MacOS. Both don't have systemd.
Entia non sunt multiplicanda praeter necessitatem.
They DID exactly the same, in the bad old days. That almost killed them, handing the entire market to Microsoft.
Linux came in from the side and unified the Unix world, which is why we are discussing this here in the first place, rather than in a closed Solaris forum requiring a paid membership.
Repeating the mistake that almost killed the Unix world, and delivered the market to Microsoft on a silver platter - the only people who would like that are Microsoft and Apple.
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?
And Microsoft has been celebrating ever since. Oh, and have you ever heard a Solaris admin talk about the thing they replaced it with? Those swear words make systemd discussions sound civil.
They were never an important Unix verndor. Phones and tablets is their strength.
The least important of the BSDs, got it.
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.
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.
It's easy to get confused between the two:
One is small, green with pointy ears. The other is Yoda.
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.
Oh, there are other parts that do the same things. The shim BSD is apparently using is one example.
Basically the new thing systemd-PID1 does is that it provides a set of services: It starts/stops stuff, it logs what it is doing and it manages the cgroups. Much of the other functionality provided under the systemd umbrella does not need that and those parts will happily run on any init system. But some parts (mostly logind) do need the cgroup management service, so these do depend on systemd being PID1.
This is a pretty standard layered architecture. You can switch out all the layers with different implementations -- provided you provide the same interfaces to the layers above yourself.
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 read the first link. Poettering says: "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..."
This is a bug, sure, but it happens only when the execution has already left the happy path due to the unsupported environment. The bug really is not that important.
I'd say when you sum this up as "Systemd contains an unchecked null reference pointer that segfaults PID 1. Lennart Poettering states he won't fix it", you're leaving out important details...
Haven't read the other links.
No.
But it's good when a developer knows how to manage his time and prioritize. There is always more work to do. It's never over. But your resources are limited.
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
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.
Frankly that is intolerable even on the desktop. Not because of aunt Tillie directly, but because someone inevitably has to fix something that does not work. And with systemd one is back to Windows, and hitting the reboot button enough times that it kinda splutters back to life (or go for a full reinstall).
Systemd is good for two things, web terminals and *aaS conainers.
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.
Once again that faggot Lennart has poisoned the well. The diarrhea that spews from his gaping goatse-esque anus continues to be slurped up by the shit eaters at RedHat. Fun fact, RedHat is actually named for the glory hole of the men's bathroom where the original development team would go to suck off anonymous faggots. Coincidentally, this was how they came across our dear boy Lennart. He popped his micropenis into a glory hole at one of the local LUG meetings and was quickly hired for his near insatiable desire for gay sex. In fact, the only thing Lennart likes more than a disease riddled cock in his ass is to write shitty code.
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
See subject: Says all that needs saying - he's onto you trolls around here and you couldn't stop me from doing well there, lol @ you ALL...
* :)
See that subject again? You WISH you were me (especially you AmicusNYCL - you're JUST LIKE Coren22 - lots of "talk", which any FOOL can do - but nothing you ever could backup with verifiable facts that you are indeed, a coder - let alone any GOOD @ it... lol!)
Coren22 claims to be a 'security guru' & MCSE? Hell, I had to show him HOW to trace my app for forensics purposes... he's full of it.
IF you guys were ANY GOOD? You'd find a bug in my work... funny - none here ever has or will (code is bulletproof & bugfree, as is all my work).
APK
P.S.=> Face facts: Nothing you trolling worms can do can affect me - get it? Good! Least of all your effete vain impotent abused moderations... 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? I've saved someone else the bs you trolls foist on them - want to mod me down validly?? PROVE ME WRONG (none of you ever has or will - especially on hosts)... apk
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
Feel as you must. I simply wish the best for linux, but fear that systemd is just going to slow adoption and thus make it a less viable alternative to windows. As the value proposition is lowered, the interest level wanes. With waning interest, I expect that the fledgling industry (And it is a proper industry now that steam actually gives a crap! But in comparison to windows, it's fledgling.) of serious (You know, not Tux Racer...) non-android linux games will not garner the income necessary to support its existence. If that happens, fewer games are published. If few games are published, there's just not much reason for AMD/Nvidia to step up to the plate and make better linux drivers.
However, I think you knew that and just want a kneejerk angry response. Tu quoque.
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
"secretary at MalwareBytes took a look at his source code & said it looked all good" - by Coren22 (1625475) on Wednesday November 18, 2015
Mr. Steven Burn of Malwarebytes
"I've been asked to further clarify so for the record yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
---
"I guess we should avoid your crap it looks like malware." - by Coren22 (1625475) on Monday November 02, 2015 @03:52PM (#50850445)
60++ reputable sources say different:
64-bit model https://www.virustotal.com/en/...
+
32-bit model https://www.virustotal.com/en/...
&
Installer-> http://f.virscan.org/APKHostsF...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl...
---
"MiTM... his software provides" - by Coren22 (1625475) on Wednesday November 18, 2015
Hardcoded favs users provide = REVERSE DNS verified & my ware filters 5,500++ false positives - security site hosts data = false positives filtered.
---
"privilege escalation's a bad thing" - by Coren22 on Tuesday September 22, 2015
How else can I programmatically update hosts?
"requires elevation to write hosts" - by Coren22 (1625475) on Wednesday September 23, 2015
Hypocrite later admits it - hosts needs it vs. WFP/SFP not my ware. Users set it not programmatic impersonation. Security wares need it.
---
"Apk doesn't think DNS servers are worth running & believes Microsoft Active Directory can run w/out DNS." - by Coren22 (1625475) on Tuesday October 27, 2015
Show us where I say it? Not illogic logic but where I literally say it. I say AD needs internal DNS far back as 2007
http://forums.tweaktown.com/wi...
See "To warn users who have ActiveDirectory/AD LAN-WAN setups to NOT use external DNS servers" there.
APK
P.S.=>
"modding you down for trolling in your signature" - by Dog-Cow (21281) on Wednesday November 25, 2015
What others like Dog-Cow (old acc't. not a new sockpuppet from you) thinks of your signatures about me
... apk
There's only 1 way to pull that off. Apk said it. You trolls can't manage it (validly proving apk technically wrong). It's hilarious.
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.
What I read in Coren22's signature that apk's posts have a quote of others not liking shows Coren22 had it coming.
All these trolls like Coren22 and AmicusNYCL have is their abused downmods like you said. They tried hiding your reply.
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."
AmicusNYCL needs to read the truth about himself and Coren22 here instead of downmodding it to hide it http://slashdot.org/comments.p...
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.
Seems reminiscent of "embrace and extend" in spirit.
Embrace and extends doesn't worrk with Free Software, so you don't understand what Embrace and Extend is.
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.
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?
Not a bad idea, that might work. :)
I'll send him an email myself to try and highlight the issue. Or perhaps I should send an anonymous email as APK and spam it 400 times like APK does to Slashdot.
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.
However, since all major distros have moved to systemd it can't be that bad as some people make it out to be
I always thought that it was because GNOME decided to require it, and for a user-focussed distro to not offer (the latest version of) GNOME would be suicide.
I never understood why people think they need a heavyweight desktop environment.
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."
Your virginal basement dwelling tears are delicious. Systemd just works! The disasters you claimed that were going to happen never did. The world has moved on. You haven't. Nobody gives a shit about your boycott. Sysvinit is going to be just about as relevant as HP-UX, AIX, and Solaris, all dead products only used for legacy systems. Even fewer employers are going to give a shit about your obsession with kludgy sysvinit scripts than knowing dead unixes.
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.
Systemd is NOT modular.
It is a bunch of executables that all depend on each other. There is no difference between the way is now and shoving it all in one executable
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.
You are arguing at cross purposes. Firstly we are talking about desktop environments not window managers. Nobody is packaging fluxbox and friends to be systemd dependant (thank God). Secondly, we are not talking about init systems. The desktop environment dependencies are on other things that systemd provides, they still don't give a shit what is PID1.
Maybe the existing interfaces don't provide the flexibility required.
It would be fine if systemd offered nothing to users, and who can argue with developers making life easier for other developers. The problem is that systemd not only offers nothing to end users, it breaks userland completely.
Car analogy. Engineers designed new tools to make mechanics job's easier. Should result in better quality of work and cheaper bills right? Win win. Only problem is the new tools are not compatible with internal combustion engines. Or wheels for that matter.
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.
Have you considered improving Guix? It uses the much lighter weight DMD.
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?
> 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.
Care to link to some actual sources or is this more shilling and talking from your ass?
Why lie about it? systemd ignores stderr.
syslog hasn't been important in two decades. The systemd guys are correct in ignoring syslog.
stderr from services does not end-up in the journal. It is simply thrown away by systemd. Why do you think people have been complaining so loudly and for so long about this systemd policy?
> systemd sends stdout/stderr where you tell it to, by default to the journal.
No, it does not. If it did, do you really think people would complain so much about this systemd design problem? There's a good reason people are so angry at systemd. Not logging stderr, which is critical when managing a server, is one of the biggest reasons so many people are complaining about systemd.
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.
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
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
Or Slackware.
Why don't the systemd people just go build their own OS?
They could call it DeadRat Enterprise Lindows.
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.
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.
LOL, bullshit - he was just redoing his site's pages code, lol you fool... the link is STILL there where he verified my code as safe http://forum.hosts-file.net/vi... and yes he still hosts http://hosts-file.net/?s=Downl... my ware too (and a newer even better versions coming very soon)...
APK
P.S.=> See subject "ne'er-do-well" big talker but can't back it up MORON troll AmicusNYCL (just like Coren22 - blowhards)... apk
Bathroom Humor (4006829) = new sockpuppet 7 digit fake account by Coren22 for upmodding himself obviously.
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."
Coren22 IMPERSONATES RESPECTED MEMBERS OF THE SECURITY COMMUNITY http://slashdot.org/comments.p...
---
"privilege escalation's a bad thing" - by Coren22 on Tuesday September 22, 2015
How else programmatically update it?
"requires elevation to write hosts" - by Coren22 (1625475) on Wednesday September 23, 2015
Hypocrite later admits it - hosts do vs. WFP/SFP not my ware. Users set it not programmatic impersonation. Security wares need it.
---
"secretary at MalwareBytes took a look at his source code & said it looked all good" - by Coren22 (1625475) on Wednesday November 18, 2015
Mr. Steven Burn of Malwarebytes
"yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
---
"we should avoid your crap it looks like malware." - by Coren22 (1625475) on Monday November 02, 2015 @03:52PM (#50850445)
60++ reputable sources say different:
64-bit model https://www.virustotal.com/en/...
+
32-bit model https://www.virustotal.com/en/...
&
Installer-> http://f.virscan.org/APKHostsF...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl...
---
"MiTM... his software provides" - by Coren22 (1625475) on Wednesday November 18, 2015
Hardcoded favs users provide = REVERSE DNS verified & my ware filters 5,500++ false positives - security site hosts data = false positives filtered.
---
"Apk doesn't think DNS servers are worth running & believes Microsoft Active Directory can run w/out DNS." - by Coren22 (1625475) on Tuesday October 27, 2015
Show us where I say it? Not illogic logic but where I say it. I say AD needs internal DNS far back as 2007
http://forums.tweaktown.com/wi...
See "To warn users who have ActiveDirectory/AD LAN-WAN setups to NOT use external DNS servers" there.
APK
P.S.=>
"modding you down for trolling in your signature" - by Dog-Cow (21281) on Wednesday November 25, 2015
Dog-Cow's (old acc't. no new sockpuppet from you) thoughts of your signatures about me
... apk
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.
Coren22 IMPERSONATES RESPECTED MEMBERS OF THE SECURITY COMMUNITY http://slashdot.org/comments.p...
---
"privilege escalation's a bad thing" - by Coren22 on Tuesday September 22, 2015
How else programmatically update it?
"requires elevation to write hosts" - by Coren22 (1625475) on Wednesday September 23, 2015
Hypocrite later admits it - hosts do vs. WFP/SFP not my ware. Users set it not programmatic impersonation. Security wares need it.
---
"secretary at MalwareBytes took a look at his source code & said it looked all good" - by Coren22 (1625475) on Wednesday November 18, 2015
Mr. Steven Burn of Malwarebytes
"yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
---
"we should avoid your crap it looks like malware." - by Coren22 (1625475) on Monday November 02, 2015 @03:52PM (#50850445)
60++ reputable sources say different:
64-bit model https://www.virustotal.com/en/...
+
32-bit model https://www.virustotal.com/en/...
&
Installer-> http://f.virscan.org/APKHostsF...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl...
---
"MiTM... his software provides" - by Coren22 (1625475) on Wednesday November 18, 2015
Hardcoded favs users provide = REVERSE DNS verified & my ware filters 5,500++ false positives - security site hosts data = false positives filtered.
---
"Apk doesn't think DNS servers are worth running & believes Microsoft Active Directory can run w/out DNS." - by Coren22 (1625475) on Tuesday October 27, 2015
Show us where I say it? Not illogic logic but where I say it. I say AD needs internal DNS far back as 2007
http://forums.tweaktown.com/wi...
See "To warn users who have ActiveDirectory/AD LAN-WAN setups to NOT use external DNS servers" there.
APK
P.S.=>
"modding you down for trolling in your signature" - by Dog-Cow (21281) on Wednesday November 25, 2015
Dog-Cow's (old acc't. no new sockpuppet from you) thoughts of your signatures about me
... apk
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
hahahahaha apk made you and coren22 eat your words http://slashdot.org/comments.p...
Coren22 IMPERSONATES RESPECTED MEMBERS OF THE SECURITY COMMUNITY http://slashdot.org/comments.p...
---
"privilege escalation's a bad thing" - by Coren22 on Tuesday September 22, 2015
How else programmatically update it?
"requires elevation to write hosts" - by Coren22 (1625475) on Wednesday September 23, 2015
Hypocrite later admits it - hosts do vs. WFP/SFP not my ware. Users set it not programmatic impersonation. Security wares need it.
---
"secretary at MalwareBytes took a look at his source code & said it looked all good" - by Coren22 (1625475) on Wednesday November 18, 2015
Mr. Steven Burn of Malwarebytes
"yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
---
"we should avoid your crap it looks like malware." - by Coren22 (1625475) on Monday November 02, 2015 @03:52PM (#50850445)
60++ reputable sources say different:
64-bit model https://www.virustotal.com/en/...
+
32-bit model https://www.virustotal.com/en/...
&
Installer-> http://f.virscan.org/APKHostsF...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl...
---
"MiTM... his software provides" - by Coren22 (1625475) on Wednesday November 18, 2015
Hardcoded favs users provide = REVERSE DNS verified & my ware filters 5,500++ false positives - security site hosts data = false positives filtered.
---
"Apk doesn't think DNS servers are worth running & believes Microsoft Active Directory can run w/out DNS." - by Coren22 (1625475) on Tuesday October 27, 2015
Show us where I say it? Not illogic logic but where I say it. I say AD needs internal DNS far back as 2007
http://forums.tweaktown.com/wi...
See "To warn users who have ActiveDirectory/AD LAN-WAN setups to NOT use external DNS servers" there.
APK
P.S.=>
"modding you down for trolling in your signature" - by Dog-Cow (21281) on Wednesday November 25, 2015
Dog-Cow's (old acc't. no new sockpuppet from you) thoughts of your signatures about me
... apk
From: services@it-mate.co.uk /. troll Coren22 now GLOATING)... apk ;o)
> To: apk4776239@hotmail.com
> Subject: RE: I have a new build ready also (adds ALL the filters both Henry & yourself gave me + more on the
> Date: Sat, 28 Nov 2015 16:13:50 +0000
>
> Alex,
> I've never even registered for SlashDot, much less posted on it
Guess what else stupid?
Take a look -> "I've been asked to further clarify so for the record yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
Impersonating him was the BIG mistake you made Coren22... huge!
Thank you for being SO stupid...
APK
P.S.=> How fucking LOW can you go, for Pete's sake, Coren22? Impersonating a RESPECTED MEMBER OF THE SECURITY COMMUNITY NOW TOO ontop of your libelous lying immature childish signatures about me?? You're low & no man... apk
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?
Bs. You signatures about apk and your technical mistakes and lies http://slashdot.org/comments.p... show the depths you'll stoop to. You are losing this and losing it impersonating others now.
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?
I'm not apk. Your signatures about apk are the act of a butthurt fool. Your tech mistakes are those of a rookie noob. My last post you replied to has links that shows them.
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?
Coren22 IMPERSONATES RESPECTED MEMBERS OF THE SECURITY COMMUNITY http://slashdot.org/comments.p...
---
"privilege escalation's a bad thing" - by Coren22 on Tuesday September 22, 2015
How else programmatically update it?
"requires elevation to write hosts" - by Coren22 (1625475) on Wednesday September 23, 2015
Hypocrite later admits it - hosts do vs. WFP/SFP not my ware. Users set it not programmatic impersonation. Security wares need it.
---
"secretary at MalwareBytes took a look at his source code & said it looked all good" - by Coren22 (1625475) on Wednesday November 18, 2015
Mr. Steven Burn of Malwarebytes
"yes I've seen the code & yes it is safe." FROM http://forum.hosts-file.net/vi...
---
"we should avoid your crap it looks like malware." - by Coren22 (1625475) on Monday November 02, 2015 @03:52PM (#50850445)
60++ reputable sources say different:
64-bit model https://www.virustotal.com/en/...
+
32-bit model https://www.virustotal.com/en/...
&
Installer-> http://f.virscan.org/APKHostsF...
MalwareBytes' hpHosts Admin (MalwareBytes employee) hosts & recommends it -> http://hosts-file.net/?s=Downl...
---
"MiTM... his software provides" - by Coren22 (1625475) on Wednesday November 18, 2015
Hardcoded favs users provide = REVERSE DNS verified & my ware filters 5,500++ false positives - security site hosts data = false positives filtered.
---
"Apk doesn't think DNS servers are worth running & believes Microsoft Active Directory can run w/out DNS." - by Coren22 (1625475) on Tuesday October 27, 2015
Show us where I say it? Not illogic logic but where I say it. I say AD needs internal DNS far back as 2007
http://forums.tweaktown.com/wi...
See "To warn users who have ActiveDirectory/AD LAN-WAN setups to NOT use external DNS servers" there.
APK
P.S.=>
"modding you down for trolling in your signature" - by Dog-Cow (21281) on Wednesday November 25, 2015
Dog-Cow's (old acc't. no new sockpuppet from you) thoughts of your signatures about me
... apk
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,
... will we have Linux server distros without systemd in 2016?