| 1 |
Thanks to all who chimed in... |
| 2 |
|
| 3 |
On 2014-02-16 3:27 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 4 |
> On Sun, Feb 16, 2014 at 1:26 PM, Mick <michaelkintzios@×××××.com> wrote: |
| 5 |
> [snip] |
| 6 |
>> You may have lost it in the link that Volker posted (thanks Volker), but this |
| 7 |
>> comment from HaakonKL probably sums it up: |
| 8 |
>> |
| 9 |
>> "... I will give Upstart this though: Should something better come along, you |
| 10 |
>> could replace upstart. I guess this holds true for OpenRC as well. |
| 11 |
>> |
| 12 |
>> You can't say that about systemd." |
| 13 |
|
| 14 |
> I had read that blog entry before. Is full of errors, like believing |
| 15 |
> that everything that systemd does is inside PID 1. |
| 16 |
|
| 17 |
Maybe it is 'full of errors', but is the primary point true? |
| 18 |
|
| 19 |
> There is actually little code inside PID 1; |
| 20 |
|
| 21 |
The quoted text said nothing about this, so please stay on point. |
| 22 |
|
| 23 |
As to the point raised: |
| 24 |
|
| 25 |
>> Can you surgically remove systemd in the future without reverse engineering |
| 26 |
>> half of what the LSB would look at the time, or will its developers ensure |
| 27 |
>> that this is a one time choice only? |
| 28 |
|
| 29 |
> You guys talk about software like if it was a big bad black magical |
| 30 |
> box with inexplicable powers. |
| 31 |
> |
| 32 |
> If someone is willing and able, *everything* can be "surgically |
| 33 |
> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank |
| 34 |
> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, |
| 35 |
> and ESD. KDE got rid of aRts (and who knows what more). |
| 36 |
|
| 37 |
I think you are being a little disingenuous here. |
| 38 |
|
| 39 |
The obvious unspoken meaning behind the 'can you surgically remove' was: |
| 40 |
|
| 41 |
Can you do it *easily*? I'm sure you would not suggest that getting rid |
| 42 |
of the above were 'easy'? |
| 43 |
|
| 44 |
It simply doesn't matter if systemd boils down to one monolithic binary, |
| 45 |
or 600, if they are tied together in such a way that they can not |
| 46 |
*individually* be replaced *easily and simply* (ie, without having to |
| 47 |
rewrite the whole of systemd). |
| 48 |
|
| 49 |
That said, it seems to me that, for now at least, it isn't that big a |
| 50 |
deal to switch back and forth between systemd and, for example, OpenRC. |
| 51 |
|
| 52 |
So my main concern is - will it still be possible - *and* easy - in a |
| 53 |
year? Three years? Five? If the answer to *any* of those is no, then I |
| 54 |
think the best solution - for gentoo at least - is to make whether or |
| 55 |
not systemd is to be used more like a *profile* choice - a decision that |
| 56 |
you can make at install time, similar to choosing between hardened or |
| 57 |
not (not easy/simple to switch to/from after a system is up and running). |
| 58 |
|
| 59 |
In fact, it seems to me that, since (from what I've read) the primary |
| 60 |
reason that systemd was written in the first place was to provide |
| 61 |
extremely fast boots *in virtualized environments*, having it be a |
| 62 |
choice made by selecting a corresponding *profile* is the *ideal* |
| 63 |
solution - at least for gentoo. At least this way everything could be |
| 64 |
documented, and switching between a systemd and non-systemd profile can |
| 65 |
be supported for as long as possible, understanding that at some point |
| 66 |
in time it may have to become an install time choice - kind of like |
| 67 |
choosing between hardened or not is mostly an install time choice now. |
Archives