Fork of Systemd Leads To Lightweight Uselessd

An anonymous reader writes A boycott of systemd and other backlash around systemd's feature-creep has led to the creation of Uselessd, a new init daemon. Uselessd is a fork of systemd 208 that strips away functionality considered irrelevant to an init system like the systemd journal and udev. Uselessd also adds in functionality not accepted in upstream systemd like support for alternative C libraries (namely uClibc and musl) and it's even being ported to BSD.

Comments

kill -1

[Spazmania]

If it still doesn't adequately support the "kill -1" functionality of initd (which kills and resets all processes init manages, especially the getty processes on the terminals), I still don't want it.

Re:kill -1

[fisted]

Like that wasn't trivial to achieve already with the existing tools.

Re:kill -1

[Spazmania]

Yes, it was trivial to achieve. With sysvinit. Lots of stuff is trivial with sysvinit and overly complicated with systemd.

Re:kill -1

[frooddude]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

Re:kill -1

[Barsteward]

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...

Re:kill -1

[swillden]

If it still doesn't adequately support the "kill -1" functionality of initd (which kills and resets all processes init manages, especially the getty processes on the terminals), I still don't want it.

What do you do that makes you need kill -1 regularly? I think I've only used it a handful of times in 30 years, and not at all in the last decade or so.

Re:kill -1

[drolli]

Yes, but in the times when i needed it, it was really helpful.

Re:kill -1

[gwolf]

I do not use kill -1, although its function is easy to understand — But sending a signal to a group of processes instead is quite useful. That's what kill -$PID achieves (instead of kill $PID — I agree the interface is not the most intuitive, but is well known and understood).

Re:kill -1

[swillden]

Yes, but in the times when i needed it, it was really helpful.

Meh. It's just a slightly-faster reboot that's only usable when you don't need to change the kernel.

Re:kill -1

[Barsteward]

How do you do it with systemd?

Re:kill -1

[arth1]

Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan.

I have turned down Red Hat EL 7 for my business systems, and install RHEL 6 with vaious 3rd party repos to get new packages, precisely because of systemd.
A leaner fork of systemd just won't do it.
Give me an init that only does init and does it well with a KISS philosophy. And give me hal back - systemd-udev cannot do what it does, which makes RHEL 7 unusable. I don't want a 90% system, when the 10% is used by my business to earn money.

Re:kill -1

[unrtst]

Meh. It's just a slightly-faster reboot that's only usable when you don't need to change the kernel.

If you rephrase that slightly, it makes a very different case:
It's just a slightly-faster reboot that's especially useful when you must ensure the kernel doesn't change (ex. unknown illo/grub state).

There are a handful of other times it's useful. My personal favorite is as a self destruct (secure delete almost all files and free space, then issue kill -1), though there are much better ways of doing that.

Re:kill -1

[Blaskowicz]

What the hell does it do that is actually of use? The one time I tried it on linux (but maybe it was a kill -9 -1) it bricked the system requiring a physical shutdown or reboot. There was such a lack of anything running anymore that ctrl-alt-del wasn't handled.

You might as well boot into DOS and type "ctty nul".

Re:kill -1

[Anonymous Coward]

Then you will be delighted to learn that, according to uselessd website, they dropped udev and systemd-udev and any dependency to it. They also dropped logind, journald (i.e. no idiotic binary logs), all of the fuckingd retardedd crapd.

Besides, they give clues (if not full explanation) about which existing third party programs you can use to achieve everything that systemd tried to replace.

In other words, they keep only what you asked for: the init part.

Re:kill -1

[swillden]

It's just a slightly-faster reboot that's especially useful when you must ensure the kernel doesn't change (ex. unknown illo/grub state).

I suppose, though I, at least, have never had a situation where I needed to reboot and make sure the kernel doesn't change. I've had mucked-up bootloaders aplenty, but the solution there is to fix the bootloader (and to keep a boot floppy / CD / DVD / USB stick handy).

Re:kill -1

[arth1]

The compatibility is a main reason. Being able to run and configure all startup/shutdown processes independently of the overseer is nice. As a sysadmin, I get to do easy manual corrections, additions and deletions without giving init a thought.
i don't have to use the "service" command, and I spend far less time when seting up a new server or adding a service.

i don't give a crap whether the system boots twice as fast - reboots are years between, and in scheduled windows. I want something that lets me admin my systems without relying on anything more than a dumb terminal - and if need be, not even that.

Re:kill -1

[Anonymous Coward]

you just can't work out how much is complete FUD and whats a genuine gripe

Once upon a time I used to carefully go over all aspects of my system, and compile custom kernels, fine-tune startup, etc. I haven't bothered in the last decade or so when things work out of the box and I want to concentrate on what I am using the computer for instead of polishing the backend. That said, I've been following some of the systemd news, and responses to it seem to be a real mess and a huge amount of complaints that end up just being strawmen (probably not intentionally). There are legit idealogical complaints I can appreciate, but the vast majority of specific, detailed complaints I come across I later find out are just false. Too many complaints saying "It can't use X" or "It forces you to use Y", when it turns out there is a simple option to change to use X or not use Y... or in many cases where it flat out doesn't do Y or already uses X by default. It makes it rather difficult to take complaints seriously, talking about the "*nix way," when I thought RTFM used to be part of the *nix way.

Re:kill -1

[hairyfeet]

Systemd...its the Metro of Linux!

Re:kill -1

[macs4all]

i don't give a crap whether the system boots twice as fast - reboots are years between, and in scheduled windows.

...and this is one of the (many) reasons why it will never be "The Year of the Linux Desktop".

In case you haven't noticed, Users (remember them? Lots more Users than Admins, right?) who grew up primarily in a Windows Desktop environment, are pretty much ingrained with the philosophy of "Bootup each morning; Shutdown (not Sleep) each night." For them, Boot times do count.

But then, they aren't you; so they are just stupid, right?

Re:kill -1

[fisted]

I was talking about a trivial pipeline involving ps, xargs and kill, mainly. Which is neither systemd now sysvinit specific

Re:kill -1

[fisted]

s/now/nor/

Re:kill -1

[squiggleslash]

Must admit that's news to me. Kinda fed up of the subtle changes to shell commands we've seen over the last few years especially as this one conflicts with the kill -{SIGNAL} syntax we're used to.

Either way, this sounds like a non-issue. (1) if we're routinely trying to determine how to kill EVERY CORE PROCESS ON THE SYSTEM then we have bigger fish to fry than whether init/systemd is capable of working with that.

(2) It sound scriptable to me, assuming systemd itself isn't capable of doing it. /proc should give you all the information you need.

I worry that this is the kind of concern holding back adoption of systemd. Good reasons I understand. Bad ones, that seek to blame systemd for major system problems that exist under init too, are bad.

Re:kill -1

[Anonymous Coward]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

In that case I suggest you hand over your sysadmin rights immediately, please!

You can reapply once you understand properly what happens on user logout. Study how HUP signal sent and delivered to all user processes (process group).

Re:kill -1

[postbigbang]

None of this is tough, and there is no science fiction, and the post cites oh, 10 CVEs in four years. My underwear has more than 10 CVEs in the past four years.

So maimed are these Tea Party software sweatshirt-wearing jokers that they're taking their bruised asses into BSD, and any place, anyplace but Linux.

No, they don't tell you about any of the actual features, they just cite covering their system's butts cause they can't kill -1. You can still hobby, still futz, still cobble with Linux. And you can run huge multi-core systems with very complex (o)virting, docker, ad infinitum while you learned a few new dependencies.

Those that compare all this to WIndows 9 know neither Linux or WIndows to make such an abrupt comparison. Adoption? It's not science fiction folks. It has similarities to how Solaris has evolved, and you can take a look at Solaris for some of the roots about WHY systemd. Go ahead and initd if you want. Nobody's stopping you. RH, Deb, etc, didn't pick this because it was stupid, or because they're part of a herd. All of them have strong egos, and they picked systemd because it's so NOT 1986.

Re:kill -1

[budgenator]

kill -1 send the SIGHUP

The SIGHUP signal is sent to a process when its controlling terminal is closed. It was originally designed to notify the process of a serial line drop (a hangup). In modern systems, this signal usually means that the controlling pseudo or virtual terminal has been closed.[3] Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.[4] nohup is a command to make a command ignore the signal.

  these signals

Signals are a limited form of inter-process communication used in Unix, Unix-like, and other POSIX-compliant operating systems. A signal is an asynchronous notification sent to a process or to a specific thread within the same process in order to notify it of an event that occurred. Signals have been around since the 1970s Bell Labs Unix and have been more recently specified in the POSIX standard.

  are required for POSIX compliance, so not only are they required for UNIX programing, but for windows as well. Usually if I'm going to kill a process manually, i just use

kill -9

, which sends the SIGKILL

The SIGKILL signal is sent to a process to cause it to terminate immediately (kill). In contrast to SIGTERM and SIGINT, this signal cannot be caught or ignored, and the receiving process cannot perform any clean-up upon receiving this signal.

a more agressive, "the only way to be sure is to nuc em from orbit" thing.

Re:kill -1

[fnj]

reboots are years between

Really? You don't reboot after a kernel security update? I entirely agree that boot time is a non-issue, but your statement sounds either like hyperbole/exaggeration-for-effect, or you're not serious about security.

I want something that lets me admin my systems without relying on anything more than a dumb terminal

I entirely agree with this, and coming from not-a-fan of systemd, systemd can be administered with ssh just as effectively and probably as easily as sysvinit or bsdinit can be. What is necessary is some additional learning/training, as with any such change.

In sysvinit, the /etc/rc.d directories are full of symlinks to /etc/init.d scripts, with "magic" prefixes to control priority. In systemd, etc/systemd/user and /etc/systemd/system are full of symlinks to ... wait for it ... scripts in /usr/lib/systemd/user and /usr/lib/systemd/system. And the systemd scripts are simpler. In sysvinit, every single script reinvents the wheel by including a big bunch of the same boilerplate.

Like I said, I'm not a partisan fan of systemd, but (I hope that) any criticisms I have are based on reasonable grounds, not misconceptions.

Re:kill -1

[macs4all]

Hit the button, grab coffee, work.

Desktops these days spend more time in POST than they do starting things, with or without the parallel and conditional shenanigans of systemd.

That's because every single person who only runs MS Office all day thinks they need more RAm in their machines than existed in the entire Northern Hemisphere about 20 years ago...

Re:kill -1

[Barsteward]

"But then, they aren't you; so they are just stupid, right?" - unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

Re:kill -1

[fnj]

Then consider yourself the recipient of valuable information. Signal #1 is SIGHUP ("hangup"). The naming is strictly historical at this point. It is probably easier to remember "kill -HUP <some-daemon's-pid>". Either way you issue it, the command restarts the daemon, or reloads the daemon's config. The precise behavior depends on the coding of the paricular daemon. There is no guarantee except what the man page for the daemon says. SIGHUP used on most non-daemon programs just terminates them. That is the default if a process is not coded to intercept and handle SIGHUP.

You're entirely right that you could go for an entire career without once using kill -1. Issuing "service <daemon> restart" strikes most people as much more natural. That will send the signal for you. Incidentally, it's high time somebody wrote "service" for systemd. A simple shell script will do it for some definition of "do it".

Re:kill -1

[macs4all]

"But then, they aren't you; so they are just stupid, right?" - unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

Exactly.

OS X switched over to "launchd" (which is essentially "systemd") way back in 10.4 (Tiger) Days. I'm sure there was a bunch of whining within the Apple Developer Community from people who were crossover Linux and OS X Devs; but now, about 5 years on, it doesn't seem to have brought death and destruction to OS X. In fact, I recently played around with an SSD-equipped MacBook Air running OS X 10.9 (Mavericks), and it booted from a Cold Start in less than 10 seconds (and actually faster than a Restart!). Yes, the SSD is a part of that; but I gotta believe that launchd helps, too.

It's amazing to me how tech-savvy people can be such luddites; but there it is...

Re:kill -1

[fnj]

Heh. If you don't know the difference between "kill -1 1" and "kill -9 1", I don't want you ever touching the kill command on my systems.

Hint: one of them terminates init. The other restarts it. A highly consequential distinction.

As for "kill -9 -1", I had to look that one up. It is actually defined, though it looks like nonsense. What that one will do is kill every process in the system EXCEPT init.

Re:kill -1

[gbjbaanb]

those users are also the ones ingrained with the 'boot up each morning and watch as a thousand bits of crappy pre-installed wares start up and pop messages saying ''X needs an update', or 'Y is protecting your system' or 'these hotties want to meet you'

Just because a couple of seconds shaved off the bootup time for a Windows laptop is advertised as a good thing doesn't mean it is - the time taken for all the other crap overwhelms it significantly.

You want faster boot up times, even with the latest and fastest boot system? Then buy a SSD.

Re:kill -1

[Rakarra]

In case you haven't noticed, Users (remember them? Lots more Users than Admins, right?) who grew up primarily in a Windows Desktop environment, are pretty much ingrained with the philosophy of "Bootup each morning; Shutdown (not Sleep) each night." For them, Boot times do count.

Do you REALLY think that's a big selling point? Really?

It doesn't come anywhere close to importance as applications, window manager, actual tasks that people do once the computer boots.

Re:kill -1

[HiThere]

That's, to me, a new example of the problems with systemd.

So far the only one that's sounded serious is the "won't fix" reply to a report of logfile corruption. But there have been a humongous number of complaints about different small problems.

To me systemd sounds like a bad idea. I don't really know. The problem appears that it's going to be hard to avoid, and with so many small problems, it's quite likely that there are some serious one.

A question in my mind is "What problem does it fix?" The only answer I've heard is that you can boot faster. This doesn't impress me, as I rarely boot my computer, and when I do I often want many of the steps to happen slowly enough that I can tell what is going on.

My suspicion is that systemd is a very bad direction to go. I'm remembering that mono was also sponsered by Red Hat. And even if I grant the best of intentions, big chunks of code tend to break more often and be harder to fix.

Re:kill -1

[Smallpond]

Is OS X open? no. Is it put together in many different ways from parts from many different developers? no. Do we care whether it becomes a tightly integrated ball of proprietary software? no. So do you understand the issue? no.

Re:kill -1

[arth1]

unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

The first ones making complaints are the users, if you kill their processes in a reboot. Even if it is was announced weeks in advance, with follow-ups.
The sane thing to do is to make sure you don't have to reboot. Not going the systemd route helps with that.

Re:kill -1

[gwolf]

I must say that I somewhat followed Debian's lengthy discussions on this subject, which were quite interesting and informing, and I don't recall this argument coming up even once. I replied to this because the use case is undertandable to long-time Unix users, but not because I feel it's usual or important.

And yes, I also expect a new piece of software (specially if it's far-reaching compared to its antecesor) to have more CVEs than one that's been used for over 30 years, and works mostly unmodified since basically forever.

Re:kill -1

[Kamien]

> i don't give a crap whether the system boots twice as fast - reboots are years between, and in scheduled windows.

On my PC with an Asus mainboard the Sleep and Hibernate simply don't work (and never worked with multiple distros and kernels). I need to reboot each day therefore boot time is important for *me*.

Re:kill -1

[KagatoLNX]

Doesn't work for anything that changes a kernel data-structure. Only code-path changes. As a sysadmin, do you spend the time to know the difference?

Re:kill -1

[thogard]

You can't do this with systemd. A kill to a process group is an atomic operation in Posix so that if you do a kill -9 -1 (i.e. send a SIGKILL to init and all of its children), the kernel will not return from the "kill" syscall until it has sent the signal to all of the processes. That syscall will also prevent any other task switches until it is done so the result is no process (other than init) ever runs again even if they are in the middle of a forkbomb. A kill -1 -1 (send SIGHUP to everything via init's process group) has traditionally told all user level programs that the user logged out and all daemons that they should reload their config files.

