SUSE vs. Debian (lindows)

[Net Llama!]

On 01/18/04 12:52, Joel Hammer wrote:
> On Sun, Jan 18, 2004 at 08:23:37AM -0800, Net Llama! wrote:
> 
>>On 01/18/04 07:26, Joel Hammer wrote:
>>
>>
>>>I blew away my debian (lindows) box (make modules_install
>>>is a dangerous command). It wouldn't boot anymore.
>>
>>I don't follow you at all.  I don't see how installing modules is 
>>dangerous, or how it can prevent you from booting the OS.  This sounds 
>>like PEBCAK to me.
> 
> 
> If modules required for the kernel to run properly are
> missing, the kernel doesn't function, like reiserfs and
> scsi modules.  If the new and old kernel have the same
> version number, make modules_install overwrites the modules
> that the old kernel requires with the newly compiled
> modules, and it looks like the old modules are erased.

Unless lindows or debian have seriously deviated from the stadard 
modutils behavior, this is most definitely untrue.  Nothing gets erased. 
  "make modules_install" does exactly as its name implies, it installs 
the modules that your kernel build created.  _NOTHING_ gets deleted, 
erased, removed, or purged.

> After the new kernel won't boot, as has been my unhappy
> experience, the old kernel won't boot either because of
> the missing modules. (Or, the old kernel with the SAME
> version number reports that the version of the new modules
> is wrong.) This happened in SUSE and lindows. It was very
> unexpected in SUSE because the original kernel had some
> suffix like -athlon, but the modules required for the
> original kernel were overwritten by the newly compiled
> modules. It wouldn't boot.

Something is very wrong with your kernels if this is what is happening. 
  I've never had this happen, even when rebuilding the same kernel version.
>>>in /etc/init.d, was not automatically configured. You had
>>>to do that yourself! So, I was not too impressed.
>>
>>Ok, so that's SuSE.  What about the other distros out there?  BTW, which 
>>daemons did you expect to have automatically configured in /etc/init.d ?
> 
> 
> apt-get lprng
> apt-get sendmail
> 
> both configured the daemons to run out of /etc/init.d.
> I did have to supply a printcap file and run checkpc -f,
> but that was it for lprng.

Redhat's RPMs create init scripts for both sendmail and lprng (now 
cups).  This sounds like a SuSE problem to me.

>>>other drives.  It has the 2.4.23 kernel, including those
>>
>>Oh, you mean the one with the huge exploit?  That sounds inexcusable to 
>>me.  But seeing how lindows let's you run everything as root, i guess 
>>security isn't a priority for them.
> 
>  
> No, these lindows boxes run behind a firewall in my home,
> so security isn't an issue.

That's funny.  So you're 100% certain that your firewall has no exploits 
whatsoever, and never will?  Talk about putting all your eggs in one 
basket.  And btw, the exploit that 2.4.24 fixed was a local root 
exploit.  Your firewall won't do you any good there.

>>>couldn't do it with SUSE, either. I just don't get the
>>>hang of initrd yet. My next project.
>>
>>initrd is not required to build a kernel for _ANY_ hardware.  You could 
>>always compile the support that you think you need in the initrd into 
>>the kernel directly and get the same result.
> 
> That is my next project. However, SUSE used grub which
> really needs initrd with reiserfs as far as I can

I've never used resierfs, but I'd be very surprised if you couldn't 
compile reiserfs support into your kernel.   In fact I'm certain that 
you can.  At any rate, this has nothing to do with grub (or LILO).

> tell. Lindows used lilo and reiserfs. So, in theory I
> could get by without initrd by building reiserfs into
> the kernel, but unluckily lindows uses scsi drivers to
> talk to my IDE drives (I have no idea why) and uses devfs
> (Now THAT is a complete mystery.).  So, unless I want to
> really modify lindow's approach, by not using those scsi
> drivers and not using devfs, I am stuck with initrd.

Hardly.  Your entire understanding is a bit flawed, to be perfectly 
honest.  Whether you build support into the kernel, via a module, or via 
initrd should be completely transparent to system functionality, as long 
as the route you take is sane.  If the kernel has SCSI support built in, 
and lindows wants to be stupid and treat all harddrives as SCSI drives, 
everything will work fine.  You might get some harmless module load 
failure errors if the SCSI modules aren't there, but that's a cosmetic 
problem, and not a functional problem.

Your explanation of lindows functionality makes it out to be an 
embarassment of a linux distribution.  But that isn't any reaason why it 
can't be dragged back to respectability, kicking & screaming.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
L. Friedman                       	       netllama at linux-sxs.org
Linux Step-by-step & TyGeMo: 		    http://netllama.ipfox.com

  15:30:01  up 42 days, 20:15,  1 user,  load average: 0.55, 0.62, 0.63