New Group Calls For Boycotting Systemd

[tiuykor]

I never said Windows was well designed. For some good points on design issues in systemd, see the following blog posts:

http://ewontfix.com/14

http://ewontfix.com/15

That being said, anything that falls under the criteria of being good enough as far as a user can tell "works" for the user. The software engineering need not be good.

This http://ewontfix.com/14 gives me concern about systemd. OS should NOT need to restart to accomplish an upgrade. And systemd use increases the attack surface?

If using systemd means I have to reboot to accomplish an upgrade, I seriously don't see myself continuing to use a Linux desktop. A big reason why I left Windows was because of Linux "features" like not having to reboot to accomplish an upgrade.

[jayrulez]

What is surprising? That I still have hope to find my bucket?

Ha!

I replied to the wrong post. I meant to reply to the person that claimed that even Linus does not like systemd.

[pal666]

The thing to keep in mind is that systemd is a Redhat project

the thing to keep in mind is that you are off your meds

[thechef]

I think the most useless arguments are those regarding anti-unix.
You can use the same against the Linux kernel as well as Unix itself - if you're so keen to understand Unix or Linux as a very single tool.

Especially Linux is a piece of crap then, because all the "bad" properties of systemd are even more present in the Linux kernel. It's just an integrated cathedralistic piece of crap.

systemd is the integrated userspace-counterpart of the kernel. You can't just make the cut at the very thin band of the syscall-interface. You need something that manages the transition to deal with the heterogeneous landscape. You need something that reutilizes the Unix approach (providing the relevant building blocks) for this problem .

[pal666]

Truth is that systemd will fall like a Roman empire in few years, just w8 and see.

i'm sorry, but roman empire fell in a few *hundred* years

[NotMine999]

Almost Correct...

And there is never going to be as long as the boycott crowd is convinced that there is no need for systemd. It seem that no one in the boycott crowd is willing to admit that systemd offers features projects want to use. They have convinced themselves that the only reason any project would ever use or even cooperate with systemd is because they were forced to by some upstream dependency or coerced by Red Hat. When provided specific examples of projects that don't fall into either category, they either claim (without evidence) that there is something shady going on behind the scenes or just ignore the example outright.

systemd offers features that most desktop-oriented distributions would like to see. Where to these big distro houses see their future "mind share"? On the desktop, but they make their money on servers. So why might Red Hat deploy systemd across all of it's distro variants? It simplifies their internal development process; everyone works from a common code base which makes bug hunting easier as more people work/see on the commonly used code.

What I hear a lot from experienced sysadmins is this: "systemd doesn't bring many benefits to me while making more work for me because I have to convert some custom app startup script to operate in the systemd format" At my own employer I am not sure how RHEL7 will be accepted when RHEL6 has a big "footprint".

Said another way, most sysadmins don't like to work hard, especially if they are responsible for 100+ servers (not uncommon in many environments, very common where I work).

So systemd for desktop-focused deployments? Why not? For servers and busy sysadmins? Probably not.

Will some sysadmins want to use systemd? Possibly...everyone is different and some are thrilled with "gee wiz" technology like systemd.

What might be an appropriate course of action? Look at the Windows world. Have you noticed that Windows server is available in versions that include a GUI and a very simple version that does not include a GUI? So perhaps a Linux distro could be successful if it just focused on the needs of servers and sysadmins and not include all of the underpinnings and elements related to systemd? And I don't mean that little fileserver that a person builds for their home; server in this case means hardware that might live in a data center.

You want systemd on your server? That's your choice and there are lots of Linux distros to consider.

You want a server without systemd? Right now that leaves FreeBSD and Gentoo and a few other smaller distros.

[sdack]

i'm sorry, but roman empire fell in a few *hundred* years

And what did the Romans ever do for us?

[pal666]

Based on the content of your brief comment it is clear to me that you lack even a rudimentary grasp of Linux. I mean how can you use numbers to declare winning on an OS that does not even have a fraction of a percentage point of market share to begin with?

Based on the content of your brief comment it is clear to me that you lack even a rudimentary grasp of Linux. linux had more than 50% of market share of end-user computers long ago and now it has more than 50% of installed base.

[TheBlackCat]

This http://ewontfix.com/14 worries me!

I hate having to restart after updates. It's one of the things I love about linux (vs Windows), not having to restart after updates.

Did you actually read the article? It says first that systemd has to restart to upgrade, but then later on admits that there is actually a built-in mechanism to avoid having to restart.

And there's going to be increased attack surface with systemd use?

If you compare to sysv alone, then yes. If you compare to sysv AND all the shell scripts, then no.

I have always been a big fan of Upstart. And was disappointed to see it "lose" in Ubuntu.

Upstart was no better in any of these regards.

[interested]

I'm primarily in the "as long as it works and works well" camp, but if the "log files are binary" is true, now THAT seems a bit of a pain. But given that I just don't have any experience trying to dig into systemd logs nor know the reasons binary was the choice, maybe if I did I wouldn't react negatively about that.

I was very sceptical about binary log files too when I heard about it. But I spend some time giving the journal reader, "journalctl" a workout, and left very impressed and totally convinced.

There are several excellent reason why the binary logs are a good idea:

It is indexed: every entry, every program, daemon, process, and bash script that have ever generated a log line can be tracked and traced. This is pure gold.

There is kernel guarantee that entries aren't faked.

Multi-language logfile support.

Integrated help database (using the -x switch)

It will finally be possible to make a GUI log file viewer that isn't just a glorified "less" with windows decorations, since all log files entries are structured with "field names" etc.


There are several other things I like about systemd's logging:

Powerful log querying facilities, stuff like:
"journalctl -p err -b" (show all entries from this boot(-b) with log-level "error")

"journalctl -f" (same as tail -f /var/log/messages)

"journalctl -f _EXE=/usr/sbin/smartd" (follow the output from this program only)


There is logging from the moment the system boots: systemd lives in initramsfs while the system is booting, and then jumps over to the rootfs when it is mounted, that means it can get early boot log info, from before the system is up.

All log files are collated into one file, including .xsessionerrors and wtmp etc. So no need to hunt around for log files or use special programs like "last" to view the binary logs. (it's a Posix thing)

journalctl works with all the standard Gnu tools like grep, tee, less/more, sed, etc.

I could go on. It is a new way of doing things, so it does require some study sessions until your workflow becomes fluent again, but is totally worth it. The documentation and man pages are fine, and the tab-support is simply superb.