Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ingo Molnar on what ails the Linux desktop

plus.google.com

Post reply on HN
Print view View original

41–50 of 200 posts

Re: Ingo Molnar on what ails the Linux desktop

#41

Post by tikhonj »

kklimonda wrote: post #6
alexchamberlain wrote: post #4

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

I don't think the Gnome/Unity/KDE split is nearly as significant as people find it. You don't have to support them all! I use KDE, and programs written for Gnome fit right in. As far as I know, there is no reason at all to depend on some particular environment exclusively; even things like notifications work uniformly across different systems.

Re: Ingo Molnar on what ails the Linux desktop

#42

Post by muuh-gnu »

DrCatbox wrote: post #31
muuh-gnu wrote: post #17

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…

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…

> But what is the alternative to a non-distributions based gnu linux operating system?

A small core set of libraries that change _very_ slowly and arent intentionally obsoleted every few months. Think of Windows like slow, stable and supported for a decade. Distribution of apps decoupled from the distribution of the base. Never make an app update trigger a lib update.

> How do you manage the 1000 packages and their libraries and dependencies?

You dont do that at all. Developers to that themselves like they do on Windows and OSX. Every dev packages his own app and puts it either into the App store or distributes it himself. You manage only the libs and dont allow them to change fast or in an uncoordinated, chaotic way.

> What you're saying basically is that linux is failed.

From the point of a normal user, yes. For a normal user, it is not an option. Everybody I personally know who tried it, went back. The main reason for most of them was the insanity of application management. (And lack of hardware drivers and games, but thats not Linux' fault.)

> since I cant see another way to distribute and manage the massive amount of packages that sit on gnu.org.

Decouple libs and apps. Dont change APIs and lib versions every few months. Make the base a very reliable and slow moving target. Dont force anybody to change everything every few damn months.

> It is my opinion that the one who solves these problem is in for a lot of business-opportunities.

The problem is already solved, at least under Windows and OSX. Thats why Windows and OSX get all the desktop business and Linux gets none.

Re: Ingo Molnar on what ails the Linux desktop

#43

Post by tikhonj »

drdaeman wrote: post #7
alexchamberlain wrote: post #4

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.

I believe proper packaging is quite complex process, so it scares a lot of the developers away.

Isn't creating one of those Windows installers also complicated? To me, it seems even more complicated than packaging software for Linux, yet it has never stopped anyone.

Re: Ingo Molnar on what ails the Linux desktop

#44

Post by _delirium »

barrkel wrote: post #35
_delirium wrote: post #26

Earlier quoted context omitted.

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.

Sure you can statically link binaries, so long as you have a license for all those libraries, or if you write your own UI etc. from the ground up not much removed from the X protocol. And when UI refreshes come around, your UI will look frozen in time in a way that UIs using standard controls don't in Windows. And how about those libraries that control shared resources? For example, sound output. It's been many years…

The semi-standard commercial solution for widget toolkits, excluding old software tied to something legacy, is typically to use Qt, which has both LGPL and (reasonably priced) commercial license options. Audio isn't really a problem for statically linked apps not doing anything particularly strange; it works fine in anything I've tried. Even ancient audio APIs in ancient binaries are transparently emulated through something-or-other in a way that "just works".

If you haven't used Linux in "many years", that might be the source of your impressions. I remember mucking with that kind of stuff on Slackware in 1998, but I haven't touched OSS or ALSA or whatever in a decade; it just does its thing under the hood. Audio even works fine when I run Windows applications under Wine!

Re: Ingo Molnar on what ails the Linux desktop

#45

Post by zmmz »

DrCatbox wrote: post #31
muuh-gnu wrote: post #17

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…

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

Re: Ingo Molnar on what ails the Linux desktop

#46

Post by barrkel »

icebraining wrote: post #33
barrkel wrote: post #28

Earlier quoted context omitted.

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

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 design. I see that there's very little reason to take that approach for open source everywhere, but that kind of environment is essential for the stability commercial development needs.

Static libraries aren't the answer. A careful API and ABI interface to the core system, with managed compatibility from release to release, is needed. This is hard work; incredible amounts of effort went into making Windows 95 work as smoothly as it does, and some of the best war stories from Raymond Chen's blog date from this effort.

Things like preserving bugs in the moral equivalent of malloc to accommodate software that used memory after freeing it. This very concept - bug compatibility - is something that I see OSS community in general as being fairly hostile to, thinking that the software with the bug should be fixed, rather than making things work for the user. Of course the buggy software should be fixed; but making things work for the user is more important still.

Re: Ingo Molnar on what ails the Linux desktop

#47

Post by bergie »

DrCatbox wrote: post #34
bergie wrote: post #29

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

You would still need to maintain and manage the core distro. The packages in their would update and break the systme, you'd have lvm issues and what not. Any way, care to give links to more on maeom/meegos architecture?

You still package and build an application separately for each distro version. And then the community tests it before it goes to the stable apps repo. So broken packages (either by packaging, or by app not functioning properly) are unlikely to pass QA.

So if your package conflicts with something, either fix that issue or don't release for that distro versio.

Re: Ingo Molnar on what ails the Linux desktop

#48

Post by barrkel »

_delirium wrote: post #44
barrkel wrote: post #35

Earlier quoted context omitted.

Sure you can statically link binaries, so long as you have a license for all those libraries, or if you write your own UI etc. from the ground up not much removed from the X protocol. And when UI refreshes come around, your UI will look frozen in time in a way that UIs using standard controls don't in Windows. And how about those libraries that control shared resources? For example, sound output. It's been many years…

The semi-standard commercial solution for widget toolkits, excluding old software tied to something legacy, is typically to use Qt, which has both LGPL and (reasonably priced) commercial license options. Audio isn't really a problem for statically linked apps not doing anything particularly strange; it works fine in anything I've tried. Even ancient audio APIs in ancient binaries are transparently emulated through so…

I use Linux every day; I haven't used desktop Linux much since a fairly unpleasant experience with the original Eee PC (701, in 2007).

But package management (I live with Debian apt-get and friends) is a bane of my life. Generally, the binaries that come when I install a package are too old, or don't have the right compile-time options configured, or there is some dependency missing that I don't have installed and is for some reason missing in the repository due to bitrot. It's usually more reliable to download the source, configure, build and install it the old-fashioned way. That also means fixing build errors, tracking down missing libraries, and generally a whole load of work I wouldn't trust an otherwise fairly competent software engineer to do, never mind the average user.

Re: Ingo Molnar on what ails the Linux desktop

#49

Post by nknight »

tikhonj wrote: post #43
drdaeman wrote: post #7

Earlier quoted context omitted.

I believe proper packaging is quite complex process, so it scares a lot of the developers away.

Isn't creating one of those Windows installers also complicated? To me, it seems even more complicated than packaging software for Linux, yet it has never stopped anyone.

> Isn't creating one of those Windows installers also complicated?

Not for years now, no. The process for creating an .msi for a basic stand-alone app in Visual Studio is pretty simple and well-documented.

Re: Ingo Molnar on what ails the Linux desktop

#50

Post by lubutu »

muuh-gnu wrote: post #17

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 way we get the benefits of packages and libraries, but each application is logically isolated from changes to any others.

I very much agree with the idea of a slow-moving core, though. That's how I've tended to use Debian: a stable foundation upon which I can install less stable higher-level software (the things I actually interact with). Of course, this doesn't address the distro fragmentation problem Ingo is talking about.

Post reply on HN