Live data from Hacker News

Ingo Molnar on what ails the Linux desktop

plus.google.com

81–90 of 200 posts

Re: Ingo Molnar on what ails the Linux desktop

#81
post #68

Earlier quoted context omitted.

You said you stopped pointing people toward Linux because of the distros. But distros only add ways to get software. You don't have to use their package management at all. If you want to install a new version of an app, with or without the help of the distro, what better way is there to avoid dependency hell? Edit: Central-repository installation methods I've used: python easy_install, perl CPAN, Ubuntu PPAs (which a…

> But distros only add ways to get software. Without distros, the way to get software is unbearable for Windows converts, where it is just "click, click, done." > what better way is there to avoid dependency hell? All distros agreeing to ship one specific version of a lib, so that app devs can target that "standard" version instead of daily changing upstream versions. The dependency chaos is a consequence of no distr…

All distros agreeing to ship one specific version of a lib, so that app devs can target that "standard" version instead of daily changing upstream versions.

You talk as if lib versions only change to harass developers and end users. Sometimes there are security updates that need to be made. And how would lib devs add features if all the app developers and distros are frozen on an old version?

Re: Ingo Molnar on what ails the Linux desktop

#82

Earlier quoted context omitted.

The problem isn't that you have to update multiple libraries - it's that you have to rely on each application developer to release an update when there's a patch for one of its libraries. That simply won't happen in many cases.

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library. Given that all this discussion largely revolves around open source projects anyway, if a developer didn't update for a new security patch in a library, someone would likely ste…

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library.

But it'd still be up to the developer to update the library, no? Otherwise, how is that better than the current situation?

If it's a niche/minor app, and there's, say, a new version of libssl, if the author isn't making updates, there's no guarantee the app will work with an updated version of an upgraded shared library anyway.

But you don't have to upgrade the version of the library to release security updates: the Security team of Debian backports all security fixes to the library versions in Stable even if the upstream didn't, in order to prevent such breakage.

Re: Ingo Molnar on what ails the Linux desktop

#83

So, how does the fact that any person or company can host their own packages or even full repositories that can be added with a single click ¹ and are not dependent on hierarchical organizations fit in that? GNU/Linux distros, at least APT based ones, are perfectly distributed if the person wants to. ¹ If you have apt-url installed, which Ubuntu has by default

I agree that distributed repositories are the way forward.

The only thing holding that back is the atrocious user-interface. Debian urgently needs to fix that and push their apt-infrastructure out of the 1990s.

In short: /etc/apt/sources.list must die.

This is how it must work:

   apt-get install https://foobar.com/debian/squeeze/widget-1.0
A package installed like that must add itself automatically to a proverbial sources.list for future updates. Don't bother me with the housekeeping.

Then add central indexing ('apt-get install widget' is nicer), a web-of-trust ("1234 users have installed packages by this author"), package-signing looks about alright already (except: no, don't make me run gpg).

This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes.

And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work.

tldr; apt needs to absorb homebrew.

Re: Ingo Molnar on what ails the Linux desktop

#84

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…

[deleted]

Re: Ingo Molnar on what ails the Linux desktop

#85
post #79

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…

I agree with your complaints but I don't see how it is related to the concept of distributions. Having multiple distributions is fine; someone just needs to make one with a package manager that gets this stuff right. Then your parents can just use that one distribution and never need to care about what other distros do. In fact, Ubuntu wants to be that one distribution that is easy for normals. But as you illustrated…

> I don't see how it is related to the concept of distributions.

Distributions freeze the set of available app versions to a specific version of the base system. You cant get a new app without upgrading everything else too, including all other apps. I cant simply get a new Emacs on my Ubuntu, because to do that, Ubuntu also wants to remove my Gnome2 and replace it with Unity.

Windows decouples the base from the apps. When you want to update an app, you just do it, everything else remains untouched. If I want to get a new Emacs on XP, it wont force me to simultaneously upgrade to 7.

Windows would have the same problems if they bundled a new set of base libs and 20000 apps that only work with that specific set of libs every few months but they dont. They invest a great effort into making the base system slow and stable and support it for a decade or more, and it shows.

Re: Ingo Molnar on what ails the Linux desktop

#86
post #79

Earlier quoted context omitted.

I agree with your complaints but I don't see how it is related to the concept of distributions. Having multiple distributions is fine; someone just needs to make one with a package manager that gets this stuff right. Then your parents can just use that one distribution and never need to care about what other distros do. In fact, Ubuntu wants to be that one distribution that is easy for normals. But as you illustrated…

> I don't see how it is related to the concept of distributions. Distributions freeze the set of available app versions to a specific version of the base system. You cant get a new app without upgrading everything else too, including all other apps. I cant simply get a new Emacs on my Ubuntu, because to do that, Ubuntu also wants to remove my Gnome2 and replace it with Unity. Windows decouples the base from the apps.…

As I said. That's a problem with the package management in most distributions. It has nothing to do with the fact that we have multiple distributions.

I.e. source-based distributions (e.g. gentoo) don't have this particular problem.

Re: Ingo Molnar on what ails the Linux desktop

#87
post #78

Earlier quoted context omitted.

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

> 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. This is the idea of the linux standard base. The concept was developed over a decade ago and it has failed to show real fruit. > You d…

I was always surprised that no one made something like "The Linux Binary Platform 2003" and then kept it up to date, maybe releasing another one later.

At the very least, developers used to Windows would understand the dynamics of it (which is probably a good idea if attracting commercial development is a goal).

I would say it is quite a bit less ambitious than something like the linux standard base.

Re: Ingo Molnar on what ails the Linux desktop

#88

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…

Eh. First of all, you're not limited to the packages your distribution supplies. Lots and lots of software is distributed in Launchpad PPAs. Other stuff can be installed without the package manager, some games are statically compiled, etc.

And I don't see what's wrong with requiring users to have an up-to-date system. Security fixes alone make regular updates almost mandatory on all operating systems. Windows installs run for a decade, but they still get constant security upgrades, including ones that require restarts and big scary service packs.

System upgrades simply should be totally painless. The kernel gets updated constantly without users noticing, it should be the same for all upgrades. Maybe a rolling release would be a better solution, because it gets rid of the scary system upgrade user interaction, but they're more difficult to QA.

Maybe the repository administration model needs to be changed. Giving the devs more control/responsibility for their package in the repository might be a good idea. Many developers already set up PPAs to get there.

Re: Ingo Molnar on what ails the Linux desktop

#89
Yes, I see the point being made in the original article. I tend to use LTS Ubuntu and conservative distributions (currently PUIAS) and so see a slower rate of change.

Another Hacker News thread is discussing the new release of Audacity.

http://news.ycombinator.com/item?id=3714766

and it occured to me that I would like to try to compile a statically linked build of Audacity that could work on any version of GNU/Linux from Ubuntu 12.04 down to (say) CentOS 5.7. Just a big binary blob that I could copy and run.

How would I find out how to do this? I've compiled little things before (dwm window manager, qalculate)

Re: Ingo Molnar on what ails the Linux desktop

#90

Earlier quoted context omitted.

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library. Given that all this discussion largely revolves around open source projects anyway, if a developer didn't update for a new security patch in a library, someone would likely ste…

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library. But it'd still be up to the developer to update the library, no? Otherwise, how is that better than the current situation? If it's a niche/minor app, and there's, say, a new ve…

The library developer updates the library, and if the app doesn't need changes to work with the new library version, he doesn't have to do anything. You could even automate finding all copies of the library and updating them...and keep prior versions around if something breaks.

To avoid relying on app developers at all, put apps in sandboxes where it appears that the libraries are where they've always been.

Post reply on HN