[opensuse-factory] Re: Why is initrd needed - to support moving bin files from root->/usr? That requires extra patches by Suse.

Brian K. White wrote:
Custom built kernels are probably a support nightmare.
----- How is a custom built kernel any more of a support nightmare than a custom built initrd? At least with the kernel, you can list out the config and easily see what went into it. Is there a proc interface for listing out the contents of initrd? I call phooey on this FUD... the initrd is more customized than any kernel. The kernel has a common interface for customization across all distros -- but show me the common initrd interface. The initrd interface is worse in this way and every way mentioned so far.
I don't fault them for using initrd, but I do think it sucks that they deliberately make it essentially required when it doesn't have to be.
---- At one point, it was an easy way out -- because it JUST contained the modules you needed to build -- it wasn't a custom boot disk.
Using an initrd is a downgrade in some cases. _Requiring_ it is an even bigger downgrade in general, as it's a loss in flexibility and in some cases a loss in efficiency.
I don't think xfs is a reasonable default fs for a linux distro like opensuse either. There are special linux distros that target security and reliability above all else, including at the expense of performance. I don't think suse was ever one of those. It was a general purpose OS that now targets desktops. xfs is not the best fs for desktops nor even for all servers.
---- It is the best for servers, and it was part of a C2-evaluated security distro (Trusted Irix) before linux existed. But it was developed to meet the needs of the media creation industry who needed to write real-time media steams -- no other file system could do that at the time, and no other file system today has it's benefits in handling media files. Where it is weak is in handling tiny bits of info -- and then -- only really on deletion. It tries to be efficient -- to the point that it will store data and/or access information in the inode if the amount is very small you have large enough inodes. But there are some features in NON-unix standard FS's that have potential for being better than XFS -- ZFS and BTRFS... maybe... have to see where they end up.. right now, ZFS is slower due to implementation and BTRFS still is in early development.
But opensuse isn't all linux itself, it's just opensuse. Every distribution takes pieces from the world of available code and packages them up in different ways that serve different needs.
The targets opensuse serves has shifted from those suse used to serve very well that's all. It's not a crime it just sucks for us.
--- Not a crime, BUT it was a distro that was general purpose and one of the best... there is no other distro that has what Suse had -- or even what suse could have again if it really turned around. My last boss bet me suse would be out of business within a year -- that was back in 2001. I never take bets - but at the time, it was a safe bet, as I knew it had at least 3-6 years more, minimum. now...If the distro doesn't change directions -- it will be gone or a bit player in 3-5 and I don't see another similar one on the horizon with the same stability that OSuse had.
I don't like that opensuse has veered off from the kind of distro it used to be, because I was well served by what it used to be and I am not well served by what it is now, and it means I now have to do a bunch of work.
But some of these things you're arguing are not really just. They should be allowed for but I don't think they are reasonable to expect as defaults.
---- I'm arguing for not *disallowing* them as default choices. People are saying there is no choice but to do "X", I am pointing out alternatives at every step and every point that belies that fact -- not that I am trying to convert everyone to my choices -- but I will fight to show my choices as solving all of their problems as long as they continue to hold up their problems as unsolvable and needing to kill off my choice as a consequence. What's happening is that they want to make sure there are no alternatives. That's really what is going on. Then they can more easily control the end user just as MS controls most of the afterboot env after win7 and and felt comfortable wiping out the desktop in win8. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-21 01:04, Linda Walsh wrote:
Brian K. White wrote:
Custom built kernels are probably a support nightmare.
----- How is a custom built kernel any more of a support nightmare than a custom built initrd?
Seconds against hours. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCsHjoACgkQja8UbcUWM1wY/wEAgBHdQX7bgbJCmOSWiSceK2lR 06AZe1ZVq0XatMX5LwQA/0/CmdqXWfFOX896flmGYsoWYOjt/qFonmCEHCeHOHHr =yGfx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:
Seconds against hours.
Seconds? to Hours? for a user to regenerate their kernel in the field? Factory could stick w/initrd, but my suggestion was to allow users to optimize that to direct boot by installing & running a direct boot package, that compiles their kernel with needed mods built-in. How can that take hours? The only diff is that instead of those modules going onto an initrd they are built-in, and then there is no need for an initrd to boot. Compiling kernel locally, a few minutes... likely <5 on a slow machine. Mine takes 129 seconds w/335 loadable modules, on a 2.8GHz machine -- but it doesn't generate an initrd -- that usually adds an extra 25% last I did it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-11-22 02:12, Linda Walsh wrote:
How can that take hours?
It takes hours on some of my machines. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlCticAACgkQja8UbcUWM1wtBAD7BkoiEN3dmbHjn0EzZRS9fG8C +2RBrPYOyO0jjp19nOMA/i4Hn1lLlkzEdLUCulnAhDTDwxF0iApu1FSLfkqaC4Ja =mixo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----Original Message----- From: "Linda Walsh" <suse@tlinx.org> Sent: Wednesday, November 21, 2012 8:12pm To: "oS-fctry" <opensuse-factory@opensuse.org> Subject: [opensuse-factory] Re: Why is initrd needed - to support moving bin files from root->/usr? That requires extra patches by Suse. Carlos E. R. wrote:
Seconds against hours.
Seconds? to Hours? for a user to regenerate their kernel in the field? Factory could stick w/initrd, but my suggestion was to allow users to optimize that to direct boot by installing & running a direct boot package, that compiles their kernel with needed mods built-in. How can that take hours? The only diff is that instead of those modules going onto an initrd they are built-in, and then there is no need for an initrd to boot. Compiling kernel locally, a few minutes... likely <5 on a slow machine. Mine takes 129 seconds w/335 loadable modules, on a 2.8GHz machine -- but it doesn't generate an initrd -- that usually adds an extra 25% last I did it. ------------- (Rackspace webmail, sorry for no quote formatting) Back on SCO, from Xenix to the last OpenServer, (I never used Unixware except in the form of I played with OSR6 long enough to hate it) kernels were generated by linking modules into the kernel and it was easily as reliable as current initrd generation, and easily faster. Even on really ancient hardware it only takes a couple seconds. And no initrd. So the compile-time argument is not ultimately necessarily much of an argument. Yes it takes hours (MANY, on my vaio P) to compile an entire linux kernel plus modules from scratch. But for the purposes of distribution support and administration, a custom kernel doesn't necessarily have to entail that. For linux there is already dkms as has been mentioned, and it's reasonably fast, compiling just a single module. And the proof of the basic idea of module linking and custom kernels in users hands has already been proven viable since at least 20 years ago. By support nightmare I just meant support people having to wonder what you did to your kernel as one of the first steps in every single question about anything. I love the _option_ of an initrd. Having an entire system loaded by the bootloader from a single file via tftp/pxe and running entirely in ram, thus giving you a way to skip right over all kinds of breakage, is "Real Damned Handy(tm)" sometimes. But it's anti-progress to make it a requirement. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
brian@aljex.com
-
Carlos E. R.
-
Linda Walsh