On 12/17/2011 06:26 PM, Cristian Rodríguez wrote:
On 18/12/11 06:13, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 17.12.2011 01:18, schrieb Cristian Rodríguez:
On 17/12/11 17:41, Bernhard M. Wiedemann wrote:
yes most of those are bugs elsewhere..
bugs that only occur because of systemd can not be ignored when you want to drop the working alternative.
If I dont' narrow down the proposal, the number of different scenarios go to the roof.
what do you count as a "scenario"? And what is bad about different scenarios?
let's have an example - I used to adapt the timeout for mounting my crypted home partition. By looking at /etc/init.d/boot.crypto I found that /lib/cryptsetup/boot.crypto.functions contains a TIMEOUT value of 120 seconds, which I then change with a text editor and will thus be used on next boot. Systemd does not use /etc/init.d/boot.* files
with "find" I found /lib/systemd/systemd-cryptsetup (binary - so unreadable)
Yes, that's because systemd interfaces with libcryptsetup ..
where is the advantage over LUKS cryptsetup?
which mentions man 7 systemd.special but this manual page does not even mention "crypt" once. And nothing about "timeout" either.
Did you filled a bug report ?
if I always filed such things there would not just be 150 reports from me.
And I would still like to know how to tune the timeout value. You said, there was a lot of documentation on systemd, so such a trivial thing should be covered, shouldn't it?
Where does the support effort come from (aside from fixing bugs that need fixing anyway)?
And by supporting /etc/init.d and .service files we get more rotten bits? My /etc/init.d has just 18K lines. Not really much to maintain.
I can see some effort in maintaining /etc/init.d/boot.* files together with their systemd equivalent.
Some of them will probably go away as systemd handles them natively.
I thought, it already does handle all of them natively, because it does not run them.
are we in a hurry?
The sooner the better, people will eb able to direct efforts into one thing, that has ONE particular set of rules.
rules of bash scripts are already well known among admins, packagers and system-integrators - no "effort" to redirect there.
Once systemd works as it should, and proves to be better than sysvinit, people will move towards it - so no need to force it upon us.
Ciao Bernhard M.