On Jan 8 2008 16:52, Tuomo Valkonen wrote:
quoted text
>
>> I can recommend that you try another distribution then.
>
>They all suck.

Roll your own.

quoted text
>Typically distros' stock kernels load the intorable integrated buzz-chip
>as the first sound card,

While that is true, configuration tools such as, ads aside, yast2 
(designed for those "idiots" you referred to with 'WIMP idiot box') has 
a setting for which card should be loaded first. "Power users" may still 
use the index= option of sound card modules and wire it up in 
/etc/modprobe.d if they prefer.

quoted text
>and the wrong network adapter as eth0.

You can guess my answer: udev will fix it. And actually, udev will 
record the MAC address and the device name the first time it encounters 
a new device, hence will always use the same interface name for a MAC 
address. So the MAC--interface mapping may be wrong on the first 
install (until you 'fix' the mapping so that it is to your liking), 
but will remain the same afterwards.
Exempt are some nvidia-based weirdo chips which assign a random 
MAC at every boot.

quoted text
>SATA and 
>USB disks appear as some randomly ordered scsi nodes, and so on.

Well what do you expect of it? The kernel does not keep USB port <-> 
SCSI device mappings. Neither USB device <-> SCSI device mapping, 
because not all USB ports or USB devices are mass-storage devices.
It just is not the kernel's job.

Now that you mention that, 
/dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026 always has had the 
contents I expected it to have. Wonder how that comes!? Don't tell me 
you are using those old-fashioned /dev/sda - that would be negligent. 
Some/most(?) distros do not follow /dev/disk consistently yet, so you 
are free to blame them. Not to forget that udev makes this possible :)

quoted text
>This could be configured with udev if one were willing to learn -- for 
>a fundamentally very trivial task --

Nothing to configure, this is standard udev configuration file 
boilerplate and comes prepackaged. Upgrade udev to version 114 at least.

quoted text
>yet another wheel-reinving unnecessarily
>cryptic piece of shit, to tolerate distros breaking your cryptic config 
>constantly,

Mine plays very well.

$ cat /etc/crypttab 
home /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part2 none 
cipher=aes-cbc-essiv:sha256

and /dev/mapper/home is a fixed name.

quoted text
>and to tolerate its intolerable slowness at boot. (/dev should
>still be the UI for modifying dynamic device mappings, reacting to ln, mv,
>chmod, etc., instead of being reduced into a race-condition ridden tmpfs
>shadow, that loses your normally created symlinks and permissions at boot.)

May I remind you that the kernel also "loses" all your network interface 
configuration, routes, firewalling rules and all sysctl settings at 
boot (sic: reboot & powerdown).

quoted text
>But the stock kernels also takes age at boot in (trying to) load a zillion
>unnecessary drivers.

Distros have to decide whether to

- not autoload a zillion of modules, potentially generating lots of 
crying "idiot" users

- autoload a zillion of modules, potentially firing you up.


quoted text
>They need to be configured to not load them. But
>_obviously_ they won't use a _simple_ listing of the modules to load
>(/etc/modules), but demand complex initrd editing.

Nonsense. The kernel notices udev about all available hardware and udev 
will load modules. It has nothing to do with initrd, in fact, this very 
step of loading a gazillion of modules is done after initrd has passed 
control on to /sbin/init. At least, in opensuse.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/