Killing a process group (the negative process id, which is what the original commentator was talking about, not a SIGHUP) is used all the time on systems. That is how apachectl (and most other forking deamons and their control programs) tell its children to reload the config file or end in a controlled way. It is used every time a user logs out to make sure all their processes do go away. Signals are the oldest and more reliable of the IPC mechanisms and are great when the number of messages you need to send is a tiny number of options.

Re:kill -1

[arth1]

On my PC with an Asus mainboard the Sleep and Hibernate simply don't work (and never worked with multiple distros and kernels). I need to reboot each day therefore boot time is important for *me*.

Then the solution seems to fix sleep and hibernate, not to break servers.

Re:kill -1

[KagatoLNX]

To be fair, I know what "kill -1" is for and I've never used it on purpose. Of course, that's because "kill -1" comes from the school of "fixing" the symptoms of the problem without understanding what's actually causing it.

Re:kill -1

[mysidia]

I think the answer is to fork Redhat EL6, and not accept the choice in RH7 of moving from Upstart to SystemD. Upstart and Udev in RH6 is just great....

Re:kill -1

[mysidia]

Really? You don't reboot after a kernel security update?

One word: KernelCare

Re:kill -1

[mysidia]

Kill -1 is like an emergency "Oh Shit"; and you're going to need to do some serious manual repair efforts and probably reboot shortly after, as only things managed by an init respawn will automatically restart.

Re:kill -1

[mysidia]

Hint: one of them terminates init. The other restarts it. A highly consequential distinction.

It's not possible for a user process to kill -9 on init. The kernel will pass only SIGHUP or SIGINT. "kill -9 -1" effectively kills all processes except init. Traditionally.... init would then respawn all processes in the init tab marked as respawn for the current runlevel, so it would bring the local VTY gettys back online, but not daemons such as inetd and SSHD which are started through scripts that do not have respawn lines in the inittab

Personally; I always thought this was quaint... this is one of the reasons why I like Solaris SMF --- the possibility of automatic self-healing applies to ALL services, not just the gettys.

Re:kill -1

[Lotana]

Linux's primary market share is on servers. Thus the distributions should focus on server usage first and desktop users second. There are hardly any of the later when compared with a former.

If you want to run Linux on a desktop, you should jump through extra hoops to install systemd on your machine, because you are a minority. In practice, there should be different distribution based on the server and desktop.

Alas this will cause more fragmentation, but as we spoke about this before, some people do not see this as a problem.

Re:kill -1

[bigfinger76]

I thought that was Unity.

Re:kill -1

[Kabukiwookie]

So how many servers are running OSX?

Do what the hell you want on your desktop, as long as it doesn't interfere with how I run my server farm.

Re:kill -1

[Jeeeb]

CentOS 7 (so presumably RH7 and other RH clones) has a service command which just redirects to Systemd - exactly what you want. Chkconfig is also half turned into a Systemd wrapper. I recently set up a CentOS 7 gateway/DNS server/firewall/MTA. I think I had to type one or two Systemd commands to enable services. It was very easy and I don't think I even had to look at the man pages. Just started from the chkconfig output. No binary logs either. All the text logs I needed were in /var/log as always.

Re:kill -1

[arth1]

I think the answer is to fork Redhat EL6, and not accept the choice in RH7 of moving from Upstart to SystemD. Upstart and Udev in RH6 is just great....

Indeed. Iffen ain't broke, don't "fix" it. Or, in this case, don't outright break it.

The best hope I see for a viable long-term supported Enterprise Linux now is a ScientificLinux spin, with eudev and continued hal support. CentOS has become a Red Hat subsidiary, and will toe the party line.

I was saddened to see CERN leave SL for CentOS, and wonder what lubed that decision. I hope Fermilab keeps up the dedication and support, also for spins, and don't get tempted by tall sandwiches.

Re:kill -1

[Kabukiwookie]

Really? You don't reboot after a kernel security update?

I do believe that the comment also include "and in scheduled windows".

I entirely agree that boot time is a non-issue

Though that seems to be the primary selling point of systemd. It's the first or almost the first issue that is brought up by systemd proponents.

In sysvinit, the /etc/rc.d directories are full of symlinks to /etc/init.d scripts, with "magic" prefixes to control priority.

You do realise that the order of execution is the alphabetical order in which these links appear in the directory. Nothing 'magic' about it, just using default behaviour that's already inherent in the OS. Simple.

And the systemd scripts are simpler. In sysvinit, every single script reinvents the wheel by including a big bunch of the same boilerplate.

OMG, the horror of having a few kB at most copied into different scripts, it's unbelievable.

Re:kill -1

[Kabukiwookie]

I've been in unix for over 20 years and never even heard of kill -1.

That's very honest of you. Don't know what you've been doing in Unix, but not knowing how to issue a SIGHUP signal (or why) after working with Unix for 20 years is not particularly a recommendation.

Probably best not to mention that on any future interviews.

Re:kill -1

[MrKaos]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

Really. I've always used it to force a re-read of inittab, however I've never found it would kill processes. A lot of commands (like ssh for example) support kill -1 and I've always found it really handy.

Re:kill -1

[epyT-R]

He's talking about a server oriented distro. Users shouldn't run RHEL and expect a smooth desktop experience.

Re:kill -1

[epyT-R]

mmm.. nope. The days of full ram checks during POST on typical consumer machines are long gone.. Today's 'check' takes a few seconds at most.

Re:kill -1

[WorBlux]

The way systemD works actually has some advantages for servers. Speed for one. Anyways the worst thing they did was merge udev into systemD rather than leaving the possibility for a stand-alon udev to other init systems actually work properly.

Re:kill -1

[epyT-R]

Or, there's just more people using ad hominem attacks, appeals to emotion, and other fallacies as arguments, instead of rationality. Unfortunately, this disease is society-wide and getting worse.

Take a hint. Calling someone a 'hater' doesn't make an argument for or against anything. It is the ultimate dubious complaint.

Re:kill -1

[bjwest]

Hit the button, grab coffee, work.

More like hit the button, go to get coffee and get new mail notification before I get two steps away. My system gets put to sleep, not powered down at night, and it's up and ready for me within five seconds. The only time I reboot is for a kernel update.

Current uptime on my desktop: 23 days 4 minutes and 42 seconds.

Re:kill -1

[dbIII]

Current uptime on my desktop: 23 days 4 minutes and 42 seconds

I do not understand - that wouldn't even be a boast on Windows95 let alone something designed for stability.

Re:kill -1

[bjwest]

Current uptime on my desktop: 23 days 4 minutes and 42 seconds

I do not understand - that wouldn't even be a boast on Windows95 let alone something designed for stability.

If I were boasting I would've fudged the uptime. I don't like lugging my UPS around, so it also gets powered down for relocation, the occasional hardware upgrade/replacement, and every now and then for a thorough clean out.

Re:kill -1

[jedidiah]

SystemD and Upstart are both more complex and easier to screw up. That right there is enough good reason to stay well enough away.

if you want to redo the plumbing under the foundation, you first need to give good reason why the foundation needs ripped up. You don't get to do random nonsense and then explain yourself later.

This is just pretty basic change control.

Re:kill -1

[davydagger]

I don't think there will *never* be the "Year of The Linux Desktop", but it won't be in the next 5 years.

GNU/Linux on the desktop is a novelty for nerds, tinkerers, and techies.

