My 2 cents on systemd

[pr1vacy]

Ignorance is bliss. I smell a shill.

 

Read: https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/

[cusco-travel-services]

Ignorance is bliss. I smell a shill.

 

Read: https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/

Shills sent by the zionist schmucks that operate RedHat/Fedora for the elitist agenda. They are just trying to undermine Daniel's good work.

[nrc]

Nope, I am pointing out that I don't have a choice about my init system and that the lack of this choice, in particular, will aliniate any user that doesn't participate. You should, at least, have a choice of, what today, is becoming the industry standard init system, resource manager, loging solution and booting-watch-cha-ma-call-it. That's all.

 

As uudruid74 pointed out earlier in the thread, Funtoo doesn't exist to provide you with the "industry standard" anything.  If that alienates someone then Funtoo isn't the right distribution for them anyway.

 

To quote the Wiki: "Funtoo Linux is a project of people who agree with the philosophy of the ideal tool, and who are passionate in our desire to improve technology to be as close to this ideal as possible."   That's the purpose of Funtoo - for the BDFL and like-minded individuals to pursue the ideal tool in each instance and share the results with those of similar mindset.

 

"The ideal tool" is similar to the "small, sharp tools" that are the core of the UNIX philosophy.  Not only does systemd run counter to that philosophy as an init system but it also pre-empts attempts to create "the ideal tool" in many of the technologies that have fallen prey to its all-consuming hunger to control every aspect of your system.  Elegant tools like boot-update and Funtoo's core networking templates would be rendered moot by systemd imposed kludges.

 

Simply put, systemd is contradictory to the core principle of Funtoo.  Funtoo with systemd wouldn't be Funtoo.

 

Well, you speak of things like if they happened unilaterally. Developers at work made their decisions and came up with, what they thought, it was the best plan. The result of SystemD taking over stuff is just a consequence of devs thinking it is the best option. I am happy to trust them on that.

 

All those choices weren't based on merit.  Some distributions chose systemd because they had little other choice.  Redhat controls many of the projects they rely on and they felt that they didn't have the resources to create replacements or deal with all the incompatibilities that Poettering was creating.

 

Fortunately the smaller distributions that have declined to adopt systemd have made better progress at working around those issues than some thought would be possible at this stage.

 

Yes, I know. I do trust him and I am not pointing a gun at anybody. I am just expressing my opinion; as you are. I truly think that Funtoo should allow and support SystemD; while favoring whatever Funtoo likes. That's all. It will be easier and people that hate it can still say they hate it. Win <-> win, huh? ;)

 

The opinion that you're expressing contradicts the Funtoo vision.   If you want systemd you don't understand that vision and you're using the wrong distribution.

[pr1vacy]

 

The opinion that you're expressing contradicts the Funtoo vision.   If you want systemd you don't understand that vision and you're using the wrong distribution.

 

;)

 

On a sidenote...but relative as it's an example of some attitudes toward systemd....was installing profile-sync-dameon...ie..psd....and ended up seeing this...read down a bit at the NOTE FOR VERSION 6:

 

https://github.com/graysky2/profile-sync-daemon

 

Some people are just lazy.

[uudruid74]

;)

 

On a sidenote...but relative as it's an example of some attitudes toward systemd....was installing profile-sync-dameon...ie..psd....and ended up seeing this...read down a bit at the NOTE FOR VERSION 6:

 

https://github.com/graysky2/profile-sync-daemon

 

Some people are just lazy.

There would seem to an issue with fragmentation of our userbase. This will only get worse. It would be nice to abstract daemon installation in some portable way.

 

Maybe some application that could convert from some universal configuration to whatever the local init system requires, or perhaps we should accept that systemd will be prevalent and make a converter that converts systemd configurations to openrc scripts? Does such a think already exist?

 

More about me at https://eddon.systems

[nrc]

There would seem to an issue with fragmentation of our userbase. This will only get worse. It would be nice to abstract daemon installation in some portable way.

 

Maybe some application that could convert from some universal configuration to whatever the local init system requires, or perhaps we should accept that systemd will be prevalent and make a converter that converts systemd configurations to openrc scripts? Does such a think already exist?

 

More about me at https://eddon.systems

 

It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files.   Call it unitrc.  Then making a unit file work for start up would just be:

ln -s /etc/init.d/unitrc /etc/init.d/myservice
mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice
rc-update add myservice 

Note that systemd's service startup information is stored in /usr.  Another example of the perversity of systemd. 

[uudruid74]

 

 

It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files. Call it unitrc. Then making a unit file work for start up would just be:

ln -s /etc/init.d/unitrc /etc/init.d/myservice
mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice
rc-update add myservice 

Note that systemd's service startup information is stored in /usr. Another example of the perversity of systemd.

Or modify rc-update to look for systemd unit files?

 

More about me at https://eddon.systems

[adcdam]

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.

[uudruid74]

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.

It doubt it will ever be an option, let alone the default.

[nrc]

I really hope that we dont have systemd in funtoo, some people are migrating from linux to freebsd because of systemd. No systemd was one the reasons i chose funtoo.

 

Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd.    Spread the word. http://without-systemd.org/

[uudruid74]

Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd. Spread the word. http://without-systemd.org/

I'm not really a fan of udisks either. Even after unmounting/ejecting a usb device, I can't fsck the thing because the kernel thinks its in use, even with no files open on it. I think this is a udisks issue, which is now a systemd thing. The workaround is to remove the device and reinsert it but don't open it or else udisks will hang on to it forever.

 

