XPost: comp.os.linux.development.system   
      
   In comp.os.linux.development.system Aragorn    
   wrote:   
      
   |> It does not mean module loading is disabled.  But it would mean that any   
   |> kernel level driver support for the video card would be built-in.   
   |   
   | As I have mentioned before, this might cause compatibility problems in the   
   | event that you'd be loading certain proprietary video drivers as modules.   
   |   
   | I already gave the example of how the GPL'ed /nvidiafb/ does not work well   
   | with nVidia's proprietary and binary-only driver module, and thus you are   
   | left with the choice of either using /nvidiafb/ on its own, or - if you   
   | want a framebuffer driver - using /vesafb/ for character mode in   
   | combination with the proprietary nVidia driver for X11.   
      
   And having module loading still available does not fix this?  I don't think   
   I understand your wording here.   
      
   The way I udnerstand it, module loading can be left enabled, and that can be   
   used in those special cases where a module is the only practical choice.   
      
      
   |> The focus is on how such a distribution would configure the kernel it   
   |> builds as part of the installation process, including what options it   
   |> gives to the user, how it presents this, and what automatic configuration   
   |> it may use.   
   |   
   | See the paragraph in which I mention scripting in combination with hardware   
   | diagnostics tools and a generic modular kernel for deciding which drivers   
   | to statically link into the kernel, but what would be the point of that if   
   | you're not going to site-optimize your kernel completely?   
      
   Doing it for all drivers in the kernel would be the way to go if that is the   
   desired direction.  Then you still leave modules for the cranky stuff like   
   a video card that has no open source support (e.g. manufacturer won't support   
   the open source effort).   
      
      
   |> The English language is full of bad and erroneous nomenclature.  I have   
   |> learned as early as high school to just "go with the flow" and use what it   
   |> is that other people use, if you want to be understood.  In cases where   
   |> there are some people that know one term, and others that know another,   
   |> you just have to figure out who knows which.   
   |   
   | Sure, you can go with the flow, and then you'd be taking the easy way out.   
   | Or you can do the right thing, name things right and be misunderstood or   
   | even scolded or called anally retentive.   
   |   
   | It's not an easy choice, but I think the news broadcasts of every day show   
   | you that most people go with the flow and that this is why our world is   
   | such a mess.  It may be somewhat of a stretch, I know, but I myself prefer   
   | doing things the right way, even if that means going in against the   
   | mainstream.   
   |   
   | But then again, I have always been considered rather eccentric, and I have   
   | also always been misunderstood. :-)   
      
   I'd rather do things that way.  But the English language is quite weak for   
   so much of that.  Not enough words?   
      
   Maybe we should all switch to Esperanto.   
      
      
   |> You can push a specific terminology of your own.  For example, I have   
   |> tried to push the term "cetal" to refer to base-16.  It really isn't   
   |> necessarily right or wrong.  But it's root ("cet") is a commonly used   
   |> Latin derivative used for 16 carbon chemical compounds in the same way   
   |> "oct" is used for 8 carbon chemical compounds.  It has a historical   
   |> meaning for 16.  But no one has adopted it, so I have to use what the   
   |> world uses.   
   |   
   | Yes, I come from a scientific education background myself and I understand   
   | what you're saying.  Nice touch, by the way. :-)   
      
   I do use it in comments of my own source code.   
      
      
   |> | For instance, people say "X Windows" instead of "the X Window System",   
   |> | they say "folder" instead of "directory", they talk of "dimensions" as   
   |> | if a dimension were a plane of existence/reality instead of a vector in   
   |> | a coordinate system, they say "tremolo" when they should say "vibrato" -   
   |> | for those of you familiar with electric guitars ;-) - or Apple users   
   |> | typically refer to /x86/ as "the PC", suggesting that a MacIntosh isn't   
   |> | a PC, and ever so on... :-)   
   |>   
   |> Go with the flow unless you have the means to change everyone.   
   |   
   | I'm afraid that it would go against my personality - this particular thing   
   | could very likely be related to my Asperger Syndrome, though - to "sell my   
   | soul" and run with the pack when I know the pack is headed the wrong way.   
      
   I know the feeling.  But one has to work around the AS to some extent to   
   deal with people because they don't know how to deal with people with AS.   
      
      
   | As strange as it may seem - and I do leave other people a very wide margin   
   | or error - I myself cannot do something of which I know it is wrong.  It   
   | would make me highly neurotic.  But like I said, that may be the Asperger;   
   | sometimes it's difficult to draw the line between what's a trait of my   
   | personality and what's a trait of my neurological condition.  Maybe there   
   | is no such line, even...   
      
   AS with a hint of OCD?   
      
      
   |> |> What would be a better name to work on getting people to use, instead?   
   |> |> Static kernel (as opposed to dynamic kernel)?   
   |> |   
   |> | Close... ;-)  The generally accepted name for it is "a statically linked   
   |> | kernel", and the drivers in such a kernel are called "in-lined drivers"   
   |> | or "statically linked drivers". ;-)   
   |>   
   |> What is the short descriptive term, as opposed to the articulated term?   
   |   
   | Ehm.... "statically linked kernel". :p  Or "non-modular", if you want it   
   | shorter. :-)   
      
   I'll use "static kernel" for now and see how that plays.  That's no more or   
   less accurate than "statically linked kernel" if one figures out that it is   
   about linking.  If module loading is still enabled, then technically it is   
   a "mostly statically linked kernel" anyway to account for a module that can   
   be loaded later.   
      
      
   |> Of course.  And how is the kernel a given distribution installed   
   |> configured with respect to these settings.  They made a choice somewhere   
   |> even if it is the kernel they built and packaged as a binary.   
   |   
   | Yes, distribution makers have to make a choice, and so they go with the "one   
   | size fits all" approach.  No processor-specific optimizations but just   
   | slower generic /x86-32/ code or /x86-64/ code, full kernel preemption for   
   | desktop kernels, no kernel preemption for server kernels, SMP support for   
   | up to 32 processors in all of their kernels, symmetric multithreading   
   | support, multicore balancing support, SELinux support in server kernels,   
   | PAE on 32-bit server kernels, et al.   
   |   
   | But then it's still left to the user to choose which kernel he or she will   
   | be running on that particular machine.  So they typically supply multiple   
   | kernel types.   
      
   I'm looking at building something for embedded systems.  That is, of course,   
   quite a different thing than a "static kernel distro" for a hosted system.   
   If the "SKD" did have user input features, that might have ideas I could use.   
      
      
   |> | So you see, you could garner a lot of information regarding the hardware   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)