boycott systemd

[James C]

From the Linux Kernel Mailing List.



http://lkml.iu.edu/hypermail/linux/kern ... 01435.html

> While we are here, can we please also talk about the !cgroup situation?
> https://bugs.freedesktop.org/show_bug.cgi?id=74589
>
> A segfaulting systemd on CONFIG_CGROUPS=n is no fun.

Wow, the attitude there is amazing:

"To make this work we'd need a patch, as nobody of us tests this."

Rule #1: systemd maintainers worldview is always correct

Rule #2: In the unexpected case that you think the worldview of
systemd maintainers is incorrect, apply rule #1.

[James C]

http://lkml.iu.edu/hypermail/linux/kern ... 01715.html

Yeah, maybe it is time Linus started his own init daemon project, like
that other thing, git, he did start a while ago. We can put it in
tools/. I'm sure it can get off the ground pretty quickly, judging by
other projects kernel people have jumped on in the past.

[bark_bark_bark]

Acording to Softpedia, there is a site claiming that the kernel itself is giving the UNIX philosophy the middle finger and that people must use Minix. Of course the site is just a joke, making fun of certain (pro-systemd?) people.

(too bad the article's author is gullible and believed they were seriously asking people to ditch linux.)

[01micko]

https://github.com/EtchedPixels/FUZIX

by Alan Cox

@technosaurus.. x86? </jk>

[James C]

Fedora upgrade process broken by systemd timeout.

https://www.happyassassin.net/2014/10/3 ... right-now/

It’s probably not a good idea to try and upgrade to Fedora 21 with fedup right now.

Currently Fedora 21 has a build of systemd that includes a new feature that was added upstream after the release of 216, which is intended to time out system startup if it’s not complete after 15 minutes – the idea being to avoid things like your laptop melting / starting a fire in your bag if it gets accidentally powered on, stuff like that.

Unfortunately, turns out that having a timeout that hard powers down the system if boot hasn’t completed after 15 minutes doesn’t work very well with fedup, because while fedup’s actual ‘install the updated packages’ step is running, systemd considers that boot has not ‘completed’. So if you try and fedup to Fedora 21 using a fedup environment that has the affected systemd build (like the one in the Beta tree, and also in the current 21 ‘stable’ tree), and your ‘install updated packages’ boot takes more than 15 minutes, it’ll just suddenly cut off and shut down. Obviously, there’s quite a high chance that’ll leave the system in a broken state.

[James C]

A little more light reading.....

https://wiki.debian.org/Debate/initsystem

This is a debate in the Essay Debating System about which init system Debian should choose as default. The tech-ctte has been invoked to decide on this topic, and asked for the different positions to be concisely summarized in debate pages.

[James C]

Thoughts on systemd and the freedom to choose

http://blowingupbits.com/2014/11/though ... om-choose/

[quote]Over the past year I’ve been reading a lot of opinions on the new init technology, systemd. Some people think systemd is wonderful, the bee’s knees. Others claim that systemd is broken by design. Some see systemd as a unifying force, a way to unite the majority of the Linux distributions. Others see systemd as a growing blob that is slowly becoming an overly large portion of the operating system. One thing that has surprised me a little is just how much people care about systemd, whether their opinion of the technology is good or bad. People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do. Opponents claim systemd will divide the Linux community and drive many technical users to other operating systems. There is a lot of hype and surprisingly few people presenting facts.

One discussion thread I read recently compared systemd to other “holy wars

[technosaurus]

The issues it originally tried to address (boot speed and process dependency) are still issues. Its not their fault though, they are addressing the wrong problem altogether. The real problem is that linux (and all OSes for that matter) lack a powerful project manager that can analyze resource usage, determine critical paths, dependencies and available resources. These data (and the data from bootchartd) are needed to feed them back and forth into profile guided optimization so that resources can be appropriately preloaded with readahead and processes can be grouped and scheduled according to their criticality. Even with all that, human input is still required to optimize it fully (you can't use /usr/share/fonts/* until the file system its on is mounted) and that requires something like a gantt chart to visualize the process flow and set each process's predecessors and successors appropriately.

I have already (manually) determined the critical path to starting a jwm desktop and used it to write a basic init system in C that will boot to X in under a second (less than 4mb ram usage with init+xvesa+jwm+rxvt). but once it is started various apps will want to run daemon processes for things like servers, tray applets, inter-process communication, printing, etc... These tend to eat up a bunch of resources, to the point where a bare desktop uses over 128 or even 256mb of ram. Unfortunately systemd does nothing at all to address this issue.

I wrote my Simple Icon Tray applet to handle multiple tray applets in a single process. The rest of the long-running processes are mostly command line tools that (except for cups and dbus) have a toybox/busybox equivalent, however neither toybox or busybox currently have a means of running multiple daemons in a single process. A few years back I did make a build of busybox that only contained the daemon processes and that alone made a huge difference.

Its feasible to add a separate configurable thread(s) that run(s) these daemon processes in init (for servers), I would rather keep all non-essentials completely separate from init on desktop systems (use the xdg autorun specification instead)

[bark_bark_bark]

systemd uses binary logs which can't be read by humans and these binary logs usually break.

[technosaurus]

Yeah, I wouldn't be surprised if instead of switching back to plain text logs, they switched to using an sqlite db ... one more small dependency to keep adding on to the vast list of small dependencies.

They used xml to allow for processes to have multiple children, but xml only allows 1 parent per child, so it cannot effectively address a process that requires completion of multiple events simultaneaously. ... but guess what? this is easily done in a shell script like this (simplified) script:

Code: Select all

parentA(){
 dostuff
}

parentB(){
 domorestuff
}

childofAB(){
 finishstuff
}

#this could be a function as well if necessary
parentA &
A=$!
parentB &
B=$!
wait $A $B
childofAB

pseudo xml this would look like:

Code: Select all

<dummy parallelchildren="true">
  <parentA>dostuff</parentA>
  <parentB>domorestuff</parentB>
</dummy>
<childAB>finishstuff</childAB>

but adding extra non-dependent processes becomes trickier

One way would be to have a separate project manager that accounts for each process's predecessor/successor and resource usage to organize the workflow. Existing project managers (planner, etc...) are not designed for this, but I could probably put one together in js to output optimized shell script ... I could even add comments to denote misuse of sed,cut,tr,grep,awk,etc... where shell builtins would be faster.

[James C]

http://www.bloodbathsoftworks.com/xylemon/xlennart.php

XLennart is an xBill modification about a hacker named, "Lennart" who has created the ultimate computer virus that is cleverly disguised as a popular init system. XLennart is commentary on a certain Linux/Unix topic, but I'll let you figure out which one.

[James C]

Systemd-resolved DNS cache poisoning

https://news.ycombinator.com/item?id=8595335

And now systemd adds to this.........

All this nonsense because someone somewhere decided that a nice, shared, global OS level client and cache wasn't good enough. Handling this complexity once would just be too easy.
Can someone tell me why? Why wasn't it good enough? What was it that prompted someone to go reimplement all this wrongly, yet again?
Yes this is a rant, but if there are underlying technical reasons for this nonsense, I'm very, very interested to hear about it.

[anikin]

Let's hear the other side for a change:

I am used to rough discussions on mailing lists, and yes, when I was younger I did not always stay technical in flamewars, but nowadays I am pretty good at that, I am sometimes articulate, but never personal. I have a thick skin (and so do most of the others involved in systemd, apparently), and I figure that plays a major role why we managed to bring systemd to success, despite all the pressure in the opposite direction. But from time to time, I just have to stand back and say "Wow, what an awful community Linux has!".
The Internet is full of deranged people...==>

https://plus.google.com/app/basic/strea ... z3gujbhh04

[bark_bark_bark]

Lennart Poettering f**ks up everything in the open source world; That is why he is hated so much.

Both PulseAudio and systemd have been used to rape the users and their freedom to choose.

[anikin]

Redundant post. Deleted.

[saintless]

Debian leader says users can continue with SysVinit

Hi, Anikin.
Jamec C already gave this information here and I think the links he posted show both sides statements.
I see nothing wrong having sysvinit alternative, or some linux programmers adding systemd as dependency, or some linux distro to replace sysvinit with systemd. From my experience systemd boots faster debian on the same machine and sometimes this is all that counts for the user. All is open source and can be changed, moded, improved or emulated from other programmers. There are some who do that - uselessd and apulse for example.
Having alternatives to sysvinit and alsa is actually having choice that was not available before. Each one may be good for some people and bad for others. No need to have a winner. Use it or don't. And we can't blame program developers adding systemd as dependency. They have the right to make this choice and we can use their product as it is, or modify it, or write alternative program without systemd dependency.
This thread is just one more tool for venting the anger. No need to be angry just because sysvinit got a new neighbor. Linux world is large enough for both.

[anikin]

Hi Toni,

oops, I didn't see that post, sorry.

I totally agree with you about systemd. The debate is more about nostalgia, hurt feelings and ideology. As a fan of Debian and DebianDog user, I'm very glad, you have taken a balanced and unbiased approach.

[bark_bark_bark]

Systemd is designed to take away choice. If you like choice of init systems, then boycott systemd. BTW I see no difference between Hitler and Lennart Poettering.

[anikin]

Arch Linux, Fedora, Red Hat and now Debian and Ubuntu, among others, have all adopted systemd. The folks, who run these distros must have considered pros and cons before switching. They are not your ordinary Linux users, but top notch professionals - crème de la crème. Have they all been fooled by a crook? Why did they switch? My gut feeling is, they didn't have much choice. Either accept systemd, or get left behind technologically. I fail to see any other reason. I disagree with your assessment of LP, the comparison is absolutely unfair.

[amigo]

Discussion of systemd here is actually superfluous -Puppy's boot process could never work with systemd. However, a sanely-built LiveCD distro could certainly use it if wanted. Every other LiveCD distro sanely separates the processes run by the initrd from the 'real' init process -which should run absolutely normal without any traces of 'live' trickery. The day that Puppy could use systemd is the same day that Puppy could use sysvinit, upstart, runit or whatever.

Note that I am in no way rooting for systemd. In fact, I think this is the first time I've posted to a systemd thread -there are loads of them on the Slackware LQ forum -which have all turned extremely toxic.