Good point. But most of these apps are written, because they can make money for the author. There just isn't a large enough user base in Desktop Linux to make that money, and hence much less people willing to invest the time to write apps. And the much smaller userbase is split up between Gnome and KDE and now Unity and Xfce and so on. So there is even less incentive to write apps.
Ingo Molnar on what ails the Linux desktop
21–30 of 200 posts
Re: Ingo Molnar on what ails the Linux desktop
#22Molnar's point about the political and procedural difficulties of adding new applications in the official repositories of most distributions is true (although this is changing -- witness Canonical's Ubuntu Software Center, PPAs, and "universe" repositories). But his reasoning breaks down when he says the relative dearth of commercial applications for the Linux Desktop is due to this issue. That's not true. The main r…
> The main reason why OSX/iOS, Android, and Windows attract more commercial developers is because those platforms have a much greater installed base!
A few years ago, Linux had a bigger installed base than both iOS and Android. Both of them outran linux with ease.
Re: Ingo Molnar on what ails the Linux desktop
#23Earlier quoted context omitted.
which distribution should they compile and distribute (sigh) for? Not to mention basic problems like "should I integrate with GNOME, Unity, KDE or nothing at all?"
There are only 2 popular package formats: deb and rpm. I don't have any experience with RPM, but to build a package for a reasonably big part of the Debian-based world, you have to set up a build system (pbuilder/cowbuilder) and tell it something like `for DIST in lenny squeeze wheezy sid lucid maverick natty oneiric pangolin do; git-buildpackage ...; done` The problem is, to get it right one has to find and read TON…
It'd be a lot more popular if it was as easy as the Android apk export wizard.
My 2c: Improve the tools and the developers will follow.
Re: Ingo Molnar on what ails the Linux desktop
#24I'm just an ordinary user, but I'd put my 2¢. Nowadays, any developer can create a packages for his application (and any of its dependencies) and publish it in self-hosted repositories. Users can easily add such repository to their system's sources list and bureaucracy problem's over. Well, some developers are doing this already - the only thing that keeps the rest of them is either ignorance or complexity of the pac…
What you think is easy is actually not easy. Any time you've added one, two, three more steps to a problem after clicking the link in the browser you've already lost. Adding repositories? Already too late. Touching the command line? Sorry, as much as we love it, for most users it's already too late. Going into Aptitude or Synaptic and pasting in the repository URL? Yep. Too late. This is all compounded by the fact th…
Maybe the experience is different on other systems, but on Fedora with KDE there already is no friction to installing random stuff. If I want to install, say, Google Chrome, which is not in the normal repositories, all I have to do is download the package and open it. A nice GUI program then takes care of the rest for me automatically; the main differences from installing a program on Windows is that it then updates automatically and I have to enter my password.
So really, there is less friction than on OS X--I don't have to drag anything anywhere! In fact, on Firefox, I just download the package and it figures out to open it with the right program automatically. And then it just works.
Of course, if a program is in the repositories it's even easier, but that's a different story...
Re: Ingo Molnar on what ails the Linux desktop
#25Maybe Android will conquer the desktop then?
All it needs is mouse and keyboard support in the interface and higher-resolution apps, which will come for tablets anyway.
Re: Ingo Molnar on what ails the Linux desktop
#26Molnar's point about the political and procedural difficulties of adding new applications in the official repositories of most distributions is true (although this is changing -- witness Canonical's Ubuntu Software Center, PPAs, and "universe" repositories). But his reasoning breaks down when he says the relative dearth of commercial applications for the Linux Desktop is due to this issue. That's not true. The main r…
Another reason is commitment to binary compatibility of a set of components over a time scale of 10 years or more. Linux has historically been relatively unstable, with an ideological focus on source rather than binary compatibility; and fragmented into different distros, which may have different ideas about which versions, configurations etc. of components are pieced together. That's a perfectly understandable focus…
You can statically link binaries and distribute those, which companies do when there's enough of a market to bother. That's how Matlab is distributed, for example. I think the bigger problem is that there usually isn't enough of a market; AutoCAD was discontinued on Unix because too many shops were retiring their Unix workstations in favor of Windows desktops, not because Unix software distribution was too hard.
Re: Ingo Molnar on what ails the Linux desktop
#27I'm just an ordinary user, but I'd put my 2¢. Nowadays, any developer can create a packages for his application (and any of its dependencies) and publish it in self-hosted repositories. Users can easily add such repository to their system's sources list and bureaucracy problem's over. Well, some developers are doing this already - the only thing that keeps the rest of them is either ignorance or complexity of the pac…
What you think is easy is actually not easy. Any time you've added one, two, three more steps to a problem after clicking the link in the browser you've already lost. Adding repositories? Already too late. Touching the command line? Sorry, as much as we love it, for most users it's already too late. Going into Aptitude or Synaptic and pasting in the repository URL? Yep. Too late. This is all compounded by the fact th…
This is all compounded by the fact that there is no app bundle.
A "collection" type for installing multiple packages transparently would be nice, but I have to point out that nothing prevents you from doing the exact same thing that you do on Mac OS X, which is to distribute the .so libraries in the same package as the application, or even compile it statically.
Re: Ingo Molnar on what ails the Linux desktop
#28Earlier quoted context omitted.
>they are mostly consumables which perish in few days or months (I exclude some utitities). This is simply false, there are plenty of complex apps with varying degrees of usefulness but they certanly don't reduce to 80's game clones and few screen apps. And even if it was true it's not a result of anything intrinsic to the app model. Also "tight control a la Apple" indicates that you missed his point. How many times…
I agree that having to make and sudo install is essentially impossible for a common PC user, but how does the sandboxing have any impact in user adoption?
State is the big evil in software. Minimize shared state, and many, many problems go away.
Centralized package management with a web of specific versioned dependencies is a huge hairball of state as it is. And when installed applications poke around inside your system, it only takes one or two oversights here and there to mess up this state.
Sandboxing, where feasible, minimizes shared state; usually at the cost of other things, but with modern software and modern resource constraints, our ability to deal with complexity is usually the tightest constraint. Sandboxing reduces the probability that things will break horribly (e.g. installing one app, and finding you need to install a new version of a library, which in turn means you need to reinstall 100+ more apps, which may bring in a new desktop or some other abomination).
Re: Ingo Molnar on what ails the Linux desktop
#29The solution for this is quite simple: split the distro to a core, and a separate 'apps' repository, and let app authors control (but with a mandatory QA step) when their software gets released or updated. We did this with Maemo (and later MeeGo), and it has worked great:
http://bergie.iki.fi/blog/application_quality_assurance_in_l...
Cross-distro app repositories are also a possibility, thanks to the Open Build Service (http://openbuildservice.org). And since MeeGo's community apps service is open source (https://github.com/nemein/com_meego_packages), all software needed for this (including an app store client app) already exists.
What is needed is a major distribution to make the first move on this.
Re: Ingo Molnar on what ails the Linux desktop
#30Molnar's point about the political and procedural difficulties of adding new applications in the official repositories of most distributions is true (although this is changing -- witness Canonical's Ubuntu Software Center, PPAs, and "universe" repositories). But his reasoning breaks down when he says the relative dearth of commercial applications for the Linux Desktop is due to this issue. That's not true. The main r…
> The main reason why OSX/iOS, Android, and Windows attract more commercial developers is because those platforms have a much greater installed base! A few years ago, Linux had a bigger installed base than both iOS and Android. Both of them outran linux with ease.
Yeah, but they're in a brand new market on brand new devices. People who already have a proprietary PC OS aren't going to switch to Linux out of the blue, but they are going to buy a shiny smart phone.
So the two situations are really not comparable. I still think the main difference is that you have to install Linux yourself. It's not even that installing is difficult--it isn't!--it's that normal people don't even realize it's an option. Your average random laptop buyer who just spent $600 on a laptop from Staples would be able to use Linux perfectly well if that's what his laptop came with--I suspect some wouldn't even realize it wasn't just a different version of Windows. But since his laptop invariably came with Windows, that's what he's going to use, not for any reason but inertia.