GNU/Linux on the server is the bread and butter of the internet itself. Most people who actually use and rely on linux for work, and their life do so without actually knowing it, or dirrectly interacting with the operating system.(ever use google search, you've used gnu/linux).

people who do, in fact install and maintain linux on computers, tend to be running servers, and need a stable platform, more than anything else.

All the people with loads of cash, and manhours of talented developer time, to spend on GNU/Linux and dirrectly related projects are spending their resources on making GNU/Linux servers(and even embedded), better, and more reliable.

a GNU/Linux desktop will happen when a company like Red Hat, google, intel, nVidia, or one of the other many other large corporations gets their dick stepped on for the last time, by microsoft, and they decide to hit them where it hurts, the desktop.

And its going to be a slow, painful, uphill battle full of headaches and tears. No, it *will* happen eventually, but its not on anyone's timeline.

Oh, and I'm sick of bellyaching about systemd. Its a great system, it runs well, reliable as fuck, and most of the compaints are fear mongering. People hate it because its new(GNU even, dum dum tiss), and doesn't conform to the mantra of an OS written over 40 years ago for a system with 64KB of memory.

Re:kill -1

[cold fjord]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...

There is an old saying that Unix is user friendly, it is just particular about who it chooses for friends. Maybe the two of you have been hanging around *nix for years, but how well do you really know it? Kill -1 (aka kill -HUP) is pretty handing if you are running infrastructure that other people rely upon for uninterrupted service. Just rereading a config file for updates is generally better and easier than stopping and restarting daemons*, and plenty of standard daemons expect it. It also a handy command since at times it will kill things that other variations of the kill command won't, including kill -9. It also can be a good place to start since "gentle" kills give a process an opportunity to clean up after themselves.

If you take into account all of the standard utilities of Unix and its derivatives there is an enormous amount of functionality and multiple ways to accomplish the same task. I haven't met anyone yet that was fluent in every tool and facility in standard Unixland. That is part of what I like about it - there is so much you can learn and apply, and knowing which tools can scratch particular itches. Even "obsolete" tools can be useful.

* Although there are times when stopping and restarting is a good thing too.

Re:kill -1

[Smonson78]

Well why don't you get right on that, then... Let us all know when you're done, because there are a lot of laptops that don't suspend and resume correctly on Linux.

Re:kill -1

[dbIII]

Users shouldn't run RHEL and expect a smooth desktop experience.

Considering how different gnome3 is people are running RHEL6 (or CentOS6) just to get the smooth gnome2 experience you can't get from other distros.
Don't get me wrong, it's about exercise of choice instead of criticism of gnome3 some time after it's become viable. I've got people with the same desktop layout they had way back on Fedora2 on their CentOS6 machines (after a series of hardware and software changes). I've also got people that like gnome3 on Fedora20 so I gave them that.

Re:kill -1

[CaptnZilog]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

So you've never done a 'kill -HUP' in 20 years?

Re:kill -1

[CaptnZilog]

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?

Um, you "use" kill -1 *every* time you use "crontab -e", you also "use" it (the SIGHUP signal) for a lot of other things probably, like forcing apache httpd to re-read it's config file, or any number of other similar things where you can make an app/daemon re-read it's config. And if you drop your connection to your login shell without logging out first, it gets a SIGHUP as well.

It has nothing to do with linux/unix being 'unreliable'.

Re:kill -1

[CaptnZilog]

I've been in unix for over 20 years and never even heard of kill -1.

That's very honest of you. Don't know what you've been doing in Unix, but not knowing how to issue a SIGHUP signal (or why) after working with Unix for 20 years is not particularly a recommendation.

Probably best not to mention that on any future interviews.

To be honest, I've had to explain signals (in general) and SIGHUP to a lot of newbies over the years - it's certainly not something I would expect an *experienced* sysadmin not to know though, and if I was interviewing someone for a sysadmin job who supposedly had "20 years" experience and couldn't tell me at least a few of the *myriad* ways SIGHUP is used in unix - even if not explicitly by them issuing a 'kill -HUP' or 'kill -1' command (many daemons, etc), I probably wouldn't hire them.

Re:kill -1

[Anonymous Coward]

I don't know about anyone else, but I can't trust my servers to a company that can't even proofread their own web page.

Re:kill -1

[Spazmania]

Actually, I miswrote it. I meant "kill -HUP 1", i.e. sent the HUP signal to process id #1.

Re:kill -1

[amck]

PID1 has special significance in Unix that means if it needs to be restarted, the whole system needs a reboot. Its essential functionality can (has) been written in 10-20 lines, allowing it to be carefully audited and ensure no CVEs, with other functionality subordinated.

systemd has too much functionality in pid1. it is also, in my and many peoples opinion, too highly integrated: Effectively everything has to be done "the systemd way". We have a range of init 'setups' at the moment suitable for embedded systems through servers to desktops. systemd does a "one size fits all" that locks in a design. Replacing it in the future (even eg. /usr on a separate mount, for example) requires rewriting much of the core code. We lose the one-component-does-one-thing design, allowing individual components to be replaced and new designs tested (eg. different mailservers, different bind implementations,etc).

Re:kill -1

[AmiMoJo]

I think that's two words. At least one and a half.

Re:kill -1

[postbigbang]

Oh, the persecution complex, a martyr for ostensible blindness in capitalism maybe?

Victimized recently?

Re:kill -1

[jbolden]

I agree this is the same debate we are having on Wayland. The Unix luddite crowd hears about deep structural problems for years, then finally there is a fix and then they start objecting. If something like Gentoo's OpenRC, which is much more an init version 2, had been in place a decade ago systemd might never have evolved. But the people who are objecting to systemd fundamentally just like init and that's not an acceptable option.

Re:kill -1

[jbolden]

How is systemd proprietary? And how would it be difficult to replace systemd with another full featured init system a decade or two from now if that became desirable? Your comment doesn't make sense.

There is no issue. You can object to having the init system become complex but having the init system become complex doesn't make it proprietary it makes it complex.

Similarly init systems aren't designed by different developers. They are just going to use the norms in place.

Re:kill -1

[jbolden]

There is a solution for that: containerization and virtualization. The end user for actual physical hardware should be the IT infrastructure management software not human end users. Genuine end users should't care about individual piece of hardware in 2014.

Re:kill -1

[jbolden]

Linux's primary market share is on servers.

  Actually at this point Linux's primary market share is on embedded. After that nodes for cloud computing. Then Android (approaching 10b). Then probably individual servers of the type you are thinking of.

In practice, there should be different distribution based on the server and desktop.

There are. But both the server oriented distributions like RedHat and Debian and the desktop oriented distributions like Ubuntu and Mageia are going in this direction. If it were a desktop only feature that's not the move you would expect.

Re:kill -1

[martin-boundary]

That's exactly what I want to use my computers for, too. But frankly, systemd and its devilspawn cousin pulseaudio just get in the way. But I'm not going to talk about that since others already do this well. What riles me most these days is X forwarding failures. I have a headless computer I want to do computations on and edit text documents in Emacs/LaTeX. For stupid reasons I shan't get into, I want to do this on a chromebook (I said it was stupid!).

So what, you say, just use an ssh client to log on and voila. Well, the state of ssh + terminal emulation on chromebooks (and android too!) is abysmal. They don't pass all keyboard combinations correctly, they all have issues or fail to implement everything correctly, and worst of all, there's no X forwarding to a decent X server. All I want to fracking do is type "plot" on the server and see a picture on my screen. Or type $\int f$ and see a typeset symbol. Without going through a third party "cloud" server which runs through a browser, takes ages to return data, tries to force me to use braindead keyboard combinations on their cloud "editor/IDE" wet dream which doesn't even handle the simplest regexes and knows a grand total of 2.5 syntactic highlighting modes. And without running a slow as molasses rdp/vnc style remote desktop, or screen switching constantly to a crippled Linux workstation installed on the hard drive.

Now, what has any of this to do with you? Fair question. The answer is that the sophisticated computing system we've had for 20 years is being eroded by imbeciles who think that anything old must be replaced, that new replacement software only needs to implement the tiny subset of features that the programmer actually understands, and under no circumstances can anything which said programmer is ignorant of, or fails to adequately appreciate, be important. And that's where the new stuff like chromeos, android, systemd, pulseaudio, etc is going. And people like you try to convince us that in fact this is great and as it should be, since you're tired of tweaking your systems and have given up control for peace of mind. Well it's ok to give up if you want. I'd rather you didn't attack the complainers though, because they haven't given up yet. They're the ones who just *might* do something, unlike you by your own choice. And they're the ones who, in complaining, share the old knowledge to everyone before the imbeciles wipe it all off the earth.

Re:kill -1

[jbolden]

You've heard time and time again why the foundation needs to be ripped up.

Init doesn't offer the range of services that modern daemon maintenance need nor does it offer a foundation for it. Thus modern daemons end up repeating boilerplate to add functionality that should be available in the init system to themselves. The Unix philosophy is "do one thing and do it well". Not meeting the needs of the direct users (daemons) means init no longer is "doing it well".

Re:kill -1

[rdnetto]

Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan. ... Give me an init that only does init and does it well with a KISS philosophy.

Try reading the project site, because AFAICT it meets your requirements. They've removed pretty much everything except for init, including journald and udev.

Re:kill -1

[Anonymous Coward]

Signal 1, SIGHUP is originally the hangup signal, as in the modem has disconnected. It is used by the system to stop all processes running on that TTY, and return to a login prompt for the next user to dial in (this was designed back in the days of serial terminals).

Try "kill -HUP $$" - $$ is the pid of your shell, and this command will tell your shell that you have logged out. If you are on a serial terminal or Linux console, this should return you to the login prompt. If you're in an xterm, your xterm window should close. If you are in a nested shell, you should be returned to the previous shell, as you are sending the signal to only one shell instance, where as a real hangup will send it to every process attached to the TTY.

As a daemon does not interact with the terminal from which it was started, and should not stop just because root logged out from /dev/console, signal 1 becomes free to do other things. It was thus selected as the signal the admin can use to tell the daemon to re-read it's configuration file when it has been modified. Sometimes through a small tool like telinit or apachectl, but often directly with the kill command.

SSH is a special case here, because even though it detaches from it's controlling terminal, it allocated new pseudo-terminal devices (PTY). But in this case, things are reversed, when the SSH connection is lost, sshd is the one that cases SIGHUP to be sent to the processes running on that pseudo-terminal. So in this case, sshd is the sender, where as when SIGHUP is used to re-read sshd.conf, sshd is the receiver of the signal.

Re:kill -1

[Martin Blank]

Really? You don't reboot after a kernel security update?

I do believe that the comment also include "and in scheduled windows".

I see too many Linux systems with uptimes well in excess of a year and even three years, in the belief that it's Linux so they don't have to worry about it, and no one codes exploits for Linux kernels, ignoring whatever may be on ExploitDB. In many cases, "scheduled downtime" is for when the service is restarted after patching, not for rebooting. It's far more common than it should be, even among people who have been using Linux for many years and should know better.

Re:kill -1

[Blaskowicz]

Yes I was thinking of that kill -1 variant that kills everything except init, as I didn't know of the other "kill -1" variant (and "kill -1 -1" maybe was a mistake from the OP?)

If you run a kill -9 -1 as a non-root user, it probably makes sense as a short hand to kill all that user's processes ; a bit like "rm -rf .*" or "chmod .*" might be safe when logged in as a user. Otherwise they're hilariously dangerous!
Doing it as root is nonsensical and I tried it out of morbid curiosity. It's like tales of people using the "killall" command on Solaris.

Re:kill -1

[Blaskowicz]

It's a colloquial term to begin with. I found it fitting because the computer was now useless, perfectly working but with no way to get data in or out of it. Probably funny keyboard combinations with the "SysRq" key would have worked, had they been enabled. Poor Ubuntu 1x.xx didn't like a fork bomb either.

Re:kill -1

[vilanye]

"Cloud" computers are servers.

It is amazing that people think that a distributed mainframes are something special.

A lot of the time a "cloud" service is an overpriced VPS and nothing more.

Re:kill -1

[vilanye]

new lines are free ya know.

Re:kill -1

[gweihir]

My guess is that the systemd core team just did not have the stones to have their product compete on merit. They had to pull in udev and are trying to get even more things in there to make it as hard as possible to do without their product. If they had not done that, I would have happily ignored systemd and many distros could easily offer it as an alternative only. Most of this backlash we are currently seeing is about their efforts to remove choice or at least makeit as difficult as possible to not use their thing. That is as anti-freedom as it gets and people are rightlully upset about it.

Re:kill -1

[gweihir]

Indeed. These "young savages" put in tons of features, optimze things, but forget about the core functionality that the tools were created for in the first place, because they never used it that way themselves. And that is a main reason for not replacing things that work well with just a few minor issues: It is very hard to get to the same quality level and in fact most people cannot do it. It also takes a long time. Maybe in 10 years systemd will have reached the quality-level of other init systems, but with all the other stuff being pulled in and added, it is more like 30 years or never. That is not smart, that is making all the mistakes Brooks wrote about decades ago.

Re:kill -1

[ebvwfbw]

... reboots are years between, and in scheduled windows.

Care to publish the IP of your machine?

Of course don't do that, only a fool would do that if you're not rebooting to a new kernel more often.

Have you even looked at systemd? By your comments I don't think so. I'm getting a 3 second reboot with a VM. Yes you have to learn some new stuff. Big deal. I'm a guy that used to compile Unix from tape on a vax 11/750. Learn it, it's worth it.

Re:kill -1

[jbolden]

I don't know Poettering. I just want a daemon monitoring standard now.

Re:kill -1

[jbolden]

In the case of X11 there is way too much cruft and things implemented for the wrong standards, backwards compatibility. In the case of init the cruft is scattered over hundreds of daemons all offering services. That's what's being gotten rid of.

Re:kill -1

[jbolden]

Cloud computers are not servers in the classic sense they are nodes. The entire cloud or at least huge chunks of it plays the role of a server. For example in a server storage is per machine in the cloud you have many boxes dedicated to managing storage. In a server you have tiny applications acting as message brokers like the TCP/IP stack. In a cloud you have whole machines acting as message brokers.

Re:kill -1

[Blaskowicz]

Current uptime on my desktop : "up 2 days, 4:42".
I would make it sleep (S3 mode) but when woken up my graphics card fan revs at 100%, is very loud and linux can't control the fan speed. But I could chat with the open source driver team on IRC about it. I don't remember if the proprietary driver can control the fan speed (it does, on Windows). Had to modify the graphics card BIOS to make it quiet during normal operation ; it is 100% loud at power on for a couple seconds, then becomes quiet before the PC thinks about loading an OS.

Re:kill -1

[Wolfrider]

--I would love to have Scientific Linux do something like this, it would give them more of a distinction from Centos. There have been times when SL was a "better" distro than Centos because they were faster with updates.

--Keeping upstart in SL would be a great move, IMHO.

Re:kill -1

[Wolfrider]

> Issuing "service restart" strikes most people as much more natural. That will send the signal for you.

--Actually, ' service blah restart ' does not just send a kill -1, it *shuts the service down* and restarts it with a new PID. The whole point of kill -1 is to tell a running process to reread its config without having to bounce it.

Re:kill -1

[arth1]

... reboots are years between, and in scheduled windows.

Care to publish the IP of your machine?

Of course don't do that, only a fool would do that if you're not rebooting to a new kernel more often.

Which one of my machines? And which interface?
Here's one:
172.17.24.4
fda7:60b8:3ce4:1:0:14da:e996:ffc2
172.17.25.4
fda7:60b8:3ce4:2:0:14da:e996:ffc3

Feel better now?

But anyhow, I probably should have written "... reboots are years between, or in scheduled windows."

And that said, not all machines are reachable by hackers, or useful to them. Some I have are on their own network, with no physical connection to other networks. Others are behind several layers of firewalls and have no security anyhow.

You don't put heavy duty security locks on your bathroom door, do you?

And if that wasn't enough, there are many kernel security fixes that do not apply, so a reboot isn't needed. If a server isn't running ext4, chances are that it doesn't need to be rebooted after a fix to the ext4 code. And if the fix is to a module, reinserting the new module will generally suffice.
I actually read the release notes for security fixes.

Have you even looked at systemd? By your comments I don't think so.

That you don't think was assumed, but thank you for confirming the suspicion.

Yes, I have tried systemd. I try it every day. And it still cannot do what I need the system to do, especially with its own embedded udev which prevents existing applications from working, but also because it's pure hell to configure/reconfigure, especially in an automated fashion due to the MSDOS INI files and what should be an init process overriding the superuser.
No, the mail server does not need to be shut down if I shut down the locking daemon due to replacing another server that the mail daemon doesn't even talk to. And I may want multiple servers with the same configuration but with different services started, so they can be ready for a manual switch of services. And much else that is easy with systemd or upstart, but a huge amount of work with systemd. I want to be able to do things without jumping through hoops.

Re:kill -1

[TemporalBeing]

On my work laptop, namely b/c I had to take it home for something and it would otherwise overheat in my bag:

up 10 days, 21:38, 6 users, load average: 0.33, 0.29, 0.25

On the system I actually work on:

up 71 days, 25 min, 2 users, load average: 0.00, 0.01, 0.05

I have several different systems (servers) like the above and I pretty much reboot them all at the same time when upgrades require it and I feel like rebooting the system. I probably have a few that are longer than that even.

Re:kill -1

[bdheeman]

KISS! the ArchLinux people boast of this KISS thingy a lot, but why the hell they embraced systemd is beyond scope of such a simple Unix philosophy ;)

Re:kill -1

[arth1]

Any machine in a network is useful to hackers. Just because it doesn't store and sensitive data doesn't mean that I can't use it to attack the rest of your network or use it as a bot.

In general, if you gain access to machines like this you are already on the network, which makes the first point less valuable.
And to be useful as a bot, you have to be able to reach somewhere from it. Being able to reach a dozen PCs on a subnet isn't too useful.

You can go behind the building the server is in and dig up and steal the flowers too. But the risk and value is too low to worry much about that. Would they be safer if we planted prickly hedges around them? Surely.

There's nothing magical about servers. They're not worth more than what's on them and what they can reach.

Finally someone decides to do something

[Skarjak]

That's how the free open source community works. If you don't like something, it's pointless to just spend a lot of time bitching about it (like many linux users have done about systemd). Just go out and make your own version. Everyone who's been complaining about systemd better contribute to this thing.

Re:Finally someone decides to do something

[Anonymous Coward]

Actually, that's a bad idea. They should go an support another init project that's already underway, like OpenRC. This is just protest software by a single guy.

Re:Finally someone decides to do something

[DeHackEd]

Ordinarily I would agree, but systemd's "MCP-like" behaviour (TRON reference, I honestly believe that's a valid simile) means that uselessd has a chance of being a replacement for systemd packages of existing distributions. If I can put this in place of systemd on centos7 and have it boot in an unprivileged container (currnetly impossible with stock) then that's a win in my book.

You can't just switch systemd for openrc in an existing distribution without some major resistance. Believe me, I wish it could or I would just install openrc or upstart. That's the problem - systemd is claiming distributions and the list of alternatives is unnervingly small.

Re: Finally someone decides to do something

[Anonymous Coward]

It is but the underpinnings are well proven so its a good start, pitty about the name.

Re: Finally someone decides to do something

[BarbaraHudson]

I think the name is probably going to help, not hurt.

It's in the long-standing tradition of weird/funny/pun names in *nix. Less is more, unix is kinda like multics, but with the gonads cut off", etc.

As long as nobody starts calling it "GNU/Useless" ... The whole "GNU/Linux" thing is so '90s, and it's just linux to the world.

Re:Finally someone decides to do something

[Anrego]

Not just that, but running a non-systemd system even if you use a distro that uses openrc by default is becoming more of a pain as more and more packages hook into it. As a Gentoo user who is trying to hold off for just a little while longer I've found myself doing a lot of package shuffling and using the package blacklist for the first time in the almost decade I've been a gentoo user.

Re:Finally someone decides to do something

[chihowa]

I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.

Re:Finally someone decides to do something

[phantomfive]

I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

This is understandable, but there are much, much simpler ways of achieving this goal than systemD.

One of the interesting things about systemD discussions. If you watch, people who criticize say things like, "that's an ugly hot mess of architecture!" People who support it answer by saying, "the features are so good!" You can see those two things are somewhat arguing past each other.

You captured both sides of the argument in a single post, so good job.

Re:Finally someone decides to do something

[stoploss]

You have my upmod if I had points.

This is exactly my perspective. Init has been in need of these features (like allowing true inter-daemon dependencies and not shoehorning everything into one runlevel or another).

But, yes, I'm not looking for an MCP—just an improvement on init. I wonder if this project will get any traction.

Re:Finally someone decides to do something

[Barsteward]

"Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise." - from the info i searched out only systemd appears to be the only process running on PID1 - http://0pointer.de/blog/projec... - maybe i'm reading it wrong

Re:Finally someone decides to do something

[visualight]

Tell me about it. I won't even sync anymore unless I have time to go to the forums first and make sure there wasn't a coup and systemd is now required on Gentoo.

  * Last emerge --sync was 63d 2h 4m 11s ago.

Re:Finally someone decides to do something

[visualight]

Semantics aren't enough to call that a myth, doesn't matter how often that link gets posted. It's a monolith and that's all there is to it.

Re: Finally someone decides to do something

[visualight]

Look any name is going to be better than P OS / Linux.

Re:Finally someone decides to do something

[Barsteward]

the kernel is more of a monolith so I take you are using Hurd..

Re:Finally someone decides to do something

[visualight]

That pat answer again? Apples and Oranges...

Get this into your head: The fucking kernel is the fucking kernel alright? It is one fucking thing. Yes, people refer to it as a "monolithic kernel" to contrast with a "microkernel" but , it is one fucking thing. Got it? Next time someone complains about the monolithic design of systemd and you feel the words "but the kernel..." welling up in your throat, just slap yourself until you start to remember words like "context" ok?

Re: Finally someone decides to do something

[Phil Urich]

Next year will be the year of the micro kernel, I tells ya!

Re:Finally someone decides to do something

[sjames]

That's more or less my feeling on it. Perhaps an early fork will afford the opportunity to assert a proper design on the thing and salvage a win. Some of the individual features of systemd are good in themselves and I believe most of the cons can be fixed with a proper design.

Re:Finally someone decides to do something

[linuxrocks123]

Come over to Slackware; the water's great! We got rid of that GNOME shit ages ago.

Re:Finally someone decides to do something

[Anrego]

Gnome isn't really the problem (although despite not being a gnome user and having all the various anti-gnome flags, I still end up with a few odd packages pulled in by other stuff that screw things up). It's stuff like udev and stuff that depends on it. Straight up adding it to the blacklist (along with systemd itself) helps, but it still seems like for the first time in years, I'm nervous about running updates against world for fear of shit just randomly breaking.

Re:Finally someone decides to do something

[mysidia]

Why don't we separate the configuration interface from the init system?

Patch upstart to include the ability to read in the configuration items of a Systemd system and either run these services in a compatibility mode or automatically generate its own configurations from the Systemd configurations.

Re:Finally someone decides to do something

