Domain: autopackage.org
Stories and comments across the archive that link to autopackage.org.
Comments · 217
-
Re:Binary CompatibilityFirstly, it's probably best if you think of FC, Mandriva, SuSE, etc each as separate OSs, even though they share a kernel and many components. Secondly, if you must, build a statically-linked binary. That's often what the commercial vendors do for their 'officially supported' binaries. Alternatively, there are various distro-neutral packaging solutions that might be werth looking into, e.g. AutoPackage [autopackage.org].
And that, right there, is the crux of the issue: Ubuntu, Fedora Core, Mandriva, SuSE, Gentoo, Debian, Slackware,
... (and hundreds more at distrowatch.com) are all seperate operating systems. I'm well aware that that is the state of things now. What I'm trying to say is, it doesn't have to be that way.Statically linking (or the equivalent: packaging your own dynamically linked libraries and using those) is an acceptable solution, provided it's used on programs without too many dependencies, and only used on a small scale. Otherwise, the system's memory usage will increase dramatically and performance will go down. The downloadable Linux versions of Firefox and OpenOffice.org take this approach. It works for them because they reimplement almost everything (including their UIs) as internal libraries. They're both genetically related to formerly proprietary codebases, and therefore they don't represent typical Linux programs.
I've been following Autopackage for a long time. It's got a lot of potential. I hope they can work out the kinks, and get a larger body of software packaged, so I can get new software releases without worring about someone packaging it for my distribution. Another interesting project along similar lines is Klik.
Incidently, the Autopackage developers have a page that explains the problems with Linux application portability much better than I did. They also talk about why massive distro-specific package repositories aren't a good idea, in the same FAQ.
-
Re:Binary CompatibilityThat's a ridiculous solution. Why should every distribution be responsible for building a binary package for every Free Software program that's out there, and updating them every release? Sounds like a huge scalability problem to me.
Did I say that? Each distro vendor will package the best, most useful packages to its target userbase. It can be seen, however, that the most popular distros (e.g. RH-alikes, Debian, SuSE, Mandriva, Gentoo) also have the largest selection of packages. Most of those do so inside the main tree, Fedora is trying to take a new approach of building a core and letting a close-knit community take care of the rest. It's working out better than I expected only a few years ago.
This is *not* a hypothetical problem. One project I follow is Battle for Wesnoth, a cool GPL-ed turn based strategy game. They release new versions, in source tarball form, quite frequenty. Typically, the Windows and MacOS X binaries come out within a day or two of release. And the GNU/Linux binaries? The most recent user submitted version might be several versions out of date. The distribution packaged versions are even more out of date that the user submitted ones. For a fast paced project like Wesnoth, being out of date is bad. (I resort to building from source, because I know exactly which libraries I need, but some distros don't package libSDL-dev, ugh)
Pick distros that you're prepared to support and prepare an official package for each, along with any dependencies that don't exist in the standard distro, in the same way as the Windows versions use Installshield or whatever. I can't speak for dpkgs and ebuilds, but once you've done the first RPM spec file, it hardly needs modification from one revision to the next. Packaging doesn't even require much in the way of technical skill to do. If the package has limited requirements, it could even be portable across distros.
Also, I'm not holding FOSS to a "higher" standard. Every other operating system out there besides GNU/Linux *has* a definative baseline you can build applications against, without requiring every application to be integrated into the OS. GNU/Linux is unique in that it has multiple incompatible baselines. If I wanted to release a cool new GPLed application right now I'd have no way of releasing a common binary package that would work for all of my users. There are too many incompatible build environments.
Firstly, it's probably best if you think of FC, Mandriva, SuSE, etc each as separate OSs, even though they share a kernel and many components. Secondly, if you must, build a statically-linked binary. That's often what the commercial vendors do for their 'officially supported' binaries. Alternatively, there are various distro-neutral packaging solutions that might be werth looking into, e.g. AutoPackage.
-
He is absolutely right.
What he'd really like to see, is for the popular Linux distros to converge on a common core platform, according to the article.
Ultimately, all mainstream Linux distributions could derive from the same basic base (with the exception of those which try to fit Linux in tight places, for example). There is no reason that RedHat, SuSE, Debian, et al have to have so many differences beneath user-space software. (Consider the wildly different boot-time initialization scripts in each of those distributions. Ironically, there is a modular system in place.) Consolidate the similarities and expand by extensions which do not eliminate cross “distro” compatibility. There are already efforts to this effect. This is no magic bullet for any particular problem, but it will help eliminate the throat-cutting within the community and encourage computer manufacturers like Dell to offer Linux solutions.
-
Re:"nice" "summary"
I've been reading Mr.Linspire's post about it. It's Click N Run software installation. It's like a frontend to apt/emerge/pacman, but more polished at both ends.
Personally, I'd rather see something like GNU's AutoPackage software put into a major distro; of course, that relies on more developer support for it, but that's also a good thing (IMHO). Additionally, it would have all the benefits of a nice polished front-end, with the additional benefit of install-time linking (no need to enter DLL/RPM hell since you can just link against the APIs on the system, supposing that at least a certain version is installed that is compatible - AND they are looking at adding multiple libraries compatibility), and it could incorporate licensing if needed - heck, it's just a open source version of Microsoft's Windows Installer - only 10x's better. -
Re:Why the AVERAGE POWERUSER doesn't use Linux
Windows are able to make cross-version binary compatible apps, why not linux?
First, see the Autopackage project. We (the Autopackage devs) are trying to make it so that one binary runs on as many Linux distros as possible. And believe me, it is hard. Much harder than on Windows. 1. Partially because "Linux" is a bunch of software being developed by a bunch of different people with a bunch of a different opinions on how to do stuff. This leads to zillions of different conventions. 2. Distros, The FSF, and (most) software maintainers don't care about binaries that work everywhere. Distros want people to use apt-get/yum/emerge/whatever-your-distro-uses, and the FSF and most developers just want you to build from the source. For example, we had to write a wrapper around GCC/G++ to fix the GCC developers problems. Take G++, the compiler for C++ software. With the release of g++-3.4, there were 2 different ABIs that are widespread. The ABI used by g++-3.2/3.3 and the ABI used by g++-3.4/4.0. The G++ developers thought that they could make everything work by providing a "abi-version" switch to g++ which would force g++ to compiled the software with the proper ABI, but it doesn't work. It was reported as a bug, and closed as "INVALID". So, we had to fix it by double-compiling the software with g++-3.2 and g++-3.4/4.0, packaging both up, and then installing the proper one at install time. Developers just say "I upload the tarball. You build it." 3. There is no such thing as the Linux Desktop Platform. See the FAQ for more on this. 4. Tons of other reasons, but distros are the main show-stopper. So, if you want to see universal binaries, ask distro about getting the Autopackage support code installed. -
Re:Why the AVERAGE POWERUSER doesn't use Linux
Windows are able to make cross-version binary compatible apps, why not linux?
First, see the Autopackage project. We (the Autopackage devs) are trying to make it so that one binary runs on as many Linux distros as possible. And believe me, it is hard. Much harder than on Windows. 1. Partially because "Linux" is a bunch of software being developed by a bunch of different people with a bunch of a different opinions on how to do stuff. This leads to zillions of different conventions. 2. Distros, The FSF, and (most) software maintainers don't care about binaries that work everywhere. Distros want people to use apt-get/yum/emerge/whatever-your-distro-uses, and the FSF and most developers just want you to build from the source. For example, we had to write a wrapper around GCC/G++ to fix the GCC developers problems. Take G++, the compiler for C++ software. With the release of g++-3.4, there were 2 different ABIs that are widespread. The ABI used by g++-3.2/3.3 and the ABI used by g++-3.4/4.0. The G++ developers thought that they could make everything work by providing a "abi-version" switch to g++ which would force g++ to compiled the software with the proper ABI, but it doesn't work. It was reported as a bug, and closed as "INVALID". So, we had to fix it by double-compiling the software with g++-3.2 and g++-3.4/4.0, packaging both up, and then installing the proper one at install time. Developers just say "I upload the tarball. You build it." 3. There is no such thing as the Linux Desktop Platform. See the FAQ for more on this. 4. Tons of other reasons, but distros are the main show-stopper. So, if you want to see universal binaries, ask distro about getting the Autopackage support code installed. -
Re:Hey, its better than Linux
For third party stuff, Autopackage (http://autopackage.org/ works really well. I use it for Oolite-Linux.
-
Re:hmmmAnd since your answers are so full of crap you either don't bother to use the system you develop for or you're just a troll
... but whatever I'll "inform" you anyway.Nice. Why don't you go "inform" yourself? In the past I've written an entire software installation framework on Linux, a binary portability environment, modifications to the dynamic linker, patches for Wine, ALSA, GNOME and a bunch of other projects I forget, and me and my team pretty much wrote the book on Linux binary compatibility.
NViDEA provides binary drivers and has an installer to do the compiling if it can't find a compatable kernel. Their installer is GPL. Slap a graphical front end on it and then you no longer have a problem.
No longer have a problem? This is insane
... you realise that the kernel developers make a sport out of breaking the nVidia drivers right? Having a source wrapper doesn't protect them from everything, nowhere near. For instance the 4k stacks fiasco.Not to mention that this solution is light-years behind Windows 95 in terms of usability. What happens when you put the driver CD containing this magic source code wrapper in the CD drive? Nothing. What happens if you don't have developer tools and the kernel headers installed? Errors. What happens if the driver is more than 12 months old and the kernel API changed? Errors.
And finally what if you're a little company and Mr Kroah-Hartman smells blood? You get sued. This is about the most uninviting landscape for hardware developers imaginable.
C++ support Then get apps from the vendor or compile them on the system with glibc
... or fix glibc yourself if you don't like it.Michael Meeks has already attempted to "fix" glibc, and his work was ignored. This is the modus operandi of the glibc people, and as a result a generic patch he wrote to solve many of the symbol fixup and performance problems that plague Linux (eg OpenOffice startup time) is now a SuSE specific file format extension. Yay standards.
And for what it's worth many of the C++ problems are GCC related, not glibc. But Michaels work would have alleviated the symtoms.
As opposed to what? Windows XP?
As opposed to every other program in the world that users don't already have but might want to try.
Linus says he doesn't mind having it. So develop it. Some people don't care because we don't all want it.
Explain to me how to build a DRM system for an operating system in which you have no guarantees about the way it works. Now, you can't built a 100% perfect DRM system ever, but you can get close enough that it's worth doing and Windows is pretty good at it these days (and will get better as hardware support starts appearing for it). But Linux can't mount credible competition in this area. If there was a Red Hat music store or something then it wouldn't matter so much - the iTunes DRM is fairly weak, but it doesn't matter because Apple are simultaneosuly platform and media provider. But Linux is just a platform, so it doesn't have that luxury.
-
Re:Binary Packages
Each Linux distribution has its own form of package management, thus gaim can't exactly offer ready made packages for each distribution.
It is easy to offer a package compatibile with any normal Linux desktop. -
Re:Where are the RPMs?
There's work under way to replace the Linux standalone installer with autopackage for Firefox 2. Only time will tell if that works is completed or not, but it has the support of Mozillians.
-
Re:Please people, get real, Linux doesn't exist.
The packaging system already exists for Linux - it's called Autopackage (http://www.autopackage.org/) and it works very well for producing distro-neutral installers. For Oolite-Linux, we do the same as most Windows developers - bundle up the dependencies. For the end user, an Autopackage is just as easy as a Windows installer. Unlike Windows Installer though, Autopackage can resolve dependencies if there are any.
-
Re:Upgrading glibc is akin to...Go read up on the versioning scheme glibc uses - it's unique and defies both logic and common sense.
Basically, and this is coming from somebody who has a lot of experience of dealing with binary software on Linux:
- Yes, it's entirely believable that a glibc upgrade was required, because when you compile a program that binary is usually locked to the version of glibc it was compiled with. Newer versions are OK, older versions aren't.
- This locking process is automatic and independent of what the source code actually does. Most of the time the developer isn't even aware it's happened.
- RPM understands it and will refuse to let you install a binary that requires a newer glibc, even though recompiling the software would allow it to be installed on your existing system just fine.
- There is typically zero benefit to be had from this scheme, it's a badly thought out backwards compatibility system, and systems designed explicitly with binary distribution in mind like autopackage work around it automatically.
We can blame the admins, or the people who set the conditions of the test, or whatever, but the real problem is that Linux is crap at handling binaries. It requires an extremely precise knowledge of a million things that don't actually matter.
-
autopackage
autopackage is probably the current best tool for this. It makes a single, easily installable (and removable) package while coercing my system's GCC and libs into versions that are suitable for other distributions.
I use it currently for schism tracker (particularly the CVS builds that I do).
It works very well for me: Debian, Ubuntu, SUSE, Fedora, Gentoo, and Mandrake users have reported success with these binaries built with (gasp) a lone FC4 machine.
One day, I'll actually do a proper release and six years later it'll show up in the next Debian release. Then your fancy apt-get tools will work.
And to kneejerk jackasses that say "just release the source"- you must realize that the source is good for you and me (well me anyway, I cannot speak for you, obviously), the people who USE these programs have absolutely NO INTEREST in doing the work that I have just done for my own purposes.
Plus, having them use a single binary means that it's very easy to debug with nothing more than a core file.
Oh, and I suppose I am giving the submitter the benefit of the doubt that we are indeed talking about Free Software, aren't we? :) -
Re:Interesting dependency (not!)
Your answer: http://autopackage.org/
-
Re:Interesting dependency (not!)
I subscribe to the notion of a binary installation. However, until the Linux world can harmonize on a SINGLE package that runs on ALL Linux distros they will be far behind the Windows world in this regard.
One word:
Autopackage. http://www.autopackage.org/.
I use it for Oolite-Linux. It has worked fine on all distros I've tried. I have had no user reports of problems with the Autopackage installer so far. -
Re:When theory and reality disagree... reality win
...and in those cases, there is Autopackage.
The difficulty in installing some software is not the fault of Linux - it's just that maybe the developers haven't got around to making a decent distro-agnostic installer. Oolite-Linux is *not* distributed with any Linux distro, but it is very easy to install - download the autopackage, and run it. An Autopackage is basically an archive wrapped in a shell script that bootstraps the entire process - including getting the autopackage management infrastructure if your distro doesn't have it, and resolving dependencies if there are any to be resolved. Autopackages can either be installed in a GUI or in a terminal window. Superficially, it looks similar to the InstallShield-style Windows installers (but it does quite a bit more, such as dependency resolution, and can install programs quite happily as a non-administrative user where this makes sense, for example, you can choose to install Oolite-Linux system wide or in your home directory).
Autopackage is fairly new, but it's picking up popularity:
http://www.autopackage.org/ -
Re:nuts
"I mean, it's not the lack of a kparts equivalent, being programmed in a 70's language - c++ is a bad OO language, but C is much worse as "OO language" still gnome went with C (and you have to admit those even if you're a gnome zealot)"
Yes, but back when it was developed, it made sense to use C. C++ compilers back then sucked. Especially today, rewriting everything in another language for the sake of using another language is nuts. Furthermore, even today C++ has ABI issues (see this page for details) while C does not, making it easier for developers to distribute C binaries.
KDE is nice though. It's a good move to at least ship kdelibs, so that KDE binaries can work out-of-the-box (more or less). -
Re:OS X style app wrappers
-
Re:Maybe true, but not necessarily desirable
If only SuSe, Red Hat, Debian and Mandrake could just agree on some STANDARDS !!! For crying out loud, everyone is bashing microsoft for not adopting an "open" standard (actually plenty of them) but the key distros cannot even agree on a common way to distribute and install an application. How can anyone blame Microsoft when the exact same idiocy is happenning in their supposedly "perfect" open-source world?
First of all, there is another few on this: There's no point of talking about "GNU/Linux" collectively as an operating system. That is because, really, if there is such a thing as a "GNU/Linux" operating system, why can't you point it out for me? Rather, there is the "Red Hat Linux", "SUSE Linux", "Gentoo Linux", etc. operating systems. Note plural form. Noone tries to sell you on a "BSD system", but rather either FreeBSD, OpenBSD or NetBSD.People should realize it's the same thing in the Linux world. Instead of trying to unify all distros into becoming the same operating system (which would just be pointless -- they are different for a reason), how about trying to standardize on a certain distro instead? I propose Red Hat/Fedora Core, but only because it already is the most common (I use Gentoo personally). By that, I don't mean that everyone should be running RC/FC, but rather that all non-expert users or other people interested in psuedo-standars compliance should be running it. Expert users can still choose their distro of choice.
Anyhow, even as the situation is right now, hasn't anyone heard of Autopackage? It is a distro-neutral packaging format, that can install programs in a user's home directory, which already exists and is working extremely well. Far better, in terms of both flexibility, ease of creation, and user-friendlyness, than any Windows MSI-like installer if you ask me. I recommend developers (and end users) to check it out.
-
Re:Maybe true, but not necessarily desirable
Perhaps you're interested in autopackage? We're working very hard on multi-distribution compatibility.
-
Re:Apt...rpm...KDE...Gnome...choices choices
They don't need to do this.
All they need to do is create an Autopackage, or, better yet, and Autopackage and a klik:// image.
Autopackage kicks ass.
http://autopackage.org/ -
Re:This is why Linux isn't more popular....
-
Re: BOTTLENECKS FOR THE UNINITIATED
Good comment. Thanks.
Software install is definitely an issue still. When the software you want is included in the distribution, then the install is easier than on windows. Open up whatever package manager you have, and chose the programs you want, and install them. As a bonus, you seamless updates to new versions for all those programs. But installing something that's not in the repository is a pain in the ass.
I know how to compile stuff, but that doesn't make it any less of a pain. Do I have all the required dependencies? There's no easy way to check, just trial and error. ./configure, look at the error, try to guess what package it's missing, install that package, ./configure again. It sucks. Luckily this problem is being approached from a few angles now. Autopackage (http://autopackage.org/), klik (http://dot.kde.org/1126867980/), and zero-install (http://0install.net/) all look really promising. I've tried klik, and it really rocks. Give it a go if you have a chance. -
Re:When will RedHat address the "rpm hell" problem
RedHat dealt with RPM hell years ago (up2date and yum both work very nicely thank you).
For everything else, there is Autopackage (http://autopackage.org/) -
Re:Linux Support
the answer is: http://www.autopackage.org/
-
Re:Package management
Autopackage isn't quite integrated with the default package manager yet (per their website, http://autopackage.org/) Once that happens I can see that being very likely.
;) -
Re:I agree, but something needs to happen
You want autopackage. I suggest you read the materials on that site, these guys not only have the skills but they actually care.
-
Re:I agree, but something needs to happen
I've been using Linux for many years, and the problem of obtaining software packages drives me to the end of my nerves.
Hmmm, what packages are you trying to install? I usually only have that problem if the software is still in CVS or something. But even then, Gentoo still usually packages it. I do have problems when I use Fedora. Not sure why they don't have a lot of packages, but it is hard to find stuff sometimes. With Debian, though, almost never a problem. In any case, Autopackage is supposed to solve this problem. It actually looks pretty neat, but I am waiting for local packaging system integration. Then it will just be a matter of convincing developers to use it. Some projects, like Abiword, already are. -
Re:I agree, but something needs to happenEven with the source, half the time I have to make all sorts of include changes.
Then the program is broken. Report the bug. The autoconf/automake scripts should take care of all that.
It sounds as if you'd like autopackage.
-
Re:Why are there distro-specific packages?
This is why most newer distros are using other package managers these days. Debian's apt and Gentoo's Portage do alot more dependency checking and just seem to work much better in general. I've heard good things about Pacman too, but never used it. RPM is slowly but surely going to die out unless they completely revamp how it works. If you can, I'd suggest just looking for a
.package as they generally work with almost any distro with very little effort. ;) -
Autopackage
There is Autopackage. Never used it but it looks like it'd suite your needs.
From Wikipedia:
Autopackage is a relatively new package management system for GNU/Linux, intended to be usable under all distributions. Unlike the RPM and Deb package formats, Autopackage checks for the presence of dependencies on the actual system, rather than querying a database of package information. Although this reduces compatibility issues with different package naming conventions, it does mean that Autopackage is slower than distributions' native formats. Autopackage packages are actually executable bash scripts, so that they can be installed simply by running them. Autopackage is intended to be used for installing non-core applications such as word processors, web browsers, and games, rather than core libraries and applications such as shells. For core applications and libraries, the distribution's native package manager is recommended for speed and compatibility reasons. Non-core libraries are something of a thorny issue, on the one hand packaging them allows installation on a greater range of systems, on the other hand there can be issues with conflicts when native packages are installed that depends on libraries that have been installed by autopackage. Autopackage differs from other executable installer systems for GNU/Linux such as Oblisk and the Loki installer in that Autopackage is specially designed to be compatible with as many distributions as possible. Autopackage uses APbuild to strip bogus dependencies, "cross-compile" to make C++ programs compatible with different versions of g++, and fix GLIBC version symbols, among other things. Programs must also be relocatable, meaning they can be installed into any location without needing to be recompiled. -
Re:Desktop Linux needs the following:
With the rich resources of the OSS community, one wonders why rpm dependency hell has no adopted solution.
The developers of yum and apt-get will be surprised to hear that their code doesn't exist.Autopackage http://www.autopackage.org/ would be a good start but all major distros are not even giving it support!
The Autopackage team points out that Autopackage is geared for third-party apps, and that distributions should continue to use .RPM/.DEB for first-party packages. The most distributions need to do is bundle Autopackage itself as a first-party app; but since Autopackage packages will download and install Autopackage anyway the first time they are run, it's not really necessary.Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.
Both GStreamer (the backend which Totem uses) and kdemultimedia (the backend which Amarok uses by default) include MP3 support normally. However, many major distributions ship these backends with the MP3 codec removed, since they cannot sublicense the patents involved to all recipients as required by the GPL. Despite what you think, this is a licensing issue.There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?
This was marked WONTFIX because it should be handled by the Linux distribution, not KDE. -
Re:Desktop Linux needs the following:
With the rich resources of the OSS community, one wonders why rpm dependency hell has no adopted solution.
The developers of yum and apt-get will be surprised to hear that their code doesn't exist.Autopackage http://www.autopackage.org/ would be a good start but all major distros are not even giving it support!
The Autopackage team points out that Autopackage is geared for third-party apps, and that distributions should continue to use .RPM/.DEB for first-party packages. The most distributions need to do is bundle Autopackage itself as a first-party app; but since Autopackage packages will download and install Autopackage anyway the first time they are run, it's not really necessary.Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.
Both GStreamer (the backend which Totem uses) and kdemultimedia (the backend which Amarok uses by default) include MP3 support normally. However, many major distributions ship these backends with the MP3 codec removed, since they cannot sublicense the patents involved to all recipients as required by the GPL. Despite what you think, this is a licensing issue.There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?
This was marked WONTFIX because it should be handled by the Linux distribution, not KDE. -
Desktop Linux needs the following:Desktop Linux will still be a long way off until applications can be installed and un-installed in an easy way. I know folks are going to mention apt-get and its sister dpkg tools. But these are not very useful unless one can configure them and is also on the internet. With the rich resources of the OSS community, one wonders why rpm dependency hell has no adopted solution. Autopackage http://www.autopackage.org/ would be a good start but all major distros are not even giving it support! From a developer's point of view, writing an application for Linux means testing the application on no more than 6 distros! In some cases, I have seen more than 17 binaries for the same applications targeting different Linux distros. In the Windows world, there could be just 1 or 2. So it follows that if we in the Linux world can make life easier for developers, then that is positive. Our egos alone will not deliver. I think we need some kind of dictatrship here.
The other thing Desktop Linux needs is good fonts. I am yet to find a desktop Linux installation that is beautiful out of the box. Often times, one has to download M$ fonts or could use the script found here: http://vigna.dsi.unimi.it/webFonts4Linux/webFonts
. sh to get good fonts for the web.Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.
There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?
Last but not least, we need publicity - good publicity. Right now, Linux is being touted as very good or good enough for the average user. What happens is that folks then have to understand that Linux is just a KERNEL and that there are many implementations associated with this kernel. To many, understanding this is a challenge. So one says "I use Linux at home, it's freely available on the net...try it out..." (and they leave it at that)! What follows is confusion as newbies find tons of distros and incompatible packages. Folks what do you think?
-
Re:The problem is
A distro agnostic packaging format like autopackage might help. It doesn't replace your distro's package system, it's in addition to it. Lets third party software writers not have to worry about distro specific crap, and gives the end users a consistant way to install packages that don't come with their distro.
-
Re:Really ?
As the GP mentioned, any-distro, painless install is the dream and reality of autopackage.
-
21st century linux?This is not a troll. This is what I believe that users want: the Firefox model.
Maybe Linux will evolve into the 21st century with Novell and SUSE.
My ideal Linux distro:
- 1 CD (less than 250 MiB)
- Gobo linux style file system hierarchy (mac style)
- YaST
- Only base KDE/base gnome
- base system (system binaries)
- No other applications (exactly, don't need 10 text editors, 5 databases, 20 audio players, etc.)
- All programs are provided by their developers directly via Autopackage or BitRock, and other windows-like installers sice no one in the linux community seems to like app folders
My next computer will be a Mactel. -
Misinformative.
I teach game development and do alot of 3D modelling. Alot of what you say above is false out of the box.
The state of 3D on Linux is far from sucking. Proprietary Nvidia drivers on Linux cannot be beaten, out-doing their Win32 counterparts alot of the time, even where frame rate (Q3a, Doom3, UT2004, AA) is concerned. Nvidia on Linux is an industry standard 3D animation platform in the feature film industry, for good reason. When teaching game development, if my students are sitting at machines running Nvidia binary drivers on a Linux OS, I'm having a very good day. Naturally, I'd love it if an open alternative could compete - you seem only aware of the open-source drivers, which are essentially blind to the rich talents of the Nvidia GPU. ATI's fglrx drivers are now (finally) on par with Win32 where pixel/vertex shaders (GLSL ) are concerned and close to a performance equal generally. The installation process is slightly more annoying, that is all. Many non-free distro's handle this for the user automagically (Mepis Linux comes to mind)
Secondly, binary compatibility is no more troublesome these days than it is between versions of Windows, eg running a game made for Win95 on XP - occassionally an issue. Installation of binaries can be done easily using a system like Autopackage if one doesn't want to find and or become an *.rpm/*.deb package maintainer.
Where devices are concerned, the trouble you speak of is many years in the past - udev works in userspace, and uses hotplug calls that the kernel signals whenever a device is added or removed from the kernel. Permissions, naming and control is all done in userspace.
Finally where sales of Linux games are concerned, I tend to agree that it is perhaps a little harder to market to Linux users, though from experience I am the first to buy a game that comes out for Linux. You will find though that due to existance of compatibility layers like Wine, publishers simply don't know how many Linux users are buying their games. I can account for around 14 windows games I've bought with the pure intention of playing them on Linux (for instance). Linux desktop market share is widely considered to be above or equal to that of the Apple OS. Whatever kind of market it is, it's growing.
Lastly, for the grandfather, Ryan, of Icculus is your best bet for a Linux port.
PS. Game development, as a culture, needs free software if a) small to medium sized developers are to survive and b) if micro-markets (like that of the indie-film industry) are to burgeon. Tools are increasingly expensive and publishers offset this cost with IP tradeoffs (buy outs). If I were you I'd ship the engine as free software (binary checksum for login, cheat protection and validation) and sell the data and/or subscription time. More on why here. -
Re:Slashdot
Oh, sorry.
I really hope you insist on autopackage! URL: http://autopackage.org/ -
Re:The real question: binary compatibility
Technical binary compatibility is an irrelevance if Mr.Average User can't get his application to install.
Quite true.
Maybe it is possible to convert an RPM to a DEB and install it with Apt-get or one of its front-ends but again that's further than most users want to go just to get a pre-compiled app running.
If you want to install an application that isn't provided by your distribution then you really want to be using an autopackage. Binary compatability becomes clear - a single autopackage can install and run on most major distributions (providing you've got the same architecture of course). If the people providing you the software haven't packaged it as an autopackage... perhaps you should be asking them to do so. Autopackage is new, but it's great for packaging up your software project - no more "RPM for Redhat, RPM for SuSE, RPM for Mandrake, DEB for Debian..." just make one autopackage binary for the lot.
Jedidiah. -
Re:Standards
The main reason you don't see it advertised for more distros is because you have to pay for certification. A lot of the distros will try to follow most of the LSB guidelines, but don't have the funding to spend on certification.
I'd love it if Autopackage support became part of the LSB one day ;) -
Re:What about MIME types/file associations?
I have no freaking idea where this thing is actually stored.
I also had trouble finding that, until I tried Autopackage. As it turns out, both Gnome and KDE use Freedesktop's MIME specification and store the files in ~/.local.The ~/.local directory is quite a wise addition, and is a user-specific directory equivalent to
/usr (with bin, lib, share, etc.). Autopackage uses it to install per-user programs, and Freedesktop uses it to install per-user MIME-settings (in ~/.local/share/mime and ~/.local/share/applications). -
What I like about LinspireThere are many things to love about Linux based Operating Systems especially on the virus/malware/addware side, but what I have come to like about Linspire is that it just works as advertised. It just works! SuSE does not (remember multimedia)? Second, it's beautiful. I love its fonts. For other distros, I have had to tweak X11 and download this script http://vigna.dsi.unimi.it/webFonts4Linux/webFonts
. sh in order to see fonts as I like them. What troubles me most is that even for Debian based ones, the invoking of this command "apt-get update && apt-get upgrade" might leave you with an unusable system.Now, if Linspire could adapt autopackage http://autopackage.org/, the better since Linspire packages would be able to install on any distro.
-
AutoPackage for Linux == InstallShield for Windows
Autopackage is an InstallShield style installer that lets users optionally install without knowing the root password. (it installs under their home directory, naturally in such a case)
Take a look:
http://www.autopackage.org/flash-demo-install.html
If I were to want to distribute commercial apps under linux, this is what I'd use. -
Re:'Static' RPMs aren't static
You should try giving the
.package file a whirl. It's built using autopackage which is a distro neutral linux based installer that also resolves dependencies. Even if you don't have autopackage installed, you just download the .package file and it handles everything. IMHO, it's best thing for Linux software development. -
Re:Mandrake on my laptop...
Autopackage is not a packaging system to build a distro, their own FAQ says so: http://www.autopackage.org/faq.html#1_2
There's nothing wrong with urpmi (and its GUI equivalent in the Mandrake Control Centre) - they work just as good as apt for me. I've been using MDK since 9.2. -
Re:Depends on what counts as a distribution
Is it a new Windows distribution, when an OEM installs extra tools, such as IBM's laptop utilities? I think there's a tendancy to see division above and beyond where there actually is any, when it comes to Linux.
Changes in policy alone can made a distro seperate from its parent.
Personally, what I would like to see is a "standard source library", where versions of packages known to work together are collected together. That would simplify the work of binary package maintainers and provide a level of unification on the baseline WITHOUT imposing unification in the installation or the experience.
Agreed. I think a combination of Componentized Linux and AutoPackage would bring us several steps closer to that goal. Also, it's too bad that Fedora "Core" doesn't join in the effort.
I have long thought that we need a package and repository system for FOSS on windows also. Wouldn't it be great if you could just install apt-get for Windows and get all of the OSS goodness in one shot with automatic updates? :)
I would ALSO like to see package maintainers work together a bit better. I use a number of the RPM distros that make up the RPMForge collaboration, yet I do run into lots of incompatibility issues. This is not necessary and definitely not desirable.
I'm not familiar with RPMForge, I agree that there should be more consolidation when possible. Why do there need to be several incompatible repositories for Fedora Core? Why can not everyone converge around an at-rpms multi-step testing style instead of pushing out the current version as soon as the latest is released? I'm not even endorsing at-rpms itself, just that style and consolidating the repositories.
Why is there not a common repository project that supports all of the big RPM based distros (at least RHEL, Fedora, SUSE & Mandriva)? If nessisary use one SRPM and compile it against the various target distros, but maybe one rpm could cover them all (I'll let someone else inject the LOTR reference).
I think diversity for Linux is essential, but a software version of the Great Library of Alexandria would definitely help with not only maintaining those distributions efficiently but also make it easier for distros to be much more compatiable with each other.
Debian is already at the center of several distros, why not extend it over to the RPM world? Use Debian source packages and make RPMs out of them. :) -
Re:There are solutions that address this...
Excuse me, there are many more packages than Gaim available here. Firefox, Abiword and The Gimp stand out as the most popular packages on the list.
-
There are solutions that address this...
Autopackage addresses this issue by allowing the providers of software to roll their own equivalent of an InstallShield package.
The only big piece of software that I know about that distributes an Autopackage is Gaim (here).
Just download and run it, and after some progress bars and some simple questions you have Gaim on pretty much any distro. Sure, it has to provide its own dependencies (so you lose the benefits of sharing libraries with your distro), but it works damnit.
So the problem is being addressed on Linux, it's just a matter of software getting packaged in a way that everyone can use. But that's kind of the idea of distributing source... -
Re:And they call themselves techies
I don't know
... user idiocy can really be equated as people using your software outside its intended purpose. To me - what marks a good engineer is one who accounts for such deviation. Calling people idiots doesn't solve the problem. It just puts further barriers between you and the problem at hand.
But on the topic of Windows, I do find it to be an inferior operating system in the sole reason that it is designed like a submarine with one compartment. Get one leak - no matter how small - and the entire ship goes down. With Linux, just seal off the damaged compartment, and keep on keeping on.
I do agree with you in regards of installing software on Linux. That's why I hope this little project takes off.