Mailinglist Archive: opensuse (1239 mails)

< Previous Next >
Re: [opensuse] Re: new network interface naming scheme (result of systemd & initrd)
On 6/11/2013 11:07 AM, Andrey Borzenkov wrote:
В Tue, 11 Jun 2013 03:22:41 -0400
"Brian K. White" <brian@xxxxxxxxx> пишет:


In short, asking why someone doesn't want to use an initrd is the wrong
question to start with. Just as wrong as it would be to ask why someone
WOULD want to use and initrd. The answers are unpredictable and infinite
in both cases.

The question is what is the excuse for removing functionality and adding
dependencies? There is none.


Could you remind which functionality was removed and which dependencies
were added? I am serious, I lost myself in this thread. And how is it
related to new network interface naming scheme? :)

Has almost nothing directly to do with naming the interfaces. Changes to the naming schedules may ultimately be caused by changes to please systemd, but I don't really know that first hand so I'm not stating that.

There are infinite functionalities removed by using systemd instead of sysv init scripts simply because of the fact that you can write anything you want into a shell script, which you can not do in a systemd unit file. Even if the unit file specifies to run a script, that is already too late to do what the original script and init could be made to do. There are many other issues which it would be silly and tedious to try to relist here. Just google systemd sysv and read until you are sick of reading about the topic :) No one wants me to go into it here. It will be a very long post.

Dependencies was a general comment, in this case mostly just requiring an initrd to boot in all cases instead of having it be an option.

Initrd is a very useful thing. I don't hate initrd. In some cases I would like to stuff an entire OS into initrd. I wouldn't exactly consider it progress if the option to use an initrd went away. It just needs to be an *option* instead of a *requirement*.

Other dependencies which kill me are things like the systemd binary syslog database instead of directly readable text by things as basic as cat, or even dd, or even the shell itself with no external binary at all not even cat. And the graphical boot/plymouth/splash stuff that ends up requiring a lot of stuff to be in intrd. And the merged /usr stuff that ends up requiring a lot of stuff in initrd also, simply because there is no longer a set of basics in "/" at boot, which is a "progress" driven by systemd. systemd requires a kernel that has cgroups. systemd requires dbus! yegads dbus in init.

If you can have both initrd and plain kernels that is the best.

Sometimes your initrd is good while your system is broken, sometimes your system is good while your initrd is broken.

Neither way is the one true way. You need both. Or at least you need the option for both even if one is used 99% of the time.

Options and freedom are always better and confer more advantages than the advantages conferred by having strict requirements and limited choices.

The idea of limiting choices is standardization, which is a good thing as far as it goes. A little bit of choice-limiting to bring standardization ends up giving you freedoms you didn't have before. You have the freedom to make assumptions about how things work, which lest you do things you couldn't do otherwise. But you can get the benefits of standardization without removing choices. Good standardization just provides a framework from within which to have all the same choices. Good standardization is also *optional* instead of a hard requirement.
Good standards try to account for every possible need. *Really* good standards recognize that this is a valid ideal, but merely an ideal to always strive for but is also impossible to actually attain, and so they include a *graceful* way to draw outside the lines when you have to.

Only the worst kind of inconsiderate sophomore tells everyone else what they don't need.

--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >