Linked by Thom Holwerda on Mon 7th Sep 2009 22:38 UTC, submitted by EvilWells
Debian and its clones Developer Frans Pop, author of debtree, posted an article showing the evolution in size of the GNOME desktop environment in recent Debian releases. The picture he paints isn't particularly pretty: the default GNOME install has increased drastically in size over the years.
Permalink for comment 383085
To read all comments associated with this story, please click here.
RE[5]: Get off my lawn!
by dragSidious on Wed 9th Sep 2009 19:09 UTC in reply to "RE[4]: Get off my lawn!"
dragSidious
Member since:
2009-04-17

"Just what exactly is your problem with HAL and udev?

If you hate automation, you should be using pen and paper, not a computer.

Is it THAT HARD to understand, that not everyone needs device automounting, media autostart, notifications; automatic recognition of file format and all of this 'wonderful enhancements'?
"

Those make things people's workflows faster. Anyways that is not describing the full benefit to the 'Utopia' approach.


As I said beore, there are MANY types of users and not everyone needs neither likes - say - Ubuntu way of doing things. And as the guy above already said - the whole lot of the enhancements bring a whole lot of new security issuess.


They solve a lot more serious security issues as well.


Some people prefer to have a minimal installations. Not because their masochists, retards, gurus, geekies or whatever. It's just a minimal nature of some of us - certainly and thankfuly not all of us.


That is one of the reasons I like Debian. When I want a desktop OS I can have one. But when I don't then I don't have to have one. ;)


@dragSidious - I think that everyone here knows exactly [or - at least - know an idea of] what the UDEV and HAL is, but thanks for an exhaustive explanation. I'm sure someone will find that useful.


I try.


Lastly - I don't really need an automation and that's the point. I don't want some future malicious code to mount my devices, access my private informations with stored enc session and so on, and so forth.



Think about this:

Using the old fashioned way of managing and mounting external drives you have to provide the root password. Quite often multiple times you need to provide a root password. Or you have to use sudo, which is just as bad.

Using things like HAL you have a privilaged daemon that performs that action on your behalf based on rules (configurable via Policykit). As long as your user has the permissions to the device then it will mount it for you. You don't even have to use 'automount'. I like to use 'pmount' which is the command line version of things.

This way you can mount and access removable media without providing the root password (or sudo, which is largely equivelent), without giving permissions to the device, or editing fstab or anything like that.

Suppose your in a situation were a firefox vulnerability was exploited and you have malicious software running in your account without you aware of it.

Which is more likely to cause problems? You continiously using root account every time you want to switch networks or mount a flash drive, or using HAL and related daemons to perform that action for you outside of the account.

Also you have similar issues with using tools like gtksudo and whatnot. When you allows sudo access to a GUI application your effectively giving full root access to that entire application. GUI applications are hugely complicated and they are very easy to exploit... were as with 'dbus' all you have to do is make sure that the input privilaged applications recieve over dbus is validated before it's acted on and you avoid almost any possibility of exploitation.

So while having dbus and that sort of thing running on your system does open new possibilities for exploitation they also provide a much much smaller attack profile compared to running a application using sudo or setuid root or whatever.


BTW, this is why I hate UDEV, HAL:

UDEV - it always MESS my whole HW config. It used to swap my ether interfaces and I don't want to be forced to use the god damn udev rules. It's unnecessary! I don't need to trimm /dev dir in size. It looks just fine on my OBSD box, so why the hell should I need udev in linux or freebsd? this is useless and it creates new troubles. I love the OLD and REASONABLE way of doing things.


Udev provides a way in Linux to innumerate hardware devices consistantly. (as well as other benefits like defeating the limitation on the number of major and minor device nodes)

Prior to Udev rules Linux innumerates devices on a first come, first serve basis. That is when the system boots the first device that gets detected is eth0 and the second is eth1 and so on and so forth.

This is fragile because if you upgrade your kernel or change your hardware configuration in some trivial manner then this can affect the order things are detected. So while the old way worked 'ok' for static hardware configurations it had a hard time coping with modern systems that are much more flexible.

So Udev on many systems tries to store static configurations.

With OpenBSD they hand out device names based on what drivers you use. So if you have a onboard VIA ethernet and then a PCI Realtek ethernet they show up as completely different network devices. In Linux it's customary to have all ethernet devices show up as 'eth0', 'eth1', 'eth2', etc, irregardless of the actual driver. This means that OpenBSD is able to avoid the innumeration problems that often caused problems with Linux routers in the past... but I expect you run into similar issues with OpenBSD when you use multiple devices that use the same driver.

Oh, and if you prefer the OpenBSD way to name devices you can replicate that using Udev. You can use udev rules to create abritrary names for ethernet devices, although this may cause problems with some system scripts. For example you can setup a router with 'external0' and 'internal0' ethernet devices. So in fact udev gives you _more_ control then otherwise is possible.


HAL - that's a real pain in the ass. It used to f43ck up the whole system and making it unusable. Keyboard used to generate the whole bunch of doubled inputs, mouse behaved oddly and everything was just a mess. Again - I don't want to edit some god damn policies! I don't need that. Everything worked GREAT without HAL, so why the hell should I sacrifice simplicity? that makes NO sense. Throw it into Ubuntu, but just don't make it default for every damn distro and kernel version on earth. Not eveyrone uses Ubuntu.



Except it did not work. For example in X.org there was no such thing as mouse hotplug support.

How it worked prior to X.org Hal/Devicekit support was as follows:

X.org has _zero_ hotplug support for anything. No mice, no keyboards, no nothing. The configuration is static and is set at start-up time through /etc/X11/xorg.conf

Linux has _very_good_ hotplug support. Originated with things like Knoppix Linux gained the ability to detect and configure all supported hardware on the fly with good success.

So.. to make mouse hotplugging work Linux set up a emulated explorer PS/2 mouse at /dev/input/mice. If you configured X.org to use that then you could use a static configuration for a standard 2-button PS/2 mouse with scroll wheel. (eventually X.org just started using this as the default wheither configured or not)

So every pointer device you plugged into Linux would end up being used as a generic PS/2 mouse.. even if it was not a mouse.

In order to make something other then a mouse work (Wacom tablets, touch screens, joystick pointers, trackballs, touchpads, mice with more then 3 buttons etc) it required you to go in and manually configure and list every device in xorg.conf. Any device added or removed, required a change to the configuration file and required you to log out, restart X, and log back in.

For me personally I used a Wacom tablet and a complex trackball and it would often take numerous tweaks to get everything working correctly. To do the tweaking necessary it would take several _hours_ of making a small change, log out, restart, test, small change, log out restart, test, etc etc.

Nowadays I just plug in my tablet and it 'just works'.

Like everything else it worked fine if you have _very_specific_ configuration and had _no_changes_ to your hardware configuration or setup. It was 'ok' for the most common configurations, but it quickly broke down if you did anything remotely advanced.

Reply Parent Score: 1