New Group Calls For Boycotting Systemd

[sdack]

Actually, that's not all it does. Speed was never even the primary motivation behind it. In fact, socket activation solves the exact problem (manual configuration of relationships between services) that you described in your previous post. The developers explained that part more than once BTW. Of course, the decision as to whether a daemon uses static configuration or socket activation or both is up to the sysadmin and/or the authors of that specific daemon.

Sure, it seems like it does a lot and offers much, but it only boils down to faster start and shutdown times. Like a Swiss army knife is really just a nice gift to give to somebody, but it has not revolutionized the world of tools nor has it replaced all your screw drivers or kitchen knifes. Of course it is easy to believe that it could.

Nor does systemd solve what inetd has already solved. It offers a few more features than inetd and walks on the same path, but it is going into the wrong direction. The fact they decided against inetd only to reimplement it documents their confusion. Then leaving it up to others on how to use it means there is no actual strategy behind it any more. It is just "herding cats" now.

[YoungManKlaus]

I remember back in the day when Linux was designed by, developed by and (perhaps most importantly) used by... people who could form sentences that made actual sense.

and I remember back in the days when linux was designed a glorious flamefest about how he could just write a monolithic system because its so not unix style, will never succeed, and microkernels are the way to go ... I kinda feel reminded of these days when I read this thread (except there is much more trolling in between the actual arguments).

[sdack]

and I remember back in the days when linux was designed a glorious flamefest about how he could just write a monolithic system because its so not unix style, will never succeed, and microkernels are the way to go ... I kinda feel reminded of these days when I read this thread (except there is much more trolling in between the actual arguments).

As a result of the discussions back then was the kernel heavily modularized, turned into subsystems, which now do one thing and to do them good, and it also became highly configurable. Can you remember this, too?

[YoungManKlaus]

As a result of the discussions back then was the kernel heavily modularized, turned into subsystems, which now do one thing and to do them good, and it also became highly configurable. Can you remember this, too?

jop, and I can also quite clearly remember that systemd is already modular (at least thats what competent people tell me, for me personally both is an unconfigurable blackbox because I have other things on my mind ).

[RahulSundaram]

As a result of the discussions back then was the kernel heavily modularized

That was due to people sending patches. Nothing to do with micro kernels. systemd is already more modular than people seem to think it is

http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

[sdack]

jop, and I can also quite clearly remember that systemd is already modular (at least thats what competent people tell me, for me personally both is an unconfigurable blackbox because I have other things on my mind ).

My point however was that a flame fest (I personally like the expression "shit storm") can lead to something good.

Going back to inetd... it never allowed to define sequences or dependencies between the services. Now systemd claims to be aggressively parallel and at the same time opens up for a serialization of services. It makes no sense. It is not possible to do one thing aggressively without prohibiting the opposite from creeping in. Hence, it tries to do too many things at once and will end up doing none of them really well.

Sometimes one needs to go a step backward only to go forward again, or to lose something before it can be missed and its value is appreciated.

Your example with the kernel is also kind of funny, because the one thing that keeps ticking off Linus and drives him truly mad is when kernel devs break user space. He should have gone with a micro kernel ...

[jake_lesser]

First of all, I'd like to say that by reading what these fucks say, You can tell that they do not use Linux but MacBook Pros running VMWare with some nearly-extinct crappy OS with no runlevels and gasping for life on it.

1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.

Good, that's the no. 1 reason to use systemd and not anyother init system. That unix philosophy is the single largest bullshit to hold back the advancement of Software and Operating Systems. It restricts change, prevents innovation, usability and integration every since it's conception. Btw, systemd binaries are not tightly coupled, you can remove or add them and still systemd will still work plus to make an effective init system, systemd has to take into account login/session management, readahead, GPT partition discovery, container registration and hostname/locale/time management otherwise the system becomes a fragmented bullshit like SysV init and worst BSD init.

2. systemd's journal files (handled by journald) are stored in a complicated binary format2, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID-compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. No, seriously. Oh, and there's embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.

Binary format logs make them unreadable to intruders. Plaintext logs are more brittle to corruption then binary logs plus binary logs are alot easilier and faster to read then text logs. How is the libmicrohttpd worst then from OpenBSD Reyk Floater's new shitty, useless httpd (developed after OpenBSD devs couldn't maintain Nginx due to thier shitty skills) that BSD init boots up?

3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.

A repeat of the first point but anyway, it's the non-Linux asshead's problem to deal with that not Systemd or Linux's problem. Non-Linux assheads have to pay a price for not following standards and trying to fragment and divided the FLOSS community from becoming a sigle sharp spear to plunge into M$'s guts. Btw, High integration with kernel API gives the applications thier speed particularly for when Linux has features desined for that. It's not an isolationist policy, it's a encouragement policy that enforces migration to Linux for the absolute benefit of humanity.

4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency.

That's because control of device node managment is very important in initialization of services because some services require certain nodes to work and they must not clash with other devices. There no political implications, this move was excepted Linux-wide only BSD and solaris were offended because they rely on dbus to run Xorg. This move actually stops BSD and Solar from parasiting of Linux development to finance proprietary masters. BTW, nearly all of systemd is comprihensively documented.

