On Thu, Dec 27, 2012 at 10:00 AM, pk <pete...@coolmail.se> wrote: > On 2012-12-27 02:14, Canek Peláez Valdés wrote: > >> I really think that's the crux of the matter Pandou: udev/systemd >> serves to the wants of the many. The eudev fork serves to the wants of > > systemd+udev serves the "large mass" (users of mainly Fedora and other > distros using systemd) that doesn't care/know computers.
Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. >> a very few which really don't want an initramfs, when it has a lot of >> technical advantages. It has some problems, of course, but we can >> solve those, and solve the problem *in the general case*. Which is the >> one that it's important ant interesting. > > It's unimportant and uninteresting on the terms that > Poettering/Sievers/Greg KH put forward, for us that wants control and > does not want an all singing and dancing system (incl. "kitchen sink"). > In my opinion the init system should be completely independent of the > kernel with a well defined, generic, interface so that the user can > choose and pick whatever pieces he/she wishes to run his system. Think > "Lego" (as in small, well defined pieces that fit together in any way > the user sees fit)... And how's that changed? If you want control, you will *always* have control. The source code is out there; what more control do you need? >> my wishing luck to the eudev fork (which, BTW, Greg also did). The few > > The way I read Greg's "good luck" was that it had quite a bit of a > sarcastic tone... Was there really any need for him to say anything at > all? I've previously had a lot of respect for Greg but this made me > think quite a lot less of him... That's how you choose to interpret it, and I'm pretty sure it was not the way Greg said it. >> of us who *dare* to praise udev/systemd get an incredible amount of >> crap for it. We are nothing but fanbois or, in your words, "udev has >> become like the cosmos: everything there is, and ever shall be." >> Really? I didn't knew that. > > You really sound like a fanboy... And I don't mean that in a derogatory > way; it's just how I see your writing... It does sound derogatory... >> Maybe we are doing it wrong. But as far as i can see, we are only >> expressing our opinion on technical grounds. We are not calling names > > Your opinions (technical or not) doesn't matter to me since (it seems) > you have a very different goal than me with your system. I want you to > enjoy whatever system you use but you shouldn't try to force that same > system on to me. In that regard I see the eudev fork as a saviour. What *I* am forcing on *anyone*? How could *I* force *anything* on *anyone*? I'm just stating why I believe udev/systemd is a nice solution to the general problem. That's all: I'm not a developer, I'm not a distro planer; I'm not in any way capable to enforce anything on anyone. And I, if I'm allowed to repeat it, have never called names on anyone. I'm just stating my opinion; how could you twist that into the idea that I'm trying "to force that same system on to me"? Really? > These are the technical grounds that I've seen you state: > > * fast boot time > Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to > XDM for me. The few seconds that it takes to boot from grub to login is > of no matter (to me). It matters to me. A lot. Specially in my laptop (I follow vanilla-sources unstable, so I reboot relatively often), in my media center (same reasons). In my servers certainly the hardware initialization phase is longer; but (IMO) that makes even more important the speed gains from grub to userspace. Please, understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * parallel service startup > Nice to have but still irrelevant, see above. Sequential is also > preferred from a trouble shooting perspective. Furthermore I like having > the ability to stop a particular daemon if there something that needs > fixing (pushing "I" when booting). Relevant for me, see above. And that's another thing I hate about the shell init scripts; problems get "workarounded" instead of properly fixed. If there is a problem at boot time *it should be fixed where the problem lives*, not "workarounded" with shell hackery. Again, please understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * "simple service unit files" > Simplicity is fine but to accomplish the same in your simple "service" > file as in the example you brought forward (sshd) you need to hide a lot > of stuff elsewhere. Not for me thanks, I'm a control freak. I'm not; let the machines do the work. The least I have to think about my system, the better; I care only for it to work. Again, please understand that my above (↑) reasons doesn't mean I don't care about yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * good documentation > I haven't read it so I won't touch this. Not a technical point though, > more of an opinion. Although I agree that good documentation is very > nice to have. Common ground. > * "Really good in-site customization" > If I choose to upgrade a daemon, I should be interested in what changes, > if any, that brings in configuration in order to not have any surprises > later. If you think that's a good thing, that really sounds like you > would be doing the OpenRC equivalent of: > 'etc-update --automode -5' But that's the beauty of systemd; I don't have to do *anything*. If the original unit file gets updated, my customization gets updated to. Again, I don't need to do anything. Again, please understand that my above (↑) reasons doesn't mean I don't care about yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * control groups > As I understand it, this depends on someone writing config files for the > individual daemons. Noone is stopping Gentoo devs or anyone else from > writing such. And I would, again, prefer to go through a good manual or > a "howto" and do it myself so that I can understand the consequences, if > I would want it. It's a little more difficult than "writing config files", in OpenRC's case. To begin with, you need to check if there is cgroup support. Again, please understand that my above (↑) reasons doesn't mean I don't care about yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * unification > I've tried quite a few distros over the years (starting with Redhat in > the late 90'ies) and Gentoos OpenRC is by far the most sane system I've > come across. Never going back to Redhat hell thank you! Standardizing > the interfaces is fine but it's not ok to force a whole "kitchen and > sink" solution in order to "satisfy" as many as possible. This is not > the Gentoo way, as I understand it. Gentoo is all about choice. And who has taken any choice from you? Even if systemd became the default init system in Gentoo, you will be able to install OpenRC always. Even if there is no ebuild, you'll be *always* able to do "./configure && make && make install". Nobody is taking choices from anyone. I just want udev/systemd to work fine in Gentoo (which it does) and not having to install OpenRC if I don't need it (which I need to use my overlay right now). I just want *my* choice to be a 1st class citizen in Gentoo; right now it's not. If Gentoo is (as you say) "about choice" (which, BTW, I don't agree 100%), then I should be able to use systemd without OpenRC without me needing to use an overlay, shouldn't I? Again, please understand that my above (↑) reasons doesn't mean I don't care about yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. > * "you tell the daemon *what* to do, not *how* to do it" > It's good if you don't want to learn about what things you install and > understand what the consequences are of different choices, in the config > files. I run very few daemons on my desktop machine so it's not so time > consuming to read up on/fix things etc. If I ever were to run a full > blown server (esp. connected to the "net") with lots of daemons I would > be very hesitant to use any pre-configurations, seems suicidal to me. > The only usage I see here of "declarative" scripts are when you don't > care about what the machine is doing. I think you are gravely mistaken in this last point: you can learn *all* the things you can from systemd as in OpenRC. The source is out there, nothing is "hidding". But, one last time, probably the best thing to do is to agree to disagree; your answers to my technical points are all basically "I don't wanna/I don't like it/I don't care about it"... which is perfectly fine, but I can retort each and everyone with a mirror argument. So, yeah, let's just agree to disagree Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
