Live data from Hacker News

Ingo Molnar on what ails the Linux desktop

plus.google.com

51–60 of 200 posts

Re: Ingo Molnar on what ails the Linux desktop

#51
post #30

Earlier quoted context omitted.

> 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…

> but they're in a brand new market on brand new devices.

But they still had no problem starting with an ecosystem with zero apps. Now they have hundreds of thousands.

> I still think the main difference is that you have to install Linux yourself.

Over the years, I've had several people, whom I talked into checking out Linux, give it up and go back to Windows because they refused to accept that they have to upgrade the whole distribution just to be able to install new versions of single apps. Did you ever try to explain a Windows user what a "backport" is, and whats it good for, and why there are none on Windows and why he can he can install whatever app and whatever version of an app he wants on Windows, but cant on Linux?

> 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

For 6 months, then he wouldnt be able any more to update his apps.

Re: Ingo Molnar on what ails the Linux desktop

#52
post #25

Maybe 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.

Android has pretty good mouse and keyboard support already. Try one of the Asus Transformers in laptop mode, for instance. Keyboard shortcuts, mouse cursor, two-finger scrolling, all works as you would expect on a desktop.

High-resolution apps are still somewhat lacking because the larger tablets haven't sold that well, but I hope this will improve.

Re: Ingo Molnar on what ails the Linux desktop

#53

It really frustrates me that authors are not responsible for compiling and distributing their software, only then will we have software upgraded regularly and quickly.

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?"

Why not all of them? OBS makes this easy. Big projects can run their own OBS, and for us others there is the public instance provided by OpenSuse. Builds many versions of all major distros.

Re: Ingo Molnar on what ails the Linux desktop

#54

The reason I stopped recommending Linux to "normal users" is _because_ of the concept of distributions. Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. Having to upgrade the whole distro (including all the other installed apps you dont want to upgrade) just to install a new version of one single app you _want_ to update is a nightmare. Total bullsh…

it's just Ubuntu, not all Linux. unless there are other distros with Unity and 6-month cycles I don't know of.

Re: Ingo Molnar on what ails the Linux desktop

#55
There are "core" linux distros, like Slackware. There are many attempts at autonomous apps distribution like zero-install and openpkg that mostly work, and probably would work fine with a reasonable effort backing them.

[1]: http://0install.net/ [2]: http://www.openpkg.org/

Of course the problem is that the big distros (redhat, debian) can't be bothered to care.

Re: Ingo Molnar on what ails the Linux desktop

#56
post #50

The reason I stopped recommending Linux to "normal users" is _because_ of the concept of distributions. Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. Having to upgrade the whole distro (including all the other installed apps you dont want to upgrade) just to install a new version of one single app you _want_ to update is a nightmare. Total bullsh…

On the other hand, being able to install software so easily with package management is a huge benefit of distributions. Perhaps the solution is to create a new package management system for a desktop distribution. A system which ensures that when upgrading an application only its personal namespace (libraries etc) changes, while other applications remain untouched. Libraries are second-class citizens, almost. That wa…

Couple other ideas:

Optionally bundling specific versions of libs (or compiling in statically), and placing in user's home directory, setting path to look there first (maybe that's what you're saying exactly?)

Stop using the same tool for updating userland apps and system core specific stuff. Same app for updating "/bin/ls" and for "audacity" is, imo, at the core of the brokenness. These are different types of apps with different areas of responsibility, but we lump them all together in one tool and process.

Re: Ingo Molnar on what ails the Linux desktop

#57

The reason I stopped recommending Linux to "normal users" is _because_ of the concept of distributions. Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. Having to upgrade the whole distro (including all the other installed apps you dont want to upgrade) just to install a new version of one single app you _want_ to update is a nightmare. Total bullsh…

Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong.

You don't have to do all that to upgrade a single app. In fact you're thinking of it backwards. Distros mean that when you upgrade the OS or libs, you get new versions of the apps for free.

You can still configure && make && make install, or grab a statically-linked binary, or any other method of getting Linux apps to run.

