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 382696
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Get off my lawn!
by marcp on Mon 7th Sep 2009 23:45 UTC in reply to "Get off my lawn!"
marcp
Member since:
2007-11-23

If you read his post he sounds like an old fuddy duddy user who doesn't want his linux install to actually recognize has hardware when he plugs it in, or his desktop to look nice. He should be using TWM and motif and shut the f--k up.

Uhm ... okay, but most of the recent tools started to DEPEND on the useless, utter crap like HAL and UDEV and you can't really do much about it UNLESS you compile your own kernel. Is that fair? no. Is that against KISS philosophy? well, surely!

I actually want my desktop to do something. I don]t want it to be a whole bunch of disparate applications like it used to be in 1998. I want my desktop to look nice. It seems to be a general consensus among desktop users if current trends are any indication. I'm not defending Gnome growing in size if and only if there wasn't any functionality added, but that is not the case.

Well, there are few types of users and I'm certainly not like you. I for example don't want the desktop to get in my way ... and I hate automation. BTW - that's why I don't use Windows or Mac ... ;)

That' not to say that Gnome and Kde couldn't use more optimization and a better grasp of dependencies.

It's not about a code optimization when the desktop env loads a @#%@load of never-to-be-used crap ...

Edited 2009-09-07 23:47 UTC

Reply Parent Score: 2

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

Just what exactly is your problem with HAL and udev?

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

Reply Parent Score: 2

RE[3]: Get off my lawn!
by dragSidious on Tue 8th Sep 2009 16:51 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