linux-kernel - Re: The ext3 way of journalling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <slrnfo7drr.c37.tuomov@jolt.modeemi.cs.tut.fi>
Date:	Tue, 8 Jan 2008 17:48:43 +0000 (UTC)
From:	Tuomo Valkonen <tuomov@....fi>
To:	linux-kernel@...r.kernel.org
Subject:  Re: The ext3 way of journalling

On 2008-01-08, Jan Engelhardt <jengelh@...putergmbh.de> wrote:
> Roll your own.

Nah, too much work, and I want all distros to perish.

> "Power users" may still 
> use the index= option of sound card modules and wire it up in 
> /etc/modprobe.d if they prefer.

Another very cryptic directory whose contents say nothing to me.
Configuration files should be self-documenting and editable,
instead having to be created based on long documentation.
The simple /etc/modules -- which at least Debian's stock kernels
do not use -- qualifies, but few other files these days do.

> You can guess my answer: udev will fix it. 

And break everything else, such as my symlinks, permissions, etc. 
I'm not going to learn its cryptic special-case config files for 
such trivial tasks as creating a fucking symlink or change the 
permissions of a file, for which exist general purpose methods:
chmod, chown, ln -s.

> 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.

Mapping everything to scsi nodes is brain damaged. The old hda, hdb,
etc. mappings had somewhat clear correspondence between to physical
evice addresses, and were easy to use without such complicated crap
as udev. Of course, I'd prefer just device unique IDs being used,
where possible... but I'm not going to suffer udev for that.

> Mine plays very well.

I was not talking of encrypted disks but cryptic udev config files,
that the distros are going to break on every upgrade.

> 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).

But traditional /dev does not lose permissions and symlinks. udev 
tmpfs shadow brain damage does. You have to illogically and
inconveniently edit udev's cryptic config files instead, and yet
it in no way stops /dev from being modified.

> 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.

And they most of them cater for idiot users, and the rest for
develors what want to do it all from scratch. Mere power users
who want to tune the system to their needs, but easily and without
WIMPshit (through _simple_ self-documenting configuration files),
are forgotten these days.

> 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.

I've never seen a system that would do so. And I won't use udev.

-- 
Tuomo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/