[arch-general] RFC: OpenRC as init system for Arch

[XeCycle]

Patrick Lauer <patrick at gentoo.org> writes:

[...]

> And how many antifeatures they have ;)
> For me the feature list of systemd is kinda nice, it's obviously more
> comprehensive than the "old" init systems, but it goes against the unix
> spirit of having one tool for a job, and do this job well.

That design philosophy can be overused.

"One tool for a job", yeah, seems to make sense, in that it makes
easy to do it well; but you have to define the job precisely.
Some jobs are cooperative; if you follow that spirit, you may not
want to let the programs know who they're talking to, and you
must invent a nice way of cooperation.  While many these ways are
out there, most are either not powerful enough or not general
enough, therefore existing programs still need to know who
they're talking to.  That's contradictory.

Violations of this philosophy can be easily found.  The Linux
kernel is such one.  It is already big, with many misfeatures, or
"anitfeature"s; but we all use it, right?  Linus said such a
design simplifies the intercommunication between kernel modules.
Yes, monolithic improves integration.  systemd, being a
Linux-only project, in my idea it's quite acceptable to use this
design: it brings together otherwise messy things, and gives a
unified interface, at the same time being easy to get good
performance.

Some jobs are born dirty.  If you deal with these using those
elegant and orthogonal tools, it's very likely that you end up
splicing those tools into another strange dirty tool; what's
worse, the user must understand how you built it to actually use
your tool without too many problems.

> Having all the features and being able to not have the
> antifeatures is what makes OpenRC extra nice ...

Above comments are towards that damn spirit, not OpenRC.  I
didn't use OpenRC though, but from all your discussions, it seems
at least more feature-rich than the default init system.

The default init is way too simple in my POV.  E.g. it requires
the user to sort out the sequence to start these daemons; that,
while not very hard to do, is unnecessary.

>>  Simply being different or offering a few bonuses won't be enough,
>> IMO. Systemd is something dynamic and is what fits that ideal model, a
>> model which satisfies the needs of the present and hopefully the future.
> "dynamic" how?
> People have thrown "event based" and such words around, but no one has
> dared to clarify or properly define what they mean by it. Thus I can't
> understand if there's anything missing in OpenRC or people are just
> throwing words around because it feels good.

Hate such words too.  But I normally ignore that, it's just like
those commercial ads --- no even one cal of gnutrition inside.

Perhaps they assume you have used their software.  systemd is
able to start programs when needed, and may stop them when no
longer in use.  They don't feel like writing this sentence every
time being asked about its advantage, so they use that word for
it.

>> Otherwise, I like my init as simple as it currently is. Dependency is never
>> a problem as it's very little work to manually ensure they're met.
>>
> You only realize what you're missing when you've lost it ;)
> For me not having dependencies is very frustrating, it makes restarting
> things so random and assumes that I know or care about who depends on
> what (hint: that's the job of the init system, not mine)

-- 
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120507/3ec65de4/attachment.asc>