Xfce 4.8 on BSD flavors
Wednesday, January 19 2011, 17:29 - Permalink
I should’ve made this more clear in the Xfce 4.8 release announcement but for a moment there I forgot that not everyone knows what we developers are dealing with under the hood.
Many users have been asking what the BSD problems are that I mentioned in the announcement. As some of you may recall is that HAL, the hardware abstraction layer that has for the past few years been used for volume and power management as well as a few other things, has been deprecated and replaced by a variety of frameworks. Today there is udev for device information, udisks for volume management, upower for power management as well as ConsoleKit and PolicyKit for session and permission control.
At least udev is strongly linked to Linux and as far as I know is not available on any of the BSD flavors. Unfortunately it is now the only good way to detect storage devices, cameras, printers, scanners and other devices using a single framework. That’s why we use it in Xfce now in situations where HAL provided us with device capabilities and information to distinguish between the different device types before. The consequence is that thunar-volman no longer works without udev and thus only compiles on Linux. In Thunar itself udev remains optional.
I don’t know what the porting status of the other frameworks is. But I am pretty sure not all of them have been ported to other platforms yet which is why I felt the need to express our disappointment in the announcement. For 2-3 years now all this has been a big mess. New frameworks were invented, dropped again, renamed from *Kit to u* and somewhere on the way it became impossible to keep Xfce as portable as it was before. I know that this is nothing new and that BSD folks faced the same situation as they do now back when HAL was invented but I don’t think it has to be this way.
For the question how we can improve the situation I have no answer yet.
Comments
Thanks for updating us on this. I' m a FreeBSD user and was wondering what the release announcement meant for BSD systems. Now I know.
I' m am using Xfce 4.8 on Sabayon linux now in Virtualbox guest. Looks and works great. Hope that the BSD's will not be forgotten because I regularly installed Xgce on it as my desktop system because both KDE and Gnome upgrades were cumbersome.
Thanks.
Thing is, if the BSD people want these features, they need to help build them. HAL did acquire BSD (and Solaris) support, but only after the new features had already been mainstream in the Linux world for several years, and packages like Gnome and KDE started making them mandatory. Eventually, BSD people contributed the necessary patches to make things work.
And the same is happening again - the replacement of HAL has been going on for a couple of years now, driven by the needs of the desktops who are mostly focused on Linux. It's been a somewhat drawn-out process of trial and error, but the key thing is - it's been entirely the work of Linux-based developers. In all that time, there's been little contribution from the BSD users and developers. I know they're a smaller group than their Linux counterparts, but if they don't get involved, they don't get supported. And they need to be involved early, so they can influence the design, instead of trying to work around Linux-centric stuff.
The problem is that XFce never really supported *BSD in the first place. It supported HAL, which was a Linux-ism ported to BSD. Now HAL is deprecated, and BSD must once again wait for the dust to settle to catch up. A proper BSD wrapper would have used devd(8) to handle volume mounting, would have been written around 2005 or so, and would have been the only consistent backend through all the years to 4.8.
I guess XFce should remove the term "UNIX-like" and the garbage about following the "traditional UNIX model of modularity.: What you really mean to say is "Linux-like" and following the "traditional Linux model of shit that is trendy this year but will be broken five years out."
@ Carl
Geez, this is too childish. I didn't know kids used BSD. Seriously, what have you done to help with the development of this software stack to require something like this?
"BSD must once again wait for the dust to settle to catch up"
So you want Linux developers to wait for BSD? :)
Grow up, Carl.
Speaking as a linux user, I have to say Carl hit the nail on the head. Besides Linux development being a psychotic and flippant process, Xfce hasn't really 'supported BSD'; HAL has. Thunar volume management should have been handled in a similar manner to how KDE provides abstractions for multiple backends, for a multitude of components, to ensure portability.
It would help if udev were well documented. As the author of devd(8) in FreeBSD, I have looked several times to find out the data stream that udev is providing, yet I keep finding vague and conflicting information.... FreeBSD's devd(8) framework has supported these things for years now... If there's a good, unambiguous reference that someone can point me at, I'll be happy to take another shot at it...
if HAL was such a great thing, where is it?
why should the bsd community invest so much energy into maintaining
these linux monstrosities? everybody hated HAL. even linux people.
same with pulseaudio.
most linux programs written with "portability" in mind are a joke.
full of linuxisms and needing constant patching. the only _really_
portable software is actually developed on non-linux systems.
just go and follow a bsd porting mailing-list for a while to see
all the pain.
DragonFlyBSD sports an udev implementation (don't remember if it is already in 2.8 or current though).
I'm building (and shortly, packaging) Xfce 4.8 for Solaris 11 Express. It's frustrating that supposedly "portable" software depends on linux kernel or daemon specifics. Hopefully I'll get the cycles to see where the gaps are, and help my friends developing the Solaris 11 kernel/userland to cover those gaps. If I do get that opportunity, I'll make sure to maximise the benefits across other OSes as much as possible.
[At the very least, I'll contribute my packaging stuff back to upstream]
Well, this is not as bad as it seems, people will find the need to (re?)write a replacement for udev. However, it won't come from the linux folk, for sure. After all, it works for them this way.
HAL was ugly but it was easier than writing all the abstractions in Xfce, and I don't blame the developers for it. However, the more a project grows, the more it needs quality (over features), and I would expect Xfce dev team to replace ugly monsters like HAL with clean, reusable, maintainable, documented and portable code. Not with some Linux-ism, that's pointless. At least I hope they will provide a way for porters to build Xfce with minimal features (--without-linux ? =) ).
@Robert:
We already allow Xfce to be built without udev etc. People lose a few features that way but Xfce will still work.
Xfce doesn't grow. It feels more like we shrink. Less active developers with less time than ever before are facing the fast-paced rise and fall of OS and desktop technologies. Instead of messing things up even more by adding our own abstraction layers on top of existing abstraction layers, I'd rather see people working on udev etc. to consider OS diversity something to value and take into account at every layer when designing the desktop stack.
That said the APIs of libudev, gudev, udisks, upower and the various Kits are very good. I just wish that under the hood those that are not portable would allow to switch between Linux-specific technologies (like udev) and those of other OSes (like hotswap as an alternative to udev on BSD).
Perhaps this is already possible today. Admittedly I haven't looked into it myself yet.
One huge problem with the linux development is the licence. Things can't go both ways.
If you're on Linux and go to use BSD code, that's fine, the BSD licence (non advertize clause) is fully linux compatible.
Not so the other way around.
So, work that's done specifically on linux with GPLv2 (and it gets worse with the GPLv3) is simply waste from a pure BSD point of view: nothing to reuse, just ideas (when they're good), but everything must be rewritten from scratch.
It would help *a lot* if people on linux would decide that standardized code is more important than closed locked licences such as the GPL.
No, that's not a troll. Think about it. If you're developping on OpenBSD, no component will be added to the base system if it's less free than the BSD licence, and we took active steps to replace a lot of old pieces we inherited from other projects.
Yes, as pointed out, DragonFly BSD does have a mostly complete udev implementation thanks to Alex Hornung. As far as these other API's go, if they were well documented the BSD projects would already have collectively implemented them. I don't think the various BSD camps care to lead on the desktop front, but we are happy to follow, show us the standards and we will.
To all the whiners: Xfce is the most BSD-friendly desktop environment available. You have no idea of the whole picture, nor of the similar (and worse) issues existing for GNOME and KDE.
Xfce core devs (a "huge" team of... 4/5 active persons!) made sure that all those dependencies (udev, *kit, upower) were _optional_. Dropping HAL was the way to go, and the decision to rely on existing frameworks completely makes sense.
As jannis pointed out, Thunar works perfectly fine without thunar-volman, you just don't have automounting of pluggable devices (but, well you can script it yourself with devd/hotplugd). Similarly, Xfce4-session doesn't require you to use consolekit/policykit, you can use the sudo backend.
(Oh, and i maintain Xfce on OpenBSD, and i contribute to Xfce, so at least i know what i'm talking about)
Hopefully such missing features will be reintroduced via one way or another… The end user doesn’t care about the specifics; The end user just wants the features back.
It appears the real concern is the lack of specification (and restrictive licensing) pertaining to udev. Whatever happens or changes to udev will affect the rest of the u* frameworks which are not an issue — they don’t require direct integration with the kernel — only udev is in-kernel. It will be interesting to see how long it will take developers to reinvent the wheel for the various Operating Systems that cannot use GPL in kernel comfortably — or because of legal issues.
BTW I am not an end user. ☺
I am still looking forward to testing and perhaps using XFCE 4.8 on some BSD boxes I have!
—Winston Weinert
Thanks Jannis, Landry, Marc and Warner. You guys have done a lot of things that I've appreciated. Just a few:
- Xfce lets me set up computers that anyone can use, and it runs nicely on my older systems. I even have it running under OpenBSD on a 533 MHz Via-based fanless point-of-sale box that I got for $40 a few years back.
- The documentation that came with OpenBSD's Xfce package (the README.OpenBSD) was a nice touch. Actually, all of the OpenBSD documentation that I've had to refer to has been pretty damn' good.
- FreeBSD's devd let me write a set of scripts a few years back to handle automatic (user)mounting. HAL was ported just after I finished, but it worked nicely and could even be made to integrate with KDE's media:/ protocol handler if necessary.
- OpenBSD's package system has been more robust than most of the others that I've used. It's also nice that you guys post your presentations online. I read one on improvements to pkg_add that Marc Espie wrote. It's nice to see how people solve problems and why.
Standards are always political. It happens in mechanical industry, too. It happens in institutional standards committees. I have a relative who's on one of the US blood-bank safety panels, and it's not uncommon that someone wants to mandate use of a specific test because they're affiliated with the only manufacturer of the lab-equipment that it requires or something like that.
Legitimate differences come up, too: what are you willing to sacrifice? A fellow that I used to work for was always dealing with customers who wanted equipment that was fast, cheap, accurate and delivered immediately. He'd say "pick any three." :)
'Linux' is kind of a broad word these days, and I'm not in a position to speak for anyone else here, but there seems to be more interest in competing with big commercial software outfits on consumer entertainment stuff than in the BSD world. That's a tough market. You have to have something exciting to tout around the holidays, or people forget about you and buy from someone else. Nobody will appreciate it if your product has been chugging away for 20 years without complaint; they probably don't even remember that it's there.
I honestly don't know, but it wouldn't surprise me at all if there were hasty standards that didn't pan out, or if people tired to push each-other around because they were in a hurry to get something out the door. One of Seagate's big suppliers has specially-trained 'abusers' whose sole job is to go out and intimidate/torture/disembowel their sub-contractors into producing more and better production equipment sooner and for less. That's just the name of the game :)
HAL daemon was hated extremely. Well deserved.
Complaining about lack of BSD compatibility. BSD has had more years to correct this issue than Linux. Linux world got sick of waiting.
"One huge problem with the linux development is the licence." Really not. BSD development is highly intolerant of Licenses used to avoid nightmares of people extending standards.
"So, work that's done specifically on linux with GPLv2 (and it gets worse with the GPLv3) is simply waste from a pure BSD point of view: nothing to reuse, just ideas (when they're good), but everything must be rewritten from scratch."
Lets purely skip over the advantage of GPL. You cannot take and extend and not release the source code. Android kernel design alterations would have never made it back into Linux without GPL.
BSD systems slow progress in the areas of device management is linked to its license.
Please be aware items like udisk are part of the freedesktop specifications. BSD guys had there chance. Failure to submit to specifications bodies that submit into bigger standards like the Linux Standard Base leaves you stuck with stuff you don't like.
Particularly if all Linux people are submitting an no bsd people turn up no duel license. The Academic Free License and GPL was old HAL. Not BSD. Academic Free License still demand source code release in case of alteration. The very thing BSD guys say is not a suitable restriction. If you want standards that work this is a required restriction so no implementer gets the idea I can extended here and no one will find out. The standard world has moved on from the time of BSD. Lessons learnt come from all the Unix systems based of BSD. They all end up forked off to a point they were no longer compatible due to secrets.
Yes All BSD people. Being a BSD distribution does not make it standard.
Yes FreeBSD has devd tell me when it specification were submitted to a independent specification body. Wait never. Basically BSD guys take it in the chin and be more involved in the broader communities in future. Also BSD people need to accept that BSD license poor for standards. GPL is good but maybe too far.
Sorry for the mess and disruption to xfce. The issue you are running into has everything todo with BSD developers not taking part in standard process and Linux guys being hell for leather for standard to clean up the o my god nightmares between all the Linux distributions in existence. Basically don't turn up to the standard process except the fact of being left behind and not considered. Because to the standard processes you are not interested in being standard so we don't have to consider you.
Yes the screaming as BSD systems lose apps is a direct result of not taking part. I would recommend XFCE just stops doing BSD releases until BSD systems come into line and starts working with freedesktop.
I use xfce on OpenBSD and I don't miss a thing. I don't care about auto-mount.
I'm glad that the xfce developers care about portability and keep OS-specific features optional.
@ oiaohm
C'mon, you want to say that XDG is standard-producing group? Did you ever been on their site? (this is the easiest thing to prove you're wrong) They're "open source / open discussion software projects...", nothing more, nothing less. They just pick up something they think should go in, and say: "This should be in every desktop system with X". It was so all the time.
Yes, they have a good, even cool target: unifying user interface in X Window enviornment. So why the hell they doesn't care at all about anything but Linux? Why do BSD people should hunt for them when it's not BSD people who's saying "we're working on interoperability"?!
Imagine that someone opens a shop near you, and intead of marketing it the person says that you should search for it on your own, he doesn't care. This what XDG should behave looking from your point of view.
Actually, they're behaving differently: "Whoa, I've seen this stuff in my Linux distro and it's cool, so let say it should be everywhere". Moreover, they doesn't care about choosing the best option, preferring "supporting" all well-known alternatives at once. They ever support HAL still! Yes, there is some logic. But this is not how _standards_ may be ever made.
I don't blame Linux people: the're working on Linux, so they are playing the Linux games. BSD people play BSD games, in turn, and so on. And whoever want to create real standard should know and respect the rules of all those games, shouldn't it?
An no, I do not want to blame XDG: they try to do their best. They don't claim they're creating standards. So the main error here is thinking about them as "standards group".
So all your wording about standards can go to /dev/null. Sorry.
@oiaohm: thanks for proving my points so thoroughly.
We were missing the rabid fan boy for the GPL, complete with all the same old arguments.
You don't have any proof for android. I would tend to think that google would still have given back the kernel changes, even under a BSD licence.
Yes, slow progress in device management is due to the licence. We can't reuse linux cod, whereas linux often doesn't care, and has lots of binary blobs to cater for a lot of devices (like nvidia cards for instance).
As a BSD user I would like to thank the XFce developers for their fine work. Sorry some of us BSD users complain so much. Even with the issues discussed above, XFce is hands-down the best BSD desktop.
just to make things clear: my comments were only about the situation wrt udev, and other so-called "open standards".
the trend is worrysome: freedesktop and xorg are hosting more and more pure GPL projects (compare to the old xfree, which had a lot of issues, but at least was sticking with a reasonable licence). You can't really fault other projects for wanting to stick to their philosophical goals.
As far as licence goes, there's a lot of reasonable, shiny software out there. Heck, sqlite is public domain, and perl has the artistic licence. GPL is definitely NOT the only solution if you want to do opensource.
There's absolutely no ill will intended to the xfce people. I assume they are doing the best they can with limited resources.
"You don't have any proof for android. I would tend to think that google would still have given back the kernel changes, even under a BSD licence."
Really when you are aware that google has gone to the extream of running a Linux kernel fork for there own internal operations with many patches not released to the public. This still goes on today. Your thinking is not based on fact. Google choice between open and keeping secrets. Google if it will give them a competition advantage will chose to keep secrets. Known fact.
Google is not offensive to open source they are not 100 percent pro either.
Freedesktop.org was fully vendor neutral when HAL was first developed. Developers and from freeBSD and other BSD took part. Everything must be BSD insanity did not exist in the year 2000 mostly because they did not have there own complier that worked and had to use gcc so BSD systems were accepting of the fact they might have to contain some GPL.
Scroll forwards a few years. LLVM exists. BSD system come massively anti-gpl. Start complaining about parts that started life GPL when they get updated. Have stopped taking part.
Go back threw the HAL mailing list on Freedesktop over udisk and devicekit before not one complaint about the upcoming change.
"We were missing the rabid fan boy for the GPL, complete with all the same old arguments." Rabid fan boy. Not really I just the same person I was in 2000 when FreeBSD and others agreed to use HAL and were unified work on the project under GPL like licenses.
Now for some reason FreeBSD still find it acceptable and BSD based commonly is unacceptable to work on a GPL project. If anyone is rabid its the BSD camp both licenses of HAL that was acceptable to BSD and others in 2000 is not any more. Yes magically become unacceptable. Now only BSD that should be worried about is FreeBSD. They do have devd that does most of udev role. udisk and others can get the information they need from devd.
Also at some point FreeBSD will have to follow. Linux. Linux won the vote to be the system call standard for all of Unix.
Basically sorry BSD for years you tried to be compatible with Unix in existence. Not your own thing. So you did not make standards you did not take part in standards and you have lost.
About time BSD side pulls there head out the sand and starts taking part in the standards and taking control of there future proper. Not waiting for it to come and then complain about licenses and so on.
XDG is a specification preparation group. Lot of items placed on XDG never existed anywhere else before they were started there. Same stupid incorrect arguments from the BSD camp that XDG is bias so we don't have to take part. It bias these days because BSD and other are not taking part.
"Whoa, I've seen this stuff in my Linux distro and it's cool, so let say it should be everywhere" BSD developers in 2000 use to do the same thing at XDG. Specs were coming from both sides. Debates in mailing lists between BSD and Linux developers were going on.
Really I hate the current state. Yes freedesktop ends up in the Linux Standard Base when it becomes a ISO standard. Problem here BSD guys have never gone through the effort of making a ISO standard. Freedesktop is exactly what it name is. It was invented to allow systems to be developed OS neutral.
Really do you expect Linux coders to know how to code correctly for BSD. There were other OS's at Freedesktop when it started. The problem is all those have left. So freedesktop has become a poorer source of specification.
If you will not come by freewill to a table of common ground force should be used. Ie you will not take part in freedesktop mailing list and development you should expect a stack of applications to cut you out and not even consider you. BSD people want to forget Freedesktop started as a joint project between everyone making X11 Windows managers. No OS in the factor.
"Yes, slow progress in device management is due to the licence. We can't reuse linux cod, whereas linux often doesn't care, and has lots of binary blobs to cater for a lot of devices (like nvidia cards for instance)."
Nvidia makes a binary blob for FreeBSD as well. Funny you talk about binary blobs Linux firmware stack has been got from all over the place including BSD systems.
Simple hard to get fact here. Linux developers working on specification for standards to solve the problems they are hitting if there are no BSD developers there. They don't have to give a stuff about BSD concerns. Reason you must not be interested in fixing it so meaning any BSD kernel interfaces they use could change on them so rendering there code a waste of time. Sorry this is the way it crumbles.
Yes Linux people don't have to give compatibility with BSD a second thought. Have they ever given BSD a second thought. Historically no. Have unix's who use to take BSD code for sections of there OS's given BSD compatibility a second thought. Historically no.
Will freedesktop give BSD a compatibility a second thought if BSD developers are taking part. Answer yes. Freedesktop gave BSD the biggest voice its ever had to control its future of compatibility with everything else. Yet for some reason BSD people want to throw the chance away. It is not logical.
Yes historically BSD has been a follower not a leader.
So what again is the problem? Just compile Thunar without thunar-volman or leave Thunar out completely and use a file manager that works, like PCmanfm (if it does, haven´t tried it, just an example).
Just some thoughts:
Independently of what is what, a H.A.L. udev+usession+uwhatever interface layer is needed.
The fact that present situation poses problems to BSD usage of XFCE... is only an effect warning us that something is missing.
Be it on Linux or in BSD, it is not very much relevant, as coexistence is needed and has a strategic value. Not to mention the spirit of both systems.
It is not a matter of "following" but of getting the wheels properly implemented.
Let us remind that XFCE, as a linking point between Linuxes and BSDs has the peculiarity of being a check point, also one that shows an opportunity... pointing the way to go.
AKA Factor-H, DuLac
I hate to add to this shameful pissing contest but:
"There were other OS's at Freedesktop when it started. The problem is all those have left. So freedesktop has become a poorer source of specification."
Perhaps you should think about this and it's implications more carefully.
DragonFly BSD has a homebrewed implementation of udev; does it suit xfce? Perhaps the other BSDs should look into porting it?
It's not a matter of having BSD developpers involved or not, it's a matter of writting code for UNIX like systems or not. There are other players in that field. BSD's of course, but also UNIX, AIX, Solaris, Darwin/Max OS X and others.
UNIX's biggest strenght and biggest problem always have been forks. That remember's me what almost killed it before Linux arrived to the rescue, mainly the famous war between SunOS/OpenLook and UNIX/Motif.