These over-complicated system daemons are horrible. And they all seem to come from freedesktop.org ... I'm really starting to hate freedesktop.org.

 

 

 

 

 

More about me at https://eddon.systems

[uudruid74]

There was a slashdot article about Busybox removing systemd support, which turned into an sub-thread about an ipv6 over ipv4 service.  The systemd maintainers added a respawn "fix" that would restart the service within 10 seconds since the daemon would abort if the network wasn't up .... of course this means that the upstream service providers get hit with retries every 10 seconds if your password is wrong or something else is misconfigured, and they were annoyed that the warning NOT to respawn wasn't being acknowledged and no notification was given that the unit file was being changed.  They site systemd as the problem for not verifying that the network is up before starting the service.  The systemd folks site that this shouldn't be necessary since "modern" systems (he mentions his Apple Powerbook) have intermittent networking and the daemon should use exponential backoff if the network is down.   The daemon author says people need to read the logs before restarting the daemon and the systemd guys say that users aren't admins and don't read logs!

 

This is a classic example of what I see as the division of thought.  The old-school admins see a server and classic start-up routines - you are started when networking comes up. If networking is down, abort.  Read the logs.  Auto-restart is bad.  Systemd wants it easy and wants it to work on a laptop without thought (and apparently without a GUI tool that checks the log to decide if it should respawn), wants services to be restarted and says that the daemon author doesn't provide an exit code as to why the daemon stopped, so the only choice is to restart for all exits.  He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.

 

Here's my take on this.  Network down and can't connect are two different things.   The former is a local issues and easy to detect.  In this instance, the daemon can/should quit and log.  Further, networking should be UP before the daemon is started.  Specifically, the daemon should be started as a response to the "event" that the network is up.  If there is a login problem or other issue, it should also abort and log.   If the network is up, but you can't connect to the server, then use exponential backoff and retry.  Systemd should know when network devices like Wifi disconnect and reconnect.  It should also know if the daemon is running.   It should start the daemon on the condition that the network has been brought up and it is not already running.

 

Now ... what am I missing ???   Why would it start without networking being up?  Why would anyone restart the service every 10 seconds?  Sounds brain dead to me!   Typical SysV init would run the network up/down scripts and get this right.  Systemd SHOULD get this right, and I'm sure someone will say its been misconfigured or whatever, but notice two different mind-sets here.  One person wants it to just work with focus on easy - and who cares what damage it may cause.  The other person wants people to stop and read (no matter how unrealistic that may be).

 

I once had someone tell me they couldn't print ... they said some error message kept popping up.  I said, "What does it say?"  They said, "I dunno".  I said, "Well, try it again and read it!"  And I could tell they were mad that I wouldn't run over there and fix their stupid Windows problem ... they did not want to read me any technical jargon from some error message on the screen!   The response was, "Nevermind."     ... WHAT?  ... Guess what the Error said?  

PRINTER OUT OF PAPER!

 

[cusco-travel-services]

The systemd folks site that this shouldn't be necessary since "modern" systems

 

cite is the correct word in this context, not site.

 

He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.

 

As above, it should be cites instead of sites.

 

We have to think of the Members whose native language is not English so that it is easier for them to learn and understand mate.

 

From your friendly grammar and spelling nazi. ;)

[b9AcE]

It's simple really: systemd is wrong for Linux.

It may be right for something else, but not (default) Linux.

It violates the "UNIX Philosophy", which is best summarized by the famous quote from the inventor of the UNIX-pipe, McIlroy:
 

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

This is important for very many reasons.

If one non-critical functions fails, it should not mean that the entire system becomes unusable as it has been on Windows where svchost.exe is used to run almost any arbitrary process and each of those svchost.exe processes can "host" several sub-functionalities. This results in that if any of those sub-functionalities "goes nuts", even if it's one that the user does not care about at all, the entire process with all its hosted sub-functionality is immediately affected. Also made obvious by the svchost.exe example is how it makes granular permissions management impossible even with third party tools like anti-virus and firewalls as if you have even ONE svchost.exe sub-functionality requiring network access to do its job, you must grant network access to the entire process and thus to everything else hosted by the same binary and this can lead to very undesirable security implications.

I use svchost.exe as the example because we Linux- (and UNIX- in general) users used to laugh at Windows' poor design in this regard for these reasons... but now when Windows is moving more and more away from this design, Linux is moving to it.

What's even worse is that there used to be several alternatives to chose from regarding system init provider, but now there are only two main ones and one that is being migrated away from, so if any major flaw is discovered in for example systemd, there is now effectively only ONE choice left.

With software now increasingly being made specifically designed for systemd, they build bi-directional dependencies so that the user can not really choose individual components anymore, which again can cause very bad security results as well as very much waste in system resources.

Imagine for example if there is a bug that causes the boot process to take half an hour each time using systemd and OpenRC can't be used because the core functionality of the system specifically depends on systemd... This can cause very expensive fines for corporations with Service Level Agreements to honor.

The migration to systemd results in user-unfriendly, bloated, unnecessarily restricted and potentially very costly systems.

It could be AN option, but should definitely not become the ONLY option as it is becoming now.

If you want a Windows/Mac-like system where the user is put out of control through the assumption that the programmers will be able to predict every usage scenario and never write flawed code so no options are needed, then it should be considered as an option.

 

I could go on, but I fear I have already passed the wall-of-text/TL;DR-threshold.

P.S.: The example scenarios in this post are all ones that I have personally encountered, so not at all hypothetical.