XPost: comp.os.linux.development.system   
      
   In comp.os.linux.development.system J.O. Aho  wrote:   
      
   | They don't as you don't know what a user will be using his/her kernel and the   
   | usage of the kernel can change, for example someone has just bought a   
   | computer, the person has a single hard drive, no poin in using RAID here, so   
   | assume they make a monolithic kernel without RAID support, a couple of months   
   | later when the person has enough money, buys a second hard drive and decides   
   | to build up  a small RAID 0 for better disk speed, but no, his monolithic   
   | kernel don't support that.   
      
   Such a system is, from the start, not a candidate for a statically linked   
   kernel.   
   I can run statically linked kernels on MY hosts because I do know what I am   
   doing, and can reconfigure and build kernels easily.   
      
      
   | On the other hand, the it could be the other way around, the distribution   
   | builds in RAID support, but the user will never use it, in this case the user   
   | will waste memory on something he/she never will be using.   
      
   Such a system is, from the start, not a candidate for a statically linked   
   kernel.   
   The admin should install Centos, Debian, Fedora, Slackware, Ubuntu, or some   
   other   
   distribution like that, which are intended for general purpose machines.   
      
   However, someone building the firmware image for a cable TV set top box, may   
   have reason to make a more solid kernel image.   
      
      
   | What about updating a driver, the sound card you are using, is badly   
   supported   
   | in your monolithic kernel and there is a new driver released for it, which   
   | means you need to rebuild the whole kernel. To start using the new driver,   
   you   
   | must reboot (don't this sound familiar from an American operating system?)   
      
   I've seen cases where module drivers won't unload, or the new driver will not   
   load even those the predecessor did unload.  I've even seen cases of a kernel   
   panic apparently due to the new module, which doesn't happen after a reboot   
   (presumably because of some leftover data structs that got changed).   
      
      
   | Modular kernel allows you build a module, replace the module file, unload the   
   | module in memory and then load the new module, and you have updated the   
   driver   
   | without the need of spending time to building a big kernel and no reboot.   
      
   I know how it works.  But I would not considered the avoidance of rebooting as   
   a suitable design direction for a high-availability system/service.  Instead,   
   I'd design such a service so that rebooting can be readily done without an   
   impact.  For example, a root or TLD name server needs to be up 24x7x366.  The   
   classic "five nines" is not even good enough.  I wouldn't depend on any machine   
   to not reboot.  I'd design around that fact that machines _will_ reboot.  Then   
   things can be quite stable when they happen to not reboot on a regular basis.   
      
   So basically I don't put all that much stock in avoiding rebooting.  But I   
   would rather have control over when a machine reboots, so I can do it when   
   I choose, as opposed to having a panic when I wasn't wanting to reboot.   
      
   I also don't put all that much stock in things like RAID.  RAID is useful for   
   cases where the service isn't capable of doing other kinds of redundancy very   
   well.  A database with poor replication features is one example where you   
   need RAID to cover drive failures.  But in other cases like a gauntlet of web   
   servers or DNS servers, I specifically avoid RAID and make use of redundancy   
   in the servers themselves.  Let them reboot every now and then.   
      
      
   |> My interest is in the rare (if not non-existant) distribution   
   |> that tries to install a monolithic kernel, whether the ability to insert   
   |> other modules is, or is not, enabled.   
   |   
   | If there is a such distribution, it's so specific fo the hardware, it's ment   
   | only to run on that hardware and the hardware is quite limited, but the   
   | general population of this planet don't install their own choice of   
   | distribution onto their TV, DVD player, Phone and so on.   
      
   The developer of the firmware for the TV, DVD player, etc, is the one to   
   make that choice.  But they need to make a choice that is rock solid because   
   they (the developer) won't be around to tweak the configuration or installation   
   to correct things or tweak them.  They need to build things solid.   
      
      
   |>  For a distribution to do that, it has   
   |> to make some choices about how it will go about having a compiled kernel   
   |> configured.  I want to see how THAT distribution would make such a choice   
   |> and the end results.   
   |   
   | First of all, people would not choose to use it, as it would imply the   
   | distribution has a long install time (build the kernel) and that you won't   
   | know if it will support what you install next on your computer.   
      
   It wouldn't be for a general purpose computer.  It would be for special cases   
   ranging from special control computers to embedded devices.   
      
   --   
   |WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |   
   |         by the abuse department, bellsouth.net is blocked.  If you post to  |   
   |         Usenet from these places, find another Usenet provider ASAP.        |   
   | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)