[MrKaos]

you feel the words "but the kernel..." welling up in your throat, just slap yourself until you start to remember words like "context" ok?

Then context switch between left and right slaps.

Re:Finally someone decides to do something

[thatkid_2002]

Actually, that's a bad idea. They should go an support another init project that's already underway, like OpenRC. This is just protest software by a single guy.

Systemd is a project that is already underway. What's your point?

Re:Finally someone decides to do something

[MrKaos]

I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

I think you've summed up the sentiments of most people who have done testing of systemd vs initd. We're running parallel tests in house and systemd has got some compelling features. Unit files do prevent some of the crappy init files. The binary logging I think is a mistake, however some of the journalctl functionality is pretty good. Anyone comfortable with awk and sed though will probably see this functionality as useful only to reduce the time it takes to parse logs for what you are looking for. The loss of the last binary encoded log data is a big failure though.

On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.

systemd could be good if it was a replacement for the rc system only, which in my opinion is pretty broken. I'm still learning if OpenRC fixes this however our tests of systemd internally show it is not yet ready for production systems at all. Our installed version seems to have difficulty with some services as simple as ssh, which are restarted for no apparent reason along with the network services. With this things functioning properly on the parallel system it really highlights how far systemd has to go.

I think the good thing about systemd is it does raise focus on how broken init.d scripts can be. If systemd stopped at unit files it would probably be a resounding success.

Re: Finally someone decides to do something

[matthekc83]

It's GNU/ Uselessd/ Linux... Microsoft and Apple fans everywhere are about to have good laugh.

Re:Finally someone decides to do something

[linuxrocks123]

My only experience with Gentoo was on SPARC. "Shit randomly breaking" described that setup perfectly.

Slackware has "rolling releases" just like Gentoo, by the way. You just update against Slackware-current. Technically that's the beta tree but it's completely usable. And we do still have udev, just no systemd :)

Re:Finally someone decides to do something

[jbolden]

I agree. I think 80% of what people wanted from systemd is in OpenRC with 0% of the risk. Had init changed some to add most of the functionality people want in systemd, systemd wouldn't have evolved. But it did and now we should be dealing with the world as it exists.

If someone wants something that is equally problematic today were individual solutions are evolving, we need a networking stack that has a better understanding of latency. Now is the time for the old school Unix guys to be fixing that, before the pot boils over.

The architecture doesn't matter too much. Systemd itself will be easily replaceable. For example FreeBSD is porting Apple's launchd over (openlaunchd). Given that systemd is based on launchd and that the FreeBSD people are going to want to run Gnome... I suspect that by 2020 or so openlaunchd would be an alternative, and likely one without the architectural issues.

Re:Err...

[fisted]

Wait for jessie

launchd

[Anonymous Coward]

Why is there so much effort going into this broken ass system when Apple made launchd available open source long ago.

Re:launchd

[ThePhilips]

Where's the fun in using something that just works?!

Re:launchd

[Carewolf]

Where's the fun in using something that just works?!

It is Apple we talking about, specifically Mac, where everything "Just Doesn't Work(tm)".

That would be useless in an OS like Linux that is mostly used to get things done.

Re:launchd

[ThePhilips]

Adding support for another file format is really a trivial task.

Re: launchd

[Anonymous Coward]

When apple released launchd it was under the apple public license which is incompatible with the GPL and annoying for BSD use. It's not like newer projects that use apache 2 license. Further it has a lot of Mach hooks and is annoying to port. I played around with it for MidnightBSD

Re:launchd

[iggymanz]

it doesn't "just work", the plist configuration is needlessly complex

Re:launchd

[Sri Ramkrishna]

systemd is designed to use specific features of the linux kernel. That's why kernel developers as a group aren't up and arms about it. Sure you might get some occasional people like Ted Tso upset, but in general systemd exposes kernel features that a lot of people have worked hard on. Things like cgroups are using copiously in systemd.

Re:launchd

[smash]

Plenty of people use OS X to "get things done". About all people "get done" in a satisfactory manner using Linux is network administration.

Re:launchd

[smash]

Much better to use XML and thus have the files readable with any XML parser, than design yet another configuration file format that needs yet another configuration file parser to be written.

Re:launchd

[Endymion]

systemd is designed to replace APIs based on {static or dynamic} linking with the dbus/kdbus IPC mechanism, as a way to use (L)GPL libraries without being bound by the (L)GPL.

Note that despite uselessd's much saner approach to technical features, the exposed dbus API is still requried. Switching to the uselessd implementation still enables this new type of "tivoizaiton".

Re:launchd

[Carewolf]

Plenty of people use OS X to "get things done". About all people "get done" in a satisfactory manner using Linux is network administration.

And software development. Though it works acceptable on Macs too (compared to Windows development), though only when developing for Apple products naturally. Problem is still that productivity on Macs is lower because the OS keep getting in your way, and there is no way of making it stop, because giving power features to power users is not the Apple way.

Re:launchd

[iggymanz]

no, not when the file is for human admin, writing a file parser for a simple file format is trivial, not a valid objection.

Re:launchd

[visualight]

--*I*-- use cgroups copiously and will not use systemd, so, not really plus for systemd...maybe a "not minus".

Re:launchd

[t_hunger]

Oh, come on... *ALL* init systems do IPC. That might just be a simple pipe somewhere, but that is still IPC. How do you think telinit works?

Re:launchd

[gbjbaanb]

which works fine, until someone changes them in the kernel requiring systemd to be updated to use it. Strange how Linus thinks an ABI for drivers is a very bad thing but its ok for systemd to directly call many kernel features.

Re:launchd

[iggymanz]

we actually have a mac server, launchd doesn't always launch the 3fd party stuff (like nagios client for example) for whatever reason. I'd take init for it any day of the week

Re:launchd

[Sri Ramkrishna]

What's strange about it? Driverse and systemd run in two different contexts. systemd has no need to access the hardware at all. So having different rules for them shouldn't be out of the ordinary.

Re:launchd

[Sri Ramkrishna]

Why not?

Re:launchd

[Endymion]

I'm not talking about *init systems* - systemd was never "just an init system". Remember, it's absorbed stuff like network management and system authentication. That kind of feature often requries linking to (L)GPL code, and you can trigger the GPL's requirements depending on how you do that.

So Poettering wants to move all those function calls to (k)dbus. In his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

Re:launchd

[prsephton]

Ted Tso is not an "occasional person" by any stretch of the imagination. He has contributed hugely to the Linux development effort and is well respected for his technological prowess as well as his opinion. Look him up for his involvement since the early 90's in projects such as e2fs, /dev/random, and more recently the C++ ABI specification.

Re:launchd

[Patman64]

Problem is still that productivity on Macs is lower because the OS keep getting in your way, and there is no way of making it stop, because giving power features to power users is not the Apple way.

This may shock you, but OS X ships with this app called Terminal. It's just like a shell on Linux. I'm guessing you haven't actually used OS X though.

I know Slashdotters have to reflexively shit on Apple, but I don't see how an OS that gives you bash, root access, and vim/emacs is "getting in your way" in terms of developing software. Every IDE that supports Linux supports OS X. You can even install BSD packages with MacPorts. What more do you want?

Re:launchd

[Unknown Lamer]

Not content to reinvent jack and init poorly, Poettering has decided to reinvent microkernels poorly as well. We're doomed.

Re:launchd

[iggymanz]

it's a lot more than just nagios, and it's a frequent lament in osx forums about launchd's flakiness

Re:launchd

[iggymanz]

You are very funny, your big iron Unix admins that are handling your money, insurance, etc. are using init, not launchd which is used by Apple Lifestyle Hipsters(tm). Serious computing is obviously not your forte, but don't worry there are plenty of managers and executives that think because they understand some things about consumer grade crap systems they know about real computer operation. You could join their esteemed ranks, or maybe even be a systemd developer

Re:launchd

[Sri Ramkrishna]

Yes, I know who Ted Tso is. I've met and argued with him plenty of times. He's conservative when it comes to operating systems and doesn't accept change that rapidly and tends to prefer an evolutionary path when it comes to system components. Systemd is radical to his tastes. He also customizes his operating system quite a bit as though some of the other kernel developers I know.

There are still better ways

[thogard]

Over the past 3 decades, versions of the inittab syntax allowed for things in the 2nd and 3rd fields to say things could be run in the background or depend on other named states which is why the 1st field is a name.

It is amazing how many properly run systems can cope with a "kill -1 -1" to reset everything without a reboot.

Re:There are still better ways

[Barsteward]

"It is amazing how many properly run systems can cope with a "kill -1 -1" to reset everything without a reboot."

out of interest, just how many properly run systems need "kill -1 -1" and how often?

Err...

[Anonymous Coward]

If you use a stable version, eventually you will have systemd if you ever upgrade.

If you use sid/unstable, it looks depressingly like sometime down the road you'll have it, unless you go out of your way to avoid it.

My sid/unstable doesn't have it yet, but I'm exploring options for leaving Debian since its developers for the most part seem to be pushing systemd.

OpenBSD's "systembsd"

[Anonymous Coward]

The OpenBSD project, in my view, has a much better way of approaching this: don't replace init at all, just create independent lightweight daemons for compatibility with the various systemd "services" (hostnamed, localed, timedated, et. al.) and make them dependencies of the relevant packages instead of putting it in the base system.

Why not support a current project instead?

[devphaeton]

All the contenders that didn't 'make the cut*' for the likes of Debian and recent converts to SystemD, namely Upstart and OpenRC... Why reinvent the wheel when the work is already half done?

Either way, I wish the project well. Though the name "Use Less D" or "Useless D" could have been better.

*I still don't see how SystemD is more ready for primetime than anything else (or sheesh, even sysvinit) but we've discussed that here already.

Re:Why not support a current project instead?

[ChunderDownunder]

It needs a hyphen if use-less, rather than useless is intended.

With a name like "use-less-d"

[ALeader71]

Should we take this seriously? The name is "use-less-daemon." Thoughts?

Re:With a name like "use-less-d"

[fisted]

Ehm. Yes?

Re:With a name like "use-less-d"

[fidelleon]

