On Thu, 6 Aug 2015, Ralf Mardorf wrote:

I'm a systemd user, but I don't like systemd and I much more dislike
the generator-hybrid-systemd.

:)

What does Requires= After= Before= do, if you use it in several service
files? Everybody will lose track of the unit order.

http://www.freedesktop.org/software/systemd/man/systemd.unit.html

If you search by Ctrl+F you'll not find RemainAfterExit, oneshot.

I don't know where upstream documented everything.

That systemd already is hard to use is the reason why I dislike to mix
it with init files.

On the other hand init files mean that any program that has init files that someone DL source for can be used.

I personally think there should be one systemd event/script that deals with all system configuration. It would work much like many such things where it would go through two or three directories running config scripts one by one. Similar to init.d BTW. One of those directories would be where packages put there config options, another would be for distro compilers to put overriding config options and yet another could be used by the user to override both. In the case of rtirq, the current /etc/default/rtirq would probably continue to work fine.

Take setting up performance instead of ondemand for example. I do not know if this has yet been cleaned up. It has been, even under upstart, an init.d script.... err, scripts. There were two of them stock to set ondemand... made by two people who did not talk to each other, I think. The first one starts ondemand, the second one waits 60 seconds after startup and then sets ondemand. I think the original idea was that the system would start in performance for faster startup and then switch to ondemand after the user had logged in. The idea didn't help as much as hoped and so the first script just got change to ondemand for the whole shot, but the second was never removed. So someone setting up their system to go performance from rc.local will wonder why it goes into performance and then suddenly it is back to ondemand. Changing the bad script will mess up upgrades, so the only way to fix it is to also put a delay in rc.local or do a "sh script &". Allowing Intel Boost to run may actually make startup faster than performance...

There are probably more such things that should be reported as bugs I guess.

Personally I have been waiting for the change to system.d to be called finished before I start messing with it.

--
Len Ovens
www.ovenwerks.net


--
ubuntu-studio-devel mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Reply via email to