jbernardo writes:
"Having had several issues with systemd, and really not liking the philosophy behind it, I am looking into alternatives. I really prefer something that follows the Unix philosophy of using small, focused, and independent tools, with a clear interface. Unfortunately, my favourite distro, Arch Linux, is very much pro-systemd, and a discussion of alternatives is liable to get you banned for a month from their forums. There is an effort to support openrc, but it is still in its infancy and without much support.
So, what are the alternatives, besides Gentoo? Preferably binary... I'd rather have something like arch, with quick updates, cutting edge, but I've already used a lot in the past Mandrake, RedHat, SourceMage, Debian, Kubuntu, and so on, so the package format or the package management differences don't scare me."
[ED Note: I'm imagining FreeBSD sitting in the room with the all the Linux distros he mentioned being utterly ignored like Canada in Hetalia.]
(Score: 2, Funny) by suxen on Wednesday February 26 2014, @12:38PM
I am glad I am not the only one who thinks systemd is brain dead. For what it is worth, debian is planning on maintaining the existing init system as an alternative, I just couldn't believe they decided to go with systemd at all. What next GNU/NT?
Personally I am planning my migration away from GNU/Linux which I deem too complex to audit and too compromised in terms of the nature of some of the biggest contributers for it to be assumed genuinely free from code that serves corporate interests rather than my computers or my own.
GNU/HURD is pretty usable and I am strongly thinking of switching to it as my main computing platform. Not only does it have some fantastic features but it is still small enough to be explorable and auditable.
(Score: 5, Funny) by nukkel on Wednesday February 26 2014, @02:57PM
Just don't press any button during boot. It will cause a kernel panic (not kidding)!
(Score: 2, Funny) by jimshatt on Wednesday February 26 2014, @08:36PM
(Score: 0) by Anonymous Coward on Thursday February 27 2014, @12:02PM
Yep. Nobody wants to use something that's not perfect; it's really inconvenient. I'd much rather use Windows 8.1--that's supposed to be really good, and very geek-friendly.
(Score: 1) by suxen on Friday February 28 2014, @08:51AM
I wanted to test this, but I couldn't find the any key on my keyboard. Pressing any of the other keys didn't do it.
(Score: 1) by marcello_dl on Thursday February 27 2014, @04:03PM
I have genode [genode.org] in my promising OSes category. If the hurd doesn't cut it for you try that. Oh and dragonflybsd with its hammer FS.
(Score: 5, Interesting) by CynicGalahad on Wednesday February 26 2014, @12:38PM
Even with Gentoo might be problematic to avoid systemd, if you use a desktop environment.
I tried myself and felt a bit of a pain ending up deciding that wasn't worth the time to force using openrc. I am with you though, systemd leaves me with the impression of added complexity, hiding the internal and cumbersome logging and service control.
I blame Gnome for trying to force its adoption despite what they say http://www.itwire.com/business-it-news/open-source /62297-developers-deny-gnome-dependent-on-systemd [itwire.com]
(Score: 3, Informative) by dweezil-n0xad on Wednesday February 26 2014, @03:57PM
In Gentoo only the GNOME desktop environment has a mandatory dependency on systemd.
(Score: 2, Insightful) by morgauxo on Wednesday February 26 2014, @04:18PM
Yeah, I know the original post was asking for a non-Gentoo solution but I have to say.. I'm still using openrc on Gentoo and it works just fine.
(Score: 2, Informative) by danomac on Wednesday February 26 2014, @04:37PM
I've been using Gentoo since the early 2000s. I am using a full blown KDE desktop with openrc with no issues at all. I think that statement largely relates to using Gnome, not any desktop environment.
(Score: 3, Informative) by Nerdanel on Wednesday February 26 2014, @04:45PM
I'm on Gentoo and I can confirm that systemd is quite easy to avoid. You just need to abandon the idea of installing Gnome, but I think not using Gnome is a plus in itself. I prefer KDE. If you set USE="eudev -systemd" in make.conf you can be extra sure systemd doesn't sneak in by accident, even if they change the defaults.
Really, Gentoo isn't that "bad" nowadays, given how computers have become faster. It's been ages since the openoffice package took hours and hours and hours to compile. On my first Gentoo-using computer the Linux kernel took 50 minutes to compile, but on my new computer that lasts a few scant minutes, like, two of them. (The time is from a table clock which doesn't produce very precise results on those scales.) The massive entirety of KDE takes something like an hour, but you can pick and choose which packages you want.
(Score: 5, Interesting) by VLM on Wednesday February 26 2014, @07:09PM
"I think not using Gnome is a plus in itself."
I have to agree. I used KDE for years, then as it got too slow to use, so I went to xfce for a little while, then ratpoison, then awesome for a couple years, and lately have settled semi-permanently on xmonad. I tend to switch every machine, work and home, that I have access to, which is pretty easy in a modern environment.
So, I wake the machine up, log in, hit alt-p and start konsole (for its good utf-8 support and tabs) in term 1 and chrome in term 2. And I switch between term 1 and 2 a couple hundred times per day (alt-1 ... alt-2 .. alt-1 ... alt-2 .. is my only interaction with the WM or "DE").
My "work" is done in ssh sessions started in konsole with the occasional IDE or whatever X forwarded back to my machine and shoved in term3. Yes I admit I used eclipse on occasion although its usually more of a productivity reducer than increaser.
Now here's the question... if I switched to Gnome or KDE, how exactly would the above paragraph improve my experience? What would I do differently? What does everyone else do? There seem to be a lot of community organizers trying to "represent" people who do this and need that and demand the other thing, yet the people they claim to represent don't actually exist or never speak for themselves.
(Score: 1) by CynicGalahad on Thursday February 27 2014, @07:59AM
I use neither (KFS or Gnome), I am simply lazy and prefer to install both and be agnostic in the utilities each provide, both libraries end up being installed either because of that ebuild or the other. Hence systemd, because Gnome pretty much enforces it and yes, Gnome does play a role in a lot of desktop users so I felt it was worthwhile to mention that even with Gentoo might be difficult to avoid.
(True, I pollute my system but I get less issues and less hassle)
But you do raise right questions and the old "if it ain't broken don't fix it" creeps up on my mind. What was so wrong with the clean and lean OpenRC? Wrong to the point of prompting a complete re-engineering.
You make mention to the users and their opinion. Can be that I am not in the right circles to hear them speak for systemd, but within my relationship circles I am still to find an advocate for it so those questions do feel rather relevant.
(Score: 5, Informative) by fbscarel on Wednesday February 26 2014, @12:39PM
Use OpenBSD... classic UNIX right there for ya, with binary packages to boot. And secure!
(Score: 2, Insightful) by omoc on Wednesday February 26 2014, @02:49PM
What I'd like to see is a modern distribution with Linux Kernel and BSD userland. OpenBSD is a joke on a modern desktop. Archlinux was initially awesome but has long given up on that path, is there something else?
(Score: 2) by frojack on Wednesday February 26 2014, @08:25PM
That seems backwards.
You want a unix kernel, with Linux pacakage (ports) availability.
OpenBSD is not that bad if you hang KDE on it. I've played with that for a few months.
Its serviceable.
Still, for security you want FreeBSD, not OpenBSD. Those FreeBSD guys are all about security.
My next firewall will be FreeBSD.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by frojack on Wednesday February 26 2014, @08:29PM
DAMMIT, I got that backwards.
OpenBSD is indeed the one you want,not FreeBSD.
FreeBSD probably has more ports, but it is security challenged.
No, you are mistaken. I've always had this sig.
(Score: 1) by electron on Wednesday February 26 2014, @10:43PM
I use OpenBSD as my only desktop with xfce and have had no problems.
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @10:52PM
Yeah, that first post was confusing.
If you really wanted FreeBSD with GNU userland, well Debian has the kfreebsd port. It will not be using systemd for obvious reasons.
OpenBSD does a really good job.
(Score: 3, Interesting) by CaptainK on Wednesday February 26 2014, @12:42PM
Big LFS fan here obviously.
Suggesting this only because I like to pontificate about how blOATed distros have become.
Slackware is kickass also.
But if you are looking for something to just plug into the CD tray, then neither of these choices will entice you.
Although, if you fall into this catefgory, then you can't complain about what you get for service startup.
Your imagination is your only limitation to creation.
(Score: 1) by bart9h on Wednesday February 26 2014, @01:14PM
I used LFS on my desktop for many months. What made switch back to a regular distro was the hassle of keeping software up-to-date, specially considering library dependencies.
That was many years ago. Is the situation improved in this front?
(Score: 5, Informative) by melikamp on Wednesday February 26 2014, @04:10PM
(Deblobbed [freeslack.net]) Slackware user here. As we speak, the official Slackware forum is being filled with very fiery systemd posts, with not one but two threads filled with love, hate, and bile, with love clearly in the minority. Long-time users and contributors are guessing that Slackware won't be switching in the foreseeable future (or ever, unless it is clearly shown to be technically advantageous), although everything is possible with time.
Slackware may not be cutting-edge enough for you, but then again, it looks like it's the cutting edge init that is driving you away, so may be it's worth trying a more conservative OS?
And then there's Debian, of course, which we know won't drop the classic init for years and years.
(Score: 1) by jbernardo on Wednesday February 26 2014, @04:25PM
I guess I will take a look at slackware again. Looks like cutting edge doesn't always equate with "the best and latest", so maybe it is time to choose a more conservative distro.
(Score: 1) by Curupira on Wednesday February 26 2014, @05:43PM
(Score: 1) by HiThere on Wednesday February 26 2014, @06:21PM
I think he was implying that the current stable will be maintained for a long time. Debian has a history of being slow to move the testing (currently Jessie) branch to stable.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 1) by melikamp on Wednesday February 26 2014, @06:24PM
(Score: 2, Informative) by bryan on Wednesday February 26 2014, @07:22PM
Bruce Dubbs (one of the maintainers of Linux From Scratch) has done a pretty good job of extracting udev out of systemd.
http://www.linuxfromscratch.org/lfs/view/developme nt/chapter06/udev.html [linuxfromscratch.org]
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @11:30PM
As far as I remember, systemd just took over maintenance of udev. You don't really have to do anything to remove systemd from udev. There just in the same tree.
Feel free to try eudev, the gentoo led fork of udev, if you want something that didn't even start out in systemd's tree. http://www.gentoo.org/proj/en/eudev/ [gentoo.org]
(Score: -1) by Anonymous Coward on Wednesday February 26 2014, @12:43PM
You know the rules: The answer is "no".
Also, the real answer is to start yet another distro. They're all the same anyway. OpenSuse, Fedora, Debian, Arch, Gentoo and Ubuntu all have Apache, KDE, Wine and Bash. The only difference is which directory they stick some files into and whether the software is packaged in cpio or tar files.
(Score: 2, Interesting) by tempest on Wednesday February 26 2014, @02:07PM
I have to agree. If systemd is really so bad, distros will emerge without it. If systemd generally works and your distro can't handle it, that's your distros fault not systemd. Since all my systems are FreeBSD (or Gentoo) this doesn't affect me much, but I worry about software dependancies with systemd leading to other systems losing software support.
(Score: 0) by Anonymous Coward on Thursday February 27 2014, @12:24PM
Alas, systemd opponents seem to have a big propensity to whine about systemd but also a big aversion to do the work to propose an alternative.
It's not that hard: if there are enough people who really want to avoid systemd, they can get together to build a new distro that doesn't use systemd and work on an alternative implementation for the systemd interfaces that software depend on.
Up until now, only Canonical did any work going this way and since they've decided they'd go the systemd way, someone has to step up and do the job if there is to be an alternative.
(Score: 0) by Anonymous Coward on Thursday February 27 2014, @05:08PM
To be fair, every operating system to ever exist in the entire universe had an alternative to systemd, which is great because systemd didn't exist back then.
(Score: 1) by bluefoxicy on Monday March 10 2014, @11:08PM
It's just business as usual. Looks like this [anandnair.com], mostly.
Look at telecom adoption. look familiar? [wordpress.com] Particularly 2G to 3G, with EDGE being 2G hacked up to run as 3G. But of course this gives a display of return of transmission speed versus engineering effort. If we switched it to cost versus return, the curves would squash vertically but follow the same pattern--they'd look similar to the above--because businesses won't output more money for a lower return.
The theoretical curve applies more to open source software than business: engineering effort versus useful output is essentially the only meter used for building something you're giving away for free. You don't need a business case when your only motivation is "make this better"; instead, you put in the least effort to get the most improvement until you hit diminishing returns, and then somebody starts hammering out something brand new that comes around not quite working well until it's had the bugs worked out. That's more likely to follow the theoretical curve--unless somebody realizes, "Hey guys, we've been doing this jackass wrong all this time," and a new technique quickly emerges as a disruptive technology.
(Score: 2, Funny) by morgauxo on Wednesday February 26 2014, @04:20PM
The only difference between Gentoo and those others is whether they stick their packages in cpio or tar files? Tell me more about these Gentoo packages please!
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @09:10PM
Ebuilds point to tarballs. I'll let you figure it out from there.
(Score: 2, Informative) by nightsky30 on Wednesday February 26 2014, @12:48PM
I'm not too fond of it either, but forcing myself to get to know systemd and firewalld because they are creeping from Fedora into RedHat/CentOS eventually.
(Score: 3, Informative) by caseih on Wednesday February 26 2014, @03:26PM
It's in RH now, well version 7, which is in beta. I'm running RHEL 7 beta, and it runs quite nicely with systemd. In fact I'd rather write systemd service files than mess with fragile, hard-to-debug init scripts that sometimes run for hundreds of lines of bash code. While systemd seems a bit opaque at first (though I understand the source code is fairly easy to understand), it's quite a bit better than having every daemon reinvent the wheel with locking code to prevent multiple instances, and having automatic process supervision.
And yes, RHEL 7 beta still a normal syslog daemon, and a text-file-based logger facility will always be there as long as people require it (usually for security audit purposes).
It's natural to be uncomfortable with something you don't understand. So just get more familiar with it, how it works, and how to use it. My only complaint is that Lenart seems to love using "ctl" in the names of his commands. journalctl, systemctl, etc. Doesn't exactly roll of the fingers on the QWERTY keyboard.
So far I think my concerns about systemd have largely been unfounded, and I'm a lot more comfortable with it. As with Wayland, it seems that most people's hate on it are based on ignorance mostly, which is unfortunate.
(Score: 1, Informative) by Grishnakh on Wednesday February 26 2014, @06:55PM
In fact I'd rather write systemd service files than mess with fragile, hard-to-debug init scripts that sometimes run for hundreds of lines of bash code. While systemd seems a bit opaque at first (though I understand the source code is fairly easy to understand), it's quite a bit better than having every daemon reinvent the wheel with locking code to prevent multiple instances, and having automatic process supervision.
Exactly. The sysvinit system is really a mess, because it offloads most of the logic to the init scripts, so it's incumbent on those scripts to do everything right, be bug-free, handle corner cases, etc. sysvinit really doesn't do much more than call these scripts; you could probably write a sysvinit clone in Perl in an hour.
systemd moves most of this logic into the core code of the daemon and its associated utilities, so all that's needed for each service is a short, simple descriptor file. The result is more centralization, and less "surface area" for bugs or security flaws. It's not much different than writing a C++ program using libraries vs. not using any libraries. In the latter case, you have to reinvent the wheel for everything: linked lists and other containers, strings, graphic widgets, etc. Why would you do that when you can just use something that an expert created and which is highly tested and deployed on a large scale so that it's reasonably bug-free?
(Score: 3, Insightful) by VLM on Wednesday February 26 2014, @07:23PM
"you could probably write a sysvinit clone in Perl in an hour."
So... why not? Or a shell script "library" for that matter.
Extremely stereotypically, systemd supporters make a well written and eloquent and true explanation of why libraries and include files were invented in the 70s, then outta nowhere switch gears into a total rewrite and rearchitecture of the entire system is necessary, and everyone's going to have to change absolutely everything in order to do exactly the same thing we've always done with no new benefit ... but don't worry its really easy.
OK a support library for sysvinit would be a great idea. Or perhaps a macro-preprocessor that eats a 3 line file and squirts out a 500 line long sysvinit script... although most of the scripts I've had to mess with have been like 10 lines but whatever. Anyway I agree with the general idea, write a support system for init. Now, what does the other 99% of systemd have to do with that?
By analogy it sounds a lot like... "I wanted to change the volume control widget on my mp3 player so it can go up to 11, not just 10. But that is a lot of work, you know, legacy code and such. So instead I merely rewrote the entire kernel interface for the PCI bus and also changed the API for the virtual memory system and embedded BASH into the kernel so you may never use any other shell again. Oh and some DE you don't use now demands it. But hey don't worry, its a really nice new API and once everyone is forced to rewrite everything you'll see how nice it really is."
(Score: 2, Informative) by Grishnakh on Wednesday February 26 2014, @08:30PM
No, it's more like "I wanted to change the volume control widget, but I also realized I wanted to be able to control that widget remotely so that I could manage a whole cluster of MP3 players easily. This required an entirely new architecture rather than making a crude hack onto something that was never designed for this."
systemd does a lot more than the old sysvinit ever did. For remotely-administered servers and embedded systems, these features are a boon.
Also, other UNIXes have had more modern init systems for ages.
(Score: 0) by caseih on Thursday February 27 2014, @05:20PM
But that's just it. You don't have to rewrite daemons to take advantage of systemd. Nor do you have to rewrite any other userspace program. There are features you can take advantage of if you want, like socket activations. I don't really understand your bizarre analogy. Seems an emotional response rather than factual.
But old-school init scripts work just fine, and if you want to take advantage of process supervision and run control (no more hacking with PID files), you just create a service file that runs your daemon in foreground mode (all daemons support this for debugging). In fact while running in debug mode you can turn on full debugging if you want and it's all captured to the log in a nice and usable way. It makes it super easy to drop in third party daemons and just run. In the old days I had to deal with poorly written init scripts that didn't really integrate well with my fedora program, or write my own init script, or punt and stick it in rc.local.
What's ironic is that OS X has been using a systemd-style init system since the beginning and there are many fans of OS X in this community. Somehow launchd is okay but systemd isn't? Come on. Launchd took some getting used to, but it works well. It replaces init, atd, and crond with a nice, easy to use system with simple service definition files.
Why is it that open source people are so quick to jump on the cutting edge (Linux 3.14 FTW), but get all bent out of shape when people try to innovate and actually make things better in user space?
Anyway, this is well past the actual discussion here, but I had to vent a bit even if no one ever reads this.
(Score: 5, Interesting) by c0lo on Wednesday February 26 2014, @12:53PM
What the hell is systemd? Why it was needed in the first place?
Also from here [0pointer.de]
If there's a niche where a company specialized in consulting services for systemd can live, it smells like an awful big trouble with the complexity: no longer a simple man page to get to the bottom of your troubles, but maybe (or... very probable?) a book 850+ pages thick.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Informative) by glyph on Wednesday February 26 2014, @01:13PM
There is a company offering "niche" consulting for pretty much every service under the sun... even wiping your ass. But that's just business, baby. Complexity doesn't have anything to do with it.
(Score: 1) by morgauxo on Wednesday February 26 2014, @04:26PM
I wonder if they really even are a company specializing in systemd or just run lots of ads targeting specific "specialties". They might even use different names.
(Score: 4, Insightful) by MrNemesis on Wednesday February 26 2014, @02:52PM
As a heavy linux user on the server-side but with almost no exposure to desktop linux in the last few years I'm also one of those people who views systemd with a bemused "Whuh...?". Then lots of people complaining "there are no more text-based log files". I was even more concerned when I see things like audio and network management being brought under the helm of this increasingly all-encompassing and apparently rather byzantine program.
I can understand the use-case for the desktop ecosystem - linux was always a little hinky with hibernate/resumes for example, but when I hear things like "systemd will also start incorporating networkd for network management" and thinking of the complete fustercluck that network manager wreaked for headless systems (/etc/network/interfaces, cold dead hands, etc). Lots of people harping on about how it boots so much faster and what have you - but again a nearly meaningless benchmark for servers (most of ours go from GRUB to login in less than five seconds in any case).
So as someone who hasn't used it yet, can anyone tell me, aside from better desktop support, what it brings into the server arena? Many of us are curious about it but sceptical since we've not yet seen what need it's meant to be fulfilling.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 4, Informative) by Bill, Shooter Of Bul on Wednesday February 26 2014, @03:55PM
Off the top of my head:
Good Daemon management by default.
Daemons can't escape monitoring. ( no amount of forking can confuse it)
Easily get the status & last couple of log lines.
All daemon output logged.
Binary log files ( prevents tampering with them).
Aggregated logging makes event correlation easier.
Socket based activation of daemons/services.
Nothing ground breaking that couldn't have been done before, but its all preconfigured to do it. And the tools are integrated with each other to work well together.
Basically systemd is cgroups applied to daemon management. That's the unifying thread that ties everything together. It turns out that its a very powerful tool that's useful in a lot of situations. So some people look at everything that systemd does and cries "bloat!" "Its taking everything over!!11", while others look at it and say "Wow that is a really useful concept that has applications everywhere. Great code reuse!"
(Score: 1, Interesting) by Anonymous Coward on Wednesday February 26 2014, @04:28PM
How so? I'd expect the typical binary file format to be easier to tamper with, because typically binary data has well-defined data boundaries. So to change a number from 3 to 127, you'll typically just have to change one byte, while with text files you'll have to insert the bytes, changing the file length.
If you want to secure your log files against tampering, why not hash/digitally sign them? And if you now say that this is not secure because the key would have to be on the same computer, well, it's no less safe than binary files. If you want true tamper security for your log files, you'll not get to avoid sending them to a place where they cannot be rewritten from the computer generating the log files.
But even without a second computer, a certain security can be achieved be regularly generating new keys and destroying the old private keys (keeping the public keys for integrity checking, of course). Then the attacker cannot replace any entry in the log file before the latest key change (because the old key is gone).
(Score: 3, Informative) by Bill, Shooter Of Bul on Wednesday February 26 2014, @05:02PM
Yeah, I was kind of fast and loose with that explanation.
Here's Lennartt's description of the security from https://docs.google.com/a/nmi.com/document/pub?id= 1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1 [google.com]
"The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-once location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected."
Why he uses googledocs for some things, his blog for others, and freedesktop for still other parts, is kind of beyond me. I wish he and the systemd team would aggregate their documentation/raison d'etre for all of systemd in one spot.
(Score: 1) by MrNemesis on Wednesday February 26 2014, @05:19PM
Damnit, ninja'd! But thanks for including the extract as google docs in on the firewall blacklist :) But it seems to reinforce the point in my post below that you still need to be using a "write only" syslog server for it to have any guarantee of integrity.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 1, Insightful) by Anonymous Coward on Wednesday February 26 2014, @05:35PM
OK, so he uses cryptographic hashes for security. But that doesn't need binary log files. It can be done with text files quite fine.
(Score: 1, Insightful) by Anonymous Coward on Wednesday February 26 2014, @06:06PM
And the irony here is, that all of this could have been done with text based logs. Git's trees and blobs, afterall are just text once decompressed, and it 'authenticates' just like LP's explanation.
No need to "go binary" just to get tamper detection.
(Score: 1, Interesting) by Bill, Shooter Of Bul on Wednesday February 26 2014, @08:01PM
Yeah, that make sense. My crazy mind combined those two for some reason. The binary nature of the log is to allow you to log binary objects as well as text, I think. It also allows for some of the meta data, event correlation, and searching capabilities I believe.
(Score: 1) by weilawei on Wednesday February 26 2014, @08:17PM
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @10:46PM
Just so you see this, that was my mistake linking binary to the hash chain not anyone elses.
If it makes you feel better, it can be converted to text very easily. journalctl spits out text, so it can be piped into other text based tools if you want.
In general, anyone who complains about breaking UNIX philosopy should take a deeper look into it. There are some good reasons why it is the way it is, and why many competing distros have adopted it. They aren't all idiots willing to sacrafice the UNIX way for a flash in the pan. I'd also argue that UNIX is very much a part of systemd, but most who would rationally debate it won't bother to consider any arguments at all.
(Score: 1) by weilawei on Thursday February 27 2014, @01:45AM
I've seen this one a lot, but not one single person (not one!) who has said this has provided an actual example of a reason for moving toward a monolithic tool, specifically. Not one single person has raised an actual argument, based on anything more than "they're not idiots" for why it needs to be monolithic, and the bits implemented by systemd couldn't be done better in a modular fashion. Modular code is more maintainable, more extensible, and has a clear separation of concerns--something lacking in systemd. Someone who is a systemd supporter needs to step up to the plate and illustrate how this monolithic structure is better in those categories.
(Score: 1) by weilawei on Thursday February 27 2014, @01:49AM
Replying again, since I should have made this point as well. Saying that they're not all idiots who are willing to sacrifice the UNIX way for a flash in the pan, saying that they're maintainers of distros, is not an argument--that's an appeal to authority. Please, stop with the fallacious appeals and provide REAL arguments based in actual software engineering concerns, usability concerns, system administration concerns, etc.. I don't care if you want to play sheep to the shepherd, but I want to know WHY systemd should be monolithic and not modular.
(Score: 1) by MrNemesis on Wednesday February 26 2014, @05:16PM
Thanks, that makes a little more sense at least. But...
Can you expand on this a little perhaps?
I'd have to agree with the AC above on this - I don't see what about binary log files makes them any more actively tamper-resistant than text-based ones, there doesn't seem to be any checksumming involved in the systemd implementation. In any case, if you're worried about log integrity you'd redirect to a syslog server - how is this accomplished with systemd? Is an equivalent command for `tail -f access.log|grep someuser` (or tail/ack)? Or even just plain grep?
I assume you mean easier to match the timestamps from one to another? Granted this can be a pain in the arse especially when you have your system/kernel log measuring things from the time of boot whilst others base on various other formats (and a colossal case of haemorrhoids when you're correlating between two different time zones in three different formats), but for that there's tools like SEC [sourceforge.net]. Even so, what I'd love even more was if there was just a simple way for force an entire system to use the YYYY-MM-DD hh:mm:ss format globally like wot you can do in windows. Manually changing the locale (the only way I know to force it) is... ugly. Very ugly.
I'm guessing this is to be used for dependency-based daemon startup? I'm not really sure what it entails otherwise.
I think that's probably the biggest problem people like me have with the concept - maybe it's because I don't really do anything advanced with finagling init scripts, but I've never had any problems with the ones in debian, they all seem to tie nicely together, and murmurs from a people about a lot of things changing (there was a comment here about single user mode no longer working for example) for what seems like a largely philosophical reason; I'm a pragmatist rather than idealist in that regard and I'll go with what works rather than something that might be more technically perfect but with considerable caveats.
Guess I'll have to see how I get on with it once it's rolled into Jessie.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 3, Informative) by VLM on Wednesday February 26 2014, @07:35PM
"Guess I'll have to see how I get on with it once it's rolled into Jessie."
Can try it today, if you're on testing or have a testing VM or a sacrificial box to test on.
apt-get install systemd
Maybe there was more to it, I don't remember.
To run it, at the grub boot menu you hit e to edit your boot line (this one time) and add init=/lib/systemd/systemd to the kernel command line thingy and boot the temporarily edited config.
Did you work, awesome, might want to think about editing /etc/default/grub and put the above into a GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/syst emd" and run update-grub of course.
Or if it blew up just reboot and avoid hitting E and changing your init, or if it blew up after changing the file "permanently" you can probably guess that on boot you edit the command line kernel params and remove that init line.
Now forcibly removing sysvinit and keeping it out and only having systemd installed is going way beyond what I've done and I don't think its currently (easily) possible.
I suppose a truly pathological event could happen if systemd blew up while you were hand editing binary database files or some such and screw up the whole machine or something. So the usual, "make backups" applies and so on. Although I've had no problems that doesn't prove your hardware can't etc etc etc.
(Score: 0) by Anonymous Coward on Friday September 12 2014, @05:14PM
Qgxh2a xnwpcuovrvok [xnwpcuovrvok.com], [url=http://omokoyaevqka.com/]omokoyaevqka[/url], [link=http://beuggjufoucf.com/]beuggjufoucf[/link], http://ixxpequimsbu.com/ [ixxpequimsbu.com]
(Score: 1) by weilawei on Wednesday February 26 2014, @08:22PM
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @10:56PM
Socket based activation of daemons/services
You can do crazy things like have a daemon that isn't started until it gets a request. Systemd listens on the port and then starts the daemon and hands of the port. This way the daemon doesn't have to be running all the time, and/or you can better utilize system resources depending on service demands. They're also working on integrating it into linux containers, so a service that lives inside a container gets started up upon request.
Kind of cool.
(Score: 1) by pe1rxq on Thursday February 27 2014, @01:28AM
So they are also reinventing inetd?
(Score: 0) by Bill, Shooter Of Bul on Friday February 28 2014, @05:39PM
http://en.wikipedia.org/wiki/Inetd#inetd_replaceme nts [wikipedia.org]
Integrated and expanded the functionality, yes.
(Score: 1) by marcello_dl on Thursday February 27 2014, @04:13PM
Real world test: on one side a 3ghz core duo with a 10 yrs old 250gb disk and debian wheezy. On the other side, the same cpu dual booting on a 2 years old 1tb disk and debian jessie with systemd. Desktop with no servers except for openssh.
Time booting the new system? same as the old one, since the bottleneck is the adsl router connecting to the net. Thanks for playing.
No, seriously, i guess systemd is 20% faster, except the time taken for IP acquisition. That amounts to a negligible amounts of seconds.
Verdict: systemd is not much useful by itself, and it's a hassle if you factor in the amount of work needed to convert existing stuff to it. It probably was chosen because it introduces incompatibilities and sadly the software market feeds itself on incompatibilities. I think I'll end up on slackware.
(Score: 2) by RobotMonster on Wednesday February 26 2014, @12:55PM
For somebody who hasn't been paying attention to the service manager wars, what are your issues with systemd? What don't you like about the philosophy of it?
I had a quick read of Why systemd? [0pointer.de] and Biggest Myths about systemd [0pointer.de], and don't see what the fuss is about.
OTOH, I am an OSX user these-days, and don't typically worry about such things.
(Score: 0, Flamebait) by Desler on Wednesday February 26 2014, @01:13PM
What's "wrong" is that it's been demonized by the "We hate Lennart" crowd.
(Score: 5, Informative) by fbscarel on Wednesday February 26 2014, @01:17PM
Well, evidently the opinion from the systemd author's website will be pro-systemd. And very much "pro" at that, I just read the page regarding myths about systemd, and apparently all of them are invalid. Who knew?
I myself think that they're trying to fix a non-existing problem. Sure, booting up faster is nice, but in a server environment it's not that big of a deal. Every sysadmin knows shell scripting, why mess with that? And before you tell me systemd is backwards-compatible... why use it if you're gonna keep your shell scripts?
There are still alternatives, thankfully. The BSD's should go unscathed from this mess, I reckon. Good on them.
(Score: 2) by RobotMonster on Wednesday February 26 2014, @01:28PM
Indeed, they were both biassed links. I googled a few other sources but didn't find anything particularly enlightening or worth linking to.
Intelligently managing dependencies between services seems like a good idea, which appeared to be a reasonable advantage not provided nicely by the other systems, from what I could find in 5 minutes.
I'm not for-or-against, I just would have preferred it if TFA actually made some kind of logical argument beyond not wanting to wear a blue hat because everybody knows red hats are what Cloister intended. [wikipedia.org]
(Score: 1, Interesting) by chris.alex.thomas on Wednesday February 26 2014, @02:50PM
why mess with that?
because it's 2014 and perhaps we don't need to keep legacy technology around just so a group of people can feel superior, perhaps we should use our latest knowledge to revisit old problems and propose a way which might reduce maintenance, use modern techniques that more people are familiar with and get rid of cruft that people are used to skipping around, instead we can just write it all out and have a clean system.
ever tried to debug an email server? nightmare....such a bunch of legacy hacks and patches, nasty design and awful learning curve, XMPP does what email should do much better than email does, also, multiple SSL certs? separate ip addresses? holy crap....I'm glad companies are throwing email in the trash and upgrading whenever they can, facebook, gmail, hotmail....they ALL work around the email server problem by providing a frontend which looks like an email server, but internally, does it's own thing once you're inside the gates....if the big guys think it's trash...then surely we should listen..
I had problems with pulseaudio to begin with, but now it seems to work flawlessly, maybe it's too complex, it could be stripped down and layered so people who wanted network transparency could install a library to do it, instead of building it in, a more modular architecture might be nice, but overall, this is what happens, it's called progress.
I'm glad somebody is trying to modernise these old systems.
(Score: 5, Informative) by VLM on Wednesday February 26 2014, @03:02PM
"clean system."
Unfortunately the architecture is bloated such that no one could ever describe it as "clean".
Its NOT a new init system. Its a new init system, and a logging system, and a hotplugging system, all incredibly tightly integrated for frankly no good reason at all other than to make it difficult to use alternatives or replace it piecemeal.
And the way it was rammed into place was getting some GUI desktop environments to require it. Absolutely disgusting political behavior.
No, I think it would nearly define an un-clean system, the opposite of cleanliness.
I am slightly concerned with security issues, so my embedded systems that don't have or need hotplug systems or logging are now vulnerable to future hotplug and logging bugs, which totally sucks.
Its architecture might be brain dead but I haven't had any problems yet (crosses fingers). Replacing a craftsman's toolchest with a swiss army knife might sound idiotic, but if it works, well, that's not so bad. I acknowledge there are negative secondary effects like "here's something with an awful architectural design and it works, so lets copy that design style".
(Score: -1) by chris.alex.thomas on Wednesday February 26 2014, @03:19PM
logging and hotplugging are important when your system is booting up, or services are running in response to devices coming and going.
remember, that as programmer, we all understand that "v1" is always the worst, "v2" fixes some problems and "v3" is where you start to implement new ideas, if this is v1 of a new architecture, then it can be fixed.
but saying that no progress forward is a good thing is just backwards thinking, sometimes you need to branch out and do weird things in order to find better alternatives.
obviously the people designing these systems are not idiots, so they either don't value your feedback, because their idea of a clean system differs from yours, or it's already possible to do what you suggest, but you didnt know it, or that nobody knows what opinions you have, or it's a future idea that will come down the line.
you're post reminds me of a wayland thread, it has a lot of similar statements.
(Score: 2) by hatta on Wednesday February 26 2014, @03:49PM
you're post reminds me of a wayland thread, it has a lot of similar statements.
Is systemd less featureful than the system it replaces too?
(Score: 2) by VLM on Wednesday February 26 2014, @06:58PM
Your post is interesting and well written, although I don't agree with most of it, and have no idea why its posted as a "reply" to my post because its apparently entirely unrelated to my post.
no comment on tight integration solely for "product tying" purposes
no comment on rammed in because of demand from some desktop environment rather than any organic desire from users or admins, or as near as I can tell, anyone at all actually wanting it...
no comment on likely security issues
no comment on architectural design other than its new therefore it must be better. I've been around too long, fooled too many times, to fall for that one LOL. That one might have worked on me in '81.
does contain tangential appeal to authority, which is generally anti-convincing to me, but whatever.
does contain distraction of wayland. I notice a certain similarity in social behavior behind both the waylandites and the systemd supporters. Where are these people coming from?
I do agree with "v1 can be fixed" although not sure how tight integration into unrelated areas and lack of compliance with existing standard interfaces helps speed bugfixes. Usually that's not the preferred architecture and development style for rapid bug fixing. I've not been hit by any bugs so I've not researched that situation in depth.
One interesting thing to think about WRT systemd is most of the opposition revolves around negative PR about its architecture and how its being rammed down peoples unwilling throats. Yet it hasn't been a serious problem, at least for me, although logically cruddy and poorly designed and managed and deployed software should be an epic fail causing me massive headaches. Yet it doesn't, not yet. This conflict does not compute... That indicates the possibly, that the incredibly negative steaming cloud around systemd might not be the most fair and unbiased coverage. In that case, the most logical way to support systemd would be to fix the coverage, but the supporters have been remarkably ineffective at that task. All we get is authoritarianism, mailing list bans, false dilemas, all that kind of stuff. If the code is actually any good, it'll eventually be revealed as good code, although the people defending it generally seem opposed to that strategy, which is even weirder.
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @03:34PM
Don't you even notice that your argument applies to Slashdot Beta exactly? ;-)
And nevertheless, you are here. On a site built on nothing but "legacy technology". Instead of http://beta.slashdot.org/ [slashdot.org] with "modern techniques". "It's called progress", isn't it?
It's really funny, but rather hypocritical.
(Score: 1) by fbscarel on Wednesday February 26 2014, @04:19PM
Agreed. Being new for the sake of being new has no purpose.
Here we are, on SoylentNews, are we not?
(Score: 0) by Grishnakh on Wednesday February 26 2014, @07:00PM
Slashdot Beta removes tons of useful features, in favor of trendy (aka ugly) new visual design. systemd has more features than other init systems. So it's quite the opposite.
As for "legacy technology" vs. "modern techniques", systemd is written in good old-fashioned C, just like Unix and Linux, not some trendy new language-of-the-week.
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @08:14PM
Things which "have more features" tend to serve as drop-in replacements for whatever they're designed to replace, and to outcompete them on the merits.
Systemd isn't noted for being capable of either. So is more properly defined as having *different* features.
Which is precisely the problem. Not everyone likes the new featureset better than the present one, and some like being deprived of choice even less.
(Score: 0) by chris.alex.thomas on Wednesday March 19 2014, @02:36PM
oh no, I agree with you, I wouldn't use a codebase like this for a modern website, I'd start again and write something which solved those problems in a better fashion, but also let other people have their opinion on the templates that run the website, the data layer is one thing, but I dont see why they screwed up the templates so badly.
also, soylent news's interface is very old, antique and pretty hideous
so it's not hypocritcal at all, I have the same opinion about both, they are both old, out of date, solving problems that no longer exist and there are better solutions to be found.
(sorry, I didnt see your reply until now, so thats why it's a little bit late)
(Score: 2) by evilviper on Thursday February 27 2014, @11:15AM
SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is notable on Linux.
There are various add-ons that do this, like daemontools, but they can't replace SysVinit, so you're stuck maintaining two mutually incompatible methods for running services.
I don't care about boot-up times, but not being able to have all system services automatically restarted (without human intervention at 3am), should anything happen to them, is a glaring failure on Linux, putting it a couple decades behind its competitors.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1) by jbernardo on Friday February 28 2014, @09:06AM
This is the dumbest thing a sysadmin can do, have services by default restart automatically on crash. You should first try to identify the problem cause before relaunching the service, to make sure it won't happens again.
If you have a critical service that needs to be restarted, there is daemontools and some other alternatives. Making the automatic restart a default and part of the init system is dumb and dangerous, just serves to "hide under the rug" any issues that the crashing services have, until it is too late, and you have data corruption or worse.
This approach is for me the worst - "as I don't understand why people would use two tools with two complementary philosophies, I make this impossible, by adding the functionality I use to the main tool and making it impossible to be replaced without replacing everything and the kitchen sink".
(Score: 2) by evilviper on Friday February 28 2014, @01:14PM
Your comment just oozes with obvious ignorance about managing hundreds of servers doing serious work. You would NOT want to be paged at 3am just because nscd crashed after 600 days of uptime. It's utterly idiotic to claim someone needs to investigate every such happenstance, or that you should rewrite all your startup scripts so every system service is run out of daemontools. After all.. ANY service that you need to have running is "critical" and failure can't be ignored.
You offered ZERO example scenarios to backup your breathless assertion for how automatic service restarts are or can be either stupid or dangerous. If there was any such issue, it would be looming over daemontools since forever, and the widespread adoption of systemd by every distro out there just serves to show the experts know something you obviously do not.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1) by Mr Dave on Wednesday February 26 2014, @09:19PM
My main problems with systemd are not technical.
1. It is LGPL. So there is no need to redistribute fixes. This is a RedHat sponsored project. The systemd developers do not at the moment seem to publish backport fixes just update fixes. So if RedHat (the company) for RedHat (the product) decide to backport fixes to a particular release, as they normally do, they are not under any obligation to publish source code of these fixes giving them a clear advantage and making Ubuntu server, Oracle Unbreakable, Scientific et al do all that rework.
2. All the daemons are bundled and tightly integrated. So if you choose a window display manager that requires the systemd-logind component your entire init system choice is now overridden. There is no plan to break up functionality into seperate packages that are independent so you can pick and choose what you want. The amount of services it has subsumed are core, critical and required by many other systems. dbus, logind, init, cgroup management et al.
3. No "advanced mode". Everything must go through systemd. For example, if there is some novel thing you want to try with cgroups it must be done via systemd. The last I read on the systemd devel list was that systemd will go as far as hiding cgroups from users (by users I mean sysadmins) and presenting slices. No ability to create your own cgroup policy engine, you have to use an api/dbus to instruct systemd to act on your cgroups.
4. Stifling independent innovation. Assuming points 1 to 3 are valid, developers must work in the systemd ecosystem or face not being adopted. Even if new "hyper init system X" gets invented and has unheard of, unimaginable functionality it will have to be integrated into the systemd packages or not be used. People won't be able to try it, they won't be able to install it without installing huge core components of their OS. And once a project is part of the systemd project the independant philosophy that may have driven the innovation will be subsumed.
In my opinion, this is very much the policy attitude of gnome all over again. Choices on behalf of the user "for their own benefit". "We're doing it to help you" etc. Remember the whole gnome argument about opening a new file explorer window every time? You couldn't have the old behaviour anymore because the gnome developers decided it was inefficient and you didn't want it.
Following the idea of "do not attribute to malice what can be explained by ignorance", I expect these developers are genuinely trying to build a better system and fix problems they perceive as important.
The problem is that it is a viral solution. All it takes is your favourite application to require one tiny aspect of systemd and you have the whole thing, whether you want it or not.
Systemd developers do not seem to be interested in building a system that contains independent and replaceable modules. Which is fine, it is their idea and their product. It does however mean that it heavily restricts the choice of sysadmins, distribution maintainers and users.
**By modular I don't mean ~100 tiny binaries in a single package, which is the current systemd. I mean 20 packages each with a well contained bundle of functionality, that you can choose from as other alternatives become available.
(Score: 2) by RobotMonster on Thursday February 27 2014, @07:24AM
Coherent explanation; thank you!
(Score: 1) by Eunuchswear on Thursday February 27 2014, @02:56PM
There is nothing in the LGPL that says this.
If you distribute modified versions of LGPL code you must distribute the modifications, just like GPL.
Watch this Heartland Institute video [youtube.com]
(Score: 5, Interesting) by mtrycz on Wednesday February 26 2014, @01:00PM
Can the submitter at least provide a resonable argument as to what is wrong with systemd, and why does it matter? "I don't really like it" is not an argument.
Stop assuming I'm up to date with all of the systems.
In capitalist America, ads view YOU!
(Score: 5, Informative) by jbernardo on Wednesday February 26 2014, @01:23PM
Well, a quick google for "what is wrong with systemd" gave several hits. One of the most comprehensive is here - http://www.linuxadvocates.com/2013/04/systemd-new- pulseaudio.html [linuxadvocates.com] - but for me, the final straw was that I was unable to boot a pc because the clock got reset somehow. "fsck -a" kept failing, as the last modify date was in the future, and systemd kept restarting it, never getting to a recovery console. Then I found out that passing "single" in the kernel command line isn't recognized by systemd - there is now some .target syntax, for some stupid reason.
So that was the final straw for me - but that wasn't the question. I don't want to get into the typical discussion around systemd.
The question is what linux, binary alternative distros are there?
I know I can switch to BSD, I've done SourceMage scripts automating the LFS "recipes" to build openoffice, java, etc., but I'd rather have pre-built binaries for the family laptops and netbooks.
So, what alternatives do have, with the linux kernel?
(Score: 5, Informative) by Desler on Wednesday February 26 2014, @01:38PM
While that link may sound great you should realize the same person made a complete 180 after writing it. You can read their current opinion here [linuxadvocates.com]:
Basically most of the systemd hate is from mostly people who have never used it and are simply riding the "We hate Lennart" wave.
(Score: 1) by Eunuchswear on Wednesday February 26 2014, @02:48PM
And his change of mind just goes to show he's still an idiot who doesn't get it.
A guy who says his distro is "fuduntu" "a fork of Fedora 14" spouts:
Or have I fallen for a Poe?
Watch this Heartland Institute video [youtube.com]
(Score: 2, Informative) by Desler on Wednesday February 26 2014, @03:08PM
Dieter no longer uses Fuduntu as the distro is DOA and he had an internet nerd spat with its creator.
(Score: 2, Interesting) by Anonymous Coward on Wednesday February 26 2014, @02:49PM
Said article does not refute any of the reasons as to why systemd i crap. It just labels systemd a foregone conclusion, as in "Give up, the start menu is gone, just get used to Modern UI".
For those of us who like to be able to configure our systems to our likings, the choice is not between systemd or upstart. It's between finding a Linux distro that sticks to the unix philosophy, or skipping to FreeBSD.
(Score: 2) by VLM on Wednesday February 26 2014, @07:39PM
"It's between finding a Linux distro that sticks to the unix philosophy, or skipping to FreeBSD."
systemd does have the smell of an "embrace extend extinguish", doesn't it?
(Score: 3, Insightful) by jbernardo on Wednesday February 26 2014, @06:41PM
And it is because this is usually how systemd defenders answer criticism that I don't want to discuss why I don't like it. I just want an alternative.
(Score: 2, Informative) by drussell on Wednesday February 26 2014, @03:13PM
Something tells me you haven't really tried FreeBSD much. As a FreeBSD user since 1.x without a single Linux box running here (7x FreeBSD and 1x Windows 2000 powered and running here at this moment, for example) I really don't understand what you mean. Pre-compiled binaries are (and have always been) available for download for virtually every FreeBSD 'port' in the ports collection. You can install an application from source (using the FreeBSD 'ports' system) with a single command. You can install an application from binary package (the packaged version of the port) with a single command. You can even build your own local copy of the package from the ports system with a single command.
All of the Linux package systems are really variations and derivatives of the original FreeBSD ports/packages system....
Where's the hard part?
(Score: 1) by dbot on Wednesday February 26 2014, @03:57PM
I got into FreeBSD around 4.4-RELEASE, so I'm not quite as old school. I'd be interested on what your thoughts are on the following, and if you have anything constructive to add:
https://soylentnews.org/comments.pl?sid=301&thresh old=0&commentsort=0&mode=thread&pid=7262#7325 [soylentnews.org]
(Score: 2, Informative) by jbernardo on Wednesday February 26 2014, @04:51PM
Sorry, seems like I mangled two phrases into one. I intended to say that for binaries I can switch to BSD, and that source distros don't scare me as I have experience with them, but I'd rather have a linux binary distro. I know FreeBSD has binaries. I apologise for the confusion.
(Score: 1) by drussell on Wednesday February 26 2014, @06:57PM
Ah, I understand what you were saying... I had misread. No problem. :)
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @06:27PM
Slackware.
(Score: 1) by bluefoxicy on Monday March 10 2014, @10:56PM
All of this sounds like paradigm shift.
I know folks who have embraced systemd and found it extremely useful. As with everything that's survived to replace a prior thing, systemd seems to be starting with a "large effort, small return" curve: it takes a lot of effort to make systemd work all the time, and in the end you're just trying to get it to do the same thing as everything else.
The thing with paradigm shifts is they happen because of the opposite. You start with high effort, low return; you hit low effort, high return; then you hit diminishing returns, where you apply much more effort for much smaller gains.
I remember when devfs faced this kind of mass pushback. Then it was hotplug, which became useful but was usurped by the hated udev, which is now accepted and is extremely important for a working system actually capable of most of what we have now--such as mounting a USB drive writable by a particular user just because that user happens to be the one at the currently active console. Each of these represented a paradigm shift where a prior approach was suddenly painful and clunky, but where the new approach was unrefined and took some effort.
What systemd started as, from what I can tell, is a new init system. You know that whole 'service vsftpd status' 'vsftpd is dead (pid file exists but process is dead)' thing? Well with systemd, you can tell it to restart things. You can configure it so that it takes a host of actions when a service dies, restarting or reloading other services. You can configure dependencies better. The hotplug system even allows for resource-based dependencies: reload proftpd or apache when a new network interface comes up if you want.
I suspect that some time in the near future we will see systemd not only replace the current infrastructure, but also become much better. It will polish its existing features, and distribution maintainers will ship with better support--better default configurations, as they needed with hotplug and udev. That means someone needs to write up init scripts, dependencies, automated actions and reactions, and so on.
After that, systemd will finally surpass ... what is it now, upstart? And people will talk about how it's so much better than all those old, clunky systems that were cobbled together near the end.
(Score: -1, Troll) by Desler on Wednesday February 26 2014, @01:40PM
There is no real argument beyond Lennart hate and acting like the "Unix philosophy" is some sort of infallible orthodoxy.
(Score: 5, Funny) by WillR on Wednesday February 26 2014, @02:50PM
The UNIX Way shall not be questioned. What was best for a university time-sharing system in 1974 is clearly also best for a single user laptop in 2014.
(Score: 1) by gawdonblue on Wednesday February 26 2014, @07:59PM
What worked on a university time-sharing system in 1974 has worked even on laptops until now (or I couldn't be typing this). But is what is best for the single user laptop in 2014 best for everything else?
(Score: 1, Insightful) by Anonymous Coward on Wednesday February 26 2014, @09:11PM
(Score: 1, Interesting) by Anonymous Coward on Wednesday February 26 2014, @02:45PM
What's wrong with choice?
Why is it that when it comes to computers, even open source, people are always called to justify their personal preferences? What's wrong with systemd? What's wrong with Windows 8?
When I told my brother, who wass an Opel fanatic incarnate - you know, the kind that drives around with stickers of calvin peeing on a VW logo - that I was looking at buying a Toyota, I was not asked to justify my choice.
But when it comes to computers, apparently everybody hates choice and loves monopolies. I guess we should all be running systemd on Windows 8...
(Score: 5, Informative) by mth on Wednesday February 26 2014, @03:38PM
I know a few reasons why it is unpopular, but a lot of those are not flaws of systemd itself.
It's new, so it has bugs and especially the service configuration files will have bugs. New sysvinit scripts also often have bugs (dealing poorly with exceptional situations), but those have been ironed out over the years. Switching to systemd introduces new bugs that will take time to iron out.
Systemd starts services in parallel, which is useful in reducing boot time, but is also a lot less predictable. If dependencies are either specified wrong or not well designed, the system might boot fine sometimes and fail to boot at other times.
It uses new syntax, both in configuration files and on the command line. For example, to access logging there are log filter options on a log DB instead of grep+less on plain text logs. While the new logging is a lot more powerful, it does mean learning a new syntax. And you're confronted with this while troubleshooting, which is not the ideal moment to appreciate a new design.
Systemd tries to do a lot of things: starting services, logging, cron-like scheduling, managing /dev. This is not the typical modular UNIX philosophy (do one thing and do it well). Maybe this is necessary to do these thing better, maybe it's lazyness of not wanting to design new interfaces between modules. I don't understand the details well enough to make that call, but in general I'm suspicious of projects' scopes that continue to grow.
Lennart Poettering made PulseAudio, which has a lot of enemies. And while I wouldn't consider myself an enemy of it, I did disable it on my desktop since it didn't provide any value for me and it did add to the audio latency.
I wasn't a fan of sysvint: there is a lot of boilerplate code that is copy-pasted, there are unnecessary differences between distros (whether the "status" subcommand works, for example) and flattening the dependecy graph to a linear startup sequence had to be done manually while that is something that computers excel at. But I've also ran into a several problems with systemd; the first time I tried it my PC wouldn't even boot at all. Time will tell whether it is an improvement in the long run.
In my opinion sysvinit is a dead end: it is good enough, but it isn't great and it won't be getting any better because the limits of the design have been reached. So I welcome new approaches; I'm just not sure yet whether systemd is the answer.
(Score: 5, Interesting) by jdccdevel on Wednesday February 26 2014, @04:33PM
That being said, the problem for me is that systemd is tied, inexorably, to the abomination that is the journal. What's wrong with the journal? Off the top of my head:
Why did they make the journal anyway? AFAICT, the journal's entire reason for existence is to provide tamper-evident logging. (i.e. if your system gets hacked, and the attacker changes the logs, there's guaranteed to be evidence of the changes.) That's it. There is no other reason that I know of. Note that it doesn't make them tamper-proof, just tamper-evident. It's a admirable goal, but the implementation is SO HORRIBLE, the cure is literally worse than the disease.
If the journal was optional, systemd would be a non-issue for me and many others. Sure the learning curve is steep, but the end results are actually quite nice. But by tightly coupling it with the journal abomination, they're making it much, much harder to swallow.
(Score: 5, Insightful) by gallondr00nk on Wednesday February 26 2014, @01:08PM
There you go, Editor ;)
I don't have a problem with getting machines running systemd, but the way the logs have been screwed around with is absolutely infuriating.
I actually run FreeBSD on a couple of machines. The basic documentation is very good, but I've found if you run into problems there aren't the user numbers to be able to always find the solution in forum posts. A couple of ports of Linux stuff misses the odd feature (lxpanel on FBSD lacks a CPU usage plugin, for example) and flash can be a bit of a pig to get working as it isn't native. Having got myself used to netcfg / netctl, I personally find the networking a bit awkward.
On the plus side, it's fast as hell, light, and very elegant. Daemons are invoked with /etc/rc.conf, modules with /boot/loader.conf, simple as that. OSS sound means you don't have to fuck around with pulseaudio either. You can run it on absolutely decrepid hardware and it'll be fairly responsive. There's a linux wrapper too.
Have a look, you might be pleasantly surprised.
(Score: 0) by dbot on Wednesday February 26 2014, @03:19PM
So, what release are you running, and what version is the browser currently running on your system? (I'm assuming you have a browser, it sounds like a desktop config.)
I can almost guarantee your browser is out of date, to the point that if someone wrote a FreeBSD exploit, you'd be exploitable. The same goes for any other third party software running on the machine.
Where you really run into trouble on FreeBSD is recursively updating the ports tree, over, and over, and over, for each security fix.
There's some really smart people working on the system, and in general, the operating system is simply awesome (pf, zfs, geom, etc, etc, etc), but for all that: the project overall hasn't addressed the elephant in the room - that the ports tree has 24650 ports [freebsd.org] with interdependency galore, and to update one library for a security fix (or installing a package later on) means recursively updating every inter-dependant package to the latest, api/config file-breaking or not, version.
Maintaining a secure system over time is a huge task. Stuff goes wrong building, all the time - the state of the ports tree is constantly in flux.
Extra credit: Install the latest 10.0-RELEASE 'desktop' system, and update firefox ('cause it's out of date already, I'm sure). Better yet, use pkgng, or portupdate, and do a binary recursive update - forget building from source and make your life easy.
I'm considering Debian/kFreeBSD for this reason for my next server build. I haven't played with it to know where the trouble spots are yet though, so it might be a world of pain for other reasons.
The idea of back-porting security fixes to a -STABLE ports branch (with no api or config file breaking changes), with signed binary updates, is a concept that has been not addressed in the slightest by the project - to my knowledge. I believe it's the only sane way to deal with actually running a system over time though.
pkgng is lipstick on a pig - it still is just running the bleeding edge of ports. That's a design problem.
My gut says: it's O(N^2) hard to build recursively (status quo), where back-ports make it O(N) hard, where N is the number of ports installed on a given machine. O(N) because you only need to update that one package, not its dependencies. Also, you don't need to update that package's config files, so even in the case where it's just one package, you are still further ahead.
Obviously back porting security fixes for ~25k packages is a lot of work. I'm not going to do it. My point being that the problem is structural for the project. I don't need the latest and greatest. What I need is a stable config that works for a time. Whether it's a year, or two years, or whatever. This isn't owed to me, I'm just going to try and balance this with my other needs, and choose software that fits.
TL;DR; There's a lot of great things about FreeBSD. Keeping up to date, or installing new stuff later is not one of them.
(Score: 3, Interesting) by fnj on Wednesday February 26 2014, @04:49PM
FreeBSD is quite a bit of work for a desktop. It's not like a linux distro, where everything has been massaged to make sure it fits together well and the defaults are sensible, fonts are pretty, etc. PC-BSD is the obvious choice for desktop, just like FreeBSD is the obvious choice for server. PC-BSD is just a polished FreeBSD.
That said, I have absolutely zero problems with pkgng. I type "pkg upgrade" and presto. Everything works, up to date with respect to this week instead of last week.
In practice I don't have any real problems due to riding the bleeding edge with either FreeBSD or Arch. I have all kinds of problems with ancient frozen snapshots from the year 2010 (like RHEL6). That crap is just so out of date for desktop use it's ridiculous. Would I use a rolling release, aggressively updated, for a critical server? Of course not.
(Score: 1) by dbot on Wednesday February 26 2014, @05:25PM
(Score: 1) by GeminiDomino on Thursday February 27 2014, @02:51PM
Has FreeBSD changed that much? It's been a (long) while since I last worked somewhere that we used it, but 4-STABLE didn't seem particularly "aggressive" in its updating. Just hella time-consuming to do it, which is why I haven't put my weight behind it where I'm at now(waaay more machines.)
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 3, Insightful) by drussell on Wednesday February 26 2014, @07:48PM
It is true that interdependencies are an issue, but they are an issue with Linux as well. You either use an old version of a library for all your installed programs or you update the library and everything that depends on it when there is a change that breaks something. I've honestly had more issues with updating things on Linux when I've used it for things than I've had on FreeBSD, but of course YMMV.
The binary updates with pkgng (which is now the default in 10-) should usually handle everything for you as long as you don't have a bunch of custom programs/builds/etc. but again, this just really depends on what you're doing, I suppose. Custom stuff relying on strange/old libraries can be compiled with the libraries statically linked in, for example, removing the reliance on something that may change for other reasons, etc.
Ports maintainers strive to maintain a given port's buildability on not only the current developers' branch (right now that would be 11-CURRENT) as well as the latest (10-STABLE) and previous (9-STABLE) 'stable' branches intended for the end-user. Often they manage to keep them running properly much, much farther back, it's just not one of the main project goals. It's not uncommon for me to painlessly build a latest version of a port with no modification on a system that is 4,5,6 or more versions obsolete. There are buildbots that constantly build these and build failures are generally fixed as soon as possible. If you've got an (perhaps 8-) or 9- box, you should still be able to just do a make install in any port directory, and it should fetch, compile, install just fine. The ports tree is one tree, there aren't separate trees for different branches/release versions but when security or other updates are applied, it IS checked to be sure it still runs on -STABLE.
My experience has been precisely the opposite. I still have internal machines here running 2.x, 4.x, 8.x, 9.x and 10.x for various purposes and reasons and I've always found it far easier to keep what I need up to date on FreeBSD than Linux. It's actually one of the main reasons I DON'T use Linux except in a few niche cases (like on one MythTV frontend box in a system for tuner card support with the other frontends and the backend running FreeBSD)... Things seem to constantly change and it's a contstant update/support nightmare! I end up manually uninstalling and re-installing things that were supposed to update themselves due to some non-obvious dependency or change somewhere breaking something else. I find the FreeBSD system MUCH easier. To me, the dependencies and such seem more clearly marked. Sometimes that means a port is marked 'broken', but then I have the option to find the broken-ness myself and fix it or work around it when I need something specific/strange/downright wierd and nutty to work the way I want.
Users that aren't so savvy shouldn't really see much difference between a 'pkg upgrade' on FreeBSD or using one of the binary update mechanisms used in the various Linux flavors. In most cases any of these systems will look at your system's version and current state, make the best decisions they can as to what should be updated and from which repository of binaries, fetch and install.
I'm sure the on Linux way is more comfortable to one familiar with that particular system just as the FreeBSD system is second-nature to me but essentially they're all doing the same thing.
(Score: 1) by drussell on Wednesday February 26 2014, @08:58PM
That was supposed to read:
Silly me, using the wrong brackets and not noticing it in preview... :)
(Score: 1, Interesting) by dbot on Thursday February 27 2014, @02:57AM
I respectfully disagree. They are not doing the same thing at all. The key being: fixes are back-ported to a static version of a library. So imagine on your 2.1-RELEASE, there was a ports tree freeze. That is the 2.1-RELEASE port tree, forever. Now, during the supported lifetime, security issues, or major bugs occur in those ports. Critical fixes from the latest upstream source are backported down to the 2.1-RELEASE tree, for the supported lifetime of 2.1-RELASE. No major version bumps. One day, when your production schedule permits, you upgrade to 2.2-RELEASE, and now you've got all the api+config file changing updates in one fell swoop.
Right now, it's: upgrade to the latest upstream version, recursively.
I don't know if you've used Debian + apt, or CentOS and yum to use some canonical examples. The repos have stable versions of the software, and have major fixes backported, for a release (as mentioned above). That is, you run an old version, with non api/config fixes backported. Periodically, these repos are updated to more cutting edge software, so you aren't running things 2+ years old, but by and large, the software you run will be the same version until you update. So when you say more issues, how are you installing software and dependencies, on which distro?
Here are some examples of things that have been a pain over the years:
autoconf
gettext
gmake
libiconv
*perl* omfg
ruby (if you use portupdate)
php
I think by the way this is phrased, people might get the impression that they are testing things on old releases. They are testing build success, periodically, for supported releases.
Anyways, I think that this discussion illustrates pretty quickly my point. There is total failure to acknowledge that this is a problem. I believe it is, for my uses. I'm not saying They Should Fix That, because it's a volunteer project. I'm not going to do it. I'm saying this isn't even in the discussion when talking about 'fixing the ports system'.
(Score: 2, Informative) by unimatrix on Wednesday February 26 2014, @04:13PM
FreeBSD is still my favorite server OS unless you need something fancy. We're getting ready to deploy a new project for a client and we elected to go with FreeBSD dedicated server(s) from Pair Networks. (Not affiliated with them other than a happy customer for over a decade now). Back in the day it had it's ports system that made installing the common binaries or compile from source easy as it would go fetch the dependancies, etc. Which back then Linux was stuck in dependency hell. The Linux package managers have caught up now or exceed the old ports system, but if you want a rock solid general server (or router or OS for NAS), FreeBSD and it's derivatives work extremely well. And oddly enough I've had FreeBSD work with hardware that I had trouble with on Linux...
If you are looking for more of a desktop flavor, go see the folks over @ http://pcbsd.org./ [pcbsd.org.] It's FreeBSD with some more polish towards the desktop with GUI installer and somethings that are more friendly towards new users.
(Score: 1) by drussell on Wednesday February 26 2014, @10:16PM
Hmm, that's strange. FreeBSD will run most linux binaries essentially natively using the built-in 'linuxulator'. Not that it really matters as we'll soon all have to run it under wine or somesuch since 11.2 is getting very old and many sites now require 11.9 or 12.0.
I'm curious what method you were having trouble with, though.
Something like the following has always installed flash and enabled the plugin in Firefox for me just fine:
Done...
(Score: 1) by drussell on Wednesday February 26 2014, @10:24PM
That was wierd, my comment doesn't appear under the comment to which I replied... :) )
I was trying to respond to gallondr00nk.
Lets see if this shows up as a sub of the correct comment (in which case I messed up somehow, a very likely possibility
This should be linked to http://soylentnews.org/comments.pl?sid=301&cid=758 8 [soylentnews.org]
(Score: 4, Informative) by quitte on Wednesday February 26 2014, @01:20PM
While systemd will be the default init system beginning with Debian jessie there is not even close to enough of a consensus to make it the only choice - and since it's debian there won't be. So how about going back to Debian?
(Score: 2, Interesting) by weilawei on Wednesday February 26 2014, @08:30PM
(Score: 0, Troll) by wantkitteh on Wednesday February 26 2014, @01:44PM
BURRRRRRRRRRRRN!
I was doing some command line work on Mac OS X and someone asked me if I was going to learn to do what I was doing on Linux as well. I asked him why I'd want to go down a notch, I like BSD.
(Score: 2, Insightful) by Anonymous Coward on Wednesday February 26 2014, @02:31PM
I switched from Arch to Slackware for the same reason.
Slackware is more stable, though, where Arch is more cutting edge, and Slackware doesn't have the ton of packages that Arch has (especially if you include the AUR).
For that reason, I ended up writing my own build script that takes a simplified PKGBUILD, and builds a slackware package.
(Score: 1) by jbernardo on Wednesday February 26 2014, @04:11PM
That seems like a nice approach. Care to share your build script? :)
(Score: 3, Informative) by grandmofftarkin on Wednesday February 26 2014, @07:04PM
Just a few small tweaks to the PKGBUILDS and you could use this http://slkbuild.sourceforge.net/ [sourceforge.net].
However if you really want to try Slackware you should learn to write SlackBuild scripts, check out slackbuilds.org (kinda like the AUR) and start using sbopkg (similar to an AUR helper).
(Score: 3, Informative) by Natales on Wednesday February 26 2014, @03:27PM
Interestingly, systemd along with etcd and docker are the basic building blocks for CoreOS [coreos.com], a Linux distro targeted to massive scale deployments. The link explain why it's seen as an advantage for that particular use case, one of them keeping boot time under 1 second.
Some folks here have said that's irrelevant in the server world, but I'd argue it depends on what are you trying to do. In fact, Linux (IMHO) is all about choice. In one end I believe that if you want to use systemd or you don't, it should be entirely up to you. It may be a default, but changing it should be as simple as update-alternatives [ubuntu.com].
(Score: 1) by jbernardo on Wednesday February 26 2014, @04:14PM
(Score: 0) by Bill, Shooter Of Bul on Wednesday February 26 2014, @04:15PM
http://www.islinuxaboutchoice.com/ [islinuxaboutchoice.com]
(Score: 0) by Bill, Shooter Of Bul on Friday February 28 2014, @06:06PM
To further elaberate. Linux is FOSS, where things are a meritocracy. If you don't like something, you usually have the freedom to change it, through code. Anything more than that is frosting on the cake. Some have distilled all of UNIX to piping text manipulating commands through the shell, for those people, I guess UNIX would be about choice. But linux in general, is not about choice. Its about a kernel for an operating system which necessarily limits what you can and cannot do with it ( in terms of api usage) without changing the code. Various Distros may put a userspace around it that may or may not introduce utlities that may or may not be switched out and around, but that's not linux and not gaunteed by anyone.
I think when people say "Linux is about choice" the usually mean one of two things:
1) A general statement that they enjoy being able to swap out userspace applications as they please.
2) Other people should change the way they code things so that they can swap something they want to use in for something else.
#1 is okay to say. #2 is telling other people to work for you, which is wrong. Especially in the context of FOSS. You want it done a certain way, you do it.
(Score: 2, Informative) by Grishnakh on Wednesday February 26 2014, @07:08PM
Linux is not all about choice at every level of the OS. How many Linux distros use non-Linux kernels? How many different versions of the Linux kernel are out there? Except for some older projects, everyone's on the 2.6/3.0 kernel tree now, with few variations. The Linux kernel has never made any attempt at being ABI compatible with other Unix kernels, and instead has preferred to forge ahead with new Linux-specific features like cgroups.
There's also been attempts to standardize parts of the Linux stack, namely the LSB. That standardization hasn't happened yet, but there've been attempts to move that way to some degree.
Basically, the lower in the stack you go, there more need there is for standardization. It's harder to swap kernels than image-editing programs or text editors on a system. The init system is pretty deep in the stack, only sitting directly on top of the kernel. If you're getting this worked up over an init system, then maybe you should take a look at other systems like FreeBSD, Solaris, or AIX. None of those use sysvinit either, and all of them have only a single init system, each one totally specific to that OS and kernel.
(Score: 1) by weilawei on Wednesday February 26 2014, @09:16PM
Linux is the kernel. It wouldn't be a Linux distribution if it used another kernel. It would be something like GNU Hurd.</pedantic>
(Score: 2) by SGT CAPSLOCK on Wednesday February 26 2014, @03:29PM
If not Gentoo, then what about a derivative such as Sabayon?
I can't really remember since it was so long ago, but I tested Sabayon at one point and I _think_ it used openrc. It also probably addresses whatever scathing issues the submitter might have against stock Gentoo! ...But I love my Gentoo. And my openrc. :p
(Score: 2, Informative) by geek on Wednesday February 26 2014, @03:50PM
Sabayon uses systemd now
(Score: 2, Informative) by jbernardo on Wednesday February 26 2014, @04:18PM
Well, it seems Sabayon uses systemd now. And the only thing I might have against Gentoo is that it became more used than SourceMage... :)
Maybe should go back to source based distros again, but I really would prefer a binary one to avoi weekly recompiles on all the house laptops and netbooks...
(Score: 1) by Subsentient on Wednesday February 26 2014, @04:20PM
I am really, really glad you posted this OP. Was testing elinks in a homebrew distro and ran across this story, and had to open it up in FF to be sure :^)
http://universe2.us/epoch.html [universe2.us]
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @05:49PM
Slackware has not succumbed to the systemd nightmare yet. In fact, it has not succumbed to the SysVinit nightmare of symlinks yet. It's startup is much more old style "rc" script file style. There is support for the sysV forest of symlinks nightmare, but it is not used by Slack, and is only present to enable installing rpm's/etc. that depend upon sysvinit style symlink nightmares.
(Score: 1) by higuita on Wednesday February 26 2014, @06:44PM
note that it is not clean if slackware will use systemd in the future or not.
Remember that several basic programs (example: udev) are include in systemd and as systemd have several features and fixes ancient init problems, Pat might also join the systemd.
No matter what some people say, systemd is right now the best init system available for linux... yes, it have many problems, but i also have some killer features... you can't simply ignore it.
As a slackware user, and after having tried several init systems and worked with AIX and solaris, i can say that systemd (or something similar) is needed to finally kill the stupid systemV init and solve the BSD init problems, so i would accept systemd in slackware (specially after applying the KISS filter on it)
(Score: 0) by Anonymous Coward on Wednesday February 26 2014, @09:25PM
(Score: 2) by Foobar Bazbot on Wednesday February 26 2014, @11:06PM
Right after he becomes a PAM supporter?
I don't hate systemd that much (I've got some ideological beefs with it, but it does work), but the idea that Pat'll slip it in slackware anytime soon? ROFL
(Score: 1) by eravnrekaree on Wednesday February 26 2014, @06:23PM
If your using a SystemD distribution, one option is you may start your own init system from systemd and then start your programs from that. You can use your own init system in parallel to systemd. You could have systemd start your own program that could be Bash scripts, C, Perl or whatever you want, which would start your programs. There is no requirement that you use systemd exclusively or that you have to get rid of systemd to use something else. You can use your own thing to start many of your programs but keep systemd.
(Score: 1) by weilawei on Wednesday February 26 2014, @08:33PM
You could hack that onto any init system. What's the point? Systemd is a stinking pile of garbage, from a design standpoint. Binary logs, specialized query languages, monolithic design... this is a recipe for a pile of Microshat. There is absolutely no excuse for building it in that fashion. The goals of systemd could be achieved in a manner more consistent with the UNIX philosophy, but apparently, writing modular code and using standard tools is beyond the author's capabilities.
(Score: 3, Informative) by aniou on Wednesday February 26 2014, @06:52PM
Handy, sane, stable and with XEN support built-in. Binary packages available by pkgin [pkgin.net]. Net also has some drawbacks - for example lack of modern KMS support (although some steps already has been taken [netbsd.org]) and small - but extraordinarily friendly - community. I have been working with different linuxes for many years but I still appreciate Net - not as smartest or strongest pet in my house, but lovely, wise and brave. ;)
But, If You have a modern Radeon GPU then FreeBSD (or Slackware or Slackware with slackbuilds or Slackware mixed with pkgsrc) may be better choice, though.
(Score: -1, Flamebait) by Anonymous Coward on Wednesday February 26 2014, @08:20PM
PUT YOUR FUCKING ED NOTES IN THE COMMENTS. Stop treating the summary as your personal podium. Join in the discussion WITH us, instead of talking AT us.