On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tansta...@libertytrek.org> wrote: [snip] > Maybe it is 'full of errors', but is the primary point true?
False implies whatever you want it to imply. You can't prove anything if your assumptions are incorrect. >> There is actually little code inside PID 1; > > > The quoted text said nothing about this, so please stay on point. I was answering to someone else. > As to the point raised: > > >>> Can you surgically remove systemd in the future without reverse >>> engineering >>> half of what the LSB would look at the time, or will its developers >>> ensure >>> that this is a one time choice only? > > >> You guys talk about software like if it was a big bad black magical >> box with inexplicable powers. >> >> If someone is willing and able, *everything* can be "surgically >> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank >> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, >> and ESD. KDE got rid of aRts (and who knows what more). > > > I think you are being a little disingenuous here. I am not. > The obvious unspoken meaning behind the 'can you surgically remove' was: > > Can you do it *easily*? I'm sure you would not suggest that getting rid of > the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. But it can be done, and that's a indisputable fact. > It simply doesn't matter if systemd boils down to one monolithic binary, or > 600, if they are tied together in such a way that they can not > *individually* be replaced *easily and simply* (ie, without having to > rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are "easily and simply" replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. > That said, it seems to me that, for now at least, it isn't that big a deal > to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. > So my main concern is - will it still be possible - *and* easy - in a year? > Three years? Five? If the answer to *any* of those is no, then I think the > best solution - for gentoo at least - is to make whether or not systemd is > to be used more like a *profile* choice - a decision that you can make at > install time, similar to choosing between hardened or not (not easy/simple > to switch to/from after a system is up and running). That's how it works right now, because Gentoo developers *did* the work. And the whole point of my "willing and able" mantra is to see if someone here steps up into the plate. It's *really* easy to say "oh, systemd should be provided by a profile so the user is free to CHOICE if she wants to use it or not", but *someone* has to write the necessary support so that the profile actually exists. You want to be sure your choice is not "taken away" from you? Join Gentoo and help to make that choice possible. Don't expect that someone will do it for you. There is a lengthy discussion in gentoo-dev about the problem with understaffed arch teams. It's worth a reading, but the general consensus is that the minor archs cannot be kept in stable if there are not enough developers for said arch to do the testing. It sucks? Of course it sucks; but there is no magical fairy that automatically will keep working all the ebuilds for all the archs in Gentoo. SOMEONE has to do the testing, someone has to triage bugs, someone has to *fix* them. If there is no one, then the arch cannot be kept in stable. And that's a hard cold fact. If *all* the Gentoo developers switched to systemd (highly unlikely), then how could they support a separated profile for systemd? They won't, and your "choice" will then be "taken away". If the Gentoo developers decide that having systemd in a separated profile is too much work (likely, even now), then what? More whining from users because they "took away" their "choice"? They could whine all they want, but if nobody steps up to the plate to do the actual work, nobody (necessarily) will do it for them. > In fact, it seems to me that, since (from what I've read) the primary reason > that systemd was written in the first place was to provide extremely fast > boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool technologies the kernel provides, and that it could solve problems like: how to easily and consistently start daemons with well defined semantics for its dependencies; how to easily and consistently apply resource quotas to them; how to deal with modern computers where hardware comes and goes (including CPUs) all the time, etc. [2]. > having it be a choice made by selecting > a corresponding *profile* is the *ideal* solution - at least for gentoo. At > least this way everything could be documented, and switching between a > systemd and non-systemd profile can be supported for as long as possible, > understanding that at some point in time it may have to become an install > time choice - kind of like choosing between hardened or not is mostly an > install time choice now. That profile idea sounds even reasonable. But I don't think the devs will implement it, since simple dependencies seems to work up until now, and *someone* would need to write the profile, and *someone* would need to test it, and *someone* would need to triage bugs for it, and *someone* would need to fix them. If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. Regards. [1] https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq [2] http://0pointer.de/blog/projects/systemd.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