I thought it would be serious until I visited uselessd' site (http://uselessd.darknedgy.net) and saw such gem: "This has meant eradicating plenty of GNUisms" and GNUisms being a link to... USA's Communist Party (no, seriously: http://www.cpusa.org/).

Re:With a name like "use-less-d"

[KermodeBear]

When I saw the headline I honestly did think that this project was someone creating a mockery of systemd, called "useless-d", which was built to take systemd's ideals to some kind of absurd extreme.

Now that I know useless-d is a real software project I'm inclined to give it even less attention. If the developers cannot be bothered to take their own software seriously, why should I? There is a space for tongue-in-cheek names, cute names, and all the rest, but this one is just plain bad.

Re:With a name like "use-less-d"

[Sri Ramkrishna]

Great, he has a political agenda well. So he basically things GNU is just a bunch of hippies. Why is he in Free Software/Open Source?

Re:With a name like "use-less-d"

[Anonymous Coward]

No.

Re:With a name like "use-less-d"

[king neckbeard]

To me, it seems more like Google's BoringSSL. It's an unflattering name intended to brutally strike a philosophy of small, simple code. Use of self-deprecating humor doesn't imply that they aren't serious about the code itself.

Re:With a name like "use-less-d"

[Anonymous Coward]

It has been my experience over several decades that "serious", "business-like" software is very often crap. Often overpriced crap, but crap at any price.

It does not matter when open source is even more crap. Unfinished projects, lacking developer resources, bad performance, missing features, severe bugs, poor documentation, unprofessionalism, terrible quality assurance, projects that are just suddenly abandoned...

Re:With a name like "use-less-d"

[dbIII]

It's tempting to think of termites destroying from within, but since systemd is more annoying and just not having reached it's potential yet than evil I suppose it's just someone with a wide range of views that don't actually impact on the project.
We already had weirdness like the editor of the "jargon file" using it as a platform to call a journalist an anti-semite, so we should just file it under an irrelevant character flaw of the author and use their stuff or not on it's merits.

Re:With a name like "use-less-d"

[shutdown -p now]

There are plenty of libertarians in the F/OSS movement who don't like GNU and Stallman's personal politics.

Re:Err...

[ThePhilips]

At least they have switch the default desktop to the XFCE.

Re:uClibc removal hardly makes sense

[luca]

Ok, so the ARM is about to be poised to take over lots of systems (cell phones, etc), and you rip out (to save space) a portable embedded tiny clibrary?

In fact the article says that uselessd adds support for compiling it under musl and uClibc

Not a boycott but a confirmation

[caseih]

Phoronix take on this is hilarious. A "boycott of systemd" led to the development of uselessd? Rather it looks to me like the uselessd developers saw that systemd had some very good ideas, and they wanted to have that, minus some parts they didn't like, on systems that aren't glibc, and aren't linux. This is part evolution, part competition. Either way it enhances Lenardts' position all along, that traditional script-based system v init is horribly broken. For even uselessd now supports socket activation (systemd's main feature) and process supervision, the latter being sorely lacking from sys v init for many years.

In any event, this is all great news. If anything it paves the way to support modern operating system features on non-linux systems, and non-gnu systems. Part of what's required to finally port modern GUI systems like Gnome 3 to other platforms.

Re:Not a boycott but a confirmation

[dskoll]

systemd does have some very good ideas when it comes to the init system. Socket-based activation and process supervision are Very Good Things.

But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc. then systemd jumped the shark.

Re:Not a boycott but a confirmation

[Sri Ramkrishna]

You just need the dbus interfaces implemented. You don't actually need systemd. The dependency is a soft one not a hard one.

Re:Not a boycott but a confirmation

[Barsteward]

"But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc." - how are they doing that? you still get all those with systemd - http://www.freedesktop.org/sof...

or am i missing something

Re:Not a boycott but a confirmation

[Anonymous Coward]

then use windows

Re:Not a boycott but a confirmation

[Endymion]

That's the whole point of all of this mess: {,k}dbus

Neither an init system nor vertical integration are the goal. The one consistent thing in all of the "systemd mess" is to leave the actual implementation officially a moving target where the trditional .so based library APIs are either hidden and undocumented or they are left out entirely. This forces you to use an IPC mechanism (dbus/kdbus) instead of simply linking to the functions you need and calling them directly. Forcing data to be serialized/unserialized so it can be sent over IPC is not nearly as efficient as calling a dynamically loaded local function. The systemd people love fast thing ("boot time!", etc), so why would they require this slow IPC everywhere?

*** if you never need to link to a library to use it, you can "link" to and distribute GPL code without being bound by the GPL. Poettering's cabal and systemd is an attempt to enable a new form of "tivoization" ***

If you are technically only "using" a library (no linking, no modifications to the library), you have not "infected" your proprietary code with the GPL. It's slower, but computers got fast enough that it doesn't really matter.

The nasty part is that by forcing arbitrary incompatable interface with systemd, to run stuff like GNOME you have to provide the key dbus features even if you don't use systemd. The end-run around the GPL still works with uselessd or any other "systemd replacement".

Unfortunatley, Lennart's cabal has everybody discussing technical features so this obvious goal isn't even addressed.

Re:Not a boycott but a confirmation

[Sri Ramkrishna]

The problem with your analysis is that we're talking about system level code which is all GPL'd. You might be right if we were talking about applications that were linking to some libraries and using dbus or kdbus that way. But that's not what is going on here. There is no end run around the license since the pieces that systemd is connecting to are all GPL'd. Even GNOME which is part of the GNU project is also using licenses that are consistent with its mission.

I don't understand what you mean by 'arbitrary incompatible interface' in regards to GNOME. There is nothing incompatible, it's just a interface to logind that GNOME needs.

You realize that you can probably use the same argument to things to such base things as 'rpc' right? Which we use all the time for NIS and NFS.

Re:Not a boycott but a confirmation

[Endymion]

You're thinking desktop. GNOME is the leverage to force the change, not the end goal.

There are a very large number of devices out there running Linux in an embedded environment. These devices often have code running right on top of the minimal bootstrap/init tools.

Re:Not a boycott but a confirmation

[Anonymous Coward]

Binary logs. If they were simply testing to see if it's a bad idea then I could give them a pass. But it's already been proven to be a bad idea via the massive heap of poo called Windows.

It's like standing on train tracks to see if it's dangerous. Others have settled that issue already.

Re:Not a boycott but a confirmation

[Sri Ramkrishna]

I still dont' see the conspiracy. As I said, rpc is doing the same thing, so does xml-rpc. I'm assuming you're saying that you can link to kernel features without a) tainting the kernel b) not corrupting your software with GPL license?

I'm not a lawyer, so I'm not sure how that plays. But if it is kdbus, you're not really doing an end run around anymore than if you were using sockets. Since it's just another socket layer. Anyways, I don't think there is some conspiracy here. Certainly, there would be some backlash if it came out that way.

Re:Not a boycott but a confirmation

[Endymion]

The traditional RPC tools don't force a chane in API for local requests - they link against the same traditional .so file that any local app would use. That is very different from forcing dbus to be the only exposed API even for local use. Apache may provide features over sockets, but apxs(1) still exists and apr.h still exposes a traditional API.

I'm not a lawyer either, but this is obviously unexplored territory for the GPL (which doesn't have a lot of court precedent regardless of the current issue.

It's not like we'll ever find some smoking gun proof. This is simply the best theory I've heard.

Re:Not a boycott but a confirmation

[phantomfive]

I'm not a lawyer either, but this is obviously unexplored territory for the GPL

The main thing it needs to fall under GPL is to be a derivative work. That's a legal term, and as you mention, a grey area.

But merely using RPCs instead of linking isn't enough to keep it from being a derivative work: I'm sure you can think of ways a product could still be a derivative work.

Re:Not a boycott but a confirmation

[Barsteward]

You should do more, some even, investigation.

"20. Myth: systemd makes it impossible to run syslog.
Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service."

Re:Not a boycott but a confirmation

[Anonymous Coward]

And then a year down the road "we (Poettering and Sievers) have decided to drop syslog support in this release because X, Y and Z."

Re:Not a boycott but a confirmation

[antientropic]

How is systemd's use of D-Bus a problem for anybody? Do you have any evidence that its use of D-Bus is causing a performance problem anywhere? D-Bus is not an appropriate IPC in every situation (e.g. if you need to send huge amounts of data), but for systemd's usage scenario (sending occasional messages between processes), it seems perfectly fine.

The claim that systemd is somehow causing "tivoization" makes no sense whatsoever. If the systemd developers feel that it's fine for proprietary code to make API calls to systemd via D-Bus, then so what? They're not forcing anybody else to use D-Bus. (Systemd is licensed under the LGPL, by the way.)

Re:Not a boycott but a confirmation

[Endymion]

That's exactly my point. I'm suggesting the goal is to avoid making a derivative work. The GPL describes various ways to recognise a project as having "derived" from covered code, and linking copyleft and proprietary code together is one of them. (with some variation depending on if we are talking GPL or LGPL).

Remember that one of Poettering's goals is, in his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

The point is if I want to do (for example) some sort of user authentication, I may have to link against libpam.so. This is something that would be reasonably commoon in embedded systems, and linking covered code into your embedded device (and having to distribute libpam.so with your product) could easily be a derivative work. (details matter, ask your lawyer about specific projecs).

Once absorbed into Poettering's project, you avoid all that risk because you don't interface with the system features directly and instead use "local RPC". This changes the project from being a potentially infringing derivative work into something that merely uses the tool. Merely using a tool that is licenced under the GPL is explicitly excempted, as the GPL only coveres redistribution and not use. ("GPL is not an EULA") This is a major change in legal status for your typical embedded device, which often wants a minimal OS to host their embedded app. They would also really like to avoid having to deal with the handling anything GPL. Changing to "local RPC" for all system interaction neatly fixes that problem.

We don't run across this pattern with traditional RPL tools, because it's bad for performance to needlessly serialize everything when you could simply call a function directly.

Re:Not a boycott but a confirmation

[Anonymous Coward]

Many GPL licenses already include an exception for linking proprietary programs to GPL libraries. I think your argument is FUD. The idea that someone would take on a project of this technical magnitude solely for legal reasons is insane. Not completely insane, but one of those cases for "extraordinary evidence". So, find some evidence, and then analyze it rationally instead of overreacting. This sort of baseless speculation is garbage.

Re:Not a boycott but a confirmation

[phantomfive]

What is good about socket-based activation? I've been trying to figure that out.

Re:Not a boycott but a confirmation

[phantomfive]

That's exactly my point. I'm suggesting the goal is to avoid making a derivative work.

I see your point, and I find it interesting. I'm not convinced that it is Poettering's goal to build an easy workaround for the GPL, but I can see how someone trying to do that would follow the path of IPC. I would be interested to see if there is more evidence on this topic.

My point is, that's not necessarily enough. Something can still be a derivative work, even if it uses IPC.

Re:Not a boycott but a confirmation

[LordLimecat]

Binary logs.

Not being a primary *nix user I dont really have a horse in this race, but it really gets tiring hearing otherwise intelligent sysadmins complain about something that in technical terms is already the case. The only difference between "binary logs" and what you have now is semantics and a thing called ASCII. There is NO REASON a binary log format could not be as well documented and supported, particularly if it were a standard across all linux distros.

Good lord, mySQL uses "binary formats" but somehow it isnt an issue parsing them. Why do you suppose that is?

Re: Not a boycott but a confirmation

[LordLimecat]

Exactly, those log files you can parse in disaster scenarios are already binary, you just have a plethora of editors that understand a particular breed of binary called ASCII. Heck, a lot of the recovery process involves manipulating binary structures-- bootloader, boot sector, partition table, etc. We just have a lot of tools to handle these scenarios, and noone pays it much mind.

Theres no reason to think the core nix toolset wouldnt come to include tools for this new format.

Re:Not a boycott but a confirmation

[dskoll]

So lets say you do run syslog, but don't want journald. Is that possible?

If not, then it means systemd forces you to run software you don't want, increasing the attack surface for no benefit.

Re:Not a boycott but a confirmation

[Quince alPillan]

I think his point is that an ASCII log is human readable with any text editor without needing an interpreter program.

Binary logs tend to be full of garbage to the average human and transferring the log file and/or running the log program aren't always feasible when you're in recovery mode.

Given that systemd is the boot up daemon for the entire system, being able to read the logs when the system won't boot properly is incredibly important.

Re: Not a boycott but a confirmation

[gweihir]

This is wrong on so many levels, it is incredible.

Re: Not a boycott but a confirmation

[LordLimecat]

Perhaps you could clarify. Was I wrong in saying that ASCII is binary? Or that bootsectors / bootloaders / partition tables are?

AFAIK even hex-based structures are fundamentally binary, but perhaps you're using a different sort of processor than the rest of us.

Re:Not a boycott but a confirmation

[LordLimecat]

I think his point is that an ASCII log is human readable with any text editor without needing an interpreter program.

And that is 100% wrong. Text files in ASCII are still binary, they just conform to a standard that uses 7 bits per character and has a character map that corresponds to written text. At the end of the day it is a stream of 1s and 0s like any other binary file. Executable code, too, is a stream of 1s and zeros that corresponds to certain glyphs, but they happen to be glyphs that are meaningful to a processor rather than to a human.

Whats crucial to really understand here is that there isnt a difference of kind here; everyone seems to be over-abstracting things to where they have some hard barrier between what makes something "binary" vs "text". The only reason we are "comfortable" with text is because there is a very wide variety of interpreters that can display ASCII in a human readable form on screen; but when you boil it down there isnt an actual qualitative difference between that and a particular record in a SQL table other than the programs that interact with that data.

Re:Not a boycott but a confirmation

[bingoUV]

Ok, so non-text binary logs are acceptable when equal or more variety of tools are available to view/manipulate them vs text binary logs.

Which is not yet, so your objection to objection to binary logs is invalid at the moment.

There is NO REASON a binary log format could not be as well documented and supported, particularly if it were a standard across all linux distros.

There is one. It is called text. Hence the objection against "binary" formats, which colloquially but imprecisely refers to "non-text binary" formats.

Re: Not a boycott but a confirmation

[gweihir]

Really, that is just one thing you get fundamentally wrong. ASCII is _not_ binary, unless you completely ignore context. If you do that, your statement becomes true, but completely meaningless. It is about as sane as claiming that "everything is quarks, so we only need to be able to deal with quarks".

Re:udev

[Rich0]

Since when did udev run as PID=1? As far as I'm aware, it doesn't under systemd.

Re:Err...

[ThePhilips]

My sid/unstable doesn't have it yet, but I'm exploring options for leaving Debian since its developers for the most part seem to be pushing systemd.

Switch to what? I want relatively up-to-date Debian based system with relatively good KDE integration.

Anyway, the way I'm using Debian at home, I do not really care what init system it has. In office, systemd and the rest of the RedHat/GNOME aberrations are simply not applicable and not employed.

Re:Err...

[Anonymous Coward]

Errr... the default desktop is still not decided as far as I can tell from the Default Desktop Qualification process.

(Please remember, making XFCE the default was just a test..... a test that based on the preconditions stated before this change has shown that XFCE as default has failed.) /Debian Developer and contributor to one of the desktop options.

Re:udev

[caseih]

FUD again. The udev module of systemd does not run under PID=1! Please take a look at how systemd is organized before you post something like this.

$ ps axf | grep systemd | grep -v grep
    1 ? Ss 0:47 /usr/lib/systemd/systemd --system --deserialize 16
  247 ? Ss 2:48 /usr/lib/systemd/systemd-journald
  603 ? Ss 2:20 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
19211 ? Ss 0:00 /usr/lib/systemd/systemd-udevd
19260 ? Ss 0:18 /usr/lib/systemd/systemd-logind

systemd encompasses many things that used to be separate, but that doesn't mean they all run in the same process. Functionality is still kept modular, and you can update systemd without requiring a reboot most of the time. systemctl --daemon-reexec will reload the updated modules.

I'm not a fan of *ctl commands (hard to type, they don't roll off the fingers), but they are okay.

Re:Err...

[Anonymous Coward]

I use Windows at home, I don't care what OS as long as it works. That's what your statement sounds like. It's not "wrong", but in the context of using OpenSource, it's like selling your soul.

They need to take SystemD and break it into a bunch of smaller processes instead of a monolithic design that is more prone to failure for something like init. init is an extremely simple concept, but they decided to just merge everything together. Why not just put your kernel and all of your programs all into SystemD? Because it's better to keep certain things separate.

There is nothing wrong with what they're doing, it's how they're doing it. Compartmentalize and separate unrelated features, so if one fails, it doesn't take down the entire system. As it stands, an unhandled exception in something as stupid as your timezone changing could crash your entire computer. Sounds freaking great.

Re:udev

[Anonymous Coward]

tip: ps axf | grep [s]ystemd

Pretend it's "Use Less"

[tepples]

If systemd has too much code, you need to use less code. Use less. Uselessd.

Re:Err...

[Barsteward]

go and read this first http://0pointer.de/blog/projec..., there is a section on monolithic design

Re:udev

[Anonymous Coward]

tip: you want to put that in quotes

What a fitting name!

[t_hunger]

This project is indeed useless:-)

First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.

It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.

Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.

Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.

Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.

Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).

Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.

It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.

Re:What a fitting name!

[efitton]

Most users could care less about running GNOME. We will see if Cinnamon, Mate and KDE make SystemD a hard requirement.

I know I do not have enough knowledge to critique SystemD, SysV or UselessD. That said, I want text logging to disk with no configuration. If I need to learn new commands to read the logs, I'm just not going to do it. At most I will have one Linux box running at home. Pushing 40 with a kid and another on the way configuring my computer has become a hassle and a headache that I don't need. Was there a time when I compiled kernels for fun? Yup, but that ship said over a decade ago. The few times I've needed the logs it is simple just to less or vi and just read the thing. Hopefully Mint will default to giving me my text files. I'm actually about to install Linux again after a multiyear break related entirely to desktop unusability.

Re:What a fitting name!

[Sri Ramkrishna]

If BSD is working on something to replace, where will these people who love init so move to? I suppose the whole "portable" thing is completely blown out of the water.

Re:What a fitting name!

[kthreadd]

We have quite a lot of GNU/Linux workstations where I am. I would say most, at least 95+ % of all users, from newcomers to experts, run GNOME 3. I occasionally find someone using Xfce or even Fvwm, but most people seam to be just fine with GNOME.

Re:What a fitting name!

[Barsteward]

See Myth 20 at http://0pointer.de/blog/projec...

Re:What a fitting name!

[Kremmy]

I must say, I see something like 'portable to other compilers but gcc', and it gets me thinking.
What are those guys smoking? The systemd guys. The GNOME guys.
If I'm a GNOME on Linux user, I'm essentially being forced to migrate to a new operating system to keep using GNOME.
systemd doesn't support other libcs. systemd requires gcc extensions.
Linux, a fine OS kernel which is supported by a wide variety of userland options, and it looks like we're trying to homogenize everything to a degree which is frankly the opposite of what makes Linux itself an amazing piece of work. Things are becoming inextricably linked to components they previously may have INTERACTED with but did not RELY on. The alternatives are being pushed aside by the very depth and breadth with which these newer projects are gobbling up system responsibility.
These issues lie at such a basic level that it's poisoning the entire ecosystem.

Re:What a fitting name!

[phantomfive]

So this does *not* ship the things that are needed to run Gnome

I think that's a feature

especially since much of the journald code still needs to stick around:

Well that right there shows that systemD is not modular and flexible

Re:What a fitting name!

[phantomfive]

FWIW the Linux kernel also requires gcc extensions

Re:What a fitting name!

[t_hunger]

So this does *not* ship the things that are needed to run Gnome

I think that's a feature

It is a feature to some, a misfeature for others. It definitely does not make this uselessd a viable alternative to systemd for mainstream distros.

especially since much of the journald code still needs to stick around:

Well that right there shows that systemD is not modular and flexible

Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others. That way you can have different implementations. In this case: Push logs to /dev/null, use journald or push it to syslog. Actually it is exactly what makes this flexible and modular.

Re:What a fitting name!

[phantomfive]

Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others.

If that interface isn't easily replaceable, you have a problem.

Re:What a fitting name!

[visualight]

"Myth: systemd makes it impossible to run syslog"

Stupid. NO ONE was saying that so what's the point of debunking this non-existent myth? Journald is a bad idea and that's not a myth it's a FACT.

Re:What a fitting name!

[t_hunger]

1. Many people do not like gnome; plus, how do you prove "soon any other desktop environment" is going to jump through the hoops thrown by systemd developers?

KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.

Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.

2. Not all people, who happen to like some of systemd's features, need to agree with everything provided with systemd. Systemd-style process supervision -- okay perhaps; logind/journald/networkd -- why the hell?

You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.

Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.

