Linked by Thom Holwerda on Wed 19th Jan 2011 22:04 UTC
Xfce When we reported on the release of Xfce 4.8, we ignored a statement inside the release announcement about the lack of new features coming to the BSD world. The statement was a bit disconnected from the rest of the press release, but Xfce developer Jannis Pohlmann has published a blog post giving a few more details about the issue.
Thread beginning with comment 459128
To read all comments associated with this story, please click here.
Uhm, Linux is the copy-cat here
by phoenix on Wed 19th Jan 2011 23:17 UTC
phoenix
Member since:
2005-07-11

FreeBSD has had devd since 5.0 was released many, many years ago. This is a kernel-level, event-driven notification framework for hardware. Everything devfs, new-devfs, udev, HAL, new-udev, and udisk wanted to be ... was already there.

It's very easy to add a script to an ACTION stanza in /etc/devd.conf to do whatever you want (mount a filesystem, import images, start a hot-spare replacement in ZFS, etc). And /etc/devfs.conf covers setting users/groups/permissions on devices nodes as they are created by devd.

powerd has been available in FreeBSD since the 5.0 days, and handles CPU power management with a bunch of options.

All of the *Kits have been available on FreeBSD fairly soon after they're available on Linux.

This is not an issue of "FreeBSD doesn't support the features we need" and more an issue of "FreeBSD does things properly, without changing every 5 minutes, and we don't know how to handle that".

The correct "solution" here is for "desktop" devs to stop using the kernel features directly and having to continuously rewrite things for udev, HAL, *Kit, u*, etc and instead to write to a standardised abstraction layer with pluggable backends. Something the KDE devs figured out with 4.0 and the creation of Solid and Phonon and similar.

Maybe the freedesktop.org community should get together and work on this abstraction layer, and then let the kernel devs from Linux/FreeBSD/whateverBSD/Solaris/etc work on the backends. A nice decoupling of the "desktop env" from the "kernel/u*/*Kit backends".

Either that, or all the desktop env projects need to remove things like "portable", "for Unix-like systems", "POSIX-compliant" and other such nonsence, and mark themselves as "Linux-only".

Edited 2011-01-19 23:19 UTC

Reply Score: 33

Delgarde Member since:
2008-08-19

The correct "solution" here is for "desktop" devs to stop using the kernel features directly and having to continuously rewrite things for udev, HAL, *Kit, u*, etc and instead to write to a standardised abstraction layer with pluggable backends. Something the KDE devs figured out with 4.0 and the creation of Solid and Phonon and similar.


Uh, so you want a standardised abstraction layer with pluggable backends - so, HAL and friends, then? Because that's *exactly* what those packages you're complaining about are!

Reply Parent Score: -1

kaiwai Member since:
2005-07-06

"The correct "solution" here is for "desktop" devs to stop using the kernel features directly and having to continuously rewrite things for udev, HAL, *Kit, u*, etc and instead to write to a standardised abstraction layer with pluggable backends. Something the KDE devs figured out with 4.0 and the creation of Solid and Phonon and similar.


Uh, so you want a standardised abstraction layer with pluggable backends - so, HAL and friends, then? Because that's *exactly* what those packages you're complaining about are!
"

No, HAL was a piece of crap that re-invented the wheel on every platform it appeared. What the original poster was talking about is something similar to KDE Solid which provides an abstraction for developers away from concerning what the underlying operating system is.

The problem with that: it has been how long and there is still no FreeBSD backend for KDE Solid. Abstractions are all very nice but if there aren't the people to implement the backends then the whole exercise is a waste of time.

Reply Parent Score: 3

phoenix Member since:
2005-07-11

Kawai touched on this as well, above.

In theory, HAL should have been perfect, in that it would be a portable abstraction layer for hardware access/info/notifications. However, the architecture of it was crap (polling? really? name a single kernel without an event system), and it was very Linux-specific. Writing alternative backends for it was nowhere near simple. There was also no input from non-Linux devs.

Those who ported HAL to non-Linux OSes have nothing good to say about it.

Reply Parent Score: 4

jimmy1971 Member since:
2009-08-27

Thank you for pointing out the truth. Linux isn't so much an "operating system" as it is a kernel with a compilation tape GNU and (to a lesser extent) BSD code wrapped around it.

BSD has a solid code ancestry and is a consistent, stable family of true operating systems.

Flame away, penguinistas.

Edited 2011-01-20 15:16 UTC

Reply Parent Score: 4