Over the past week, some of the Linux desktop’s foremost developers gathered together in Portland, Oregon at the OSDL Desktop Architects Meeting to work further on bringing order to the Linux desktop. According to John Cherry, the OSDL’s Desktop Linux initiative manager, there was a good turnout of about 45 developers from the community, including major Linux vendors such as Novell and Red Hat, and ISVs like Google and Adobe.”
What’s Next in Linux Desktop Standardisation?
44 Comments
-
2006-12-13 8:07 pm
-
2006-12-13 9:50 pm
WorknManThat is why we are pragmatic: a workaround that actually works is better than a perfect solution that doesn’t exist.
Of course, you’re right, and I agree with you. My only point is that some people look at autopackage as if it were the actual solution. For example, whenever I bring up the idea of a package management standard on these boards, I usually get back, “But what about autopackage?”
People need to understand that autopackage is merely a ‘stopgap’ until the thick-headed are able to be convinced that a real standard is needed
2006-12-13 7:02 am
2006-12-13 10:36 am
2006-12-13 11:59 pm
-
2006-12-14 7:20 am
wakeupneoI know this is a standard response and is sure to be modded down, but how about loosening the leash to RedHat/Fedora and trying something else?
I used RedHat/FC for years before moving to another distro and I haven’t looked back…and I haven’t experienced many of the issues I was having with RedHat/FC either. A ‘real’ desktop-centric distro makes a big difference if that’s the primary use.
I won’t bother telling you what distro I settled on coz that’s just asking for trouble around here
The more open/cross-platform standards the better. This is something that Linux could benefit greatly from; not in the area of being “standards compliant” necessarily, but in providing a standardized interface by which the processes behind the user experience are streamlined.
I’ve been off and on the linux desktop for the past decade, and the biggest problem that I’ve seen over the years is that there was never the canonical desktop distribution for linux.
What that would have brought to the table is a set of APIs that most distros would have had to included in order to be ISV-friendly. Essentially, this would have brought leadership to the linux desktop years ago, in contrast to the design by committee that is being via OSDL today.
So I still see a tough road ahead for desktop Linux acceptance. The best case scenario for the current trend is that there is small gains over the years. The other scenario I see is that someone with deep pockets come along out of the blue and basically puts an entire ly new desktop operating system on top of Linux. But the wrong paths that were taken in the past are hard to overcome.
the biggest problem that I’ve seen over the years is that there was never the canonical desktop distribution for linux.
Canonical? You should try Ubuntu, then. 🙂
Canonical? You should try Ubuntu, then. 🙂
The funny thing is that Ubuntu is almost becoming the canonical desktop.
The funny thing is that Ubuntu is almost becoming the canonical desktop.
Every year or two has a different ascendant Linux distro. Used to be Slackware. Then Debian. Then Redhat. Then SuSE. Then Mandrake. Then Gentoo. Then Fedora. Now it’s Ubuntu. Next year will see another OMG Linux distro.
Every year or two has a different ascendant Linux distro. Used to be Slackware. Then Debian. Then Redhat. Then SuSE. Then Mandrake. Then Gentoo. Then Fedora. Now it’s Ubuntu. Next year will see another OMG Linux distro.
Direct link for this comment-
Not really. Slackware has always been a minimalist distro. Gentoo has been for the ricers. Mandrake, at one time was the best out of box distro.
But desktop Linux has to mature at some point. There’s just not going to be some distro out of nowhere (unless they do something really different), that is going to dethrone Ubuntu in the near term. And frankly, it’s not needed. If anything there should be more consolidation if desktop Linux is to take off.
And of course the resources needed to provide a stable and ongoing distro just keep on going up, and one of th e reasons that canonical was able to get ubuntu going.
“There’s just not going to be some distro out of nowhere (unless they do something really different), that is going to dethrone Ubuntu in the near term. And frankly, it’s not needed. If anything there should be more consolidation if desktop Linux is to take off. ”
Yes, there already is. It’s called Kubuntu.
Not really. Slackware has always been a minimalist distro.
Slackware It may have been minimalist, but when it came out, it definitely was the *ascendent* distro. In fact, it was the distro that first put into people’s minds the possibility that Linux might be suitable for the desktop.
Gentoo has been for the ricers.
Of course it has. But the Linux community has a heck of a lot of ricers! For a while, Gentoo was the distro to have because it gave you the fairly easy tweakability and optimization. It may not have been ready for Aunt Tillie’s desktop, but then again, neither is Ubuntu.
But you’re missing my whole point. Every year or two there has been a “new” distro that suddenly attracted everyone’s attention. I confidently predict that late 2007 or 2008 will see a new ascendent must-have OMG Linux distro that you have to use to retain your l33t membership.
Of course, that doesn’t most of us old timers will continue to use whatever we’ve been using for the last ten years or so. I know I will.
My guess: rPath [1]
[1] http://www.rpath.com/corp/
The issue is not just a ‘set’ of API’s its also the ABI/version changes of this set of API’s which is kicking Linux in the ass.
OSX has the ‘core’ api’s
Windows has win32 and DirectX
Linux has … ?
Audio is another big issue, I my self like gstreamer and xine.
A standard ‘action’ api would be nice, IM/web/email even file types, no matter what DM your using it will always open that file type with that app … not per DM settings
Hell while im on a roll, why not have /usr/share/desktop for all the damm .desktop files, so every ‘app menu’ system displays all the applications, without having to search /usr
“Audio is another big issue, I my self like gstreamer and xine.”
And I like mplayer and xmms. 🙂
“A standard ‘action’ api would be nice, IM/web/email even file types, no matter what DM your using it will always open that file type with that app … not per DM settings”
By principle this would be great. But what application would be the right one? As an example: You click on a MP3 file. Fron the KDE point of view, a KDE program would be launched to play the file. But the user may want to use XMMS.
As an example from real life, my uncle is new to Linux. He got some SuSE stuff with KDE installed and wanted to play a MP3 file, so he clicked on it and there was Kaffeine, I tink, which started to scan through his CD and hard disks to find more MP3 files – instead of playing the one selected. Confusing for him. Same with video files.
A customizable connection between MIME types and programs to use would be a solution. The programs should be provided if they’re referenced to in this file. By default, the user won’t have to change the file / the settings. Still it should be changable, maybe with a standardized GUI frontend for users who are not that experienced.
“Hell while im on a roll, why not have /usr/share/desktop for all the damm .desktop files, so every ‘app menu’ system displays all the applications, without having to search /usr”
Good idea, except /usr/share belongs to system shared data only. Logical alternative to prefer: /usr/local/share/desktop (or even /usr/X11R6/share/desktop).
And I like mplayer and xmms. 🙂
What are you rambling about?
mplayer and xmms are applictions. gstreamer and xine are application frameworks. (well, ok, xine is an application as well as a framework… -1 for me)
Edited 2006-12-12 22:47
“mplayer and xmms are applictions. gstreamer and xine are application frameworks. (well, ok, xine is an application as well as a framework… -1 for me) “
You’re right, xine is described as “an X11 multimedia player” with many plugins, backends and alternative GUI frontends available. So it is okay to mention it as a program – xine / gxine – (first) and a framework – xine-lib – (second). From the xine homepage: “xine is a free multimedia player.”
BTW: I like xine because it runs on my SGI. 🙂
Gstreamer is mainly used by Gnome video players (e. g. totem-gstreamer), but it can handle audio as well.
You can surely see gstreamer as a framework. In fact, gstreamer80 is described to be a “development framework for creating media applications”. From the gstreamer homepage: “GStreamer is a library that allows the construction of graphs of media-handling components, […].”
Once gstreamer is installed, it provided command line tools as well. They can be considered to be “gstreamer applications”.
What do we have?
gstreamer = { library, framework, application }
xine = { library, framework, application }
So it’s completely okay to talk about them regarding their quality of being an application. q.e.d.
Maybe you didn’t know that, so I don’t mind your unfair judging and your insults. I won’t punish you for your individual opinion. 🙂
Edited 2006-12-12 23:48
//gstreamer = { library, framework, application }
xine = { library, framework, application } //
AFAIK, this is correct. Gstreamer and xine are the two main competing audio frameworks, and they both “sit above” the ALSA audio card driver.
AFAIK gstreamer is the audio framework for GNOME.
I am not quite sure where jack fits in to this picture.
http://jackaudio.org/
aRts used to be the audio framework for KDE, but some distributions have replaced it already with the xine engine (and AFAIK others may have used jack), and AFAIK KDE4 will have a whole new audio framework called Phonon.
http://phonon.kde.org/
Hope this helps (?? … I don’t see how, since it confuses even me).
PS: Hmmm, it doesn’t seem like jack is in this picture after all.
To replace aRts, KDE is apparently considering: libxine, gstreamer, NMM and Helix.
http://phonon.kde.org/cms/1005
I didn’t know about NMM until just now. http://www.networkmultimedia.org/
AFAIK Helix is a spin-off from Real, isn’t it?
https://helixcommunity.org/
Edited 2006-12-13 00:10
AFAIK gstreamer is the audio framework for GNOME
No, it is not. It is just the fact that it is used in Gnome. The only dependancy here is GLib I think.
But all proposing GStreamer or Phonon should focus on other problems with them.
GStreamer hasn’t got stable API/ABI yet and that was the major problem on the table of this meeting. Which would mean terrific framework, but unusable for these needs unless stable API/ABI wrapper would be written.
One could say Phonon is the answer here (Phonon is wrapper around various audio engines). Again not. It would be if it would be written in C and then made to C++ implementation. This way all parties could be happy and use it. But as long as Phonon is C++ at the base this makes problem for non-C++ needs.
API/ABI wise linux audio is really in terrible state. That is reality for now.
Most other problems could simply be solved by setting standard libraries, audio not, there simply isn’t one that would fit all.
p.s. DBus on the other hand has that. 1.0 was the first stable API.
jack is software mixer just like ESD.
Oh hell no. Don’t let a Jack dev catch you saying that.
ESD is a sound daemon.
Jack audio is pro-audio. It’s single user, low latency, offers interprocess piping, provides time code sync, and transport controll. The development versions support midi and slaving other jack dameons via network. Video support is in development. It is NOTHING like ESD.
thanks for the correction i didnt know that. i knew it was more pro oreanted.
//As an example from real life, my uncle is new to Linux. He got some SuSE stuff with KDE installed and wanted to play a MP3 file, so he clicked on it and there was Kaffeine, I tink, which started to scan through his CD and hard disks to find more MP3 files – instead of playing the one selected. Confusing for him. Same with video files.
A customizable connection between MIME types and programs to use would be a solution. The programs should be provided if they’re referenced to in this file. By default, the user won’t have to change the file / the settings. Still it should be changable, maybe with a standardized GUI frontend for users who are not that experienced. //
KDE does this. It is a part of Konqueror, or any other KDE filemanager for that matter (Krusader, Dolphin).
http://www.konqueror.org/features/filemanager.php
http://krusader.sourceforge.net/
http://enzosworld.gmxhome.de/
Kaffeine is the default player for KDE for audio mimetypes. You can easily change this to whatever you want … XMMS, Mplayer, VLC, Totem, Xine … myriad choices here.
Kaffeine doesn’t scan through Hard disks and CDs. Amarok might do that (on first run only), but Amarok is much more than just a simple media player. Amarok is more like a “media collection browser”.
http://amarok.kde.org/
http://amarok.kde.org/index.php?set_albumName=1-4-Series&id=amaroks…
“Kaffeine doesn’t scan through Hard disks and CDs. Amarok might do that (on first run only), but Amarok is much more than just a simple media player. Amarok is more like a “media collection browser”. “
Ah! My mistake! Of course it was Amarok. Sorry for remembering incorrectly, but because I don’t use KDE I’m not very familiar with the applications connected to file types by default. So Amarok would “just play” a selected file for the second run? (I still use XMMS for MP3 playback.)
//So Amarok would “just play” a selected file for the second run?//
I’m not sure. I think it would.
Amarok isn’t really designed for the scenario “double click an audio file in the file manager to play it”. That is really Kaffeine’s domain.
Amarok is more of a “media collection browser” come super-playlist-organiser come lyrics finder & displayer, etc. Amarok is more intended to be used in the scenario “open Amarok to select tracks for a session of listening to your music collection”.
IIRC, Amarok on first run will give the option to build a collection (and first you have to choose between MySQL and SQLite backends), but I think you can skip it and just play the file if you prefer. I’m pretty sure you first have to select paths to scan before it does so as well.
Amarok FTW, by the way
Like Kaffeine, it defaults to Xine but can use different player engines. For example (and it’s the only one I know that can do this) it can use the Helix engine, which is obviously good if RealMedia streams are your thing.
I really like this modularity that the diversity of engines/frameworks/frontends has caused. With maybe 3 choices for each of audio subststem/engine/frontend, and cross-compatibility between them all, you basically have a choice of 3x3x3=27 different ‘stacks’ — one of which is bound to actually work :/
ehm… /usr/share/desktop?? you mean /usr/share/applications ? try look there..
/usr/share/applications does NOT list all the gui applications on my system, its a good list, but doesnt list all my kde apps. [Gentoo]
/usr/share/applications does NOT list all the gui applications on my system, its a good list, but doesnt list all my kde apps. [Gentoo]
They should be listed there, unless they are really old (before KDE3.4) and haven’t been updated since then.
Can you provide a couple of examples?
Hell while im on a roll, why not have /usr/share/desktop for all the damm .desktop files, so every ‘app menu’ system displays all the applications, without having to search /usr
This is called the freedesktop.org menu specification and has already been implemented by GNOME and KDE for several releases.
I think even XFCE implements it.
http://www.freedesktop.org/wiki/Standards_2fmenu_2dspec
I agree with what was discussed especially on the Audio front.
I believed Gstreamer was supposedly meant to be the replacement for ARTS and the other old desktop system I can’t remember the name of.
At the moment audio seams to be very minimal in implementation and configuration especially if you want to get into multi channel outputs, surround configuration, multi app access and so on.
It would be nice if using ALSA as the driver base (and including driver firmware as a default in dist installs) that Linux bit the bullet and used a single sound server setup that could handle the capabilities of different hardware and sound plugins.
ALSA has to improve in it’s documentation and setup as well as it is pathetic to have a multi channel sound card and only be able to find config files that give a bare minimum stereo output.
That being said, I do notice a considerable difference in sound quality using Linux and ALSA compared to using Windows XP. More detail in the audio output and I have noticed this on a couple different pieces of low end pro audio equipment (Echo Audio and Hoontech).
Hope things improve and soon especially with supposedly what Windows Vista is bringing to the audio front.
Is 2007 will be the Linux year for the desktop >:) ?
The mime stuff and menus are already covered by some freedesktop stuff i think. And both kde and gnome use it.
When it comes to sound its my understanding that jacks have become a kind of de-facto standard sound server in the pro and related areas. However, for other uses its not that simple.
Browser: Opera/8.01 (J2ME/MIDP; Opera Mini/3.0.6306/1528; en; U; ssr)
Maybe one day, somebody will get smart and decide on a standard format for binary and source-based package. I mean, we’ve got ODF as a standard for documents, so why can we not have one for packages?
And don’t give me any of this Autopackage BS either. Autopackage is no more a standard for package formats than OO.org is a standard for document formats. Can one not understand the difference between the file layout and the applications used to read them?
I don’t understand why we can’t have distributed packaging with fine-grained versioning. I always thought Conary http://wiki.rpath.com/wiki/Conary:Overview was an interesting concept.
Not sure what’s your point. “Autopackage” is a software suite for managing autopackages, which are packages of a specific format. Just as “rpm” is a program for managing .rpm packages.
There is. Linux “Standard” Base chose RPM many, many moons ago. Why some insist on carrying on with deb/dpkg I have no idea.
Personally I would love if packages could be semi-standardized. Perhaps a compact standard for packages that is also extensible so that commercial developers could create a package based on the standard while distro packages could contain additional information and features.
Edited 2006-12-13 05:46
Autopackage is not a *package* format, it is a standalone *installer*. Think of it as install.sh or SETUP.EXE, it’s much closer to those than x.rpm or x.deb.
It is a format, too. It just happens to be executable.
Funny that folks now mod you down for no apparent reason – http://osnews.com/edit.php?news_id=16701&comment_id=191484
Edited 2006-12-13 07:52
I’m an Autopackage developer.
I’m all for standardization of a single packaging format for Linux. But frankly, I don’t think that is going to happen, which is one of the reasons why we exist. There are two ways to tackle the Linux installation problem:
1. All distros must standardize on a single format.
2. We must create a format/installer that’s flexible enough to work on many distros despite differences.
While I think that the first one is obviously the best one, I and Mike chose the latter because we think that 1 will not happen any time soon. Of course, anybody may prove us wrong.
Unfortunately, there’s more and more evidence that distros don’t want to standardize on a package format. Mike has recently blogged about his talk about packaging at the Ubuntu Developer Summit:
http://plan99.net/~mike/blog/2006/11/20/the-ubuntu-devconf/
You should read it before calling Autopackage “BS”.
I’m all for standardization of a single packaging format for Linux. But frankly, I don’t think that is going to happen, which is one of the reasons why we exist. There are two ways to tackle the Linux installation problem:
1. All distros must standardize on a single format.
2. We must create a format/installer that’s flexible enough to work on many distros despite differences.
While I think that the first one is obviously the best one, I and Mike chose the latter because we think that 1 will not happen any time soon. Of course, anybody may prove us wrong.
Yes, we are in agreement. The first option would be better.
Unfortunately, there’s more and more evidence that distros don’t want to standardize on a package format. Mike has recently blogged about his talk about packaging at the Ubuntu Developer Summit: