Rajko wrote:
On Thu, 29 Nov 2012 17:35:12 -0800 Linda Walsh <suse@tlinx.org> wrote:
Um which list does one post questions about current and future development and current releases on?
This one.
BTW, do you have idea (proposal/solution) how to boot different hardware without initrd, but also without asking users to learn how to deal with kernel configuration and compilation on installation, and later on each kernel upgrade.
Why can't you have the option to have both? I.e. if you want to have it boot from disk, they install package 'disk-boot', that will build it for their system and install it. I'm not suggesting that the default of initrd need be change -- nor that it is right for everyone: I'm saying, 1) don't make it very difficult by moving boot related binaries off of the root partition, and 2) make a package available to those who want to boot from disk but don't have the knowledge or desire to learn how to set it up. I really only need 1) -- don't kill compatibility. But @2 has several variations -- the reason I went to disk boot is because I couldn't get native text console output and I had a problem during boot that I couldn't analyze from initrd. The best I got from grub/initrd was a blank screen until I got a login prompt. I had all the verbose options set, they were ignored. I wanted control-c to break out of hung bootup scripts... wasn't doable without me creating my own intird -- something that is FAR more difficult than creating a kernel (making a kernel is well documented and has several methods, making a suse initrd .. no docs and only 1 right true that changes with each release). Second possibility on #2 is to figure out how to do what all the old unix vendors did -- dynamic config for HW and link that into a cached copy -- no compile necessary. I don't know why this hasn't been done for linux -- a util that allows you to take modules and bind them into the kernel, after the fact, without recompilation.
For you it can be simple to fiddle with kernels and you may consider that not a waste of time, but it is not for me, and even lesser for people that just learned how to download iso and burn it on CD.
---- Wait till you need to make your own suse-compat initrd... then you'll realize why being able to boot w/o one is a godsend.
Dealing with older Vista laptop right now, that is faster from the USB stick with openSUSE 12.2, then Vista from the hard disk I can understand that people want to try it. It is free and it has all that 99% of users need; no need to chase applications around the web.
Please get what I want str8 -- not to eliminate or remove current options, but to restore previous functionality and allow both. Then, ideally, allow for an optional package that handles it as as well or better than dkms does for recompiling modules for each version. I wouldn't want it done during boot -- let me do it in background while I am not waiting for a boot (stupid dkms design...idjots!)... Does that make anything more clear. The reason this came up is that suse is making everything fail if you look at it wrong. They are hard-coding interdependencies into programs so you can't upgrade without taking they whole thing... sorta like windows update. A really horrid case is hardcoding the version into vim for what perl it will allow. The version on windows has no such restriction. It's a suse-only "feature" (vim spec file): %define vim_prereq %{name}-base = %{version} # Explicitly require versioned perl for libperl.so %define perl_requires perl = %(rpm -q --qf '%{VERSION}' perl) vim doesn't require it -- but it's required by suse. You'll not be able to get bug fixes without them also violating your rights, like, "Oh, sorry, court order, says we had to release a mandatory update to remove the C compiler because it allowed hacker programs to be compiled".... (a slightly worse version of amazon deleting purchased books off of people's kindle when they next hooked up for any reason -- due to a lawsuit..which has happened)... I have things break all over the place on full upgrades and critical machines are offline for days, with random failures for months following. That's not acceptable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org