3. Removal of journald removes some nic(h?)e features, but also brings about merits, for example reduction of log corruption, which might happen to be one reason people fond of some systemd features feel unsatisfied with systemd. Yes, you have counterarguments, but I have as well; you'd better get a degree in hypnosis before assuming all people will agree with you. And btw, systemd developers seem to like saying something like "don't like it? then make your own", which does not seem suitable now ;)

I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.

4. OpenBSD develops system-bsd to mimic systemd interface because of increased hooking of FOSS into systemd (and not necessarily because systemd is good ;). BTW, why do FreeBSD's choice need to be exclusive? Does porting launchd affects the plausiblity of contributing to uselessd? Yes, manpower maybe, and it seems really nice of you to care about FreeBSD's human resources instead of themselves ;D

No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.

5. So now it's about the portability vs. exclusive feature issue? I'm not sure, either, but maybe in a different sense 8)

I do not get what you are going at with this point.

6. So glibc is also the dominant libc on routers and a lot of other "niche" platforms?

Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.

7. Again, please earn your degree in hypnosis before you use "we" instead of "I", really ^_^

I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.

Re:What a fitting name!

[Barsteward]

that's just a matter of opinion as usual.

Re:What a fitting name!

[t_hunger]

Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.

Once clang builds the kernel it will most likely also build systemd:-)

Re:What a fitting name!

[t_hunger]

If that interface isn't easily replaceable, you have a problem.

Why should it be replaceable? It is internal. You are fine as long as you can attach everything you need as some kind of backend to that interface.

Re:What a fitting name!

[phantomfive]

Hey, I'm going based on what you said lol: "much of the journald code still needs to stick around." If it needs to stick around, that's not easily replaceable lol

Re:What a fitting name!

[efitton]

The students I have seen using Linux are mostly running Cinnamon or KDE. One loves Unity. None are on GNOME. Not a random sample but apparently Cinnamon and KDE are the clear winners in their tech classes at a Career Center (pulls students for part of the day from around the area).

Apparently it depends a great deal on where you are at. Would be interesting if LinuxCounter or something ran a survey as we know how worthless internet polls are. A random sampling from lwn.net or LinuxCounter would carry a lot more weight but probably never happen.

Re:What a fitting name!

[efitton]

There is a huge difference between allowed and done by default. The it is only a line or two in the configuration file isn't exactly what I am looking for, I just want it to work. Maybe I'm just at an odd spot where I am technical enough to read the logs and get an idea of what is going on if things break and yet not having the desire to google the configuration and setting it up. Yes I _can_ do it, but I just want to be a user and have my computer work. I suppose that truly nontechnical people wouldn't know about the logs and couldn't use them anyway, and truly technical people just edit the configuration file; I might just be an outlier. That said, there is a reason text is so beautiful and so often used in Unix and Linux and I have not seen a single reason for binary logging.

Re:Err...

[ThePhilips]

Yes. No. Wait - yes. No... no. Uh....

The systemd has modular design.

But monolithic architecture.

Literally everything inside systemd is intertwined using the D-Bus.

So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

at least the rationale is good

[iggymanz]

Regardless of the particulars of this project, it's good people are waking up and realizing what a bloated feature-creeped rube goldberg contraption systemd is, a non-Unix non-Unix-way solution no serious Linux/Unix admin wants, it hinders troubleshooting and configuration. Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability.

Re:at least the rationale is good

[Barsteward]

a great load of well thought out and articulated reasons not to use "systemd" there... i'm sure it'll sway everyone to your point of view

Re:at least the rationale is good

[iggymanz]

Serious admins already have that point of view, no reason to sway. Kids who experiment and only worry about their desktop or hobby system might have another.

Re:at least the rationale is good

[Carewolf]

Regardless of the particulars of this project, it's good people are waking up and realizing what a bloated feature-creeped rube goldberg contraption systemd is, a non-Unix non-Unix-way solution no serious Linux/Unix admin wants, it hinders troubleshooting and configuration. Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability.

Actually systemd might be bloated, and new and less reliable, but it was the old init system that was rube goldberg machine, it was an ancient well tested and well unstood rube goldberg machine, but it did run a many random independent tools one after the other handing one result to the next sequentially like a rube goldberg machine. Now it is all parallel and all part of the same machine.

Re:at least the rationale is good

[visualight]

"Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability."

Exactly. There is no doubt that he's a very smart person who can code, but his ideas suck. Dependencies, political pressure, and inexperienced young windows refugees are why we are where we are now...

Re:at least the rationale is good

[Barsteward]

so anyone who agrees with your point of view is a "serious admin" and everyone else is a "kid", sounds a very considered assessment.

Re:at least the rationale is good

[Barsteward]

so trying to dilute the amount of bullshit put about a particular system by a load of posters who are just repeating shit they've read elsewhere by pointing them to places where they can get some info is "astroturfing"? i'd say most of the shit arguments against the system is "astroturfing"

Re:at least the rationale is good

[Barsteward]

if it don't suit you, don't use it. but don't "serious admins" use Unix? well, that used to be the argument

Re:at least the rationale is good

[koinu]

And don't forget to mention that systemd still does not work properly. I haven't had a single systemd-based system that would not show non-deterministic behavior.

