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.
Thread beginning with comment 382810
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Get off my lawn!
by dragSidious on Tue 8th Sep 2009 16:51 UTC in reply to "RE[2]: Get off my lawn!"
dragSidious
Member since:
2009-04-17

HAL is 'Hardware Abstraction Layer'. There are all sorts of 'HAL' in all sorts of different operating systems. It's a generic term that could mean anything.

In the case of Windows NT the 'HAL' is a abstraction layer that sits between the kernel and the hardware. This allows the kernel to be portable.

In the case of Linux desktop HAL is a way for applications running on your desktop to be able to access information related to hardware in a standardized way. It's currently being fazed out in place of 'DeviceKit' which is a better design, but provides similar functionality.

The Linux kernel detects and configures all your hardware on the fly. Each time it boots up it does it. It then presents lots and lots of information on hardware and configurations (as well as other stuff) via /sys and /proc virtual file systems.

HAL/DeviceKit is designed to work with that and make things easier for userspace to deal with changing hardware configurations.

-------------------------------


Here is various things and what they do:

UDEV = Configures your /dev directory and contains configuration information on hardware stuff. For example if your touchscreen is not showing up as a touchscreen, then you need to edit udev's rules so that it gets properly configured as a touch screen.

HAL/DeviceKit = Collects system information and presents it in a nice way to userspace. Deals with notifications when hardware configurations change. Also performs some actions on behalf of user applications.

DBUS = IPC (Inter-Process Configuration) for applications. There are two major 'busses'; 1. System Bus, 2. User Bus. This is the protocol that is used to send notifications and other information back and forth to users.


--------------------------------------------

This is a example of how it works when you insert a USB flash drive:

* You insert thumb drive
* Linux's USB system notices this and begins communication with the thumb drive, configuring it, analyzing it. Each major configuration detail gets sent out to /sys.
(for example you have a USB device that gets configured, and the Linux SCSI protocol stack is used to abstract the communication with USB Mass storage protocol, so you get a SCSI device that shows up, etc etc)
* HAL Daemon is watching things change in /sys. Each new device that gets configured (some virtual, some real) then sends a notification over the DBUS System Bus.
* Gnome-Volume-Manager is listenning on the DBUS System Bus for devices that have a 'volume property' that indicates that it's a storage volume that contains a mountable file system.
* Eventually after the device 'settles' the Linux kernel does the final configuration and sends the partition volume information to /sys
* HAL picks up on this and sends a notification to DBUS System Bus that a device has been detected and configured that contains a volume with a mountable file system.
* Gnome-Volume-Manager (running as your user) receives the notification and sends a request to HAL that that volume should be mounted to /media
* HAL checks with PolicyKit to make sure that your user has the correct permissions to be able to mount 'removable' volumes, which you do.
* HAL mounts the volume at /media/disk and sends a notification of the new file system over DBUS
* Nautilus recieves the notification and then creates the icon on your desktop.


-------------------------

The following is the 'old' 'non-bloated' way that you had to do stuff prior to things like udev and dbus:

1. You insert the USB Drive.
2. You open up the terminal.
3. You run 'dmesg' several times to find out how the device is detected.
4. You run 'su' or 'sudo su' to become root in a terminal.
5. You check to make sure that the correct /dev/ node exists. If it does not then you have to look up the Major and Minor device numbers in the Linux documentation to corrispond with the devices and it's partitions.
6. Then you run the 'mknod' command to create the device node if it does not exist.
7. Then if you want you can run the 'chmod' command to configure the permissions for the device.
8. Then you mount the device to /mnt or something else.



Now you can exit out of your root shell or stop using sudo and begin accessing that file system.



DISADVANTAGES TO OLD WAY:

* You have to use root permissions or use sudo. This is very insecure. Modern approachs have small system daemons that check user permissions with Policykit before performing functions that otherwise require root permissions. This allows administrators to set group policies and configure things in a sane manner for lots of desktops and lots of users. For single user systems it still allows users to perform common desktop functions without resorting to using root permissions.

* The number of Major and Minor device node numbers that Linux supports is limited. This limits places artificial restrictions on the number of disks and different types of devices that Linux can support. Udev allows recycling and using abritrary Major and Minor numbers to innumerate devices, thus eliminating this restriction.

* There is no standard system-wide notification. There is no way for 'the system' to notify userspace of system hardware configuration changes. This makes adding things like:
- USB Thumb drives
- Mice
- Cameras
- SD Cards
- Wireless and Wired Network devices
- Audio devices
- Joysticks
- WebCams
- USB Cdroms
- USB Floppies
etc. etc. etc.

It makes all that a completely manual process requiring root account (through su or sudo the effect is the same). This requires that users either have intiment knowledge of how Linux deals with things and configuring hardware devices manually through the command line, or that a system administrator needs to be on call to handle these sort of things.