Re: Ingo Molnar on what ails the Linux desktop

#58
post #57

The reason I stopped recommending Linux to "normal users" is _because_ of the concept of distributions. Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. Having to upgrade the whole distro (including all the other installed apps you dont want to upgrade) just to install a new version of one single app you _want_ to update is a nightmare. Total bullsh…

Coupling the updates of single apps with the updates of the whole desktop or framework and libs, is just plain wrong. You don't have to do all that to upgrade a single app. In fact you're thinking of it backwards. Distros mean that when you upgrade the OS or libs, you get new versions of the apps for free. You can still configure && make && make install, or grab a statically-linked binary, or any other method of gett…

> You can still configure && make && make install

You aren't serious, are you?

> statically-linked binary

Nobody builds them.

> any other method of getting Linux apps to run.

There are no other methods.

> Distros mean that when you upgrade the OS or libs, you get new versions of the apps for free.

That in turn means that if I dont want to upgrade the OS and the libs, I cant get new app versions. The collective refusal to acknowledge that this is a problem is what is holding back (aka killing) desktop Linux.

Re: Ingo Molnar on what ails the Linux desktop

#59
post #45

Earlier quoted context omitted.

But what is the alternative to a non-distributions based gnu linux operating system? How do you manage the 1000 packages and their libraries and dependencies? Many of them have separate runtimes which may or may not depend on the other packages runtime. How would you design an application sandbox to cover them all? What you're saying basically is that linux is failed. At least for me, since I cant see another way to…

Is there a linux equivalent of PC-BSD[1]?: _Programs under PC-BSD are completely self-contained and self-installing, in a graphical format. A PBI file also ships with all the files and libraries necessary for the installed program to function, eliminating much of the hardship of dealing with broken dependencies and system incompatibilities. _ [1]: http://www.pcbsd.org/index.php?option=com_zoo&view=item&...

but but but....

"you'd have duplication of files!" or "you'd have to update multiple libraries when there's a security patch!"

I didn't know about pcbsd, but I've espoused similar ideas to my linux friends years ago, and was generally met with the one of the two objections listed above. I think they're both bad arguments, but it's what I encountered the most.

Re: Ingo Molnar on what ails the Linux desktop

#60
post #46

Earlier quoted context omitted.

That has nothing to do with sandboxing: it's a matter of distributing the libraries with the package itself, either as .so files or as a big statically compiled binary, and using those instead. Nothing forces the developer to use the distro provided libraries. And frankly, I think this is one of the things where you can't please everyone; personally, I rather have dependencies and know that a security fix in a librar…

That's true to the degree that the implementation of those libraries does not require other things from the rest of the system. If they are just libraries of code, attached to nothing, sure. But when they need integration with things beyond that? That's when it breaks down. That's when you need interfacing libraries that adapt one version of a library's interface to the next version, and very careful API and ABI desi…

Actually, your post is making me optimistic.

On Linux, the 4 most common API layers encountered by an application are:

1) system calls 2) standard (and not-so-standard) libraries 3) X11 4) d-bus

#1 is notoriously stable. Linus often posts quite a vehement response to anybody who proposes breaking #1.

#3 was for a long time, TOO stable, it wasn't taking advantage of new developments in hardware and design. The breakup of XFree86 freed that up.

#4 is relatively stable because it's a cross-distribution partnership. They're designed to be the same across multiple distributions which by necessity makes them stable.

The problem are for Linux is #2. Most standard libraries are actually very stable on the micro level. The problem is the vast area they expose: if a single backwards-incompatible change can break your app, it's a problem if there are a million things that can potentially change.

Windows & OS X applications "solve" this problem by shipping their libraries with their applications.

I think Linux has a potentially even better solution: simply allow multiple versions of applications and libraries to be installed simultaneously, a la rubygems & bundler. You'll get all the disk space savings of shared libraries at the point of initial install, which will slowly erode as users install new apps, upgrade some apps but not others. But who cares? Disk space is cheap, but more importantly, if the user cares he can do something about it, only upgrading applications when the whole application upgrades.

Post reply on HN