Fork of Systemd Leads To Lightweight Uselessd 469
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.
kill -1 (Score:5, Insightful)
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: (Score:2)
Re:kill -1 (Score:4, Insightful)
Yes, it was trivial to achieve. With sysvinit. Lots of stuff is trivial with sysvinit and overly complicated with systemd.
Re: (Score:3)
Re: (Score:3)
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
Re:kill -1 (Score:5, Interesting)
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: (Score:3, Informative)
Then you will be delighted to learn that, according to uselessd website [darknedgy.net], 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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 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: (Score:3)
Really? You don't reboot after a kernel security update?
One word: KernelCare [kernelcare.com]
Re: (Score:3)
I think that's two words. At least one and a half.
Re: (Score:3)
Re: (Score:3, Interesting)
"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
Re:kill -1 (Score:4, Informative)
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: (Score:3)
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: (Score:3)
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: (Score:3, Interesting)
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 comp
Re: (Score:3)
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 (Score:4, Insightful)
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.
Comment removed (Score:4, Interesting)
Re:kill -1 (Score:4, Interesting)
Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.
Re:kill -1 (Score:4, Interesting)
Re:kill -1 (Score:5, Interesting)
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: (Score:3)
So what, you say, just use an ssh client to log on and
Re:kill -1 (Score:4, Informative)
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: (Score:2)
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: (Score:3)
Re:kill -1 (Score:5, Informative)
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: (Score:3)
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: (Score:2)
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: (Score:2)
Yes, but in the times when i needed it, it was really helpful.
Re: (Score:3)
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 (Score:5, Informative)
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: (Score:3)
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.
Finally someone decides to do something (Score:5, Insightful)
Re:Finally someone decides to do something (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:5, Insightful)
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: (Score:3)
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: (Score:3)
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: (Score:3, Insightful)
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: (Score:3, Interesting)
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.
Pretend it's "Use Less" (Score:2)
There are still better ways (Score:2)
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: (Score:2)
out of interest, just how many properly run systems need "kill -1 -1" and how often?
Why not support a current project instead? (Score:3)
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.
With a name like "use-less-d" (Score:2)
Re: (Score:2)
Re:With a name like "use-less-d" (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Not a boycott but a confirmation (Score:4, Interesting)
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 (Score:5, Insightful)
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: (Score:3)
or am i missing something
Re:Not a boycott but a confirmation (Score:4, Informative)
"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: (Score:2)
Re:Not a boycott but a confirmation (Score:5, Interesting)
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: (Score:3)
I don't understand what you mean by 'ar
Re: (Score:3)
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
Re: (Score:3)
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 [0pointer.net], "... 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 te
What a fitting name! (Score:2, Informative)
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
Re: (Score:3, Interesting)
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.
Re: (Score:3)
Re: (Score:3)
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:-)
at least the rationale is good (Score:4, Insightful)
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: (Score:2)
Re: (Score:3)
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 (Score:5, Insightful)
"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...
Boycotting RHEL7's uselessd (Score:2)
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 /bin, /sbin, /liband /lib64are
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
Re: (Score:2)
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: (Score:3)
> 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. RHEL
Re: (Score:3)
>>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 i
launchd (Score:3, Insightful)
Re:launchd (Score:4, Informative)
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
systemd fails at reliability and fault-tolerance (Score:3)
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)
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.
A perspective (Score:3)
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: (Score:2)
Re: (Score:2)
At least they have switch the default desktop to the XFCE.
Hear, hear. (Score:3)
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: (Score:2)
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: (Score:3)
Re:Err... (Score:5, Interesting)
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.
More FUD (Score:5, Interesting)
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... (Score:4, Interesting)
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.
Re:Err... (Score:5, Informative)
In short, just because the author calls something a myth, doesn't mean it's actually a myth.
Re:Err... (Score:4, Interesting)
Re: (Score:3)
Myth: systemd is difficult. This also is entire non-sense..."A systemd platform is actually much simpler than traditional Linu
Re: (Score:3)
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: (Score:2)
Where's the fun in using something that just works?!
Re: (Score:2)
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: (Score:2)
Adding support for another file format is really a trivial task.
Re: (Score:2)
it doesn't "just work", the plist configuration is needlessly complex
Re:launchd (Score:5, Interesting)
Re:launchd (Score:4, Interesting)
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 [0pointer.net], "... 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:uClibc removal hardly makes sense (Score:4, Informative)
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
Re: (Score:2)
Since when did udev run as PID=1? As far as I'm aware, it doesn't under systemd.
Re:udev (Score:5, Informative)
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.
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.