* Any application that does actually need to watch and listen for hardware configuration changes needs to implement the entire functionality of 'HAL' in itself, each and every application. So no shared functionality, code, or library. It needs to run with much higher level of permissions to access and examine the /sys and proc file system then is otherwise necessary.



So people can keep their 'bloat free' systems and unusable junk like that. Just becuase THEY (as in I am not deriding the person I am repling too... Not knowing how something works is one thing, not knowing how something works and then claiming it's nothing but shit and bloat is entirely different matter.) have no clue how things work does not mean other people don't.

Reply Parent Score: 8

RE[4]: Get off my lawn!
by marcp on Tue 8th Sep 2009 19:32 in reply to "RE[3]: Get off my lawn!"
marcp Member since:
2007-11-23

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

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

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.

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.

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.

ugh ...

Sorry for the typos. I don't have a time to correct them

Edited 2009-09-08 19:45 UTC

Reply Parent Score: 2

RE[5]: Get off my lawn!
by vivainio on Tue 8th Sep 2009 19:41 in reply to "RE[4]: Get off my lawn!"
vivainio Member since:
2008-12-26


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'?


They would be better of switching to NetBSD instead of fighting the windmills on Linux side.

Reply Parent Score: 2

RE[5]: Get off my lawn!
by cjst on Tue 8th Sep 2009 20:21 in reply to "RE[4]: Get off my lawn!"
cjst Member since:
2009-03-30

It looks just fine on my OBSD box, so why the hell should I need udev in linux or freebsd?


FreeBSD has a devfs which is quite a different beast from udev on Linux. With udev you have a tmpfs mounted on /dev and udev, a userland daemon, populates the /dev directory with whatever info the kernel sends it. It's fat, slows down boot time and there are the problems you mention with the ethernet cards amongst others. Devfs on the otherhand is in the kernel and is slimer, and orders of magnitude faster. Linux used to have a devfs (I used it full time, never had problems with it) but it was deprecated because the code was said to be hard to understand and no one wanted to fix the races devfs was said to have. Kroah-Hartmann's udev was chosen instead. And this guy said that devfs was flawed by design. Nevermind that devfs has zero problems on FreeBSD and Haiku for example. But udev does have one advantage, it doesn't rely anymore on the minor and major device number scheme. That makes it possible, according to Kroah-Hartmann, to plug-in much more devices which is needed because of USB etc... Bottom line let's wait and see when FreeBSD and Haiku run out of minor/major device numbers ^^

Reply Parent Score: 2

RE[5]: Get off my lawn!
by No it isnt on Tue 8th Sep 2009 21:52 in reply to "RE[4]: Get off my lawn!"
No it isnt Member since:
2005-11-14

If you just really don't want to use HAL, then just don't use it. Choose a distro that caters to your needs and stop whining. None of your complaints have any technical merit anyway.

Reply Parent Score: 1

RE[5]: Get off my lawn!
by BluenoseJake on Tue 8th Sep 2009 22:24 in reply to "RE[4]: Get off my lawn!"
BluenoseJake Member since:
2005-08-11

perhaps if you used an OS that made your life a little easier, and took some of the drudgery out of your day, you'd have time for editing your spelling and grammer errors.

Reply Parent Score: 2

RE[5]: Get off my lawn!
by dragSidious on Wed 9th Sep 2009 19:09 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

RE[5]: Get off my lawn!
by FooBarWidget on Fri 11th Sep 2009 08:32 in reply to "RE[4]: Get off my lawn!"
FooBarWidget Member since:
2005-11-11

Yes, in fact, it is that hard. I absolutely can't understand why anyone would want their desktop to be unusable and why they would care to micro-manage things like device nodes. I want my computer to Just Work so that I can get things done, instead of fiddling all day with configuration files and obscure commands.

People like you are exactly what's keeping Linux behind on the desktop.
"Developer> hm, XXX sucks, why do I have to do this? let's make it easier
You> NOOO! BLOAT! DO NOT WANT!
Developer> okay, since users are protesting so much I'll leave it be."
[...nothing ever changes and the system remains in its 1960s state...]

I'm glad that a lot of developers are sensible enough to ignore people like you.

Edited 2009-09-11 08:33 UTC

Reply Parent Score: 2

RE[5]: Get off my lawn!
by DrillSgt on Fri 11th Sep 2009 12:05 in reply to "RE[4]: Get off my lawn!"
DrillSgt Member since:
2005-12-02

Sorry for the typos. I don't have a time to correct them


<joke>Of course not. You are too busy typing in mount commands each time you plug in your USB key or inserting a cd-rom!</joke> ;)

Reply Parent Score: 2