Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Just to make it clear: the current way of installing software in GNU/Linux distro is not going to make a good app store possible. Having a nice interface to deal with a million dependencies behind the scenes is like putting lipstick on a pig. The limitations imposed by the current "spread the app across the filesystem" are too far-fetching. In the GNU/Linux eco-system, having a distro-dependent app store means further fragmentation and less adoption. Having only system-wide installation implies that every user needs to be an administrator to install apps."
Posted Jan 4, 2011 1:08 UTC (Tue)
by codewiz (subscriber, #63050)
[Link] (23 responses)
The initial assumption that applications need to be self-contained in order for an appstore to work is unjustified. Local, unprivileged installation may seem like a nice to have feature, but the vast majority of computers these days are laptops and single-user desktops, so in practice it doesn't make that much of a difference. The article also fails to consider the need to co-evolve the OS with its application, that can't be done robustly without a decent dependency system. The distinction between an application and a system component is also very fuzzy. A lot of Windows and MacOS X applications hook into the file manager, the browser or the multimedia system. The problem we're facing now is mostly a UI issue: we need a good search interface for applications which would return results relevant to end-users, with meaningful descriptions, screenshots and a maybe a rating assigned by other users. All this could be built on top of a sane package system.
Posted Jan 4, 2011 6:51 UTC (Tue)
by elanthis (guest, #6227)
[Link] (3 responses)
The distribution-specific package repositories and proprietary frontends are a problem, not a solution. Adding more crap to a broken system is never going to result in a better design.
Posted Jan 4, 2011 8:37 UTC (Tue)
by tcourbon (guest, #60669)
[Link] (2 responses)
I understand what the OP propose as "a search interface for installable application and meaningful informations (and only meaningful informations) at the time of the installation process".
Google or any web/internet based search engines doesn't know (and I don't want to tell them) anything about my desktop setup. So I doubt it can lead me to only a set of relevant programs.
Also when you search the web for programs, you often find programs' official web site and some blog/forum/mailing list messages about troubleshooting, tips and tricks the program. And a lot of irrelevant informations. We all know that FOSS programs' web sites greatly vary in quality and that it's not unusual that information is cluttered across several pages.
A specialized and well designed programs installer, cross-distribution or not, would be a win as far I'm concerned. (And I don't consider a packages manager as a programs installer since it bother me with programs separated in several packages and their dependencies. It's only if I want to mess with libraries and dependencies that I would use a packages manager.)
And if you think the system is "broken" please feel free to fix it. But I'm afraid you will soon understand it's not that easy to satisfy with a unique solution the needs of users who choose different distributions that fit their own need.
(I beg the LWN readers for indulgence about my poor English writing skills.)
Posted Jan 4, 2011 9:16 UTC (Tue)
by gidoca (subscriber, #62438)
[Link]
Posted Jan 4, 2011 20:42 UTC (Tue)
by elanthis (guest, #6227)
[Link]
I think you misunderstood, and in fact that is the complete opposite of how I feel (I despise the focus on the Web and Web applications that the FOSS community seems to think is the future of desktop computing). I totally want real apps. I just don't want a half-assed search app to find other apps that I already found because my friend just linked me the app's URL in instant messenger or email or because I just stumbled across a link on an LWN article or because I searched it in Google while researching available applications for a particular need. If I already found the app, I should be done.
People find apps on the Web. When they've already found the app, the last thing you want to do is make them find it a second time in another app. It's annoying on the iPhone as on anything else.
Any application marketplace type of thing should be a web page. Either let users download an installer (and not the raw binary things like .exe or .bin files, but a .msi for Windows or a new distribution-neutral .install for Linux) or integrate the Web page with a package installer via a browser plugin (like various distributions have done in the past).
You can also accomplish this by adding a new type of URL that Web sites can link to that opens your app finder, but this only works if all the distributions get their heads out of their asses and start agreeing on at least a common package naming scheme if not a common package format and repository structure.
"Google or any web/internet based search engines doesn't know (and I don't want to tell them) anything about my desktop setup. So I doubt it can lead me to only a set of relevant programs."
There isn't that much variation in desktops, and there shouldn't be that much variation in applications. Either you just found a geneaology program or you didn't. If you're trying to find a geneaology program optimized for KDE on NVIDIA's drivers on a netbook with an SSD, you're doing it wrong.
If you're paranoid about telling a search engine that you want a GNOME application specifically, that's your mental issue and not anybody else's. Intentionally retarding the user experience to pacify a few nutjobs with phobias is the sure fire way to guarantee that Ubuntu Bug #1 never gets resolved as Linux continues to languish as a niche OS unfit for the masses of regular people. People who think with that kind of fear can rot away with the idiots who completely disable all browser cookies and hence can't access any modern website (but hey, nobody can track them with cookies now! they're safe from the Martians!).
"Also when you search the web for programs, you often find programs' official web site and some blog/forum/mailing list messages about troubleshooting, tips and tricks the program. And a lot of irrelevant informations."
So it's okay to force distributions to come up with this info over and over and over for the 30,000+ packages that they all have rather than just having upstream fix this once in a single place? Heck, let's decentralize it even further, and just make the users fill in the package info themselves before they do the search. Takes all the effort out of the developers' hands entirely, which is clearly what some people want.
Distributions today can't even consistently get their .desktop entries to be of high quality when upstream doesn't do it for them. Getting their package descriptions and info into a high quality searchable state is just asking for way too much out of people who aren't the most qualified to be writing that information in the first place.
Upstream needs to step up and do their job. If they don't, then instead of trying to do it for them, let the project sink into irrelevancy as users fail to find it or just fail to figure out how to install/use it. Bending over backwards to help every little bumhick FOSS projects whose developer is too lazy/stupid to write a DOAP file or a package template isn't doing the community any real favors. It's just filling up distributions' package repositories with a ton of low quality shitty apps that then make it that much harder for users to find the good quality apps. If there are 20 IM clients (not uncommon), then instead of packaging all 20 when obviously only 3 of them have any real effort or love from upstream, just use those upstream packages (which would exist if they were necessary and didn't require upstream to repackage their app 50 times to cover all the versions of all the popular distributions) and let the other 17 apps rot like they deserve.
Posted Jan 4, 2011 9:27 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (3 responses)
* search
Lacks:
Though I would like to avoid a packaging system that requires being on-line to work.
The package system is sane. One particular thing I like about it is marking a package as "automatically installed". Which means that if the user chose to install foo-fighters, and that pooled the dependencies bar, baz, and libwhatever, then removing foo-fighters would remove all the others (unless another package happens to depend on them).
This means that your search result only needs to show 'foo-fighters'. But this only works in a proper repository where foo-fighters can rely on bar not to change in an unexpected way.
Posted Jan 4, 2011 13:02 UTC (Tue)
by rvfh (guest, #31018)
[Link]
But you do need to download things at one point most of the time, so I don't see this as a problem.
> The package system is sane. One particular thing I like about it is marking a package as "automatically installed". Which means that if the user chose to install foo-fighters, and that pooled the dependencies bar, baz, and libwhatever, then removing foo-fighters would remove all the others (unless another package happens to depend on them).
This is already done (though the removal is not automatic) in Ubuntu (and I guess all Debian-derived distributions).
> This means that your search result only needs to show 'foo-fighters'. But this only works in a proper repository where foo-fighters can rely on bar not to change in an unexpected way.
So I guess we are not that far off! But I do agree that most Windows users are used to turning to Google and downloading from the first dodgy site they come across, so we would need to intercept the user action somehow and offer to install the official version of a given software if one exists (think Chrome / Chromium).
Posted Jan 5, 2011 0:05 UTC (Wed)
by codewiz (subscriber, #63050)
[Link] (1 responses)
The Fedora PakcageDB web interface is also moving in the direction of an end-user oriented appstore: Lacks:
Posted Jan 5, 2011 0:19 UTC (Wed)
by codewiz (subscriber, #63050)
[Link]
Oh, and the GNOME PackageKit GUI is also getting better:
Posted Jan 4, 2011 9:52 UTC (Tue)
by epa (subscriber, #39769)
[Link] (13 responses)
For better or worse, an increasing share of systems are mobile phones where the user doesn't have root access. An app store offering unprivileged applications might be acceptable to carriers (or corporate IT departments) where installing packages as root would not be acceptable.
Posted Jan 4, 2011 14:03 UTC (Tue)
by gmaxwell (guest, #30048)
[Link]
How true but you could simply make every file on the system owned by the "user account", and all daemons run under the same account, and you would have achieved your maxim while simultaneously _reducing_ the security and reliablity of the system.
Elimination of root access is adventitious when it increases separation. It's less than clear to me which side of this line installing software as the user falls on.
Posted Jan 4, 2011 20:46 UTC (Tue)
by jthill (subscriber, #56558)
[Link] (11 responses)
Don't the graphical sudos read sudoers?
Easy enough to install .debs for at least some and I'd guess most apps locally, an ar x, a tar xf to .private or whatever, and a path entry. The ones that hardcode /usr for their own resources are wrong anyway.
Posted Jan 5, 2011 10:46 UTC (Wed)
by epa (subscriber, #39769)
[Link] (10 responses)
Posted Jan 5, 2011 15:34 UTC (Wed)
by etienne (guest, #25256)
[Link] (7 responses)
Seems that to generate a .deb you need to respect the "DESTDIR" in "make install", so you could type:
Posted Jan 6, 2011 12:40 UTC (Thu)
by epa (subscriber, #39769)
[Link] (6 responses)
Posted Jan 6, 2011 16:37 UTC (Thu)
by etienne (guest, #25256)
[Link] (3 responses)
Posted Jan 7, 2011 9:46 UTC (Fri)
by epa (subscriber, #39769)
[Link] (2 responses)
What's needed is a cultural change - if every program is built to be relocatable (another poster mentioned gcc as an example) then the package manager can quite easily install into the user's home directory instead, provided there are no extra dependencies to pull in.
Posted Jan 7, 2011 16:42 UTC (Fri)
by codewiz (subscriber, #63050)
[Link] (1 responses)
Good luck with that, most projects out there seem to ignore even reports of segfaults! :-) The existence of a public bug tracker is an implicit promise to the users that developers care about fixing bugs. Sadly, most bug trackers out there appear to have just become giant black
holes. A more effective strategy consists in hunting down the actual maintainers of the software on IRC and mailing-lists, then work with them interactively until the bug finally gets fixed. Filing a decoy bug may still be useful to show due diligence on your side: "yes, I did file a bug, one week ago!"
Posted Jan 9, 2011 15:11 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
I've got a bunch of bugs in Red Hat's bugzilla that haven't been taken up, but even so I do see interest in some of them. Many of my reports were fixed without closing the bug (probably the developer/packager found it someway else, or fixed it without being aware of the bug). Globally, I'd say the vast majority have been resolved to my satisfaction.
My (much more limited) experience with a wide range of projects has been similar, all around. Except for those that should be declared legally dead, that is.
Posted Jan 6, 2011 17:39 UTC (Thu)
by codewiz (subscriber, #63050)
[Link] (1 responses)
What's missing at this point is improving the various package managers to enable local unprivileged installation of packages that would support it. The hardest problem is resolving dependencies against two separate package databases (the system global packages and the user-installed packages). Ensuring consistency in all cases is not going to be easy.
Things seem to "just work" on Windows and OSX only because there's no dependency checking whatsoever! Users are required to take extra manual steps after an OS upgrade to ensure that 3rd party applications still work. The actual compatibility grid of proprietary OSes and versus proprietary applications would be quite scary if someone bothered to publish it.
Good support and documentation ensure that the users accept this without blaming the OS. Instead, we do a very poor job at the UI level, to the point that inexperienced users end up thinking that dependencies are there to interfere with easy software installation.
Posted Jan 9, 2011 15:20 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
You surely mean totally nonexistent OS support and just hiding the fact that there could be dependency problems...
This is just the result of being honest about a very complex problem, and the fact that with open source you are much more likely to update packages (you don't have to shell out $$$ for the next version).
Posted Jan 5, 2011 17:24 UTC (Wed)
by jthill (subscriber, #56558)
[Link] (1 responses)
Anyway, like I said above, you don't need to use apt-get or dpkg to install package contents locally: a .deb is just an ar archive.
I think the only thing necessary to make just-that-simple workable is relative paths and install scripts don't really need to run on private installs (no need to update-alternatives or whatever). I've never really looked hard at dpkg so I'll stop talking now.
Posted Jan 6, 2011 16:45 UTC (Thu)
by dtlin (subscriber, #36537)
[Link]
Posted Jan 4, 2011 10:11 UTC (Tue)
by loevborg (guest, #51779)
[Link]
Posted Jan 4, 2011 2:14 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (37 responses)
> What an app store needs: a GNU/Linux app store will need an update
What does it matter who handles the update mechanism, or which piece of software associates applications with a file type?
> It needs to be possible to make apps that will run on different CPUs
We already have multi-arch support and frankly it works pretty well. Although the only time I end up using it is when proprietary applications (like Skype) require old 32-bit libraries.
> It needs to be possible to rate apps in a central database and it needs
What does this have to do with package management? So create a website that rates apps, and has links to the Fedora/Ubuntu/whatever packages.
> Having a nice interface to deal with a million dependencies behind the
What difference does it make where files live?
Android "spreads the app across the filesystem". Chrome libraries are in one place, JPG libraries are in another, etc. If the filesystem in question is inaccessible to the user, what does it matter if the files needed by the application reside in 1 file or 100?
Honestly, this whole essay sounds like it was written by Dilbert's manager. Ooh, add an app store to it. And make sure to use cloud computing and Web 2.0? I'm counting on you, Dilbert.
Posted Jan 4, 2011 10:58 UTC (Tue)
by eru (subscriber, #2753)
[Link] (18 responses)
Do we really have multi-arch? I see 64-bit distros handling 32-bit apps seamlessly, but that is a limited special case for two generations of basically the same CPU architecture (x86 and x86_64, and similarly on other 32 and 64 bit variants of the same CPU family). I recall there was a suggestion for real "fat binaries" a year or two ago, even discussed on LWN, but it went nowhere.
Posted Jan 4, 2011 12:02 UTC (Tue)
by tzafrir (subscriber, #11501)
[Link] (11 responses)
Debian will support it, when it's ready, I guess.
Posted Jan 4, 2011 18:19 UTC (Tue)
by nye (subscriber, #51576)
[Link] (10 responses)
The basic idea seems to be that if we stonewall long enough, eventually the ia32/amd64 problem will go away, and that's all anyone really cares about anyway, so we won't have to worry.
Posted Jan 4, 2011 23:28 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (9 responses)
> The basic idea seems to be that if we stonewall long enough, eventually
Having ia32 and amd64 binaries and libraries installed side-by-side is not a problem on modern distributions. It works fine on Fedora, for example.
I can usually see the other side of the debate, but in the fat-binaries debate, I just can't understand why the pro side is all about. I think it's a case of engineers trying to solve a non-problem with a very heavyweight solution.
People seem to think that it would be a good idea to copy every minor technical decision that Apple makes. In reality, a lot of those decisions are only well-suited to Apple's closed and proprietary ecosystem, and certain quirks of history. Their real success is in marketing and good user experience design.
Bottom line: you shouldn't rush out to buy a 1-button mouse, just because Steve Jobs thought they were cool in 1984. And you shouldn't rush out to implement fat binaries just because they were kinda sorta helpful in the nineties when Apple was transitioning proprietary software from PPC to x86.
Posted Jan 5, 2011 0:03 UTC (Wed)
by ikm (guest, #493)
[Link] (4 responses)
This was discussed before. The most useful application of fat binaries are shared libraries, where one shared library can be simultaneously used for both 32 and 64-bit apps. This simplifies filesystem layout and life in general considerably (no need to mess with separate library paths, separate library sets etc).
Posted Jan 5, 2011 0:13 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (3 responses)
Why does having a simple filesystem layout matter? Non-technical users never see the filesystem layout on the rootfs.
This is just a lapse in elementary logic. It's like saying:
Elvis Presley ate fried peanut butter and banana sandwiches. Elvis Presley was a famous musician. Therefore, eating fried peanut butter and banana sandwiches will make you a famous musician.
Apple has fat binaries. Apple has a great user experience and a strong brand. Therefore, fat binaries will give you a great user experience and a strong brand.
Only one problem: it's illogical. Eating fried sandwiches will just make you a fat slob, not a famous musician. Moving around paths on the rootfs will mean absolutely nothing to non-technical users, who often don't even know what a shared library *is*, let alone the difference between /usr/lib and /lib64. Just ask any Android user-- paths on the rootfs have nothing to do with the user experience.
Posted Jan 5, 2011 8:37 UTC (Wed)
by ikm (guest, #493)
[Link] (2 responses)
Because it makes life so much easier.
> Apple has fat binaries. Apple has a great user experience and a strong brand. Therefore, fat binaries will give you a great user experience and a strong brand.
No one has ever said this here except you.
Posted Jan 5, 2011 21:21 UTC (Wed)
by JEDIDIAH (guest, #14504)
[Link] (1 responses)
No it doesn't. It's just like the analogy about the fat binaries.
>> Apple has fat binaries. Apple has a great user experience
Well, this idea of yours had to come from somewhere. I don't
These details are completely invisible to a desktop user of a
Some of us "users" don't want our "user experience" to suffer just Posted Jan 6, 2011 17:41 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
But not on Debian, unless you happen to be using one of the most popular applications for which there are specific hacks.
Posted Jan 9, 2011 15:26 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
It works on Fedora, because they take extra pains to ensure that the files that repeat among the arch-specific packages (manpages, header files, and so on) are exactly the same, and hacks to make files belong to several packages.
Posted Jan 6, 2011 17:50 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
I feel the same, only the other way round. I see distributions coming up with baroque and brittle 'solutions' to a simple problem, for which a much simpler solution is already known, just because they can't bear to do the same thing as a company known mostly for its annoying fanboys.
Posted Jan 6, 2011 20:10 UTC (Thu)
by nevyn (guest, #33129)
[Link]
On my desktop x86_64 I currently have ~2,200 packages and ~100 i386 packages.
And that's without discussing problem like Live CDs, where you simply can't just add 100MB+ of useless data.
Mac uses Fat binaries because they don't have good package management, I wouldn't be shocked if that changed when they introduce their Mac app. store this year.
Posted Jan 4, 2011 14:11 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Jan 4, 2011 16:40 UTC (Tue)
by utoddl (guest, #1232)
[Link] (4 responses)
Posted Jan 4, 2011 19:05 UTC (Tue)
by dtlin (subscriber, #36537)
[Link] (3 responses)
Posted Jan 5, 2011 20:40 UTC (Wed)
by daglwn (guest, #65432)
[Link] (2 responses)
Posted Jan 6, 2011 16:53 UTC (Thu)
by dtlin (subscriber, #36537)
[Link] (1 responses)
Posted Jan 7, 2011 22:45 UTC (Fri)
by daglwn (guest, #65432)
[Link]
Posted Jan 4, 2011 18:57 UTC (Tue)
by drag (guest, #31333)
[Link] (17 responses)
And... the distributions are not doing a very good job of it.
Google and Apple blow Linux distributions out of the water when it comes to distributing software. They have more software, more users, and in almost every way (size, scope, user friendliness, etc etc) completely blow Linux distributions out of the water. And they did it in a fraction of the time and with less people.
The idea that you have all these different distributions each with their own pool of software that they build and provide for users is a bad one. It's broken design.
It's not the tools, it's the design. It's fundamentally broken. It's better then Windows, but being better then Windows is easy nowadays. Everybody does it better then Windows.
If we had only one distribution then that would be one thing, but it's not.
Until Linux-on-the-desktop is willing to accept this and move forward then there will be almost no progress.
The software should be built and packaged by the developers themselves. They should provide distributions the packages and then the distribution's job is to make them work for end users. Sure there is a lot of technical issues, but technical issues can be solved.
Package manager is a good start, but the way it is done now is just bandaging over gaping wounds.
Posted Jan 4, 2011 21:20 UTC (Tue)
by nevyn (guest, #33129)
[Link] (2 responses)
Compared to what?
> Google and Apple blow Linux distributions out of the water when it
You are delusional.
Google are trying a lot of different things, some as an ISV and some as an OS company, most of which seems like crappy re-implementations of Linux package management. I've seen more than a few android market apps. that have their "deps." listed in their descriptions. At least they have (kinda) auto-update now ... which almost makes three features.
> The software should be built and packaged by the developers themselves.
Maybe you are trying to say something profound here, but the words you are using make it sound the most delusional part of your comment. There's nothing stopping the developers from doing repos. or even being Debian/Fedora/etc. members. In fact unstable/rawhide could be considered almost exactly what you describe ... and they have very few users for a reason, it does not work.
Or, if you believe the press releases, zero-install has been able to do what you want for years (yeh, only two packaging infrastructures). But they are pretty much hated by distros. and ignored by users (and, again, it's for good reasons).
Posted Jan 5, 2011 18:37 UTC (Wed)
by talex (guest, #19139)
[Link] (1 responses)
Having a way for users to install packages in a way that won't mess up the distribution package system (e.g. by introducing conflicts with distribution packages), yet still allows depending on distribution packages where possible should be pretty useful to distributions, and having packages and libraries work across distributions should be useful to smaller distributions at least.
Posted Jan 5, 2011 20:08 UTC (Wed)
by nevyn (guest, #33129)
[Link]
There's a huge difference between getting something into the repos. and the people in charge of the distro. "liking it". Esp. the community distros. like Fedora/Debian/etc. there tends to need to be a really big reason not to have something accepted.
I doubt you'll find anyone working on apt in Debian, or yum in Fedora (etc. etc.) who would recommend zero-install. Or that any number other than one is the best number of package managers to be using.
Posted Jan 4, 2011 21:35 UTC (Tue)
by DOT (subscriber, #58786)
[Link]
But wait, zoom in! Yes, down there in the corner there is 1% of the Linux user base using stranger and better distributions! Oh no, we're doomed!
Don't you think that the real reason for Ubuntu's minimal desktop usage share is because Windows has conquered the market and nobody cares to change it until a real interesting alternative becomes a real interesting alternative?
I have seen a graph somewhere that showed a remarkable adoption of Linux in the mobile space. You know, where Windows sucked. There is one particular system that does really well, called Android. Systems like OpenMoko and MeeGo don't seem to have a negative impact, even though they don't make Android's (or Ubuntu's) applications work.
Posted Jan 5, 2011 0:17 UTC (Wed)
by ikm (guest, #493)
[Link] (7 responses)
This is very true. While one can easily make an .exe installer which would happily work on pretty much all Windows versions, one should possess very strong maintainer skills to create a bunch of different packages for a bunch of different distros/flavors/arches. When I faced this problem as a developer myself, I just gave up - I've made a single .exe for happy Windows users and a single tarball for everyone else. I couldn't even master a single deb file - even that was just too complex for me to invest time in it. I mean, If that would have worked for all the distros, I might've gone this way, but it seemed too much effort for too little gain otherwise.
So in a nutshell, creating packages is tough by itself, and most importantly, there's just too many flavors you need to create for. A simple and singly accepted way to create packages is truly needed. As long as it's the distros who package the software, their selection will always lag and be incomplete.
Posted Jan 5, 2011 3:00 UTC (Wed)
by rich0 (guest, #55509)
[Link]
With linux there is no single standard for packages to target. The only way that would work is if something like java were used (single api/classlib/etc), or static linking. There are issues with both of these approaches. Static linking of course brings security issues and wastes RAM. Java is fine, as long as the classlib/APIs/etc are adequate and you don't need the performance of native code.
The other issue is which linux distro do you pick? I'm sure Canonical and Red Hat have no desire to make their distros redundant with each other. So, this becomes a case of the nice thing about standards being that there are so many to choose from...
Posted Jan 5, 2011 5:24 UTC (Wed)
by HenrikH (subscriber, #31152)
[Link] (2 responses)
What I think that we really need is a build server, either a local one or a hosted one, to which one could supply a tarball and out would come DEPs and RPMs for dozens of distributions and architectures.
SUSE has something like that but the supported distributions are not that great AFAIK.
Posted Jan 5, 2011 6:45 UTC (Wed)
by dlang (guest, #313)
[Link]
you will usually want to modify the package it created (to define dependancies etc) but as a bootstrap, it's very useful
Posted Jan 5, 2011 8:40 UTC (Wed)
by ikm (guest, #493)
[Link]
Yes, tried it, and it was very cryptic.
Posted Jan 5, 2011 20:35 UTC (Wed)
by talex (guest, #19139)
[Link] (1 responses)
What extra features did you want over the plain tarball? Automatic updates? Dependency handling? Digital signatures?
Would http://0install.net have helped here? It should just be a case of putting up a signed XML file saying where your tarball is, which file inside it to run, and any dependencies you want handled.
Posted Jan 6, 2011 7:10 UTC (Thu)
by ikm (guest, #493)
[Link]
Me personally? None, of course. Users? They just wanted an easily installable package for their distro.
Posted Jan 6, 2011 13:42 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Oh, come on. Not even Microsoft can build packages that work on all their systems (got burned by a game by MS that was supposed to run on every then-current system, that could be installed but never got past the spash screen). And that with massive effort by them to keep "important" legacy applications working (i.e., bug-for-bug compatibility). This "it is easy to create a Windows application that runs everywhere" is true just as long as that means the same version. Even service packs do break applications badly.
Posted Jan 5, 2011 9:04 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (4 responses)
The software Google distributes was mostly developed by, and for, Linux distributions. For example, Chrome links to libexpat, libgnutls, libcrypt, libz... I could go here, but maybe you get the picture? Android depends on sqlite, FreeType, WebKit, and a whole host of other libraries that have been part of the Linux ecosystem for a while. Apple is also smart enough not to re-invent the wheel. Even their kernel is based on Mach rather than developed in-house.
> It's not the tools, it's the design. It's fundamentally broken. It's
Doesn't Windows have like 95% market share on the desktop? And isn't the desktop what we're arguing about here?
The problem with this argument, every time it comes up, is that engineers always want there to be *technical* reason why Windows has 95% market share, Apple has 4%, and Linux has 1%. They can't accept the real reasons because it would challenge their egos by suggesting that maybe, sometimes, technology isn't the deciding factor.
The reality is that Windows still dominates because of economics, and Apple's success has been mostly based on a powerful brand name, great marketing, and good quality assurance. Technology is fun to argue about, but it doesn't have much to do with those numbers.
Posted Jan 5, 2011 13:01 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (3 responses)
On the other hand I could agree that *distribution* technology might be overrated in this discussion.
Posted Jan 5, 2011 21:27 UTC (Wed)
by JEDIDIAH (guest, #14504)
[Link] (2 responses)
Are you kidding? Were you even around in the days of MS-DOS? THAT is how far back this BS goes. MS-DOS was wiping the floor with MacOS when you still had to do MANUAL MEMORY MANAGEMENT.
A naieve view of economics and technology simply aren't adequate to explain the success of Microsoft and the failure of Apple (and everyone else).
Posted Jan 6, 2011 8:32 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Jan 6, 2011 13:48 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
The point was simply that then a computer was expensive (a reasonable PC would set you back some 5000 US dollars), and Apple machines were (and still are) exorbitantly more expensive. Sure, Apple machines themselves were carefully designed and build, not made by slapping the cheapest parts that did the job together. But "good enough" is all most people are looking for...
Posted Jan 4, 2011 2:19 UTC (Tue)
by gmaxwell (guest, #30048)
[Link] (1 responses)
Am I the only one that thinks an "app store" is really ignoring one of the critical fundamental advantages of free software that the software is truly no cost and thus doesn't need a centralized app store hook to monetize it.
We're perfectly capable of doing serious "batteries included" installs after all even the most outrageous install-everything option on a current distro would only be about 10% of the diskspace on a modern low cost system. But even with things like BTRFS' transparent disk compressing bringing down the cost it seems that the trend is away from fully featured installs.
I guess I don't understand the motivation behind imitating the methodologies of closed systems some of which (like a pay-access app store) are interest primary for closed software exclusive reasons rather tan focusing on the unique things that free software can do. The swiss army knife out of the box experience is something we can do that the competition can't.
Posted Jan 4, 2011 15:36 UTC (Tue)
by fuhchee (guest, #40059)
[Link]
Posted Jan 4, 2011 3:23 UTC (Tue)
by yarikoptic (guest, #36795)
[Link] (9 responses)
If Debian ever decided to go the way article suggests, I guess I would be able to install only under 10% of what I have now on my laptop (>4000 packages... how many do you have on your OSX box? Android system?) with SSD, or would be busy re-installing bulk of dependent packages to maintain some reasonable security of my system whenever core libraries get security updates.... or would enjoy misery some people experience while deploying pre-crafted bundles of python modules so they then struggle to use more than 1 at once from the same script... Here I simply admire integration aspect of Debian.
As I have mentioned, I do have my software market on my Debian box... yes -- I think it could be improved, but it is quite good already -- I can find actually useful tools in a matter of a simple search, check for similar ones if I am looking for an alternative, get whole system upgraded in a matter of minutes. And I am not sure where author got idea of dependencies' "lipstick on a pig" analogy -- dependencies seems to be fine (at least on Debian systems) and installing consumer-grade applications (i.e. not servers which do require configuration) is just a matter of few clicks no-matter on how many externals they depend.
Getting back to the article, it has its merits in that we do lack centralized way to bring 3rd party software to Debian users and I am not sure if we would want that for good and for bad -- if there is demand for a FOSS project, usually it does not take too long for someone to take care about packaging and contributing to Debian himself or via interested Debian developer/sponsor. But there is indeed investment of time necessary in preparing fully policy compliant package, which is a must for the acceptance into Debian; at the end imho benefits overweight the cost: actually being a part of Debian, software gets built across all the supported architectures automatically, transitions are handled taking all present software in account, centralized bug tracking system with a unified point of entry, etc. And ratings -- sure -- just enable popularity-contest on your box! Another side of the coin -- proprietary, freeware or some other kind of non-free software -- most of the time Debian distribution cannot accept those for obvious reasons ;)
And yes, I like ideas of easing the monetary contributions... for now we have http://www.debian.org/donations ;-) Mechanisms for per-application/support_request_handling monetary contributions indeed would be useful but the flow would need to be thought more through (i.e. how would contributions would sift into core-libraries projects which would not be user-visible directly etc) to become worthwhile and fair to the FOSS economy.
Posted Jan 4, 2011 19:48 UTC (Tue)
by drag (guest, #31333)
[Link] (8 responses)
Most of those arches are not relevant anymore and while I certainly would not begrudge somebody wanting to support a arch as a hobby, it is not really something of value to any end user... especially desktop.
The number of packages that Debian supports now is not very impressive anymore either. When the only counter example people could bring to the table was Windows it was easy to point at the package management and extol it's positive virtues.
However now we have other systems like Android and iOS that combine the distribution creation of software with package management and those systems quickly surpassed Debian. Not only in terms of users, but in packages.
Do you think that 15000 apps is a big thing? Try 200,000 for Android. Android will probably have well over 300,000 apps by years end. And iOS has many more then that.
And, hell, Android is even multi-arch.
The problem here is that the way things now is horribly inefficient. Its slow, it is labor intensive, and is full of a very significant bottlenecks. Instead of one guy packaging firefox and then distributing it, we have 30 guys packaging it. All doing the same work and all independent of one another.
What sense does it make that if I am using Debian I cannot benefit from work being done on Fedora? Must I wait until one of the SPICE developers goes through Debian boot camp for 5 years before I get to use that protocol in Ubuntu? Does a existing Debian developer have to give up supporting Rhythmbox so that he has enough time to support SPICE? Do the Redhat developers working on SPICE already know everything about it and do a good job building it and testing it?
That is insane. Fedora and Debian are almost entirely alike. They use the same source code, same design, etc etc. Almost everything with them is the same.. only a tiny number of differences makes them incompatible with one another.
Nowadays I regularly use software that is not part of Distributions. Usually because the distributions do a worse job then the developers or they are not available.
Some examples are:
* Google Chrome
All that is great software. I download the binaries and they "just work".
I also install a lot of software from Ubuntu PPA's (which are freaking fantastic things to have) and I don't have to worry about recompiling any of that when a dependency is updated. The chances of running into compatibility problems is small and if there is problems it is probably caused by the package management software more then anything else.
There are technical reasons why software needs to always be repackaged. But you know what? I can usually install Fedora packages just fine on Debian if I am willing to pollute my OS with alien software.
Posted Jan 4, 2011 20:02 UTC (Tue)
by dlang (guest, #313)
[Link] (4 responses)
PPAs are very much tied in to the existing packaging system, and the fact that you are so happy with them while being so pro app store indicates to me that the package managers that linux has _can_ do the job, if we use them properly.
the PPAs tie in and use the existing ubuntu libraries and dependancies, they _don't_ try to install their own versions of libraries or be stand-alone installs.
it's pretty easy to package something up to be a stand-alone install, but still tie in to a package manager. If you can compile the project statically linked you eliminate almost all dependancies, and you can use something like checkinstall to do 90+% of the work of packaging it for all of the major distros.
Posted Jan 4, 2011 20:26 UTC (Tue)
by drag (guest, #31333)
[Link] (2 responses)
No. Because I am complaining about the bad design of distributions, not their use of package management.
Package management is all fine and dandy, but its the subtle differences in distributions and the huge amounts of duplicated effort is that it causes is the problem. Removing barriers between developers and users is something distributions should strive for.
> the PPAs tie in and use the existing ubuntu libraries and dependancies, they _don't_ try to install their own versions of libraries or be stand-alone installs.
Some do.
The advantage of PPA's is that they do not require the developers to go through anything like FTP masters so it is a lot easier to get packages to end users in a fast fashion.
Getting rid of the requirements for Debian or Ubuntu membership and getting rid of ftp masters is a big win and that sort of thing is something all distributions should be aiming for.
> it's pretty easy to package something up to be a stand-alone install, but still tie in to a package manager. If you can compile the project statically linked you eliminate almost all dependancies, and you can use something like checkinstall to do 90+% of the work of packaging it for all of the major distros.
I already install a lot of software that is dynamic AND works just fine across lots of different distributions. Compiling everything to be statically is no more of a solution then requiring every individual to compile their software from scratch.
What I am getting at is that the lack of giving a shit about binary compatibility is a huge liability for Linux systems. Not caring about it, not designing for it, and not taking it into consideration the negative effects this causes the end users and third party developers is the problem. It hurts users and it hurts developers and whether or not the source code for those applications is available is entirely mute.
Distributions should provide packages for core items and the system and should worry about providing reliable set dependences that other developers and users can build off of how ever they see fit. They should care about having packages that install across multiple systems properly.
What constitutes a "core" component and what constitutes the API and such things are questions that need to be answered. Probably modular, but not terribly fine grained.
Distributions should be taking the same approach that Linux kernel developers do and set up a set of boundaries between what they consider to be their job and what they consider to be external interfaces. Only change APIs/ABIs when they have no other choice. Like Linux developers they should have the ability to remain fluid and be able to do what they want with the system in order to improve performance, fix bugs, and improve features.
And like Linux kernel developers they need to keep in mind that binary compatibility and external interfaces should be respected.
Posted Jan 4, 2011 20:45 UTC (Tue)
by yarikoptic (guest, #36795)
[Link]
Posted Jan 4, 2011 20:47 UTC (Tue)
by dlang (guest, #313)
[Link]
the bigger problem is with two things
1. what optional features are enabled in this distro vs the distro that the application developers use
and
2. what other packages are needed (defining the dependancies)
PPAs avoid some of the distro packaging issues, but they don't avoid these two issues.
most people who are advocating the app store approach seem to want it to magically solve these two problems, and the only way to do this is to eliminate depenancies by packaging everything that you depend on with the package.
as for the high number of android apps, if they were really that useful, why hasn't someone created an android emulator that can run on your desktop and use all of them? In my experiance, most of the android and iphone apps are things that on a normal PC you would just have a browser bookmark for. Yes there are many real apps that do not fall into this category, but for every "real" app there are tens to hundreds that are better off as bookmarks.
Posted Jan 6, 2011 13:54 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
And by linking statically you build too large packages, and create incompatililities with the other packages on the system (and security risks). That has too many downsides to be realistic for non-hobby use.
Posted Jan 4, 2011 22:52 UTC (Tue)
by robert_s (subscriber, #42402)
[Link]
* Google Chrome
All that is great software. I download the binaries and they "just work"."
You're clearly someone that likes to play around with software. Most of us don't. Most of us just want to tell our OS what software we want installed and trust it'll be there and be installed sanely.
I personally don't want to have to trawl around the web finding and installing the stuff I need and installing it in a way that will likely install its files in weird and wonderful places according to how the author thinks things should be done. I would rather spend that time being productive.
I'll stick with debian thanks. I consider the modern package-managed distro to be a pre-evolution of the app store.
Posted Jan 5, 2011 3:06 UTC (Wed)
by rich0 (guest, #55509)
[Link]
With something like Chrome or Android the core UI is fixed. Apps are much more contained than on a typical linux distro.
You also need to look at value-add distros like Debian. Debian doesn't just provide a bunch of packages - they also provide QA and assurance that you don't need to risk breaking your web app to get a security fix just because upstream stopped releasing updates to the version of your servers/browsers/etc that you are running. One of the things that many distros offer is a fixed major release schedule.
Don't get me wrong - both approaches have pros and cons. I run Gentoo on my server, so it is unlikely that I'll ever be running something packaged by an app distributor...
Posted Jan 5, 2011 6:26 UTC (Wed)
by eru (subscriber, #2753)
[Link]
How may of those are really anything more than specialized viewers of some web content for mobile use? Stuff that on any desktop OS is handled by one app: the web browser.
Posted Jan 4, 2011 5:47 UTC (Tue)
by iabervon (subscriber, #722)
[Link] (4 responses)
I recently got the Humble Bundle. But I couldn't do this through my distro's package manager, nor could I hand my download link to my package manager and have it install them (or, in the case of Penumbra, say, "With that video card? Surely you're not serious."). Now, apps these days only tend to have dependencies that you will almost certainly have a ABI-compatible version of, due to generally good practices, reasonable abstraction, not-too-fast ABI churn, and the ability to include any necessary obscure libraries, so it's not terrible that the package manager doesn't know anything about these programs. But, still, it would be nice if there was a distro-neutral catalog of programs (or more than one, with different organizations approving them) that could be seemlessly installed on whatever distro I happened to be using.
Posted Jan 4, 2011 8:09 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (2 responses)
Well, the big issue is version mismatches. If the code you're trying to install depends on libfoo version 10, and your system has version 11 installed, things may not work. You could argue that distributions should allow you to install all possible versions of the library, but that is an unrealistic amount of work for the distribution to take on. You could argue that the developers should spend some time to get their product to work with the distribution, but apparently they didn't.
In practice, what systems like Apple's iOS and Android do is that they have some central organization that effectively blesses a few versions of the libraries. It's like a dictator telling the developers that "you may use versions 10 or 15, but never any other ones." Then developers write their code so that it can handle one of the supported API levels.
The alternative is bundled libraries. A lot has been said about the evils of bundled libraries: the memory bloat, the unpatched security holes, and so on. It's probably fair to call this "the Windows way." We're all familiar with the 50-meg chunk of mystery meat crammed into an .exe that you double click on.
At the end of the day, all the different systems involve tradeoffs in terms of user freedom, technical quality, and convenience. I think Linux's current system is good for power users, good for office setups, servers, and so on. Systems like Android and possibly ChromeOS will take Linux to the masses, but only by making tradeoffs that you or I probably wouldn't want to make on our desktop machines.
Posted Jan 4, 2011 17:20 UTC (Tue)
by iabervon (subscriber, #722)
[Link] (1 responses)
Obviously, having a cross-distro app catalog with package manager integration doesn't add any technical problems with dependencies that just getting those apps individually wouldn't have, and getting apps individually does seem to work at present.
Posted Jan 5, 2011 2:21 UTC (Wed)
by cmccabe (guest, #60281)
[Link]
So in other words, if you have libfoo.1.1.0, it will be compatible with libfoo.0.0.0. libfoo.2.0.0, on the other hand, will not be compatible with either of these.
Compiling and install apps manually works fine as long as the libraries you need haven't made any backwards-incompatible changes recently. I guess you could come up with a self-installing binary of some kind that came with bundled libraries, but only installed them if there was no compatible version on the host system. I don't know if that would be welcomed or not. A lot of the time what you install with a self-installing binaries is proprietary software, and the maintainers don't have much interest in ensuring that it continues to work after they stop releasing updates. (This is quite reasonable on their part, economically speaking.)
Posted Jan 5, 2011 3:13 UTC (Wed)
by rich0 (guest, #55509)
[Link]
You download/extract a tarball, then type ./configure, and then make (or make install with a suitable destination like /usr/local). Worst case you need to install a few dependencies.
Most distros also provide for tagging the files as part of a package so that they can be managed.
It seems like app stores mainly serve to make it easier to reach a linux audience with proprietary software. I doubt that many open source linux distros have much interest in facilitating this. The big exception are firms like Red Hat, and of course everybody selling serious linux software already targets them anyway.
Posted Jan 4, 2011 7:55 UTC (Tue)
by dambacher (subscriber, #1710)
[Link] (1 responses)
You have an App-Store for Apple
get it?
Ubuntu has its package repository
So where is the difference?
The only interesting part is that you can install a debian package on ubuntu. With some handwork you can install it on gentoo.
Posted Jan 4, 2011 21:14 UTC (Tue)
by oak (guest, #2786)
[Link]
Linux distros are missing the good ol' Digital Rights Management that guarantees that the company writing the new world's best fart app will get their money for every instance of the app user installs on his different devices/computers.
Most Linux distros are about freedom, so lacking lock-down is by design. Google's Chromium OS and Intel/Nokia MeeGo distros are going to provide that though.
Posted Jan 4, 2011 11:51 UTC (Tue)
by oever (guest, #987)
[Link] (4 responses)
An important missing point is security. I would love to be able to download applications, like one can do with e.g. Android, and say: this application can only read from this directory, can write to that one, cannot maximize, cannot use more than 50% of memory and cannot access the internet apart from this list of hosts, to which it may send these requests at these specified periodic times. Ok, you cannot do all of that with Android, but I'd like to be able to restrict application like this.
In a few words: installing applications should be easy and secure. There should be no need to trust the application with more of your data and resources then you want to. Sure, the source code might be available, one might even compile during the install to make sure the binaries match the code, but that does not give the average user they feeling that they are in control, since they cannot understand all of the code easily.
Posted Jan 4, 2011 13:34 UTC (Tue)
by sorpigal (guest, #36106)
[Link]
Posted Jan 6, 2011 14:04 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (2 responses)
The "checking dynamically and falling back to our own" is a lot of work, that is hard to check if it works right (i.e., will be broken most of the time), and has all the downsides (bloat, incompatibilities, security risks) than just bundling libraries for very little gain.
Posted Jan 8, 2011 0:52 UTC (Sat)
by oever (guest, #987)
[Link] (1 responses)
Posted Jan 9, 2011 15:48 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
So nobody can fix even minor problems in the library, or use a different compiler, or...
Posted Jan 4, 2011 13:06 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
A recurring theme from these projects is strong distaste for package management systems, with lots of insistence that you should just (fill in whatever manual procedure is used for installing the simplest programs on that OS) which is much easier, so therefore package management is unnecessary.
Attempts to _discuss_ this will devolve. If someone mentions dependency tracking, they're told everything must be standalone. Versioning? All versions of all software should work with everything ever, and it's only laziness that prevents this. Configuration management? The program should handle that for you. It always comes back to "Making it work is the programmer's problem, I'm a user, don't worry about what I need, here is what I want" with occasional bursts of "I'm learning C++ in night school, wait a few months and you'll see how things should really work".
Then someone introduces a package manager (usually by stealth, maybe it claims to be a "temporary workaround" for something, or only for developers) and slowly but surely all the people who were sure they didn't want a package manager find themselves asking for it to do more, and for more software to be packaged.
Soon, questions from new users will routinely be answered by referring them to the package manager, perhaps even when it can't help (and then there's a new round of "features the package manager ought to have")
Package management works. The App Store is largely package management distilled down to the barest essentials. But we already have package management. At most we need continued user interface work to ensure we have something that's as easy as possible to use.
Apple's App Store made them lots of money because they had early adopters. Early adopters will buy a five dollar bill for $10 if it means they get to play with the new vending machine. Check back in five years and the App Store will no longer be hot and exciting and income (on a per-user basis) will have tailed off. Free Software isn't about exploiting early adopters, so we have no significant lessons to learn on that front.
Posted Jan 4, 2011 13:22 UTC (Tue)
by skvidal (guest, #3094)
[Link]
Posted Jan 4, 2011 13:29 UTC (Tue)
by sorpigal (guest, #36106)
[Link] (5 responses)
Just as the debate never changes a few facts never change. No matter what you do there are advantages and disadvantages. You can't get everyone to agree on a replacement for the status quo (and if you think your way is so superior get out of your armchair, start a distro, start a revolution and prove your point.)
We won't ever have a stable, universal target. We won't ever have a single distribution. We won't ever get everyone to switch to app bundles. No matter what we do there are hard problems to solve and your pet answer probably doesn't solve them.
The theoretical ideal, where all users can find and install whatever they want, apps stay up to date if the users want them to, nothing every breaks, everything remains secure and trusted, and every user is not required to be an expert, is not possible. You have to give up something somewhere. Giving up control to Apple or someone like them is one option that won't be happening in Linux-land. Changing the way users search for software doesn't solve everything, changing who hosts the software doesn't solve everything, and splitting software into arbitrary system and non-system categories just plain doesn't work.
Can we all get back to something useful now?
Posted Jan 4, 2011 20:01 UTC (Tue)
by ejr (subscriber, #51652)
[Link] (4 responses)
Posted Jan 6, 2011 14:18 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
That one creates as many problems as it solves, just for each individual user not for the system a a whole (and given that nowadays it is mostly a system to a user, it just duplicates the problems). Installing packages that depend on what is installed but unbeknownst to the underlying package manager is just stark raving madness.
Posted Jan 7, 2011 12:45 UTC (Fri)
by talex (guest, #19139)
[Link] (2 responses)
Posted Jan 9, 2011 15:56 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
I looked it over when it was first discussed here, and saw enough downsides to never even try it. If I need a package that isn't in my distributions repos, I either do an extraofficial install (under $HOME or /usr/local) by hand, and am acutely aware of the mess I could get into; or I go and create a package and install that, thus getting the advantages of package management for real.
Posted Jan 9, 2011 16:38 UTC (Sun)
by talex (guest, #19139)
[Link]
Could you give some examples of the downsides of 0install you saw, though? I'm still not quite clear what they are.
Posted Jan 4, 2011 13:43 UTC (Tue)
by debacle (subscriber, #7114)
[Link] (1 responses)
Having such libraries implicitely installed along with applications, possibly multiple times in different versions, is a security nightmare. Furthermore, in the context of free software, it doesn't make any sense not to use the latest stable version of a certain library. For special cases, distributions do already support multiple versions anyway.
To the very least, any "app store" application should manage dependency lists, not library copies. To be both distribution and architecture agnostic, it should be at least source-based, i.e. compiled on the vict^Wusers machine. But then, I prefer the repository of my distribution, where I can use binary packages or source packages, just as I like.
Furthermore, my distributor gives me a single point of contact for bug reports. Sometimes, a bug is reported against one application, but after more investigation it turns out that the error is in a library or in another application. This can be handled easily in the BTS of a distributor, but how would this be handled in an "app store"?
Posted Jan 9, 2011 15:59 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
App stores just distribute the leaves of the dependency tree. That is the most trivial part of the dependency handling.
Posted Jan 4, 2011 15:11 UTC (Tue)
by tstover (guest, #56283)
[Link]
-bundling LGPL libraries with proprietary code is possible, but non-trivial
-at least for research / exploration sake, Code Data Environment (http://www.stanford.edu/~pgbovine/cdepack.html) is very close to the dependency-less package we sometimes might want or think we might want
-commercial / proprietary software vendors, can always let users add their own repository server to an apt/yum/* configuration. Sure this could be ironed out a little, but a very powerful, very real, very right here right now, option that I suspect to see more of. Maybe add more options for requiring clients to authenticate, etc. This also of course handles updates.
(ok this one is not technical)
Posted Jan 4, 2011 16:42 UTC (Tue)
by jejb (subscriber, #6654)
[Link]
The next omission is that if you want a specification for a write once run anywhere (at least on the same architecture) for linux, we have one: the Linux Standards Base. Every major distribution complies with this, so in theory you can write a LSB compliant app once for all of them, so the article essentially boils down to a call for something we already have. However, it doesn't get to the practical problem with the LSB: it has to be a trailing edge standard (plus it's too much effort to standardise everything), so the new eye candy interfaces that app developers want to use tend not to be in the LSB. This, unfortunately, is the nature of the open source beast: we have to let evolution occur first and work out the taxonomies of the useful species afterwards. Trying to force creative evolution to occur on spec is a recipe for stagnation.
The practical solution to all of this is a build service (like the one SUSE runs or the Linux Foundation). You give it source code and a description file and it produces packages for a range of distributions and updates them automatically as the distributions evolve. A build service for all major distributions would essentially be an app store, because you'd be able to download your packages from it using the standard distro tools.
Posted Jan 4, 2011 18:11 UTC (Tue)
by RogerOdle (subscriber, #60791)
[Link] (1 responses)
Government workers will want to take work home so they will need Linux there. Students will have to master Linux to get those Government jobs. Industry will need Linux to work with the Government. Three things have been proven already: 1) Linux can do any job that a proprietary OS can, 2) Google has established that you only need one application (a web browser) to accomplish any office task, and 3) no proprietary vendor is irreplaceable, not Microsoft, not Apple, not anyone.
Posted Jan 6, 2011 14:32 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Dream on.
It is called Linux Standard Base (LSB). And nobody uses it. That one is solved as it is solved today: Want to work for/with us, make sure you have Windows version X with servicepack Y, configured like Z, and use only applications A, B and C in one of the versions we recommend.
Change "Windows" for "Linux" or "BeOS" or whatever in the above, it will stay exactly the same. Cross-system compatibility is a noble ideal, but a hell more work than it seems at first sight (yes, there are programs that depend on particular quirks/bugs; yes, it is a nightmare finding out why something doesn't work or fix it or (re)configure something on a distribution you're not used to; now add troubleshooting over the phone for Aunt Tillie).
Posted Jan 6, 2011 3:42 UTC (Thu)
by dbruce (guest, #57948)
[Link] (1 responses)
Posted Jan 6, 2011 16:37 UTC (Thu)
by gvy (guest, #11981)
[Link]
In short, "lets go writing some visionary analythics" shortly after lively celebrations tends to result in arbitrary crap.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
* screenshots (uses http://screenshots.debian.net/ )
* Better ranking (use data from popcon? relation to packages that are already installed? Just throwing some ideas here without even a thought about how they could be implemented).
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Fedora PackageDB
> synaptic has:
> * search
> * screenshots (uses http://screenshots.debian.net/ )
> Lacks:
> * Better ranking (use data from popcon? relation to packages that are
> already installed? Just throwing some ideas here without even a thought
> about how they could be implemented).
Package Kit
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Local, unprivileged installation may seem like a nice to have feature, but the vast majority of computers these days are laptops and single-user desktops, so in practice it doesn't make that much of a difference.
I'm not sure I can agree with that. The more we can eliminate root password prompts and root access, the better. (See Fedora's recent troubles with package installation by unprivileged users.)Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
jthill ALL=(ALL) NOPASSWD: /usr/bin/apt-get upgrade
jthill ALL=(ALL) NOPASSWD: /usr/bin/aptitude update
jthill ALL=(ALL) NOPASSWD: /usr/bin/apt-get update
jthill ALL=(ALL) NOPASSWD: /usr/bin/apt-get install *
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Easy enough to install .debs for at least some and I'd guess most apps locally, an ar x, a tar xf to .private or whatever, and a path entry. The ones that hardcode /usr for their own resources are wrong anyway.
That's the issue - most packages expect to be installed into /usr and you can't just put the files somewhere else and expect it to work. Out of interest what is the correct way to put pathnames into your code so that it is relocatable? Should you make them relative to the executable file?
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> That's the issue - most packages expect to be installed into /usr
make install DESTDIR=/home/$(USER)/root
once you have rebuid the software, and add /home/$(USER)/root/usr/bin to your path.
I am not sure how "apt-get install" would handle dependencies on those user-installed packages (installing abscent/incompatible libraries in /home/$(USER)/root/lib/ ?) - it "would be nice" for testing that a package works before installing it... mostly if the root and locally installed package are the same file.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
If configuration/library pathnames are hardcoded in the executable, then it is a source code problem - the package manager do not manage that.
Searching the "install:" target in Makefile can sometimes tell you which file to copy manually and where...
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> I wonder if most free software projects would accept a bug report that
> said 'I built installed the software in /foo, but then when I copied it
> to /bar it did not work'. I expect that currently, many would respond
> 'not a bug'.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Good support and documentation ensure that the users accept this without blaming the OS.
Instead, we do a very poor job at the UI level, to the point that inexperienced users end up thinking that dependencies are there to interfere with easy software installation.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Should you make them relative to the executable file?
Just like html, internal links relative to the link-er, yes. I did a private install for Wine, trying to get Rise of Nations working again when an upgrade broke it. I had .20 or .24, I forget, in .RoN/whatever with the Ubuntu PPA latest in /usr. It worked fine for a while, several weeks at least, then some upgrade borked it. I dual-boot now to game with my kid. Warband needs unclamped relative mouse reports and I can't be arsed to patch it to read direct from /dev/event* or whatever it'd take. A well-maintained XP is fast and stable anyway, it's not that hard to do.
ar p any.deb data.tar.gz| gunzip | tar tf - to see what's in it, xf to plop them wherever - a swamp like /usr, a per-app tree the way Apple does bundles, whatever.
Easier: Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
dpkg-deb -c something.deb and dpkg-deb -x something.deb dest.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> mechanism that is not distro specific, and a way to associate
> self-contained applications to a file type
> to be possible to forward one to all of your friends.
> scenes is like putting lipstick on a pig. The limitations imposed by
> the current spread the app across the filesystem are too
> far-fetching.
> It needs to be possible to make apps that will run on different CPUs
Multiarch?
We already have multi-arch support and frankly it works pretty well. Although the only time I end up using it is when proprietary applications (like Skype) require old 32-bit libraries.
Multiarch?
Multiarch?
Multiarch?
> the ia32/amd64 problem will go away, and that's all anyone really cares
> about anyway, so we won't have to worry.
Multiarch?
Multiarch?
> shared libraries, where one shared library can be simultaneously used for
> both 32 and 64-bit apps. This simplifies filesystem layout and life in
> general considerably (no need to mess with separate library paths,
> separate library sets etc).
Multiarch?
Multiarch?
>
> Because it makes life so much easier.
>> and a strong brand. Therefore, fat binaries will give you a
>> great user experience and a strong brand.
>
> No one has ever said this here except you.
see it coming from actual Linux software management from the
last 10 years. No. It sounds like you are attempting to use
ideas and propaganda from another OS without any consideration
for what's already there.
Unix system and are mostly invisible even to a shell user. That's
why I can pop open a terminal and type "sc3u" and it will work as
desired.
because some people latch onto really misguided ideas.
Multiarch?
Multiarch?
Multiarch?
Multiarch?
Multiarch?
I'd still like to see semantic dictionary encoding supported in Linux. That would allow running current "binaries" on processors that haven't even been thought of yet. Oh well.
Semantic Dictionary Encoding
PNaCL aims to use LLVM bytecode for that. From David Sehr's presentation at the 2010 LLVM Developers' Meeting, it seems to be coming along quite well.
Semantic Dictionary Encoding
Semantic Dictionary Encoding
They're defining their own ABI (see pages 28-30 of the presentation). There's no reason why it should have to match 1:1 to native ABI. The next issue (aside from finishing up that work) seems to be that LLVM bitcode isn't necessarily stable from version to version.
Semantic Dictionary Encoding
Semantic Dictionary Encoding
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> comes to distributing software.
Apple _might_ catch up a bit when they open their Mac OS X "app. store" in the next couple of months, but atm. it's currently a horrible joke of downloading random .dmg images and just copying the directories in them somewhere. And that just gets you "yum install" for the other 666 missing features, it sucks to be you. Steam also has full-update, which is ok for the games that are available from it (but that's still missing a lot of features, and the QA is at least as bad as Fedora).
Trying to do simple things like install xemacs was a multi-hour PITA. The fact they have a good desktop OS, and have applications available is _not_ the same as distributing software ... currently they really suck at that.
> They should provide distributions the packages and then the
> distribution's job is to make them work for end users.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> distributions have a zeroinstall-injector package in their repositories.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> would happily work on pretty much all Windows versions, one should
> possess very strong maintainer skills to create a bunch of different
> packages for a bunch of different distros/flavors/arches. When I faced
> this problem as a developer myself, I just gave up - I've made a single
> .exe for happy Windows users and a single tarball for everyone else. I
> couldn't even master a single deb file - even that was just too complex
> for me to invest time in it.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> to distributing software. They have more software, more users, and in
> almost every way (size, scope, user friendliness, etc etc) completely blow
> Linux distributions out of the water. And they did it in a fraction of the
> time and with less people.
> better then Windows, but being better then Windows is easy nowadays.
> Everybody does it better then Windows.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> and "technology" that easily.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Debian: We do have our "store" but we have the doors guarded ;-)
Debian: We do have our "store" but we have the doors guarded ;-)
* Blender 2.5 beta
* PS3 media server
* Subsonic
Debian: We do have our "store" but we have the doors guarded ;-)
Debian: We do have our "store" but we have the doors guarded ;-)
Debian: We do have our "store" but we have the doors guarded ;-)
> getting rid of ftp masters is a big win and that sort of thing is
> something all distributions should be aiming for.
ROFL -- must be a quote of the month.
replies could stop here
Debian: We do have our "store" but we have the doors guarded ;-)
Debian: We do have our "store" but we have the doors guarded ;-)
Debian: We do have our "store" but we have the doors guarded ;-)
* Blender 2.5 beta
* PS3 media server
* Subsonic
Debian: We do have our "store" but we have the doors guarded ;-)
Do you think that 15000 apps is a big thing? Try 200,000 for Android. Android will probably have well over 300,000 apps by years end. And iOS has many more then that.
Meaningless numbers
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
> distro's package manager, nor could I hand my download link to my package
> manager and have it install them (or, in the case of Penumbra, say, "With
> that video card? Surely you're not serious."). Now, apps these days only
> tend to have dependencies that you will almost certainly have a
> ABI-compatible version of, due to generally good practices, reasonable
> abstraction, not-too-fast ABI churn, and the ability to include any
> necessary obscure libraries, so it's not terrible that the package manager
> doesn't know anything about these programs. But, still, it would be nice
> if there was a distro-neutral catalog of programs (or more than one, with
> different organizations approving them) that could be seemlessly installed
> on whatever distro I happened to be using.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
You have an App-Store for Android
You have an App-Store for Windows Mobile
You have an App-Store for Symbian
You have an App-Store for Betavine
Debian has its package repository
RedHat has its package repository
Suse has its package repository
Gentoo has its package repository
The same free software packet can be installed on either ubuntu or suse or gento or...
This is the only idea I think wich is worth it: having an unified package description and maybe package format to interchange packages between the distros.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
I expect the eventual outgrowth of the desire for stand-alone applications plus security will be app-VMs, where each application runs in an isolated VM by itself and only appears to integrate with the system visually. Of course a lot of tapdancing would have to occur under the hood to make sure files could be exchanged between apps.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
App stores - a flawed concept in the context of free software
App stores - a flawed concept in the context of free software
I'll try to keep it technical
-don't loose scope of the larger trends. just as many "web apps" are giving way back to "browserless apps", and many "products" are giving way to "services" - most of all most "users" are leaving traditional computing in favor of games/phones/locked down widgets. Meanwhile, "computers" i.e. server/desktop/laptop/ultra portable, are going back to more technical/professional/enthusiast roles. So don't work your self to death trying to figure out how "John Q. D A" will keep swiping their card at your app vending machine.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
I do not know when it will happen but I do believe that it will happen. An app store will be established that will have the effect of stabilizing a cross-distribution API. Applications written to this API will run everywhere. Each distribution will can maintain an ABI module to retain compatibility while allowing the various distributions to grow in their different ways.
This will have the effect of providing a solid core of applications that are portable across different releases of a particular distro so that the public can see stability without the system becoming stagnate.
Government workers will want to take work home so they will need Linux there.
Free Software: the road to a Universal bundle, a powerful app store, and world domination (Free Software Magazine)
"Universal bundle" scam