5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl4. Besides going against all reason, it also creates complications in multi-user environments (good luck running gdb on your program's core dump if it's dumped to the journal and you don't have root access), since systemd requires root to control. It assumes that users and admins are dumb5, but more critically, the fundamentally corruptible nature of journal logs makes this a severe impediment.

systemd allows you to easily enable or disable that option. It's these BoycottSystemd fucks that are dumb. Btw type ulimit -c unlimited and run the problem from shell if you want core dumps on the filesystem but that's a waste of time. coredumpctl4 makes debugging way easier then any debugger.

6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 20106. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.

Systemd is robust and relaible. All the CVE reports of Systemd has been traced to services that use systemd to start. These services could easily be running on other OSes.

7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion8.

Distro maintainers necessitate dependecy conversion becasue packages run more smoothly and it a more intergrated fasion with systemd. GNOME dev have fully realised this potential and are hard at work exploiting it. GNOME devs also don't want to see Non-Linux such as the OS "You-Know-What" parasite of Linux development. Btw, OpenBSD has GNOME 3.10 in it's ports tree (abid not working correctly due to OpenBSD's shitty kernel) so what are these retards talking about? Are they brain dead like the developers of "You-Know-What"?

8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur9. This happens to be another example of SPOF.

That's what all inti systems do especially "you-Know-What" init. More like Windows 9 BSD.

9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much10. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc.

That's not the systemd dev's problem also, glibc is the most used libc and the best as well. Any developer who does use glibc is at best braindead. Full Stop.

10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly. One also needs to worry about a much higher multitude of code paths and behaviors in a system-critical program, including the possibility of systemd not synchronizing with the message bus queue on boot, and thus freezing. This is as opposed to a conventional init, which is deterministic and predictable in nature, mostly just execing scripts.

Sound's alot more like BSD..er I mean "You-Know-What" init which has stayed the same for more then 30 years and completely disconnected to the requirements of today.

11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.

It's the Non-Linux terrorists like these morons who are the parasites and are vehemently antimodern, anti-integration, anti-userbility, anti-choice, isolationists who reinvents the flat tire. these people are the lowest common denominator.

12. systemd doesn't even know what the fuck it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.

These BoycottSystemd fucks doesn't even know what the fuck they are talking about. They what to fracture the FLOSS community so thier proprietary masters would have a free run continue thier oppressionist activities.

[Vax456]

Good, that's the no. 1 reason to use systemd and not anyother init system. That unix philosophy is the single largest bullshit to hold back the advancement of Software and Operating Systems. It restricts change, prevents innovation, usability and integration every since it's conception. Btw, systemd binaries are not tightly coupled, you can remove or add them and still systemd will still work plus to make an effective init system, systemd has to take into account login/session management, readahead, GPT partition discovery, container registration and hostname/locale/time management otherwise the system becomes a fragmented bullshit like SysV init and worst BSD init.

Nonononono, that's a very good philosophy to live by, when you combine it with the other UNIX philosophy to have a well-defined interface. I've managed to salvage and reuse a lot of code and programs doing this.

Systemd, by its very definition, is complicated. I don't know why, but everyone seems to forget about the other UNIX rule, which is to keep it simple until you can prove that you can't. Complicated features calls for a complicated program.

Binary format logs make them unreadable to intruders. Plaintext logs are more brittle to corruption then binary logs plus binary logs are alot easilier and faster to read then text logs. How is the libmicrohttpd worst then from OpenBSD Reyk Floater's new shitty, useless httpd (developed after OpenBSD devs couldn't maintain Nginx due to thier shitty skills) that BSD init boots up?

Eh? Security through obscurity is not security.

I find systemd's binary logs to be very nice. It's hassle-free to see a service's log and parse the times they occured. However, I'm not sure where you're getting that binary logs are less brittle to corruption than plain-text. They're files that can be written to, they're both extremely brittle. At least with plain-text, if something gets overwritten, you can still see everything else because there's no format the file has to be in.

[interested]

Systemd, by its very definition, is complicated. I don't know why, but everyone seems to forget about the other UNIX rule, which is to keep it simple until you can prove that you can't. Complicated features calls for a complicated program.

If that Unix rule had any meaning, SysVinit would have been taken out and shot at dawn 20 years ago by a mob of angry Unix Purists.

Anyway, it is way simpler to understand systemd as a project than reading up upon dozens of more less obscure projects, each with each own terminology. Just the fact that SysVinit requires programming skills for even trivial jobs (executable config files, eh!) is a violation of the KISS principle. And lets face it, half of all programmers are below average.

What systemd opponents don't understand (because they haven't read the man pages), is that systemd enables powerful features with great ease. A single keyword in the service config file, enables security features from "kernel capabilities", or resource management from cgroups.

Systemd makes hard things simple to use, because it is made to solve real world problems, not be some stuffy showcase for obsolete ideas.

Seriously, I don't have any respect for people spouting nonsense about "Unix Philosophy" here on Phoronix, unless they edit their text first in "ed" - the one true editor, and post and fetch all pages with "curl". Using a web browser is clearly a strong violation of the Unix Principle; it does way too many things.

[Luke_Wolf]

lets face it, half of all programmers are below average.

What a nice abuse of statistics that denigrates, while saying nothing at all.