User: Password:
|
|
Subscribe / Log in / New account

The case for the /usr merge

The case for the /usr merge

Posted Jan 27, 2012 21:32 UTC (Fri) by nix (subscriber, #2304)
In reply to: The case for the /usr merge by gb
Parent article: The case for the /usr merge

Most of these are actually good ideas.

initramfs: without it, a *lot* is impossible. No heavily modular kernels. No rootfs on LVM. No rootfs on md/RAID. No rootfs on any other filesystem requiring userspace involvement to mount. No rootfs over the network (sounds silly for most machines until you have a disk failure and can revive the system, temporarily mounting everything over the network, with a one-line change). The list goes on and on. And the cost of the initramfs? These days, nearly nil.

dbus: we didn't have a decent RPC mechanism on Linux before now. SunRPC is dead and a security nightmare to boot. The service invocation stuff is nice too, no longer do we need scads of always-running daemons for rarely-needed jobs. The XML configuration file swarm is a horror, I wish they'd picked something, *anything* else. But we can't have everything.

network-manager: useless-verging-on-destructive on machines with wired networks doing lots of persistent network connections to other machines (e.g. remote filesystems). Bloody useful in dynamic situations, e.g. laptops with wifi. Which is these days a pretty common case.

KMS: video drivers in userspace were a nightmare to keep working, and there are lots of things they simply cannot do: a lot of the jobs necessary to keep modern video cards happy requires privileged support, some of it requires interrupt handlers (which is a kernel-only thing), much of it requires a full-blown memory manager to manage memory on the card, which will only work if the video driver is shared between X instances, which means the kernel again or some sort of cross-user, cross-X-instance daemon. Drivers for hardware in userspace sometimes work OK, but normally only if driving the hardware is simple (e.g. USB, and even there the job of driving the actual USB hardware is down to the kernel). Video cards are by some distance the most complex hardware on the system: driving them from userspace was always backwards, and was dragging X down.

gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.

pulseaudio: as long as we have to have a software mixer -- and we do, modern sound cards don't do hardware mixing -- we may as well make it a nice capable one. When you do that it turns out that nothing it has to do requires kernel-side operation, and for the non-pro-audio use-case of pulseaudio millisecond latencies are not required, so you might as well implement it in userspace. I note that you cannot simultaneously damn pulseaudio for being in userspace and KMS for being in kernelspace while remaining consistent.

The reason why a lot of these are RH ideas is because RH does so much of the work to keep Linux infrastructure going.


(Log in to post comments)

The case for the /usr merge

Posted Jan 28, 2012 14:44 UTC (Sat) by Los__D (guest, #15263) [Link]

> gconf: well, OK, I'm a KDE man and prefer the ini-files-and-ksycoca thing. gconf *is* horrible and has no right to exist: there are better ways to provide performance as good as binary deserialization without needing all your configuration to spend all its time living in a binary lump.

Errrr, GConf is not using a binary lump... It is using directories and XML files.

The case for the /usr merge

Posted Jan 28, 2012 15:02 UTC (Sat) by nix (subscriber, #2304) [Link]

I thought it could use both, but preferred binary lumps?

... oh, hang on, that's *d*conf, isn't it, where the d stands for 'a letter earlier than g in the alphabet' or something like that. I always get them mixed up.

gconf

Posted Jan 29, 2012 0:22 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link]

..in fact, gconf really is excellent. It:
- Has an underlying XML filestructure, which is possible to manually edit (though not so good as the .ini format), and these files can be copied around like other dotfiles.
- Has a CLI interface, gconftool-2, which lets you get and set certain keys. This is REALLY(*) useful.
- Can support changing settings in real-time (across multiple instances of the app without restarting the app, and even without needing an "Apply" button).
- Has a GUI editor: gconf-editor, which is useful for finding the keys whose name you don't know.

(*)For example, I've set up a new system. I want to preserve most of the system defaults, and especially if there is a new feature I don't know about, I don't want to remove it from the conf-file. But there are about 20 settings I really want to keep. So I have a script with lots of lines such as:
gconftool -t string -s /apps/metacity/general/button_layout 'menu:minimize,maximize,close'
I can run these commands inside a running GNOME session, and they immediately take effect.

[Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]

gconf

Posted Jan 29, 2012 11:38 UTC (Sun) by k8to (subscriber, #15413) [Link]

You lost me at "excellent ... XML".

gconf

Posted Jan 29, 2012 22:49 UTC (Sun) by Los__D (guest, #15263) [Link]

I was just waiting for an ridiculous comment about XML... A there it was.

gconf

Posted Jan 29, 2012 23:09 UTC (Sun) by k8to (subscriber, #15413) [Link]

That was actually a pretty reasonable one. I could make a ridiculous one if you want.

gconf

Posted Jan 29, 2012 15:27 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> [Sadly, KDE doesn't have such a system, as far as I can tell. It's impossible to script the setup of a KDE system in a non-brittle way]
KDE does have tools for that purpose. Check out kwriteconfig/kreadconfig. It doesn't work as well gconf though. Changes aren't applied immediately, and there's no GUI editor I'm aware of.

gconf

Posted Jan 29, 2012 15:41 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link]

I know of kreadconfig/kwriteconfig. Unfortunately, it doesn't work at all well - you have to already know which file the setting is in, and details of the setting name and the ini-file grouping. kread/writeconfig are simply a friendlier equivalent of 'sed' that speaks the .ini format.

The way this should work (and I filed a bug on this years ago) is that kcontrol ought to expose every single field in the GUI via DCOP. Then it would be easy to find out what keys to use. At least a way to recursively dump all the kreadconfig keys would be nice...

gconf

Posted Jan 30, 2012 2:34 UTC (Mon) by HelloWorld (guest, #56129) [Link]

Huh? You can explore the configuration simply by looking at ~/.kde/share/config, so why do you need kreadconfig to dump all keys?

gconf

Posted Jan 30, 2012 2:44 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link]

Well, it can be rather tricky to find out which conf-file does what, if you don't already know. If you don't know the key-name, section-name, or possible values, it's not easily discoverable.

BTW, In gnome, the easiest way to derive the changes is this:

1. Start with a clean distro installation.
2. Dump all the gconf keys.
3. Change lots of things to taste, within the GUI.
4. Dump all the gconf keys.
5. Use diff to discover the changes, and generate a script that will make these changes the next time.

gconf

Posted Jan 30, 2012 3:32 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I still don't get it. What stops you from doing just the same with .kde/share/config? diff -r is your friend.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds