Weekly Edition
Return to the Announcements page
| |||||||||||||
Keeping the Desktop Dream Alive (LinuxInsider)
LinuxInsider talks
with Linux Foundation Executive Director Jim Zemlin. "What you
call fragmentation is that core kernel, which is a multibillion-dollar
investment, and what people are doing is taking that and building products
in the marketplace based on it, whether it's Google Search, Android,
Samsung TV, Facebook, a music service or the New York Stock Exchange. You
could characterize all these things as fragmentation, but I'd characterize
that as an efficient market -- in other words, the market is solving the
problems today."
(Log in to post comments)
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 17, 2011 20:47 UTC (Fri) by realnc (guest, #60393) [Link]
> desktop computing is starting to become less relevant
So what is he trying to say? Forget about the Linux Desktop because it's not relevant?
Jim Zemlin sure comes up with comments that totally miss the point in an annoying fashion. You ask him about Desktop Linux, he starts talking about the kernel. What do Google Search, Android, Samsung TV, Facebook, music services and the New York Stock Exchange have to do with "Keeping the Desktop Dream Alive"? Yey, hurray for the Linux kernel. But that was not the issue here.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 17, 2011 21:50 UTC (Fri) by kirkengaard (subscriber, #15022) [Link]
It looked to me like Linux Insider's questions were the problem. There's no reason to play that game -- as Jim says, to try to be Windows+Office and match Microsoft. "A stern chase is a long chase." But all the questions were asking "Why aren't you trying to beat Microsoft at the desktop game, particularly by becoming a monolith to fight a monolith?"
It may be just as well to say "Linux products have basically quit trying to play the "get on OEM desktops" game, which Microsoft has locked up, and have moved into critical if not dominant positions in every other market in computing." Desktop operating systems based on the Linux kernel and associated tools aren't going anywhere -- just as Windows isn't going anywhere. But all that tells you is that the desktop isn't the endgame anymore -- except not everyone in the press has gotten that message.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 17, 2011 23:23 UTC (Fri) by Wol (guest, #4433) [Link]
Isn't LinuxInsider closely associated with the Mogster and Pretenderle?
If that's the case, then what else do you expect?
Cheers,
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 18:50 UTC (Mon) by zonker (subscriber, #7867) [Link]
"But all the questions were asking "Why aren't you trying to beat Microsoft at the desktop game, particularly by becoming a monolith to fight a monolith?"
That's a legitimate question, from a lot of people's perspective. It's Zemlin's job to move the discussion, but it's a reasonable question - remember that part of a reporter's job is to ask the questions that the audience wants answered. While LWN readers may understand the problem with the question, I suspect that may not be the case for LinuxInsider and other more mainstream publications. (Despite the name, I don't count LinuxInsider as an actual "insider" publication by any stretch.)
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 9:17 UTC (Sat) by AndreE (subscriber, #60148) [Link]
I feel fragmentation is a pretty big problem on the desktop. There are competing products that often reimplement similar things in incompatible ways. Zemlin notes that the kernel really isn't fragmented, and the kernel is surely the most successful part of the Linux ecosystem. The kernel doesn't suffer from fragmentation precisely because at various levels, people make decisions for the benefit of the kernel. There is no such community or process for desktop technologies. Freedesktop.org is a lame duck, while KDE and GNOME generally develop in isolation.
Ultimately, to really compete on the desktop the platform has to be cohesive for both users and developers. Windows and OSX not only offer a certain level of polish for users, but a level of cohesion and friendliness fo desktop developers. The excuse for the Linux desktop has been that Windows has application inertia, but I don't think any attention has been paid to making Linux a superior environment and target for desktop application developers. One thing the phone wars have highlighted is that attracting developers to a platform is important, and Linux's failure to attract desktop developers cannot only be put down to market and mind share.
Now it seems we are holding out on the belief that the desktop will become less relevant, when we move to a service model. Yet, it doesn't neccessarily followthat a free Linux will be a true competitor. Many of these service-based models will rely on proprietary components that won't be available for free operating systems, and it's not inconceivable that future proprietary operating systems will have hooks for improved performance for their own proprietary cloud platforms. Furthemore, will people using Linux based phones be using Linux based operating systems if the phone is actually better supported on Windows or OSX? Hell, my Android-based Galaxy S needs Windows or OSX to get official firmware updates.
The Cloud only reshuffles some of the issues of adoption anyway, it doesn't mitigate them. Browsers will neccessailry become more complex, and thus demand more of from the operating system. Mozilla's recent problems with WebGL on Linux suggests that the move to the cloud isn't going to be the democratising panacea that let's us claim near parity with Windows and OSX.
Finally, I feel Zemlin's response is a little bit evasive. The central question is why Linux on the desktop hasn't taken off, and Zemlin essentially points to Linux's success in other ares. I don't think anyone's doubting this. The Linux-based platform has been very successful, but the Linux desktop has not. And if the desktop in general is in decline, why should anyone believe that the Linux desktop will as a result become more popular? My biggest worry is that any "death of the desktop" will see free software resources devoted to other platforms, and the only desktop products available will be those with strong desktop market share.
Of course, for many users (including myself), the Linux desktop is "good enough" in many respects, and far superior in other aspects. Although I do often appreciate the polish and cohesion of Windows or OSX, the Linux desktop for me is familiar and just too powerful. But I wouldn't migrate my parent's computer, nor friends who I know are not computer savvy or simply not interested in hunting around for solutions to certain problems. I certainly encourage people who are interested, but I am now more hesitant to consider free systems for "normal users"
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 9:30 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
"but I don't think any attention has been paid to making Linux a superior environment and target for desktop application developers."
Gosh... I wonder what we at KDE have been doing for the past fifteen years then, if not exactly that.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 10:48 UTC (Sat) by AndreE (subscriber, #60148) [Link]
Improving KDE. Except Linux is not KDE. Thanks for being glib though.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 12:05 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
What's glib about it? What KDE does is exactly what you asked for: provide "a superior environment and target for desktop application developers" on Linux.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 12:14 UTC (Sat) by AndreE (subscriber, #60148) [Link]
So I write an music player application using Phonon and QT.
Now, can GNOME users use this?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 12:40 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Yes, and it was always that way. Your point being...?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 13:03 UTC (Sat) by AndreE (subscriber, #60148) [Link]
Sorry, I should have been specific.
Can I be SURE GNOME users will be able to use the application? No I can't, since I don't know which backend they have registered, and the functionality varies from backend to backend.
This doesn't compare favourably to CoreAudio or DirectShow, which provide a better guarentees.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 13:23 UTC (Sat) by stumbles (guest, #8796) [Link] Yeah... I know and I am being glib; it is terribly hard to use your distros package management tool to install gstreamer, xine or vlc backends. But I guess then you will complain about the hugely complicated-ness of the varied package management tools.Since when has software of any sort had any carved in stone guarantees? Never... afaik.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 13:55 UTC (Sat) by AndreE (subscriber, #60148) [Link]
You're missing the point.
I write a phonon app. User A uses gnome/gstreamer, user B uses kde/phonon-VLC. Both backends actually have different functionality. That's really great for the consistency of my application, isnt' it. Then there's the guy using phonon-xine who has other issues.
That's really great for the consistency of my application isn't. When I only have one target on Windows, one target on OSX, and potentially three on Linux, I wonder nice operating system really seems worth my effort.
I dont think it's that complicated Posted Jun 18, 2011 16:45 UTC (Sat) by Arker (guest, #14205) [Link]
You just write the app to phonon and if any gnome users want to use it, warn that they might have to install the backend. Why is that so hard?
There is no top-down enforced standard like in the Windows and Mac worlds, true. This is a good thing, not a bad thing. It means *you* can choose which of the available alternatives fits your need in writing your application, and potential users can also choose the application that fits their own needs as well.
Would it be a nice thing to see someone build a Gnu/Linux-based desktop OS that DID have such monolithic control? It might well be good for some users, and some developers. I've actually flirted with that idea on and off for 20 years now, it's quite doable, but it requires a decent investment and apparently isnt considered such a great prospect for profit in most investors analysis, or we would have several. The closest thing I can see is Ubuntu, but it doesnt seem to be going too well to me. I see a lot of really bad decisions. But maybe for someone else they are good decisions? Fine, then those people use Ubuntu. Again, what's the big deal? The idea that you can't tick off *linux as a checkbox and rely on customers runing linux having no unforseen problems? The problem there is this sad misunderstanding that linux is an OS. It isnt, never was, never will be. Linux is an infrastructure product on which many distinct OSs are and have been built. Want a checkbox target? I would suggest Slackware. If your app will compile nicely there then it should work on most anything else.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 12:22 UTC (Sun) by Lennie (subscriber, #49641) [Link]
There is no single API for anything in Windows either.
But it is documented, on old Windows you have X on new Windows you have X and Y. And as a developer you have 5 years to move to the new API or your application might not work so well on a newer versions.
On the Linux desktop you have, X, Y and Z. Different versions for different distributions and so on.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 21:48 UTC (Sat) by elanthis (guest, #6227) [Link]
Actually, yes, I will complain about the myriad packaging tools.
As a third-party developer (that is, someone who is not Red Hat, SUSE, etc.), the multiple package formats is a pain. Even worse is just the fact that a package for Distro V3 probably won't work in any way on Distro V5 because some packages have been removed, ABIs changed for libraries (and the older libraries are not kept around for a reasonable length of time, that being 5-10 years), etc.
Windows suffers from a similar problem, but fixes it by just having apps distribute libraries with them. Which is horrible.
Linux as a larger ecosystem _could_ give us the best of both worlds. It really could. I wish to #DEITY that it would. But instead, it gives us desktop appliance models without the versatility and third-party support that Windows has in exchange for fixing a problem with the Windows model that only really bothers developers but not users and publishers.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 8:48 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> As a third-party developer (that is, someone who is not Red Hat, SUSE, etc.), the multiple package formats is a pain. Even worse is just the fact that a package for Distro V3 probably won't work in any way on Distro V5 because some packages have been removed, ABIs changed for libraries (and the older libraries are not kept around for a reasonable length of time, that being 5-10 years), etc.
I've been playing with the following model in my head recently (I know that it won't do anyone much good as long as it stays there, but one has to start somewhere).
A repository-based system like what distributions have now, but not tied to any distribution (but with all the security updates and what not).
Libraries are included as static (static linking has a bad name, but has many plusses too, see http://sta.li/ and the linked FAQ), not shared.
When your application is downloaded it pulls in all needed dependencies, is statically linked with whatever libraries it uses (address space randomisation happens at this stage) and packaged up into a nice little *Step-style bundle which can then be moved about in the filesystem as needed.
Checks for updates are triggered by the application on startup, but using a framework provided by the repository system (made available using distribution-native packages).
Possibly use a hashbang wrapper to start the applications combined with a starter helper which is also part of the framework. This could take help with application relocateability and possible also handle the update check automatically.
I think in some ways this would be your "best of both worlds", though now I've posted this I am sure that all the other ways will be pointed out to me :) The bundle bit also satisfies my personal sense of aesthetics by keeping everything in one place instead of exploding installed packages across the filesystem as is common in Linux-based systems (this always seems to me to be stretching the KISS principle badly).
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 22, 2011 13:54 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
In your attempt to solve the "too many moving targets" platform problem you laid out requirements that would require an unobtainable level of agreement from at least all users of a distribution if not most Linux users.
No solution that requires "app bundles" will be generally accepted. No solution which is not generally accepted is the answer to the problem. If you don't believe this, sorry.
Worry less about the mechanism ("hasbang wrapper", etc) as long as it is practically implementable and more about the structure of the solution. You should also attempt to solve both desktop and server scenarios at the same time or, if you can't, invent two solutions that work together.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 22, 2011 19:35 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> In your attempt to solve the "too many moving targets" platform problem you laid out requirements that would require an unobtainable level of agreement from at least all users of a distribution if not most Linux users.
I'm not quite sure which parts would require that much agreement. I would have thought that the repository/updater bit could be done as a single installable distribution package containing the service. A newly installed (as in dropped into the filesystem) package could ping the updater the first time it is started to let it know that it is there, and where in the filesystem it is (which also lets the system owner move it without having to worry). It could of course run even without the updater if necessary.
Obviously proper OS X-style GUI integration of the "app bundle"s would require a lot of agreement, but that isn't really needed to make them usable. A desktop file under /usr/share/applications and a symlink in /usr/bin, which the updater can also put into place, can also do the trick (and it can also take care of other sorts of system integration such as creating init scripts/systemd service files or installing mimetype descriptions).
> No solution that requires "app bundles" will be generally accepted. No solution which is not generally accepted is the answer to the problem. If you don't believe this, sorry.
Again, do you mean app bundles with full GUI integration? It seems to me that bundles under /opt are the FHS's recommended way of installing third-party applications. Designing them in such a way that they could be integrated with the GUI makes sense of course (for desktop applications at least).
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 14:51 UTC (Sat) by krake (subscriber, #55996) [Link]
"Can I be SURE GNOME users will be able to use the application? No I can't..."
Yes you can. The workspace/shell a Phonon using app runs in is of no concern to the app. E.g. Amarok is not only used by people running one of KDE's workspace offerings, some are using GNOME, XFCE or even "just" a window manager like Awesome.
Using applications from one vendor in a workspace provided by another vendor is very common on a lot of platforms. Actually as far as I know on all major platforms even in the mobile space
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 15:35 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah. And that's why Amarok doesn't play MP3s on stock install of Ubuntu (with codecs), even though Rhythmbox works just fine.
Couple of releases ago Amarok hadn't worked at all (I had to manually install Xine backend and select it in Phonon configuration). Even though Rhythmbox worked just fine.
Yay, isn't choice great!
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 17:30 UTC (Sat) by drag (subscriber, #31333) [Link]
Phonon is the most obvious example of just pure wrong-headiness with the Linux desktop.
We need to have one thing that does one thing and does it well.
We don't need one thing that supports a dozen different things to do the same thing poorly in different ways.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 23:11 UTC (Sat) by erwbgy (subscriber, #4104) [Link] Actually Phonon is an attempt to deal with this wrong-headedness. If you are not going to get everyone to agree to use the same backend then having a layer that hides this from applications and exposes the common functionality is really useful as it avoids them having to deal with the differences. The Linux desktop would be better off if we had more use of things like Phonon and Solid so that application developers could have a more consistent target, regardless of the distribution. I agree that we'd still need an underlying implementation that actually works though :-)
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 23:42 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
The answer to "We have three widely used multimedia libraries" is to get people to pick one of them, not introduce a fourth library that serves as a leaky abstraction of the other three - now you've got *four* problems.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 23:43 UTC (Sat) by bronson (subscriber, #4806) [Link]
Phonon is just a symptom, a shim. The Linux audio wrong-headedness runs a lot deeper.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 1:30 UTC (Sun) by drag (subscriber, #31333) [Link]
> Actually Phonon is an attempt to deal with this wrong-headedness. If you are not going to get everyone to agree to use the same backend then having a layer that hides this from applications and exposes the common functionality is really useful as it avoids them having to deal with the differences.
Yes.
That's why you don't let them choose a back end. They don't want to care about backends.
Nobody does. Nobody really cares if their applications use gstreamer or vlc or whatever. I don't want to care, application developers don't want to care. You don't want to care. Nobody wants to care. It shouldn't be a problem or issue in the first place.
Unless they are:
Nobody wants to care. That's the point. However they do care.
The reason they do care is because they _have_ too. Because they all suck. But they suck in different ways. Some audio stuff will work with VLC, but not Gstreamer. Other stuff will work great with Xine, but runs like crap with mplayer. etc etc.
So users will just use trial and error and flail around until they get something that works for their particular purposes.
Then the desktop developer either has to either support that particular configuration till the end of time or simply chooses to break a bunch of people's systems during the next update. Either way then everybody gets pissed.
A better approach would of been to pick one backend and work on 'just making it work'. It doesn't matter which. It's largely irrelevant except for some unfortunate legal issues. It's often more of a aesthetic choice then anything else... any one of them can be made to work with enough effort. And then put the effort into fixing what is wrong with it and make it work for everything that KDE needed.
> Phonon is just a symptom, a shim. The Linux audio wrong-headedness runs a lot deeper.
Your exactly right. My point was not that Phonon was the only thing wrong with Linux on the desktop. It was a example.
The fact that they tried to solve a deeper issue with a _shim_ is a example of why we have these problems. It's a sort of pointer or indication of cause of the issues we face here.
The concept of making a nice library like Phonon to make simple things simple is a sound one. From the phonon part on up is probably very good design. But the idea of supporting all these backends is just silly. I am only picking on it because it's so obvious that the design is wrong and it was mentioned before.
There is certainly all sorts of things like phonon floating around. It's a common approach to try to fix underlying issues with just layering crap on top of it. But it's not usually a good way to do things, unfortunately.
So I don't mean to insult KDE developers or anything. If phonon was the only major issue then it wouldn't be a issue. It's symptomatic and because there are a lot of smart people doing the same mistakes means that KDE are not dumb people.
I wouldn't mind seeing a good KDE desktop be created.
Just like 'Gnome OS' I would like to see 'KDE OS'.
Just pick the distro with the best KDE support so far and run with it. Just take it over and make it as the best KDE desktop possible with the exclusion of all other things and all other purposes. Just go all out and forget all care about portability or whatever. Just make it the best it can be and worry about portability after you have something that works better then it ever did before. Take control of it from the ground up and make it as lean and KDE centric as possible.
Make a new type of Linux desktop.
I think that would be fantastic.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 2:00 UTC (Sun) by cmccabe (guest, #60281) [Link]
> The reason they do care is because they _have_ too. Because they all suck.
> But they suck in different ways. Some audio stuff will work with VLC, but > not Gstreamer. Other stuff will work great with Xine, but runs like crap > with mplayer. etc etc.
I just compile mplayer with every option I can turned on. It plays everything I can throw at it just fine, thank you.
I understand the theoretical justification for frameworks like Gstreamer and Phonon. But in practice, when I install the distribution, they come without mp3, mpeg and other useful codecs. Yes, I understand the legal rationale. Fixing all the various omissions turns out to be harder than just compiling mplayer, so guess which one I choose?
> Just pick the distro with the best KDE support so far and run with it.
That has already been done several times, hasn't it? There was Kubuntu and that other one.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 13:12 UTC (Sun) by hmh (subscriber, #3838) [Link]
Stock mplayer is utterly unable to deal with most common non-joke subtitle formats. Maybe you mean mplayer2 ?
NIH syndrome is a really big problem in the Linux DE media framework area.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 16:38 UTC (Mon) by cmccabe (guest, #60281) [Link]
Well, I don't watch that many movies with subtitles, so I'm not too familiar. The last two I tried worked with regular mplayer, for what it's worth.
KDE-only distro Posted Jun 20, 2011 9:25 UTC (Mon) by eru (subscriber, #2753) [Link] > That has already been done several times, hasn't it? There was Kubuntu and that other one.Isn't Kubuntu just a slightly KDEised version of the basically Gnome-centric Ubuntu? I think a better example would be Mandriva. But it is not pure KDE either. Probably it (or the Mageia fork) would be a good base for the proposed fanatically-KDE-only distribution. It would be an interesting experiment to see if ditching the heterogenuity would result in a better desktop experience.
KDE-only distro Posted Jun 20, 2011 12:57 UTC (Mon) by Pawlerson (guest, #74136) [Link]
If you're looking for some fanatically-KDE-only distribution there's a Chakra Linux. It's a community driven distribution based on Arch Linux. There's probably no single bit of gnome and gtk in its repositories, but it allows you to install some popular applications using, so called 'bundle system'.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 26, 2011 11:31 UTC (Sun) by lab (subscriber, #51153) [Link] So users will just use trial and error and flail around until they get something that works for their particular purposes.As a Linux user for 15 years, I would say that it's exactly like that. I would also venture that this is one of the major stumbling blocks, which have prevented major Linux desktop catch-on through the years. In my humble experience, the only way to get Linux that 'just works', is to stick to your own carefully worked out recipe, extracted from much pain.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 26, 2011 16:27 UTC (Sun) by bronson (subscriber, #4806) [Link]
> The only way to get Linux that 'just works', is to stick to your own carefully worked out recipe, extracted from much pain.
Yes, well said! Although you can borrow your friend's carefully worked out recipe too.
Things are getting better (especially hardware support), but desktop Linux still has a long way to go.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 10:30 UTC (Sun) by krake (subscriber, #55996) [Link]
"Phonon is the most obvious example of just pure wrong-headiness with the Linux desktop."
When you look at Linux in isolation then this could be a valid interpretation.
Of course Qt is not not only used for application development on Linux, so having different implementation of an API on different platforms is desirable (unless of course all non-Linux platforms supported by Qt already have moved to a shared multimedia framework, I am not really up to date there).
When people write about Phonon the often think about it as a multimedia framework and then base their comments on that wrong assumption, thus leading to wrong conclusions.
After all Phonon's main purpose is to provide a simple media playing API for applications which do not need the flexibility of all-purpose frameworks. Allowing the API to be implemented on more than one platforms is a side effect, a free bonus so to speak.
I always wondered why this is so hard to get for so many people, having an API implemented on different lower layers seemed a very common thing to be in software engineering.
Strange, but maybe this is a really a novel concept that Trolltech came up with, although I distantly remember that Java actually had the same API on Windows and Linux, so maybe it's a late 90s thing.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 18:27 UTC (Sat) by stumbles (guest, #8796) [Link] Well as I see that has zero to do with Amarok and *everything* to DO with your distro of choice. I have been using Lunar-Linux for years now and have had no issues playing MP3s.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 1:32 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, the fix was easy - 15 minutes of Googling and several config changes.
However, imagine that you're and ISV and want to release your product on Linux. What are you going to use? What library should you target? Phonon usually works fine when KDE is installed and it might be even portable to Windows.
ALSA is nice, but it is strictly Linux-only, so no support for Solaris or FreeBSD. OSS is supported on Solaris but is NOT supported on Linux right now, except through buggy emulation layer.
Oh, there's also Jack and native PulseAudio. Have fun.
PS: I've been in exactly this situation. We went with raw ALSA and promptly got feature requests to integrate with Phonon.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 10:36 UTC (Sun) by krake (subscriber, #55996) [Link]
"We went with raw ALSA and promptly got feature requests to integrate with Phonon."
And it is very likely that whoever requested that had no or very little knowledge about Phonon and thought it would be some kind of audio system or framework.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 13:06 UTC (Mon) by Pawlerson (guest, #74136) [Link]
"However, imagine that you're and ISV and want to release your product on Linux. What are you going to use? What library should you target? Phonon usually works fine when KDE is installed and it might be even portable to Windows.
ALSA is nice, but it is strictly Linux-only, so no support for Solaris or FreeBSD. OSS is supported on Solaris but is NOT supported on Linux right now, except through buggy emulation layer."
KDE puts a lot of efforts to provide good integration. The NIH syndrome in the gnome camp is a problem. Personally, I don't care about gnome at all, because I consider it follows some stupid guidelines which just hurts Linux. I'm happy Canonical will encourage developers to write applications in Qt.
Are we talking about Linux or about other operating systems? I see no reason why Linux developers should even bother thinking about *BSD or Solaris.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 23:00 UTC (Tue) by cmccabe (guest, #60281) [Link]
I think if you're just doing something simple with audio, like playing a sound, libao would be a good portable choice.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 10:13 UTC (Sun) by krake (subscriber, #55996) [Link]
"Couple of releases ago Amarok hadn't worked at all (I had to manually install Xine backend and select it in Phonon configuration)."
Interesting. Which backend did orginally get installed instead?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 12:13 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Gstreamer, if I remember correctly.
If I remember correctly, this is it: http://chanweiyee.blogspot.com/2009/04/ubuntu-904-amarok-... , though I also had to change Phonon configuration manually.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 18:44 UTC (Sat) by nicooo (guest, #69134) [Link]
> Can I be SURE GNOME users will be able to use the application?
That's the distro's job. Users -> package maintainer -> you. That's how things should work when it comes to integration.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 10:49 UTC (Mon) by dgm (subscriber, #49227) [Link]
Not if your application is not Free Software. Then it's more like this:
users -> ISV -> package maintainer -> desktop developers -> kernel developers -> hardware vendors -> Microsoft.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 13:39 UTC (Sun) by tuna (guest, #44480) [Link]
Phonon is, in my own subjective opinion, a totally useless abstraction layer. The only thing phonon makes possible is to write a limited media player that can use different backends such as gstreamer, xine-lib and others. Then you can give the user the choice of which backend to choose. This means you can never use the full capabilities of the backend, only what phonon exposes. You will also get a really difficult testing matrix and bug reporting chain. If a user reports a bug you will have to find out if it is backend specific or not, to which backends it affect, if the bug is in the phonon backend code or in the actual backend itself. Phonon also pushes a lot of responsibility to the user. If something does not work it is easy to say "try another backend". And if backend X works when backend Y does not, what is the point of giving (the user the choice of running broken backend Y?
On a more retorical level, I would say that Phonon forces the user to make choices almost all cannot really make an informed decision about.
Now, all distros ship GStreamer as it is the only multimedia framework that can be legally distributed and works really well. Therefore, if you want to make a limited media player for KDE would it not be better to use QT-GStreamer, cut one layer of your dependency graph and make your testing a whole lot easier?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 14:01 UTC (Sun) by tuna (guest, #44480) [Link]
One thing Phonon might actually be useful for is writing cross-platform simple media players. So you could write to Phonon to support simple media playing on Windows, MacOS and Linux distros (through GStreamer, or another framework the Phonon devs choose). Of course, if you go this route and X (such as audio volume control) does not work on platform Y, all you can do is to file a bug with the phonon devs. But then at least the Phonon devs knows what actual backend.
So, a Phonon with set backends for different platforms would be a valuable project, but as Phonon is now I would say it is useless.
But of course, if Nokia wishes to pay for it or people do it for fun, good for you! I hope you have fun hacking and I am sorry for dissing you all! I just wish you would do something more beneficiary to the world, but I have no right demanding anything from you. So, happy hacking to all Phonon devs!
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 7:20 UTC (Mon) by ab (subscriber, #788) [Link]
We had these arguments ran through Trolltech guys through whole my 2.5 years at Nokia as media experience applications architect. Phonon was unusable for Maemo/Meego purposes, even for those limited functionality applications that we were building, and no reasonable API was provided so we had to go directly to GStreamer level. That worked very well and in the end we were able to also fund QtGstreamer work that produced reasonable Qt bindings to GStreamer to work with.
Unfortunately, there seems to be quite bad attitude towards GStreamer among those who never did media work other than simple players. If your API targets only cases like simple playback, you'll end up with limitations that allow only simple playback. You'll have to think about other parts of media production/consumption cycle as well, in order to come up with something reasonable. And even simple playback needs to be aware about sources where content comes from, their potential streaming nature, DRMed setup, etc. I'm not talking about more complex options like camera and audio recording coordinating between multiple devices.
Qt Mobility Multimedia API tried to address Phonon's misses to certain degree. Unfortunately, it fails too -- if you need to be extensible, extension points go to backend level as well, which means exposing backend-related knowledge too. At this point intermediate layer that hides backend becomes irrelevant.
We (a group of multimedia architects at Maemo/Meego and Symbian) tried to get a common platform for Qt-based multimedia, on top of GStreamer as it now runs everywhere where Qt has its targets. We almost succeeded but then Elopocalypse came and paralyzed most of work. I guess there will hardly be any new opportunity...
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 12:34 UTC (Mon) by Wol (guest, #4433) [Link]
>Unfortunately, there seems to be quite bad attitude towards
>GStreamer among those who never did media work other than >simple players. If your API targets only cases like simple >playback, you'll end up with limitations that allow only simple playback.
:-)
Reminds me of that thread about Jack and latency a few months back ...
"But latency isn't important. Maybe less than 1% of users need that strictly controlled latency, don't they?"
Finally got it through to the guy that yes, it's a special case and yes it's probably less than 1% of all users. BUT that 1% makes up 99% of Jack users!
I can't be bothered to fix it at the moment, but I keep having MySQL conflicts between Amarok and Postfix, and every time my wife runs XP in VirtualBox, it kills the sound for everything else on the system.
How did you guess I run gentoo? :-)
:-(
Cheers,
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 14:55 UTC (Mon) by ab (subscriber, #788) [Link]
:)
I would separate a bit needs of users who run targeted hardware+software combination and needs of software developers at large, not limited by a specific hardware+software combination.
PulseAudio vs Jack discussions have their own merit and both sides have equally important arguments. At the end of the day, if there is specialized hardware to be used, it is the developer of that product to decide which framework fits better his/her main purpose. But for generic cases like "Qt" limiting itself to a single simplified technology and hoping that "backends" will handle everything is just fouling yourself.
That said, Jack should have been quite useful on Maemo devices. Perhaps, -- and at this point it is mere wishful thinking -- it was not ready/experts were not available in 2004/2005th when all the story started compared to PulseAudio/Alsa guys availability.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 12:40 UTC (Mon) by Pawlerson (guest, #74136) [Link]
There's a very simple solution - focus on KDE. It's much more advanced, mature and provides far better tools for developers. Last time I checked it's a Gnome camp who don't collaborate with others (KDE and Canonical) and who doesn't care about unifying the Linux desktop. Shell is very hostile to non Gnome applications.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 15:05 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
This is precisely the attitude that won't work. Collaboration and building consensus is not easy. Posting a spec in freedesktop.org doesn't automatically accomplish that. I am sure all parties have to accept responsibility instead of mud slinging and accusing others. Get out of the pettiness and do something better. Talk in person in the desktop summit for instance.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 11:16 UTC (Tue) by Pawlerson (guest, #74136) [Link]
I know, but I speak for myself and I'm not from KDE. I read gnome folks responses to Aaron's post and their attitude was exactly like this.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 13:02 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
Yes. I'm writing a painting application with Qt and KDE -- and most of my users are actually Gnome users.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 14:13 UTC (Sat) by AndreE (subscriber, #60148) [Link]
I don't think the image situation is comparable to the audio situation, but even so, KDE might be doing an excellent job, but GNOME/GTK also exists, providing a different target.
Qt is really great, and plays very nicely in KDE and GNOME. GTK doesn't play so nice. Really, it's so unwieldy and unfriendly on KDE. If the standard for writing desktop applications stipulates targeting Qt, then there would be no problem. There would be a level of consistency. But that's the problem. There really isn't a standard or something to base consistency on.
It was probably wrong of me to suggest that NO work has been done on providing a good application environment for developers. What I really mean is that there is no standard or even consensus on what the base technologies are that desktop developers should target. Now you might suggest Qt/KDE, and I might even agree, since that's the system I use, but I'm sure the GNOME guys would suggest differently.
And of course, KDE/GNOME can't really do anything about differing package formats, naming conventions, etc etc.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 22, 2011 14:13 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
Having a single standard API would be nice on a certain level but I don't believe this is obtainable. What's more important is to make sure that no matter what toolkit the developer chose the user's experience is the same, or as close to it as possible. This means making sure that theme, keybinding, and other settings are set similarly for all possible toolkits whenever something is changed by the user and that a new toolkit on a system bases its default configuration on the current configuration of an existing toolkit. This sort of dynamism is doable and would go a long way towards making things consistent.
There is a consensus on "base technologies" - it's called the LSB, and it's not very useful when it comes to graphical apps.
We probably can't ever get consensus, where consensus means a single toolkit wins and everybody starts using it. We lost that chance in ~1996. The question now is, in the absence of a single API, how can things be made better?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 12:22 UTC (Sat) by krake (subscriber, #55996) [Link]
I think Boudewijn was referring to your assumption that no thought has been paid to making Linux a viable target for desktop application developers.
The fact that KDE technologies can be used by desktop application developers to create applications for more than just one operating system doesn't invalidate the fact that said technologies have been enabling desktop application developers to deliver great products on Linux for years.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 13:13 UTC (Sat) by AndreE (subscriber, #60148) [Link]
Saying "no thought" was exagerated, if that's what I said. KDE is excellent, it's my desktop of choice. I think I did state that there are plenty of applications written over the years for Linux.
But the question is not just writing applications, it's trying to lure users and developers away from Windows and OSX. And obviously it's not just a problem with KDE/GNOME, the sound, graphics, and packaging situations have similar issues.
Compared to our competing desktops systems developers have much more to think about. There isn't set of desktop technologies they can expect to be present and to target.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 19:08 UTC (Sat) by nicooo (guest, #69134) [Link]
How many applications written fifteen years ago compile on 4.6? I understand that the desktop needs to evolve, but revolutionary changes are a problem for developers.
It's even worse for users. I run FVWM and know that in 10 years it'll be pretty much the same. I can't say the same for GNOME or KDE.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 19:29 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
My own application, Krita, was started in 1998. It compiles fine, and has never been in a better shape. That said, yes, api churn is big problem and I'm not looking forward to Qt5. But as a whole, the desktop has been getting better and better and better.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 19:53 UTC (Sat) by nicooo (guest, #69134) [Link]
I meant code from 1998 ;)
Anyway, I'm happy with KDE as long as I can keep running individual applications independently.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 20:10 UTC (Sat) by boudewijn (subscriber, #14185) [Link]
Yeah, the original code from 1998 -- that's going to be a problem. Although... Last year, there was an opensuse live cd that contained KDE 2.0, built on opensuse 11.3, if I remember correctly.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 5:39 UTC (Sun) by realnc (guest, #60393) [Link]
> Gosh... I wonder what we at KDE have been doing for the past
> fifteen years then, if not exactly that.
Your work is remarkable, but it can't solve the basic problems. KDE (and any other DE) is split from the underlying OS. I don't DEs providing configuration options for X.Org, ALSA, my web cam, my MIDI keyboard... You get the point.
(Shameless rant: Also, what's the deal with all those annoying KDE bugs/glitches that have been reported forever but never get fixed and make KDE still look and feel like a beta version? :-P)
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 10:45 UTC (Sun) by krake (subscriber, #55996) [Link]
"Your work is remarkable, but it can't solve the basic problems. KDE (and any other DE) is split from the underlying OS. I don't DEs providing configuration options for X.Org, ALSA, my web cam, my MIDI keyboard... You get the point."
Actually it does.
On a related topic, developers at operating system vendors, can use the very same infrastructure to integrate system or system service configuration.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 10:24 UTC (Mon) by dgm (subscriber, #49227) [Link]
You have been changing the ABI. That's a no-no for developers.
And not only that, but also the API. Where's the backwards compatibility? Supporting a custom application for desktop means freezing the environment (that is, keep using old unsupported desktops forever) or rebuilding and retestesting (expensive!).
I hate ti say it to you, but from the point of view of a ISV, both KDE and GNOME suck. But KDE sucks more.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 13:12 UTC (Mon) by Pawlerson (guest, #74136) [Link]
Looking at Gnome 3 I beg to differ. It's an example how PC desktop shouldn't look like. It must be also pain for developers - Canonical, KDE vs Gnome.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 0:55 UTC (Tue) by HelloWorld (guest, #56129) [Link]
Oh my, what a poor trolling attempt.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 10:46 UTC (Tue) by dgm (subscriber, #49227) [Link]
It's the pure truth. You can dig your head in the sand if you wish, but I will not go away.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 13:34 UTC (Tue) by nye (guest, #51576) [Link]
How is that trolling? Enormous ABI and API changes with no provisions for backwards compatibility mean that any KDE application more than about 4 years old needs/has needed a tremendous amount of work to remain functional. Even if the reasons for it are good enough to outweigh that problem (and my personal opinion on this changes with the wind) you can't seriously argue that it's not a valid concern.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 13:36 UTC (Tue) by nye (guest, #51576) [Link]
As an addendum: obviously the problem results in large part from the changes made between Qt3 and Qt4, so they aren't actually KDE's *fault*. It's entirely understandable that nobody in the KDE community has the copious free time to keep maintaining compatibility libs forever, but that doesn't make it any less a problem.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 18:15 UTC (Tue) by krake (subscriber, #55996) [Link]
"How is that trolling?"
Most likely not trolling but not very accurate comment either.
"Enormous ABI and API changes"
There have been neither ABI nor API changes, all library products (Qt, KDE, GLib, GTK+, etc.) have respective policies for that and try hard to not slip any violation through.
You and the other commenter are probably referring to the introduction of new API and ABI as from then on recommended bases for application development.
Which happens on all platforms all the time, because at some point all frameworks reach a situatuion where new usage requirements cannot be provided for in a reasonable fashion.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 22, 2011 13:47 UTC (Wed) by nye (guest, #51576) [Link]
>There have been neither ABI nor API changes
So I can download, say, ktop (http://linux.maruhn.com/sec/ktop.html) and run it unmodified on KDE SC 4.6?
>Which happens on all platforms all the time
You're an outright liar
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 23, 2011 13:28 UTC (Thu) by krake (subscriber, #55996) [Link]
"So I can download, say, ktop (http://linux.maruhn.com/sec/ktop.html) and run it unmodified on KDE SC 4.6?"
I don't see why you couldn't.
"You're an outright liar"
Really?
So all the companies which spent resources on porting the OS X apps from Carbon to Cocoa were just plain stupid because Cocoa actually has the same API and ABI as Carbon and their application would have been using the new frameworks automatically?
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 22, 2011 14:24 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
If I can take a binary compiled against e.g. Qt 2.0 and run it on a recent distribution that has only Qt 4.5 and the application starts, runs, and works then I would agree that everything is compatible. If this doesn't work then something changed and broke compatibility.
If the answer is "Just keep a copy of the old Qt installed" then someone forgot to tell the distributions that this is required.
On a related note, why are gtk1 apps dead? Why can't I simply link them against gtk2 or a gtk2 wrapper library that provides the same old API and lets the app keep working even though the distribution stopped shipping gtk1? Why must I throw out my old applications just because they're unmaintained? I keep gtk1 libs installed myself, but this is a pain and old bugs are annoying.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 23, 2011 13:41 UTC (Thu) by krake (subscriber, #55996) [Link]
"If I can take a binary compiled against e.g. Qt 2.0 and run it on a recent distribution that has only Qt 4.5 and the application starts, runs, and works then I would agree that everything is compatible. If this doesn't work then something changed and broke compatibility."
If you taken an application and remove one of the libraries it depends on will of course not make it run.
Application developers use libraries in order to not have to implement all functionality themselves but that of course implies that the provider for such external functionality is available during runtime.
Having a different library which provides similar functionality does not matter at all. The operating system's component for loading external code into memory does not know about application requirements on a semantic level that would allow it to find equivalents on its own.
Therefor all platforms I know of allow the introduction of new APIs/ABIs in parallel, i.e. without having to remove existing ones.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 27, 2011 14:36 UTC (Mon) by nye (guest, #51576) [Link]
I'm aghast at the extent of your doublethink.
You've actually managed to redefine backwards compatibility in such a way that it is logically impossible for an API break or ABI break to exist in any circumstances, whilst claiming the complete opposite in another post.
Since you can't even agree with yourself and appear to be spewing random inflammatory nonsense I conclude that you are simply trolling.
Plonk
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 10:51 UTC (Sat) by jku (subscriber, #42379) [Link]
So in the area of kernels you are comfortable with defining the playing fields as "linux kernels" (and not open source kernels) and saying that there is no fragmentation in that group.... Why doesn't the same hold for desktop environments or OSes? In other words why can't I say that KDE is _not_ fragmentation of the desktop fields because I'm only looking at the "GNOME desktops" group.
I don't think that makes much sense. I have nothing against standardization in the desktop space where it makes sense, but I don't see how the existence of several desktops is holding back their individual success. If an environment/OS is good enough, it will succeed -- good interoperability with other environments/OSes is just a cherry on top.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 12:08 UTC (Sat) by AndreE (subscriber, #60148) [Link]
The kernel is different from the desktop environment because there is essentially one body that manages the kernel. Sure, there are vendor forks, and different entities can support there own tree, but there is really one recognised "Linux kernel", this seems widely accepted by all contributors. Also, the success of the linux kernel isn't dependant on comptability with these branches. If you are maintaing your own external tree, you really have expectations that changes to the main kernel branch will compile or work with your external tree. The kernel is a pretty singular base entity off which other derivation are based, but ultimately, it doesn't have to worry about interoperability
The problem with desktop environments is that they neccessarily have to play with other environments and toolkits. If every program was a KDE app or every program was a QT app, then life would be easier. The problem is that it isn't, and KDE, GNOME, GTK, and QT each bring along a set of different behaviour and assumptions.
It may seem trivial, but I run KDE4, and my location bookmarks aren't reflected in GTK apps. GTK apps can't access the network shares I see in dolphin. GTK apps don't obey my selection settings (single-click selection is my setup in KDE), they don't obey my view settings, and there is no way to really set a lot of these properties from within a KDE environment. This sort of cohesion and consistency is important because having certain assumptions about UI functionality contradicted in various ways is detrimental to the user experience.
If I want to write an application for the Linux desktop, I have to choose amongst a variety of APIs, and that choice might ultimately alienate or even exclude a particular segment of the user base. Should I be choosing Phonon for my QT app? What about non-KDE users? Will there be problems if the user uses PulseAudio instead of ALSA? What packaging format should I use? There is a question of a base operating environment that a developer must address. I'm not saying these problems are insurmountable, or that they are particularly difficult to work around. There are obviously plenty of companies providing software for the Linux desktop. But these are certainly stumbling blocks when trying to convince people to write multiplatform applications. Particularly for an envrionment that is often perceived as niche or having small market share, the variety and the complexities associated with the variety just make many developers think it's not worth the effort.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 13:20 UTC (Mon) by Pawlerson (guest, #74136) [Link]
"If every program was a KDE app or every program was a QT app, then life would be easier."
It was till someone started the gnome project. I know Qt wasn't free those times, but when it was released under the terms of GPL it should become a toolkit of choice. The logical thing to do was to kill gnome and gtk just after Qt became a GPL project, but sadly it didn't happen. Divide and conquer, I guess.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 13:55 UTC (Mon) by roc (subscriber, #30627) [Link]
Think about Firefox as an example.
Could we release "GNOME Firefox" and say that was all we needed to do for Linux? Of course not. We'd have to also release a "KDE Firefox" port, and maybe an "XFCE Firefox", etc.
That might work better than what we do now (a GTK2 Firefox that should run okay across desktops), but it would be *a lot* more work.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 2:34 UTC (Sun) by cmccabe (guest, #60281) [Link]
> Zemlin notes that the kernel really isn't fragmented, and the kernel is
> surely the most successful part of the Linux ecosystem. The kernel doesn't > suffer from fragmentation precisely because at various levels, people make > decisions for the benefit of the kernel
The Linux kernel gets forked all the time. Some of those forks are short-lived and get merged back into master-- like the Red Hat kernels. Other forks live for a long time, like the Android fork, and sometimes do have major differences.
Moreover, you are comparing apples and oranges. The equivalent to KDE versus Gnome would be the Linux kernel versus the OpenBSD kernel. In both cases, you have two codebases that do mostly the same thing, but in a completely different way. There is a community around both, although maybe not of identical size.
One of the biggest advantages of open source is that it gives its users choice. This is true at the personal level, where desktop Linux users can choose their distribution and window manager, and also at the corporate level, where companies can choose from MySQL or Postgres, or even something non-SQL entirely like Redis or Cassandra.
Users want choice. This is as true among non-technical users as it is among technical ones. One of the most common reasons users give for not switching from Windows to something else is that their favorite programs and extensions would become unavailable. There is usually an equivalent program for the user's favorite Windows program-- unless it is a game-- but it's not the one the user would choose.
> Ultimately, to really compete on the desktop the platform has to be
The ground is littered with the bones of operating systems that tried to be a better Windows than Windows. BeOS, SkyOS, Amiga, and so forth. You can't succeed by building a slightly better Windows than Windows. Microsoft will just throw another 1,000 programmers at the project and erase any small advantage you might gain.
What you can do is change the game. Rather than trying to create a highly proprietary, centralized operating system, create a decentralized, open source, and highly customizable one.
> The Cloud only reshuffles some of the issues of adoption anyway, it
We both know that nearly every website can be viewed from every platform. For a lot of applications, the post-desktop world will soon be a reality.
Pretending that the world is ending because there were some minor glitches with WebGL is disngenious at best. In fact, Microsoft has publicly stated that they will *never* support WebGL in Internet Explorer. Probably those supposedly doomed desktop Linux users will get good WebGL support long before most Windows users, simply because they will be using Firefox and Chrome rather than IE.
Someday, the software we're developing now will come back to the desktop and conquer it. But it won't be called "Linux." It will be called "Android." All the devices will be locked down and subject to centralized control and monitoring. And it will be friendly to proprietary developers, and easy to administer. Unlike the desktops we have now, it won't be carrying the heavy baggage of an antiquated security model or business model.
I understand the appeal of this kind of efficient, industrialized desktop. However, the one I run at home will always have quirky homebrew software running on it. And I suspect a lot of people here feel the same way.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 19, 2011 12:44 UTC (Sun) by Lennie (subscriber, #49641) [Link]
You two seem to have confused WebGL and hardware acceleration (think 2D and so on).
There is currently no hardware acceleration enabled on Linux-builds of Firefox because many drivers have problems with it.
It seems the pretty much the only one that is enabled is the closed-source NVidea one. Which is sad.
WebGL is mostly for games and so on. Very specialised "webapplications" that need 3D-acceleration.
Firefox on Linux thus pretty much has no support enabled for both of the previously mentioned.
Obviously Microsoft wouldn't want to add WebGL to their browser, because WebGL is based on OpenGL and it is a competing API from Direct3D.
WebGL considered harmful Posted Jun 19, 2011 15:18 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
For once I actually don't think Microsoft are being disingenuous at all.
3D hardware has not evolved to be a reliable, secure platform. It has been focused very much on raw performance for video games. If you solve a problem in a way that's obviously exploitable, but makes games run slightly better, you've got a market winner.
And a big part of this happens in the drivers. We expect a mouse driver, a sound driver, a network driver to protect the system from exploitation by malicious but unprivileged users. There isn't a WAV file you can play that gives you a root prompt, or a packet you can send that executes the included code in Ring 0. If such a thing were found, fixing it would be a high priority.
But to get that performance for video games, 3D drivers wrote their own rules. The highest threshold they're expected to meet is that they'll try not to lock up the machine and render it unusable. And you shouldn't have trouble finding LWN readers who've seen them not even meet that low standard.
WebGL considered harmful Posted Jun 19, 2011 17:05 UTC (Sun) by morganr (subscriber, #43385) [Link]
WebGL is a promising technology for cross-platform gaming and as such is anathema for Microsoft. In the same way that html5 is beginning to render their commanding position in desktop applications less meaningful (eg google docs versus office) WebGL could start to erode DirectX's share of developer attention, reducing the value of the Windows platform as a whole.
There is nothing inherent in GPU drivers that would preclude bounds-checking of input parameters to ensure correct operation, in the same way that the linux kernel is responsible for the security of its fairly massive attack-surface available to native applications.
Microsoft was able to prevent OpenGL from becoming the most-widely-used 3D standard on its platform, but I don't think they will have the same success against WebGL, having lost the battle in smartphones.
WebGL considered harmful Posted Jun 20, 2011 9:27 UTC (Mon) by Lennie (subscriber, #49641) [Link]
For the other readers you should have probably explained this:
"...having lost the battle in smartphones."
All current smartphones running iOS, Android and probably the others too have support for the mobile OpenGL-subset called OpenGL ES. Which is pretty much what WebGL needs*.
I think there is no other unified API on the smartphones I'm aware of. But I'm no expert on smartphones.
Atleast that is what I think you mean. :-)
* the creators of the spec knew what support smartphones had/what OpenGL ES is and choose to base WebGL around that.
WebGL considered harmful Posted Jun 20, 2011 14:01 UTC (Mon) by roc (subscriber, #30627) [Link]
If you believe that GL drivers are inherently and permanently exploitable, then you must also agree that installing a GL driver is equivalent to letting any user run as root. This has not normally been the assumption on Linux (although maybe it should be).
It would also mean that the application sandboxing performed by iOS and Android (which let apps use GL without no special permissions) is worthless.
WebGL considered harmful Posted Jun 20, 2011 19:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
That's not quite the same thing, there is a difference between intentionally downloading a potentially malicious application (trojans have already been pulled from the Andriod Market) and viewing a web page. The attack surface between web pages and the browser application is heavily defended. It's certainly not considered secure to download and run every bit of malware one runs across but viewing web pages is generally assumed to be "safe".
WebGL considered harmful Posted Jun 20, 2011 20:45 UTC (Mon) by roc (subscriber, #30627) [Link]
I'm not saying they're the same thing. I'm saying that if you've given up on GL security then you have additional problems.
WebGL considered harmful Posted Jun 20, 2011 21:34 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I guess I didn't really communicate very well. I think that the threat models for an application that you download and run under your authority as a user is different than the threat model of a browser javascript engine which needs to prevent code from running under your authority as a user even though the environment that it runs in is running as your user account. Maybe the kernel interface has been hardened against security threats but I don't have reason to believe the userspace components have been, there wouldn't have been a need to. If you are already running arbitrary code then there is no need to break libraries running at the same security level but that changes when the application is trying to maintain an internal sandbox between running arbitrary malicious code and the rest of the application.
WebGL considered harmful Posted Jun 21, 2011 3:40 UTC (Tue) by roc (subscriber, #30627) [Link]
That's a fair point.
WebGL considered harmful Posted Jun 21, 2011 23:45 UTC (Tue) by cmccabe (guest, #60281) [Link]
This mentality that "if the user downloaded an application, it should be able to do anything he can do" is why the traditional desktop will never be secure.
If there was no other reason for replacing desktop applications with web applications and Android apps, this would already be a good enough reason. Just give code the capabilities that it needs, and no more.
The WebGL security allegations have already been debunked.
It should be obvious to anyone that technical issues have nothing to do with Microsoft's decision about WebGL support. Microsoft provides exactly the same GPU access to untrusted code in Silverlight 5.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 14:17 UTC (Mon) by roc (subscriber, #30627) [Link]
Users don't want most of the "choices" the Linux desktop offers. Users don't care which media framework they use. They don't care which toolkit apps are using. They don't care which configuration framework is being used, or which audio backend, or which notification protocol. Most users don't even really care about KDE vs GNOME. They just want something that works well.
Most application developers not only don't care about choices, we actually hate them. Supporting multiple options in each category is much harder than supporting one. In each case want a single solution that works well and is supported everywhere.
Almost all the "choices" in the Linux desktop stack exist not for the benefit of users, but for a variety of other reasons, e.g. "developers couldn't get along, so they split", or "developers found it more fun to create a new solution than improve an existing one", or "no-one was able to make the hard decision to choose A over B".
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 16:31 UTC (Mon) by cmccabe (guest, #60281) [Link]
It is useless to discuss "users" in general. You have to ask yourself what demographic you are targeting. If you were in the marketing group of your company, rather than the engineering group, you would already know that.
For example, what about if we are just talking about the demographic of LWN readers. I suspect that most of the readers of this site do know and care about Gnome versus KDE, and are happy to have a choice. Or maybe, like myself, they use none of the above.
It all depends on what demographic your project or product is targeting. Casual users? Professional users? Artists? Scientists? Engineers? What kind of product are you making?
> Most application developers not only don't care about choices, we actually
Most application developers hate fixing bugs too, but for some reason, bugs get fixed.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 20, 2011 20:51 UTC (Mon) by roc (subscriber, #30627) [Link]
I'm talking about the "desktop mass market". You can't target a generic desktop operating system at a particular demographic like "scientists"; their needs are almost the same as everyone else.
Sure, application developers hate lots of things, but most of them aren't the fault of the Linux desktop stack, which is what we're talking about here. Just giving up and saying "well, I guess we're stuck with the Linux desktop being the worst platform to develop for" would be sad.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 19:12 UTC (Tue) by cmccabe (guest, #60281) [Link]
> I'm talking about the "desktop mass market". You can't target a
> generic desktop operating system at a particular demographic like > "scientists"; their needs are almost the same as everyone else.
Scientific Linux is targeted at the needs of particle physicists, and it seems to be doing pretty well.
> Just giving up and saying "well, I guess we're stuck with the
The Linux desktop isn't that hard to develop for. Just use a nice toolkit like QT or GTK and maybe something like libao.
Linux needs to emphasize the things that are different and better about it, rather than trying to be just another "generic desktop operating system." Apple learned this message under Steve Jobs and they have prospered. Linux has done the same but in somewhat different markets. Apple's advantage was quality control and strong branding; Linux's advantage is choice and cost.
Complaining that Linux is not Windows is missing the point completely.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 19:28 UTC (Tue) by andrel (subscriber, #5166) [Link]
Scientific Linux is really just a rebranded RHEL, and no more/less targeted at physicists than RHEL. Furthermore, the particle physicists I know all say that Ubuntu does a better job for them as a desktop operating system than SL.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 23:10 UTC (Tue) by cmccabe (guest, #60281) [Link]
Well, specifically, Scientific Linux is targeted at the needs of the CERN and FermiLab guys, because they create it. It seems like having something fairly close to RHEL is pretty important to them. But they don't necessarily care about putting lots and lots of packages in the repository as much as some other distributions. At least that is the impression I got from a casual reading of their home page.
Anyway, there are literally thousands of products out there that have a customized spin of Linux inside them. Linux would not be commercially important right now if everyone had to use the same distribution with the same libraries.
People who argue that choice is bad, and that there's too much open source software in the world, ignore the fact that Linux has been successful because of choice, not in spite of it. If you want Windows, where everyone has to use the same kernel, the same bootloader, and the same core libraries, whether or not it fits their needs, you know where to find it.
The Linux desktop may not be as popular as Mac OS or Windows, but it is important because it is the place where a lot of new open source software gets developed. It's also the operating system used by a lot of developers and a good laboratory for new concepts.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 21, 2011 12:08 UTC (Tue) by mbar (subscriber, #73813) [Link]
Sad but true.
Keeping the Desktop Dream Alive (LinuxInsider) Posted Jun 18, 2011 17:39 UTC (Sat) by idupree (subscriber, #71169) [Link]
Desktop Linux serves an important role for developers too.
Let's say 1% of desktops are Linux*.
I switched from Mac OS to Linux about six years ago because I wanted to be part of the Free Software ecosystem**. In the process, I have learned a lot about Linux and its many distros that make it easier for me to do Linux server administration now. I also personally enjoy Linux as a development environment and for its customizability.
I find it fine for desktop tasks too.
That last point is because there are so many people using Linux on the desktop. 1% may look small, but it's millions of users. The state of video editing on Linux, say, may be imperfect but I suspect that it would be much worse if only developers (or no-one at all) ran Linux on their desktop.
Developers play an important role in the software ecosystem. (I'm not sure how important, or what role it plays for developers to use Linux, but I sense it's important somehow.)
*I don't know the real number, and Wikipedia thinks it might be higher, but the number isn't crucial to my argument
**Obviously, being entirely part of the Free Software ecosystem, but there's more: At least back then, using Fink on 10.3 - and/or manual compilation - was not nearly as nice an experience as actually running a Linux distro. Linux had functioning package management for everything. Free software generally compiled and ran properly without workarounds on Linux -- both well-known and obscure software. XTerm could actually handle at top speed lots of messages (from, say, a compile or a grep). It was amazing!!! (Six years is a lot: the speed comparisons are totally out of date by now; I hear MacPorts is official but would have to use it for a while to sense whether it's as pain-free as Linux. But regarding Free Software, the Linux desktop is now *more* often functional with only Free drivers. Meanwhile Apple, everywhere *but* the desktop, has actually increased its power-over its users. And nobody fears Microsoft anymore - at least not like we did a decade ago. That changes the landscape significantly even while MS is still not very good at open-source and still has billions of dollars to throw at whatever it feels like.)
|
|||||||||||||