public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: lu_zero@gentoo.org
Subject: Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
Date: Sun, 26 May 2013 13:15:57 +0200	[thread overview]
Message-ID: <20130526131557.15a599b8@gentoo.org> (raw)
In-Reply-To: <51A1E2B7.5020803@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

On Sun, 26 May 2013 12:23:51 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 9:37 AM, Michał Górny wrote:
> > By the way, we should really keep the separation between systemd itself
> > and the unit files. I agree that systemd is not the best thing we could
> > have. But the unit file format is, er, good enough -- and has
> > the advantage of eventually taking a lot of work from our shoulders.
> 
> Unit files had been considered when I started exploring the idea, sadly 
> Joost shown me their limitation wouldn't make people life exactly happy.

There are always people who are unhappy with anything you'd change.
Sometimes it's just about changing the way you see things. I can't tell
more without knowing the details though.

> > First of all, working on it will require a lot of work. Seeing how
> > large systemd become and how rapidly it is developing, establishing
> > a good alternative (even dropping such useless parts as the Journal)
> > will take at least twice that work.
> 
> You make clean blueprints, get enough people agreeing with them and 
> implement simple workalike for what you care about.
> 
> For example logind seems to be the current fad.

You're probably right here. But I would have to have the time to work
on it, and as you probably noticed I'm engaged in too many projects
right now.

> > The systemd haters will refuse the project because of its resemblance
> > to systemd. The systemd lovers will refuse it because of its
> > resemblance to systemd. And the OpenRC lovers will want to design it
> > to resemble OpenRC which is just pointless. Then the few remaining
> > people will find systemd 'good enough'.
> 
> systemd haters, as you name them, could be split in few groups:
> 
> - those that consider systemd a bad idea because it is a single item 
> with many parts that would break horribly, if your idea is to make it 
> less tightly coupled and with less parts many would consider helping.
> 
> - those that consider systemd a bad idea because of the force feeding 
> theme started with udev incorporation and continued with logind and 
> such, again if you are creating alternatives the people would help gladly.
> 
> - those that consider key part of systemd just wrong the limitation in 
> the unit format or path activation as panacea, in that case you have to 
> make clear the scope of your project, you might win few or lose some.

You are right again. The outcome would be probably a very modular
project which some parts will be used more frequently and others
infrequently.

But the fact is -- that as far as I see it -- we should be working on
replacing all of systemd components. Mixing tightly-coupled parts of
systemd with external replacements seems wrong.

> > And even if there are a few people who will want to work on it,
> > and design a 'good systemd', they wouldn't get much appreciation.
> > Fedora definitely won't care for it. It would have to be really
> > definitely awesome for most Linux distros to even notice it.
> > And I doubt *BSD people would be interested in something external.
> 
> Make it bsd and they would consider helping.

I'm not really sure about this. For some of the components probably
yes. But the general init replacement / unit runner is not something
I'd expect much help with.

> > So there's a lot of work, no fame or money in it, and most likely more
> > work being the only future. Anyone volunteering?
> 
> Probably would be better sit down, figure out exactly what you want and 
> see who has interest:
> 
> E.g.
> 
> Init-project
> 
> - portable   -> must work on non-linux and non-glibc more or less decently
> - modular    -> loose coupling of functionality
> - robust     -> the core functionality must not crash or remain 
> inconsistent because of libdbus or such often occurring problems 
> unrelated to
> - compatible -> should grok at least a good subset of systemd unit files.

Quite a good summary, I'd say.

> On a side note I really want to know in detail why you loathe openrc 
> with this strength but we can discuss on irc.

I'd suspect this is mostly with the growing irritation of systemd
haters who spawn endless threads about how they hate anything with
'systemd' name in it. Plus the people who try hard to port the mistakes
of OpenRC init scripts to systemd services files.

I have my limits, and I'd really prefer doing something useful rather
than setting up random things straight, fighting developers and making
sure everything keeps working in a semi-sane way.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

  reply	other threads:[~2013-05-26 11:15 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-25 16:14 [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697) Ben de Groot
2013-05-25 16:48 ` Michał Górny
2013-05-25 17:38   ` Rich Freeman
2013-05-25 20:02     ` Chí-Thanh Christopher Nguyễn
2013-05-25 20:40       ` Rich Freeman
2013-05-25 20:45       ` Michał Górny
2013-05-25 21:38   ` Luca Barbato
2013-05-26  7:23   ` Ben de Groot
2013-05-26  7:43     ` Michał Górny
2013-05-26 10:04       ` Rich Freeman
2013-05-26 15:21         ` Ben de Groot
2013-05-26 16:15           ` Rick "Zero_Chaos" Farina
2013-05-26 17:14             ` Matt Turner
2013-05-26 17:19             ` Andreas K. Huettel
2013-05-26  7:54     ` Pacho Ramos
2013-05-25 17:00 ` Pacho Ramos
2013-05-25 17:14   ` Carlos Silva
2013-05-26  7:15   ` Ben de Groot
2013-05-26  7:44     ` Pacho Ramos
2013-05-26  7:45     ` Michał Górny
2013-05-26  9:59       ` Luca Barbato
2013-05-25 18:13 ` Markos Chandras
2013-05-25 19:53   ` Anthony G. Basile
2013-05-25 19:58     ` Mike Gilbert
2013-05-25 21:55       ` Anthony G. Basile
2013-05-25 19:59     ` Rich Freeman
2013-05-26  7:00     ` Michał Górny
2013-05-26  7:22     ` Tiziano Müller
2013-05-26  7:46       ` Pacho Ramos
2013-05-26  7:49       ` Michał Górny
2013-05-26  7:00   ` Ben de Groot
2013-05-26  7:37 ` [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697)) Michał Górny
2013-05-26  8:32   ` Ben de Groot
2013-05-26  9:49     ` Rich Freeman
2013-05-26 10:12       ` Robert David
2013-05-26 10:31         ` Michał Górny
2013-05-26 11:12           ` Rich Freeman
2013-05-26 11:31           ` Robert David
2013-05-26 11:47             ` [gentoo-dev] Reusing systemd unit file format / forking systemd Luca Barbato
2013-05-26 10:23   ` Luca Barbato
2013-05-26 11:15     ` Michał Górny [this message]
2013-05-26 11:59       ` Luca Barbato
2013-05-26 13:35         ` Sergei Trofimovich
2013-05-26 14:22           ` Luca Barbato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130526131557.15a599b8@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=lu_zero@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox