[arch-general] [arch-dev-public] Migration to systemd

[Jayesh Badwaik]

Hi,

+1 for your post. I am really happy for the freedom too. 

But what I feel is either systemd, GNOME and stuff would takeover linux 
and drown. Or they will take over linux and flourish or they will be 
separated into their own Linux space and isolated. I have got a big 
feeling that they will not co-exist with other competing distributions. 

And if other distribution really do not like systemd then they would 
develop some other methods and it will be great for everyone.

Here, is my analysis. 

Now on for something. First [1]. There Poettering says

" I'd like to propose systemd 
(GPL2+,http://www.freedesktop.org/wiki/Software/systemd) as blessed 
external dependency for GNOME 3.2. 

Currently the interfacing between GNOME and systemd is minimal. Bastien
has been implementing a UI for changing the host name via a
configuration UI in the control center which uses a tiny mechanism
daemon included in systemd as backend. GLib already exposes
g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose
only implementation I know right now is in systemd."

Okay, now according to fd.o specs, the XDG_RUNTIME_DIR can be set by any 
init process, so why should GNOME set systemd as a dependency, just 
because right now systemd is the only one who does the job? (Not Cool) 
He goes on more about how can systemd and GNOME interface more, but 
still just because GNOME can use systemd does not mean it should have  
it as its dependency, right? The dependency is init. Systemd is just 
filling the role of init. 

Doing a pacman -Qi on sysvinit gives initscripts depending on sysvinit 
and doing pacman -Qi on initscripts give no package depending on 
initscripts. Why should a package then depend on systemd? 

And now if Ubuntu does not like systemd, and if GNOME makes it a 
dependency, you will have a Unity-like fork. I am sure, there must be 
some similar discussion with GNOME and PulseAudio people and hence the 
problem we are not facing. 

If GNOME, systemd and pulseaudio pull out more stuff like that, the guys 
are either going to be isolated or have their way. Time will answer. 

Now for some rant. 

Next, we analyze LP's blog [1]. There he says 
"systemd is also a big opportunity for Linux standardization. Since it 
standardizes many interfaces of the system that previously have been 
differing on every distribution, on every implementation, adopting it 
helps to work against the balkanization of the Linux interfaces. 
Choosing systemd means redefining more closely what the Linux platform is 
about. This improves the lifes of programmers, users and administrators 
alike."

Why should we standardize? 
Ans by LP: adopting it helps to work against the balkanization of the 
Linux interfaces. Choosing systemd means redefining more closely what the 
Linux platform is about.

Balkanization in what space? It is not as if I could not use an app in 
ArchLinux but could use it in fedora because fedora used a different init 
system. I have not noticed this effect as an end-user, but probably 
developers did. If yes, I would like to know and I will take back my 
complaint. But people must remember the cost of throwing away the 
diverse efforts at the cost of reduced work. 

"Redefining what Linux platform is all about. "
Linux platform is all about diversity of different systems which can be 
used as needed by a person. If systemd satisfies the multi-dimensional 
requirement, then great. Else, no. And only time will tell the future, 
so leave space for other init systems in future by not doing that 
dependency stuff I just described at top. How do you expect someone to 
develop a better init system that systemd if the person has to first be 
compliant to all systemd things before even getting started. 


-- 
Cheers and Regards
Jayesh Badwaik
stop html mail      | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

[1] https://mail.gnome.org/archives/desktop-devel-list/2011-
May/msg00427.html

[2] http://0pointer.de/blog/projects/why.html