| 1 |
Andrew Savchenko posted on Sun, 17 Sep 2017 18:44:11 +0300 as excerpted: |
| 2 |
|
| 3 |
> On Sun, 17 Sep 2017 12:05:07 +0200 Michał Górny wrote: |
| 4 |
>> W dniu nie, 17.09.2017 o godzinie 12∶12 +0300, użytkownik Andrew |
| 5 |
>> Savchenko napisał: |
| 6 |
>> > On Sun, 17 Sep 2017 02:56:08 +0700 Vadim A. Misbakh-Soloviov wrote: |
| 7 |
>> > > Hi there! |
| 8 |
>> > > |
| 9 |
>> > > Every time I switch from mastering service on my work |
| 10 |
>> > > (Ubuntu-powered) to my own server farm (Gentoo powered) I'm going a |
| 11 |
>> > > bit frustrated: Ubuntu (with all my hate to many other things in |
| 12 |
>> > > it) has nice user-friendly way of managing services: you can freely |
| 13 |
>> > > call any of `service <servicename> action` irrelevant to which |
| 14 |
>> > > init-system is currently in use. Will it be systemd, or (whatever |
| 15 |
>> > > there is alternative there). `service` wrapper will detect it |
| 16 |
>> > > anyway and will do the proper things (forward it to either systemd |
| 17 |
>> > > or another service manager). |
| 18 |
>> > > |
| 19 |
>> > > I'd like to suggest to remove `service` widget from openrc and make |
| 20 |
>> > > it the part of (which package? baselayout?)? Here is a pseudocode |
| 21 |
>> > > of how I see it: |
| 22 |
>> > > |
| 23 |
>> > > ``` |
| 24 |
>> > > servicename=${1} |
| 25 |
>> > > action=${2} |
| 26 |
>> > > |
| 27 |
>> > > if in_systemd; then |
| 28 |
>> > > systemctl "${action}" "${servicename}" |
| 29 |
>> > > else |
| 30 |
>> > > rc-service "${servicename}" "${action}" |
| 31 |
>> > > fi ``` |
| 32 |
>> > > |
| 33 |
>> > > Well, actually, there may be some more logic (for example, instance |
| 34 |
>> > > units (`unit@instance` in `systemd` vs `unit.instance` in openrc), |
| 35 |
>> > > "enable" action (forward it to `rc-update add` for `openrc`, |
| 36 |
>> > > probably) and maybe some more. But anyway, the conception is |
| 37 |
>> > > something like that. |
| 38 |
>> > > |
| 39 |
>> > > |
| 40 |
>> > > What do you think about that? |
| 41 |
>> > |
| 42 |
>> > https://xkcd.com/927/ |
| 43 |
>> > |
| 44 |
>> > We will create even more confusion for Gentoo users with one more |
| 45 |
>> > tool to do the same stuff. |
| 46 |
>> > |
| 47 |
>> > Of course you are free to implement some separate wrapper package, |
| 48 |
>> > but it must be completely optional, since some users will have no use |
| 49 |
>> > for it including myself. |
| 50 |
>> > |
| 51 |
>> > Really, unifying distributions is futile. We will have either the |
| 52 |
>> > same and only distribution (to rule them all) or an attempt will |
| 53 |
>> > fail. The same way you can try to unify emerge and apt tools via some |
| 54 |
>> > wrapper manager. |
| 55 |
>> |
| 56 |
>> Fun fact: systemd was created to unify distributions in one init |
| 57 |
>> system. |
| 58 |
> |
| 59 |
> Exactly. This case is perfectly covered by https://xkcd.com/927/ :) |
| 60 |
|
| 61 |
Well, I'd argue the case for "not 'perfectly'", because for better or for |
| 62 |
worse, systemd has had rather more luck at cross-distro init-system |
| 63 |
unification than that comic suggests. There's still special-cases like |
| 64 |
small embedded where systemd simply won't fit, and there's still a rather |
| 65 |
strident no-special-case opposition, but virtually all the "don't care as |
| 66 |
long as it works" distros are systemd, now -- the middle ground simply |
| 67 |
isn't there any more, it's all systemd. |
| 68 |
|
| 69 |
That's rather more successful as a unifying standard than the comic |
| 70 |
suggests, so while the comic does cover the general situation and perhaps |
| 71 |
matches the first few years near perfectly, as the situation has evolved |
| 72 |
by now, the punchline panel would have to be rather different to be a |
| 73 |
"perfect" cover. |
| 74 |
|
| 75 |
-- |
| 76 |
Duncan - List replies preferred. No HTML msgs. |
| 77 |
"Every nonfree program has a lord, a master -- |
| 78 |
and if you use the program, he is your master." Richard Stallman |
Archives