| 1 |
On Tue, Jan 29, 2013 at 2:00 PM, Alon Bar-Lev <alonbl@g.o> wrote: |
| 2 |
> On Tue, Jan 29, 2013 at 9:49 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 3 |
> |
| 4 |
>> I would not bet on that ;) too much resistance. However it is |
| 5 |
>> certainly getting better and better: the LWN article on The Biggest |
| 6 |
>> Myths about systemd had an overwhelmingly majority of comments |
| 7 |
>> positive to systemd, and just a handful of negative comments: |
| 8 |
>> |
| 9 |
>> http://lwn.net/Articles/534210/#Comments |
| 10 |
>> |
| 11 |
>> But that is in LWN; Gentoo is way behind, I believe. |
| 12 |
> |
| 13 |
> Gentoo is not behind, it provides you the option of using systemd. |
| 14 |
> |
| 15 |
> However openrc is superior in many ways, as unlike systemd it provides |
| 16 |
> script base metadata vs static systemd units, so for example a service |
| 17 |
> can depend on other services based on LOGIC. Also, it has the nature |
| 18 |
> of virtual dependencies what systemd lacks, for example there are N |
| 19 |
> services that provides timesync, in openrc you provide timesync and |
| 20 |
> depend on timesync, in systemd there is no way to do so. |
| 21 |
|
| 22 |
I really should not enter into this discussion (again), and even less |
| 23 |
with a Gentoo dev (BTW, thanks for all the great work). However, this: |
| 24 |
"for example there are N services that provides timesync, in openrc |
| 25 |
you provide timesync and depend on timesync, in systemd there is no |
| 26 |
way to do so" it's just a lie (or missinformation). |
| 27 |
display-manager.service and syslog.service work like this; they are |
| 28 |
soft links to the desired service (gdm.service and syslog.service, for |
| 29 |
example), and other units depend on them. They work like virtuals in |
| 30 |
Gentoo. |
| 31 |
|
| 32 |
> openrc is |
| 33 |
> working in various environments including embedded, while systemd |
| 34 |
> requires so much dependencies that it is not really usable at all |
| 35 |
> environments. |
| 36 |
|
| 37 |
I don't know about "all environments", but ProFUSION [1] works in |
| 38 |
embedded systems and several of its developers are systemd upstream. |
| 39 |
|
| 40 |
Also GENIVI, the standardized common software platform for developing |
| 41 |
in-vehicle infotainment (IVI), uses systemd. |
| 42 |
|
| 43 |
> openrc can be used correctly in chroot environment, |
| 44 |
> while systemd is inoperative. |
| 45 |
|
| 46 |
I know it's not exactly the same, but with systemd we have |
| 47 |
systemd-nspawn, which I (IMHO) consider far superior: man 1 |
| 48 |
systemd-nspawn. |
| 49 |
|
| 50 |
> openrc supports extra commands for |
| 51 |
> services, while systemd enforces only start/stop sequence. I can go on |
| 52 |
> an on. |
| 53 |
|
| 54 |
Yeah, OpenRC needs zap, because sometimes a daemon ends unexpectedly, |
| 55 |
and OpenRC is unable to detect it. I would not call this an advantage, |
| 56 |
though. |
| 57 |
|
| 58 |
> Just because there is hype of some branding, does not mean it is better. |
| 59 |
|
| 60 |
I believe it's better, but it's only my opinion; it's certainly better |
| 61 |
for my use-cases. I don't want to impose systemd on anyone, but I |
| 62 |
would be really happy if I could *easily* uninstall OpenRC from |
| 63 |
Gentoo, since I don't use it. I'm using an ovelay [2] right now, but |
| 64 |
is far from optimal. |
| 65 |
|
| 66 |
And, BTW, I didn't mean "behind" in the sense that Gentoo doesn't |
| 67 |
support systemd; I meant "behind" in the sense that us systemd users |
| 68 |
get a lot flak just by mention it in the list. |
| 69 |
|
| 70 |
[1] http://www.profusion.mobi/ |
| 71 |
[2] https://github.com/canek-pelaez/gentoo-systemd-only |
| 72 |
|
| 73 |
Regards. |
| 74 |
-- |
| 75 |
Canek Peláez Valdés |
| 76 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 77 |
Universidad Nacional Autónoma de México |
Archives