I started on Arch where it lead to a system that could not boot sometimes and was impossible to shut down (ACPI broken, even with the 5sec power-switch trick, it just rebooted! I don't even know how the hell this was possible... the system was like possessed! the only way to power off was the switch on the ATX power supply during reboot).

The other Arch system could not mount NFS shares at boot. Race condition with network interface initialisation. Googled up some really exotic fstab flags, but systemd-based boot ignored them completely. ACPI was also broken, of course and there have been some other problems with services not starting properly.

Now on Debian (in Virtualbox), I have the problem that every 4th or 5th boot slim is starting but I cannot type anything. It looks like the keyboard is not initialized and slim is already started. At least ACPI works, so I can send Virtualbox Hotkey+H to make it shut down cleanly.

Re:at least the rationale is good

[iggymanz]

No, people who have successfully done Unix administration for over two decades on multiple flavors (SunOS/Solaris, IRIX, HP/UX, AIX, etc.) with deep knowledge of system builds, configuration, provisioning, maintenance, troubleshooting, are serious admins.

less(1) is more(1)

[Anonymous Coward]

Pfft less sucks. I'm going to fork this fork and call it usemored instead.

Hear, hear.

[gwolf]

The reason why XFCE was mentioned as a possible default desktop in Debian is the install media size — In order to ship a self-contained distribution that can give you a functional desktop in one CD, GNOME is no longer an option.

But yes, there are several active discussions on how to better achieve this. It's not that Debian has decided XFCE suits us better than GNOME.

(said with a Debian Developer hat on — No, I'm not a desktop guy, nor work in the debian-installer, but do follow the discussions)

Re:Hear, hear.

[kthreadd]

Are there any statistics on how often users actually install Debian from a CD? My guess would be that installing it from a USB stick is getting more and more common.

Re:Hear, hear.

[gwolf]

I don't have an answer for you, but can direct you to the latest thread on the topic — On August 8, a message was posted to debian-devel@lists.debian.org titled Reverting to GNOME for jessie's default desktop; the thread had 174 messages. Josselin Mouette made a specific question that goes along your question, but I'm sure you will find more.

Boycotting RHEL7's uselessd

[kolbe]

I have no idea why Redhat made so many changes in their most recent release, but it is so vast that it may as well be a completely new distro. To name a FEW:

  Anaconda RHEL installer completely redesigned
  Legacy GRUB boot loader replaced by GRUB2
  Procedure for bypassing root password prompt at boot completely different
  SysV init system and all related tools replaced by systemd
  ext4 replaced by xfs as default filesystem type
  Directories /bin, /sbin, /liband /lib64are now all under the /usrdirectory
  Network interfaces have a new naming scheme based on physical device location (e.g., eth0might become enp0s3)
  ntpdreplaced by chronydas the default network time protocol daemon
  GNOME2 replaced by GNOME3 as default desktop environment
  System registration and subscription now handled exclusively with Red Hat Subscription Management (RHSM)
  MySQL replaced by Mariadb
  tgtdreplaced by targetcli
  High Availability Add-On: RGManager removed as resource-management option (in favor of Pacemaker)
  ifconfigand routecommands are further deprecated in favor of ip
  netstatfurther deprecated in favor of ss
  System user UID range extended from 0-499 to 0-999
  locateno longer available by default; (available as mlocatepackage)
  nc(netcat) replaced by nmap-ncat

Systemd is pain to use for me and feels backwards... I find troubleshooting processes with it to be more frustrating than anything else Redhat has done in the past 20 years... Well, almost.

Re:Boycotting RHEL7's uselessd

[kthreadd]

OK, so you have to learn Systemd. But what is it that you can't do anymore? If you want ext4 then use ext4. If you want MySQL then use MySQL. If you want the old network interface names then use them, it's just a kernel parameter you pass with grub. And everything is now in /usr? Big deal. If you want GNOME 2 then sorry, things changes; we don't have GNOME 1 anymore either. Things change. New features come, old features go. That's how it is. Learn to live with it!

Re:Boycotting RHEL7's uselessd

[Barsteward]

Progress ?

Re:Boycotting RHEL7's uselessd

[kolbe]

> What can't I do anymore?

Let me see, the top 3 I cannot do anymore include:
- More than half of my companies preferred vendor applications will not run on systemd (some of which will never support it)
- Majority of in-house scripts need to be rewritten
- Kickstart now REQUIRED since they removed "Full Custom Install"

The growing list of complaints are raising flags in my company so much so that we are looking at outright dumping Redhat and we have been a dedicated Redhat Enterprise customer since 1997. RHEL7 has ZERO TCO for everyone I've spoken with... Retraining, retooling, reconfiguring and reorganizing are absurd.

Re:Boycotting RHEL7's uselessd

[kthreadd]

- More than half of my companies preferred vendor applications will not run on systemd (some of which will never support it)

Then those apps will effectively not support GNU/Linux going forward since more or less everyone is jumping on the Systemd bandwagon.

- Majority of in-house scripts need to be rewritten

I don't know about how you write scripts, but I find it amazing that a majority of them has to be rewritten. What are you guys doing really? But if this really is such a problem all I can say is that you should really look into making abstraction layers, because whatever you're doing is so low-level it's going to break no matter what changes.

The growing list of complaints are raising flags in my company so much so that we are looking at outright dumping Redhat and we have been a dedicated Redhat Enterprise customer since 1997. RHEL7 has ZERO TCO for everyone I've spoken with... Retraining, retooling, reconfiguring and reorganizing are absurd.

So, what alternative are you looking at?

Re:Boycotting RHEL7's uselessd

[kolbe]

>>So, what alternative are you looking at?

Our vendors who have explicitly stated they will not support systemd in any way (due to +Priv, DoS and bypass issues/concerns) have stated that they recommend either staying with RHEL6 & Oracle Linux 6 until it is no longer supported or switching to AIX or FreeBSD. Two of these vendors are financial software suites, one is a Point of Sale system and the other is a CRM Suite that "may support it in the future". What the other vendors plan on recommending is still TBD for them. Simply put though, many companies are more invested in their applications than any flavor of *NIX.

>>I don't know about how you write scripts, but I find it amazing that a majority of them has to be rewritten.

Have you not seen the number of changes in management, monitoring & configuration commands made within RHEL7? Seriously, it borders on being a completely new distro the way everything has been retooled. Many of our SysAdmin scripts are written in Perl & Bash with remote get for everything from deployment to monitoring and analysis (netstat? gone. ifconfig? redirected. iptables? gone. lsof? switches changed. chkconfig? redirected. So many more...).

Re:Boycotting RHEL7's uselessd

[kolbe]

A lot of what I listed was directly from the RHEL Customer Portal article and it was intended to illustrate the number of changes, but none with any particular order of importance or grief.

For my team, the grievances begin with the slurry of ctl command changes like (but not limited to the following off the top of my head):

rhn_register > subscription-manager
system-config-* > gnome-control-center (Who installs gnome on a server?!?!)
chkconfig/service/runlevel/init/shutdown/halt/inittab > systemctl
system-config-date > timedatectl
vi /var/log/ journalctl
parted > gdisk
ifconfig/network/hosts/dns/eth > nmcli
netstat > ss

Re:Boycotting RHEL7's uselessd

[kthreadd]

I'm in the process of migrating a couple of AIX 5.3 systems over to AIX 7 and is almost impressed of how little has changed between those. So by all means, if your vendors suggest that you switch to AIX I think you should do it. Would love to get my hands on some POWER8 hardware though.

Re:Boycotting RHEL7's uselessd

[kthreadd]

Arch, Debian, Fedora, OpenSUSE, RHEL, Ubuntu have all either migrated to Systemd or are in the process of switching to it. They are the big ones that most people use.

Re:Boycotting RHEL7's uselessd

[kolbe]

We dropped $2.2M on 2 half populated IBM Power 7 780's (redundant VIOS with IBM's tailored 42U cabinets) in 2012 and are running approximately 239 AIX 6+ & 7.1 LPARs for many of our Financial and Business Continuity Applications. LPAR isn't quite as advanced as VMWare, but it is getting there (no more stupid 4 lines of lpar commands for simple resource management/adjustment). Compared to what we spent on the p5 series years ago, we paid 40% less for our Power 7's. Power system prices have come down A LOT over the last 3 years though and I would professionally recommend checking them out if you need some SystemV style stability.

Anyway, we WERE hoping to move away from AIX to RHEL so we did not need to have two separate UNIX SysAdmin groups, but RHEL7 kinda threw that out the window for us sadly. Personally, I am less bemoaning of systemd than I am over the plethora of other MANDATORY changes they decided to dump on the customer all at once. It affects me and my team directly whereas the systemd thing effects my vendors and their applications.

Re:Boycotting RHEL7's uselessd

[Damouze]

I have no idea why Redhat made so many changes in their most recent release, but it is so vast that it may as well be a completely new distro. To name a FEW:

Anaconda RHEL installer completely redesigned

About time.

Legacy GRUB boot loader replaced by GRUB2

Adds a bit of complexity to it, but GRUB2 is much more versatile than old-fashioned GRUB. Besides, it's also much more mature now.

Procedure for bypassing root password prompt at boot completely different

As long as [sudo] su - still works (with any kind of password), I'm happy. It's root. You're not supposed to bypass the password prompt! But, if you really, really, want to, you could always issue init=/bin/bash at the kernel command line in grub[2]. Used to work with lilo, still works with grub[2] as well.

SysV init system and all related tools replaced by systemd

The sheer horror. Seriously, another reason NOT to use Red Shit.

ext4 replaced by xfs as default filesystem type

That, at least, is an improvement. Both ext3 and ext4 have fundamental design flaws (like kjournald (and alike) that pops up every five seconds and slows down your system to a grinding halt if you're especially unlucky because it fails to check if it's already running). XFS is a much more robust design in any case, and way, way faster to boot!

Directories /bin, /sbin, /liband /lib64are now all under the /usrdirectory

Not too sure what to think of this. On the other hand, Solaris does basically the same and has been doing that for a quite while.

Network interfaces have a new naming scheme based on physical device location (e.g., eth0might become enp0s3)

Not sure what to think of this either. On the other hand, various UNIX variants do more or less the same.

ntpdreplaced by chronydas the default network time protocol daemon

Hmm. Not familiar with that one. Is that the one that will absolutely refuse to update your time and date completely?

GNOME2 replaced by GNOME3 as default desktop environment

Arf. Gnome. Nuff said.

System registration and subscription now handled exclusively with Red Hat Subscription Management (RHSM)

I blame Oracle for that.

MySQL replaced by Mariadb

I blame Oracle for that too.

tgtdreplaced by targetcli

What a shame. Last I checked, tgtd was just about the only ISCSI target daemon that made any kind of sense. But I admit, it's been a while.

High Availability Add-On: RGManager removed as resource-management option (in favor of Pacemaker)

Just a symptom. WIth systemd as the beating heart of your system, you'll need that Pacemaker. Especially if it's in the death throes of the log corruption you are bound to get.

ifconfigand routecommands are further deprecated in favor of ip

I love the 'ip' command. It's powerful. Still, for heaven's sake, let's keep the old commands?

netstatfurther deprecated in favor of ss

Stupid decision. Netstat is at the core of many a UNIX admin's skills.

System user UID range extended from 0-499 to 0-999

Couldn't care less. As long as I can reserve 1000 for myself (pun intended).

locateno longer available by default; (available as mlocatepackage)

Hmm. Why on earth would one want to do that?

nc(netcat) replaced by nmap-ncat

Well, nmap is a powerful tool. This, for once, makes sense to me.

Systemd is pai

Re:Boycotting RHEL7's uselessd

[ArsonSmith]

at best, I'll be running rhel6 docker containers in rhel7 as a thin layer os to support our apps.

It will seen be the way of ... well ... everything anyway.

Re:Boycotting RHEL7's uselessd

[serviscope_minor]

due to +Priv, DoS and bypass issues/concerns

What are those issues?

Re:Boycotting RHEL7's uselessd

[kolbe]

That list was FROM Redhat, not a troll of any kind... just a list. Sheesh.

Re:Boycotting RHEL7's uselessd

[kolbe]

I am not a security adviser, so I cannot say for sure which ones they were referring to and the only info they gave me was a list of about 13 x US-CERN, NVD and Canonical advisories regarding the exploitation of systemd through various methods. These were not noted as "fixed" either and 4 are listed as "Medium".

launchd

[smash]

... seems to work adequately for the 70+ million OS X installs out there.

Is systemd more complex than it needs to be?

[iamacat]

Or is it complex simply because it takes complexity to do things better? Gnome is more complex than twm for example, but many people find extra functionality useful. Is traditional script-based init a good match for cell phones, watches, robotics, other new devices that Linux needs to support to remain relevant?

I fully understand that there should be server and education oriented Linux distributions where simplicity and ease of customization are more important than boot time milliseconds. Just don't think that others are doing anything wrong by catering to their own needs.

Re:Is systemd more complex than it needs to be?

[iggymanz]

what core things about init need to be done better? Parallel starting of scripts, trivial do that and so there are many parallelizing versions of init out there. Something that monitors and restarts? script can do that. aything else needed, I sure don't need my logging in a database instead of a text log file, and systemd fanboys who point out text logging from the journal possible don't seem to comprehend that's if everything is working that will happen. KISS

Re:Is systemd more complex than it needs to be?

[iamacat]

Parallel is trivial.. hehe. Not when it needs to work unattended every time. Monitoring TCP/UDP sockets and starting/stopping services and their dependencies on demand in /bin/sh - interesting! Managing messages from all smart light bulbs in your house in text files? Go and try it.

Re:Is systemd more complex than it needs to be?

[koinu]

Is managing light bulbs something worthy to write to a system log file? Isn't an application log suitable for this? And why should any application want to spam log files in high volumes?

Give me an example why you need a DB format for logs when you have trouble booting the system and most of the system actually does not work and you try to find the cause with tail/cat (whatever there is left that might still be executable). If your system log is high-troughput ... your system is broken. It should contain all necessary messages to understand in which state a system is (or was, when it is not coming up), give understandable warnings and to be easy to grep and compare with previous states the system had.

Re:Is systemd more complex than it needs to be?

[iamacat]

You don't debug devices like watches and lightbulbs by connecting a keyboard and booting them to single user mode. You mount them as a drive, or they replicate logs over network.

Re:Is systemd more complex than it needs to be?

[dshadowwolf]

Every Android device I have has USB debugging turned on and is set to allow ADB connections to my other machines and I can do a "logcat" or even "adb shell". This does not help when the device gets stuck somewhere in the boot process and just hangs (and I have had this happen). This also does not help when the device has decided that it is no longer going to allow USB connections. It also does not help when the device freezes and nothing is shown in "adb logcat" and an "adb shell" hangs.

The fact that I can later go in and get a copy of the log, however, does help immensely.

When I try to start a service and it does not start the reason why should be logged in the system log or the programs own log file. I should not have to use commands to communicate with the init process to find out the reason. Whats more is that the error messages I have seen when I have had to interface with systemd have been singularly unhelpful and in one case actually pointed me in the wrong direction when looking into a solution. Now this may not be different from if the data had been logged to the system log or an applications logfile, but I have seen much more helpful errors from systems using sysvinit or upstart. I have, admittedly, also seen similarly unhelpful messages from those two, but at least those messages were stored in a place and a format that would (hopefully) survive a panic or oops - and even be much more easily reconstructed if the file is damaged.

I have nothing against replicating logs over a network or other connection and I have nothing against having to go and download those logs manually over FTP, TFP or even using SCP. But by doing things like storing the logs in a database instead of as a flat-text file you ensure that my job of finding out what went wrong and working to stop that from happening again just got harder because I need yet another tool to read the logs.

Re:Is systemd more complex than it needs to be?

[dshadowwolf]

Sometimes complexity is required to make things simpler down the road.

I cannot see this being the case here. I read a bit on the net a week or so back (think it was on the 'boycott systemd' website) that actually pointed out that the existing init system is a lot more complex than such a key part of the system needs to be. An init that does nothing but start one other process and then makes sure to notify of any processes needing reparenting or reaping on a specific Unix or Network socket to whatever process is listening would be better.

Why? Because then the system would be modular and survivable - the process handling being the "orphaned process parent" could be separate from the "reaps zombie processes" part of the system. The part that handles actually starting up system services and making sure they are running will be separate from either as well.

This is a clear separation of duties, simplifies all the different parts of the code to make them easier to check for correctness and ensures that it would take something going monumentally wrong for the system to crash because something happened that tried to "kill init".

I could, probably, write the basis of this entire system myself in a month or so of concentrated coding but would first have to start with an equally long period of research and planning to make sure I knew exactly how the parts were to interact, how to make sure that the orphaned processes were properly reparented, etc...
While I could probably find the time to do this, I do not, currently, have the time to do this and there are certainly people out there with more skill at writing important system code like this than I am.

(Come to think of it... Before I spotted this post and had an unnatural urge to respond, I recall someone mentioned Solaris' SMF as being similar to my proposal. Which means that at least 3 (at least somewhat) well educated people think that this separation of duties into multiple modules is a good thing)

Re:Is systemd more complex than it needs to be?

[iggymanz]

you are silly, testing tcp and udp services from scripts is the bread and butter of anyone who customizes the popular monitoring softwares (e.g. nagios, zabbix).

parallel starts from a script, seriously you don't know how to fork and detach, and then check status of process. trivial.

try it?, been doing things like that for 25+ years

Re:Err...

[Anonymous Coward]

Yet I love XFCE4 and although I run Gentoo as a software developer who needs to freeze various C/C++ libraries in certain versions without crippling my systems update capability, I actually love XCFE4 for it's simplicity and ability to be modified.

I'd rather run XFCE4 and add a bunch of various extra toolbar plugins for a lot of eye candy. Because XFCE4 is lighter weight I don't feel bad having cpu graphs, temp sensors, mem/net/disk indicators, weather, etc all flashing away because it's still less load average than sitting idle on a Gnome3 desktop which oddly needs 6 mouse clicks to get anything to happen.

Gentoo + XFCE4 + OpenRC is how things have been for me and how things will remain.

I have many GCC/GDB versions installed, valgrind, a specific /etc/portage/package.mask which freezes various libraries I code against, yet I can still update my system and stop any changes I do not like. Since the distro is source based it works around these changes unlike a binary distribution where someone else hardcodes their C++ libs into your packages and crosses their fingers you haven't mucked with it.

I clearly used to think Gentoo was a joke in the server world purely due to it's update cycle but honestly I don't think RedHat or anyone else for that matter is really doing it better. I'm starting to think Gentoo with a manual portage overlay on a bunch of servers is what I will switch to next. CentOS isn't cutting it these days and systemd isn't coming to my servers. Not as long as my $$$$ are behind that risk.

Re:Err...

[ThePhilips]

But the kernel is monolithic, [...]

Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd.

I know that the uninitiated see the kernel as a big black box. But actually Linux very well structured and highly hierarchical.

systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking.

The question here is about the case when systemd itself "stops talking".

Some time ago that would have been theoretical question, but actually there were already such bugs in systemd where it was simply stuck because the daemons which compromise it couldn't understand with each other. This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly.

Best rationale ever

[Tough Love]

We’re opinionated and socially maladjusted dwellers who lead monotonous lives and are trying to bring some variety in our existences by seeing if we can win a Darwin Award, or at least rustle your jimmies.

I'm in.

Re:Err...

[ChunderDownunder]

Don't the "haters" regard systemd as some all-encompassing Hurd-like wannabe, except whereas Hurd runs on top of a microkernel (mach), systemd bootstraps linux? :-)

A "Hird of Unix-Replacing Daemons" might otherwise be a good description of systemd...

Re:With a name like "use-less-d"yes

[ChunderDownunder]

Well google have BoringSSL, perhaps it's a trend of stupid names for forks in seeking to discredit the upstream...

Re:Err...

[phantomfive]

That particular blog has been fairly well deconstructed in this thread.
In short, just because the author calls something a myth, doesn't mean it's actually a myth.

Timer units -- Cron as a separate concern

[moogla]

Cron has specific semantics about batch scheduling of tasks or periodic, non-overlapping tasks. It runs them in a particular execution context, and I like knowing that it logs it an very identifiable way (both through the audit log and cron logs). Syntax of a cron job file is very low on the totem pole of things I care about when it comes to batch or periodic tasks. This is not a trivial task, as you say, and it deserves a closed system, especially if it must be targeted by cross-platform products needing such a facility.

Re:Funny inability to see alternatives

[t_hunger]

I wonder if you realize that your post boils down to a longer version of this:

• for all features X removed from Systemd, to achieve X in a replacement init, you must add Systemd back again.

In other words, it appears that you've been so indoctrinated by Systemd that you can't even conceive that there are structural alternatives possible for each feature X.

Well there are, unlimited numbers of them. :P

I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.

This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.

So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.

The features provided by the init system itself or how those are implemented is irrelevant to my point.

Re:udev

[visualight]

No one thinks udev is PID 1 , but there are people who think POS is so integrated it might as well be. Calling udev PID 1 is just people trying to win an argument. Like "debunking" a bunch of "myths" no one holds while ignoring real and valid complaints. It's about WINNING for them.

Re:Err...

[visualight]

mod up please, I'm so tired of seeing that irrelevant myth blog trotted out as if it's a trump card.

Re: Err...

[gnu-sucks]

All those users that don't directly interact with init scripts might suddenly find that they need to when systemd causes things to break that used to just work.

This is a big deal to more than just admins.

Re:Err...

[Barsteward]

"Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd" - i don't see the difference

"The question here is about the case when systemd itself "stops talking"." - the question is when "init" itself stops talking

"This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly." - thats the case for all things, its all the same but different

Re:Err...

[Barsteward]

Unless someone is going to dispute his responses to the myths with good arguments and real life repeatable cases then his blog response is more valid than a bunch of whiners repeating shit without checking it out.

Re:Err...

[Barsteward]

it does trump most of the shit pumped out repeatedly - please explain what's irrelevant about his responses to the myths.

Re:Err...

[phantomfive]

Unless someone is going to dispute his responses to the myths with good arguments and real life repeatable cases then his blog response is more valid than a bunch of whiners repeating shit without checking it out.

That's not a very good argument, I might as well say, "unless he's going to write code that's not crap, he's just a whiner." Woohoo, a point that makes no sense.

For specific, easy to see problems with the blog post, start by noticing that he actually agrees with many of the points that he calls myths. You don't even need to dig deep! The following are quotes from the actual post:

Myth: systemd is difficult.
This also is entire non-sense.......systemd certainly comes with a learning curve.

Myth: systemd is a freedesktop.org project.
yes, we host our stuff at [freedesktop.org]

Myth: systemd is not UNIX.
There's certainly some truth in that.

Myth: systemd is complex.
There's certainly some truth in that.

Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to......

Useless?

[angel'o'sphere]

So, in the year 2014, long after the subversion of source control, and submissive UIs all jokes about man/woman or more/less are still so hot that a core process of a unix like system needs to be called "useless"? Erm, I typoed: uselessd ...
Lucky that I no longer have to convince managers to use 'subversion' (eeeek, what that?) but can propose git.

Excellent name because...

[ext42fs]

...the init process needs to be really minimalistic and offload everything else with a simple and well documented (better: obvious) interface. "systemd" should have been named "borgd" a long time ago and by now it has gone completely wild assimilating a lot of things it thinks a problem needs to be solved. http://boycottsystemd.org/ summarizes the issues very well.

Re:Funny inability to see alternatives

[Damouze]

You know. I could not care less about systemd, journald or wayland.

Wayland is just a piece of crap that supposedly should bring the desktop to Linux. Well, here's a reminder: the 'desktop' has been available for Unix like operating systems for the past 30 years or so. It's called X. But the developers of Wayland (or Mir) don't like X. The fact that it is a f****ng UNIX standard does not even come to mind! Instead, they decide to reinvent the wheel. Twice! But... Remote X sessions? No way José!

I have played around with systemd and journald. It's sort of fun. Until you realize it breaks the very thing that it is supposed to provide: a standardized way of booting up your system. Again, someone tried to reinvent the wheel. And now twice as well!

And why the hell do I need dbus? Come on, can't people invent an IPC mechanism that is even marginally more useful than that and at least more well-programmed and well-behaved? What do I need dbus for if all I am doing with my system is say, running sendmail?

Anyway, enough with the ranting. Uselessd is a fitting name. Even so, adopting it (or systemd) requires a change of philosophy, one that I am not willing to make. Linux (and UNIX in general) is supposed to be an open system with a intelligible interface. Hell, all init is supposed to do is run a shell script! It is not supposed to be this big binary blob that only takes up memory. Memory that I could be using for other things, like say, run sendmail...

More FUD

[antientropic]

This is just more anti-systemd FUD very light on actual facts.

First you assert that it's somehow a bad thing that systemd uses a standard, established IPC mechanism (D-Bus). Would it have been better if it had invented its own?

Then you claim that a crash of one systemd daemon "might" cause deadlocks/hangs/crashes, but you don't give any example. What daemons are intertwined in such a way that a failure of one would bring down the system? As far as I know, you can kill any systemd daemon (other than PID 1, obviously), and systemd will notice and restart it. Daemons like systemd-journald even use systemd's watchdog mechanism to ensure that they get restarted in case of a hang. In other words, systemd provides a much stronger basis for a reliable system than SysV init.

Fun fact: I just did a "kill -9 -1" to kill every process in a NixOS VM except PID 1. Systemd restarted every system service perfectly. Try that on SysV init.

Re:Err...

[Barsteward]

You missed out some relevant bits in your redaction which illustrates the problem, detractor just cherry pick and take out of context the bits they want to fit their pre-conception. So i think he did a good enough job in his blog post to dispel the myths. Most of that so called deconstruction you linked to is full of personal attacks on him and full of things that are still wrong

Myth: systemd is difficult. This also is entire non-sense..."A systemd platform is actually much simpler than traditional Linuxes" ....systemd certainly comes with a learning curve.

Myth: systemd is a freedesktop.org project. yes, we host our stuff at [freedesktop.org] - "Well, systemd is certainly hosted at fdo, but freedesktop.org is little else but a repository for code and documentation".

Myth: systemd is not UNIX. There's certainly some truth in that. "systemd's sources do not contain a single line of code originating from original UNIX. However, we derive inspiration from UNIX, and thus there's a ton of UNIX in systemd."

Myth: systemd is complex. There's certainly some truth in that. "However, systemd is certainly not more complex than prior implementations of the same components".

Myth: systemd is a feature creep. Well, systemd certainly covers more ground that it used to......"but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want".

Re:Err...

[phantomfive]

So i think he did a good enough job in his blog post to dispel the myths.

I don't.

Re:udev

[caseih]

Good idea! Thanks.

Re:Err...

[phantomfive]

I mean, just to go a little deeper, look at this example:

Myth: systemd is complex......rebuttal: systemd is certainly not more complex than prior implementations of the same components".

Do you see how that's not actually a rebuttal? All he's said is, "it's not complex." But the criticisms are that it is more complex. He hasn't said anything to address the criticisms, except that he disagrees with them!

Does it really surprise you that he disagrees? I hope not.

Re:Err...

[Anonymous Coward]

i don't see the difference

Then go read a book. "I am ignorant" is not a counter-argument.

Re:Funny inability to see alternatives

[gbjbaanb]

But the developers of X don't like X either, that's why Wayland has come about. Whether its been developed well is another matter, but X has reached its end of life. And you can still "remote desktop" with Wayland with just as much performance as X, because X nowadays sends bitmaps over the wire anyway thanks to the desktop compositors we all run now.

Another high

[drolli]

in the self-ironic naming of open source software.

Re: The useless daemon, eh?

[Rakarra]

At some point it will happen, should uselessd get any traction.
It has all the hallmarks of a school-yard taunt, and eventually distro maintainers will ask them to grow up.

HURHURHURHUR

[buckfeta2014]

I thought systemd was the useless one.

When systemd stops talking

[Anonymous Coward]

I have run into cases where the system, due to load or a busy daemon, resulted in a daemon not responding to systemd in time. This caused systemd to kill the daemon and restart it, which then had to start its task over again, which caused systemd to kill it when the daemon took too long. Basically, systemd gets impatient and will kill off busy daemons who take too long to respond or return. This makes systemd completely unsable with some daemons and means the daemon needs to be re-written or systemd needs to be removed from the position of daemon manager.

tenaciousd

[MrKaos]

Obviously we need Jack Black to come in here and write a song about the epic conflict unfolding here.

Scat throwing monkies

[ourlovecanlastforeve]

Angry computer nerds gathering up their toys and going to play by themselves in the corner because someone decided to play in a way they deemed unacceptable.

Not just for personal computers

[dbIII]

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?

Wrong question - is software and the choices of people in using it so unreliable and prone to disaster that "kill -1" is useful? The answer is yes on multi-user systems when one person's stuff hogs all resources and can neither progress or let other tasks progress, or even if you accidently set your graphics program to open a hundred huge images at once and you stop yourself doing much more than preparing for a six month wait until is sorts it all out, unless you can kill it or reboot.
It's not quite a high school level thing to consider, but it comes close, so presumably it's late at night or you've had a few drinks before posting.

Re: Funny inability to see alternatives

[t_hunger]

So the people that build the system do not care about it. *plonk*

Re:Funny inability to see alternatives

[lilrobbie]

Anyway, enough with the ranting. Uselessd is a fitting name. Even so, adopting it (or systemd) requires a change of philosophy, one that I am not willing to make. Linux (and UNIX in general) is supposed to be an open system with a intelligible interface. Hell, all init is supposed to do is run a shell script! It is not supposed to be this big binary blob that only takes up memory. Memory that I could be using for other things, like say, run sendmail...

Hehe. I had a good chuckle that "run sendmail" is in the sentences just following "Linux (and UNIX in general) is supposed to be an open system with a intelligible interface."

From the horrors that are sendmail config, it sounds like there is already some wiggle room in that philosophy :-)

Re:Err...

[Anonymous Coward]

No need to repeat. Pretty well summed up here: http://linux.slashdot.org/comments.pl?sid=5620493&cid=47812373

Let's rephrase that

[dbIII]

Let's rephrase that - I don't understand what point you are making with that number unless it's about hibernate being better than it used to be on most hardware or something else I've missed.

Re:Let's rephrase that

[TemporalBeing]

Let's rephrase that - I don't understand what point you are making with that number unless it's about hibernate being better than it used to be on most hardware or something else I've missed.

Hibernate? What's that? My computers are either powered on, or powered off entirely. They don't sleep (S3) or hibernate (S4).

Re:uClibc removal hardly makes sense

[knorthern knight]

> Ripping out udev? Have fun with you init scripts no longer knowing anything
> about device state change. Sure, might be useful if you could guarantee that
> devices don't drop in and out of a system, but that's not been true for at least five
> years now. I constantly plug and unplug my phone into my laptop (often just
> to charge the battery, but sometimes for file transfer or for music) so you're
> not capturing the desktop market either. Servers need it for hot swap. Exactly
> what benefits are gained in which market? If you can list them, then we will know.

Udev can be replaced by mdev which comes as part of busybox. See https://wiki.gentoo.org/wiki/M... and also https://wiki.gentoo.org/wiki/M... Yes, folks, automounting+autounmounting USB keys, without X running, let alone GNOME or KDE. Yes, mdev *CAN* handle device state change. It sets /proc/sys/kernel/hotplug to point to /sbin/mdev

Re:Err...

[prsephton]

That's crazy. A great many of the "Myths" in the article were never under dispute to start with.

For example:

Postulate: "Myth: it was not written in C" Rebuttal: "It was written in C. In fact ...." You: "Unless someone is going to dispute his responses to the myths..."

To which the only reasonable answer is: "No one said it wasn't written in C in the first place!" (sounds stupid, no?)

One can prove the merit of just about anything with this kind of roundabout argument.

The whole "Debunking the myths" article is one big red herring.

Systemd may be a great technological accomplishment, and may have many amazing features- and here we are using some silly "false myth" debunking article to try to prove it's technical merit. It's demeaning.

Re:Funny inability to see alternatives

[Damouze]

You noticed that huh? ;-)

systemd fails at reliability and fault-tolerance

[octogen]

My main problem with systemd is the lack of robustness in its design and implementation. It seems like an attempt at reimplementing Solaris' SMF, but poorly. Even the SMF itself could probably be called 'overengineered', however, it is certainly a more sophisticated, less monolithic design that provides a much higher level of fault-tolerance.

systemd is basically a huge pile of modules compiled into the PID 1 init process. The problem with that is, that if PID 1 dies, the system stops (e.g., kernel panic). On Solaris, a small basic init process starts the SMF master restarter (svc.startd), which is responsible for starting, stopping or restarting the other components of the SMF as well as all services managed by the SMF. If a component of the SMF fails (maybe it just dies/SEGVs, or say, you kill it, cause it hangs), the master restarter will respawn it. Even if the master restarter goes south, that small basic init process will respawn the entire SMF, and you're still up and running.

Then, let's take a look at the implementation of systemd:
static int socket_spawn(Socket *s, ExecCommand *c, pid_t *_pid) {
_cleanup_free_ char **argv = NULL;
...snip...
r = socket_arm_timer(s);
if (r < 0)
goto fail;

...snip... (function call with lots of undocumented arguments, returning r)
if (r < 0)
goto fail;

r = unit_watch_pid(UNIT(s), pid);
if (r < 0)
/* FIXME: we need to do something here */
goto fail;

*_pid = pid;
return 0;

fail: s->timer_event_source = sd_event_source_unref(s->timer_event_source);
return r;
}

Actual code from systemd-216; see full source at src/core/socket.c

Most of the systemd source code looks like this.
Virtually no comments; lots of single-letter variable names, confusingly similar names like "_pid" and "pid"; throwing 'int' return codes back up five calls, where the original caller cannot even remember what all the possible return codes might be (how about enum?); lots of arbitrary goto- and return-jumps out of the middle of somewhere; lots of break and continue, even mixed in the same loop; even substantial amounts of three-star-programming (never heard of it? google it, it's funny); etc.

Okay, I have to add, that the code of lots of the "good, old, reliable UNIX codebase" does not look a lot better (and upstart, or even the Linux kernel, are guilty of at least some of the same bad coding habits). But we have paid the price for writing code that way numerous times, and it seems we did not learn from history.

Coding like that is probably okay if you're writing a nice, little command line utility. But if systemd wants to be THE new init system, it had better look like it had been written by the inventor of reliability engineering.

Right now, the systemd source looks like it violates virtually all of the best practices for writing reliable code. Take a look at what those people who know their craft recommend - e.g., the Federal Aviation Association, European Space Agency, Lockheed Martin's avionics section, etc. - and compare that to systemd's source.

It's like a disaster waiting to happen.

Re:Funny inability to see alternatives

[koinu]

Many people (also from the BSD world) actually like Wayland, because it is actually not useless but replacing really awful X APIs. I don't know if you have ever written a program for raw X API. It is even worse than Win32 (which already is a total mess!), in my opinion. X is even more than just mess, it is bloat, full of things you will never need and uses quite old concepts that are not compatible with sane minds of today's programmers. It is a real improvement to graphical desktops on all systems. Wayland will be ported, because it is something many have waited for long time.

systemd is different. It makes a generic API unportable and provides users with functionality (mainly for desktops), but which is also totally weird and seems to workaround all the failures in software design that have been introduced a while ago. It does not solve them, it makes them even worse and more complex. The worst about it is that there are still people want to use these APIs and break portability. And for what? For something you don't even need and never expected to change.

Boycott

[jbolden]

The only major distribution that doesn't use systemd is Gentoo and that's because they have their own very interesting init replacement. There is no boycott. There are objections to a decision that's been made by some isolated individuals who object.

Re:Boycott

[jbolden]

I'm a bit iffy in calling that a major distribution, 20 years ago absolutely, today? Also they long ago lost support for most of the applications that make use of systemd (so far enterprise applications and Gnome). But OK. They going with a classic approach on this like many other things.

Re:Err...

[rdnetto]

Yes. No. Wait - yes. No... no. Uh....

The systemd has modular design.

But monolithic architecture.

Literally everything inside systemd is intertwined using the D-Bus.

So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

AFAICT, uselessd strips out everything that isn't part of init from systemd, including journald. So exactly which daemons are left that are intertwined with each other?

Quite the opposite.

[Medievalist]

Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?

Quite the opposite!

Kill -1 tells a service daemon that is handling hundreds of thousands of simultaneous connections that it needs to re-read its configuration file, without interrupting service even momentarily.

Kiddie stuff doesn't need kill -1. It's only the ultra-reliable stuff in mission-critical roles that needs it.

Suppose you, personally, have a piece of software that controls your artificial heart. Your doctor has discovered that there's a security vulnerability in the silicon, but luckily it can be remediated with a change to the software configuration, so that you don't have to get your chest cracked to fix it. He uploads the new configuration and kill -1's the running software, and it picks up the changes between one beat and the next, never causing you to, you know, die.

OK, maybe that was an unnecessarily dramatic example. A more mundane one would be adding a new web site - you enter the new A, AAA, SPF and MX records, put the new config in the httpd.conf and access.conf files, then you kill -1 the DNS and httpd servers, and none of your other customers have to have their web sites shut down while the new one is being brought up. This happens ten thousand times a day at web service providers all over the world.

A perspective

[dshadowwolf]

It does not matter what Apple does - there is tight controls on the system and code contributed to Darwin might never see life as part of the actual Mac OSX released by Apple.

The init process in Unix and Linux is a very special thing - if it ever crashes, so does the whole machine. It is the first process started by the Kernel after it finishes initializing the system and mounting the root filesystem and is the "parent" of any process that deliberately orphans it's child-processes before exiting itself. It is also in charge of "reaping" any zombie processes. With each addition to its duties the area for an error to happen increases, which increases the risk that the system will just suddenly crash.

This is a problem that people lambasted Microsoft for from the birth of Windows through it's transition to a 32 bit system and still continues to this day for an extent - that they had one piece of the system doing a lot of work and having a wide surface for errors but still critical for everything to work properly. I am loathe to praise Microsoft for anything, but I must praise them for this - they have been moving away from that and I have actually found Windows 7 to be pleasantly stable - to the point of actually being able to recover from the graphics drivers crashing and managing to recover and re-load and re-initialize the system without losing any data. They have turned things around and begun to compartmentalize things to an extremely high degree - lowering the amount of code in each component, raising the ability of their programmers to actively find and fix the bugs during development and lowering the chance that a user will actually hit one of those bugs.

That compartmentalization and modularity (of the userspace, at least) was a hallmark of the design of Unix - each piece did exactly one job and did it well - as well as being as small as possible to reduce the amount of space there was for an error to be in. Yet with this "systemd" we see Lennart Poettering leading the charge to turn that around in order to save some small fraction of time during the boot process. That he created "Pulse Audio" - which appears to have flopped severely and, at least for me, was the cause of a lot of problems (not just for me - I remember finding thousands of people finding that problems were being solved when they got rid of Pulse Audio when I first started having those problems) - seems to be lost on people.

No, one mistake does not make everything someone does wrong, but in this case sacrificing simplicity and modularity so you can "do the boot process faster" is a wonderful idea. Extending the system that does that so it subsumes some of those processes it used to start in parallel for a faster boot time is just idiocy. What's next? Am I going to find that I can send a "draw an ASCII art of a kitchen sink" command to systemd and have it take over the current TTY to do just that?

If systemd was just a system for organizing the boot process, adding some complexity to simplify much more and making sure that daemons providing services get run in parallel to boot the systems boot time... Well, I'd have absolutely no objection to it. Instead it has subsumed separate projects and forced people to fork them or recreate them if they do not want to use systemd. Further, it appears that people that don't like systemd but like Gnome will soon lose the option to run new versions of Gnome because several key components of Gnome now have a hard dependency for systemd or one of it's sub-projects. Open Source is supposed to be about choice and by forcing people to use something that they might not want to that choice is being taken away.

So, with all the sarcasm I can muster, all those systemd supporters out there and it's creator have my hearty applause for doing something that goes against one of the key tenets of the Open Source movement. Bravo! You've successfully taken away something from people that you claim to be supporting. What a show of hypocracy!

Re:systemd fails at reliability and fault-toleranc

[JustNiz]

>> Take a look at what those people who know their craft recommend - e.g., the Federal Aviation Association,

Lol. As someone who worked develping software for avionics for 8 years I can tell you that the FAA standards e.g. DO178B are bizarrely clueless, and most avionics companies have enough fingers in the pie to get any old piece of shit through FAA certification. Unfortuantely the FAA have decided to be completely reliant on the fox for advice on watching the hen house.
I've seen some bad code in my 35 years as a developer, but truly all the worst sutff was for avionics supposedly written to FAA procedures/standards.
Most of the US avionics industry is so stagnant and full of truly clueless managers and beancounters with wrongehaded priorities enforcing retarded metrics that I simply refuse to ever work in avionics again.