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