Maintaining a separate patchset is normal, accepted, and not considered forking. They'll still be just applying these patches to the mainline tree, not severing development. Forking would be if they took the codebase and began changing it with a different set of developers and not just adding some code to each release of the kernel. EVERY distro does that. Perhaps not slackware or debian, I don't know, but Gentoo, Mandrake, Gobo, all have heavily patched kernels.
it's pretty easy. This procedure should work for most packages:
1) Download the tar.gz or tar.bz2 (for instance, foo-1.2.tar.gz) 2) unpack the tarball: tar xvzf foo-1.2.tar.gz (or tar xvjf foo-1.2.tar.bz2) 3) enter the program directory: cd foo-1.2 4)./configure 5) make 6) become root: su 7) make install
Most packages have a file called INSTALL, which directions for installation. Almost always, this is the same text, detailing what I said above. If it's different, pay attention! If there's no INSTALL, the README will usually have directions.
I suppose the "tar xvzf" could be hard to remember the first few times. For reference: x - extract v - verbosely (list files being extract) z - unzip. (for.gz) j- unbzip2 (for.bz2) f - from file [name]
It's worth reading./configure --help if you run across problems, there may be options that can help.
source. You can always compile from source. Every (non-proprietary, obviously) program for linux comes with source, and 99% of them have the standard./configure, make, make install dance.
So if Opera doesn't want to keep supplying 12 versions, they just have to open their source and supply a tar.gz, which EVERYONE can install. At that point, it's also trivial for disto maintainers to package it up as a binary so that their users can install it with $PACKAGE_MANAGER.
Anyway, the installers are more-or-less standard for a lot of things. Just swap one word. EG, to install gaim:
Gentoo - emerge gaim
Mandrake - urpmi gaim
Debian - apt-get install gaim
(and many other examples, I know.)
I mean, it's really difficult for it to get any simpler.
Actually, that's part of the very idea of user intuitiveness. It SHOULD involve more effort to do something drastic like deleting all your files. A world where deleting your whole file system with a rm -rf/* is as easy, or easier, than deleting a specific file, is an unbalanced one.
So, you better be SURE you're willing to do such a thing, so making more effort involved is helpful.
The problem with apt, and all package systems, is the dependence on the maintainers. You have to wait for someone to package it up, and trust them to do it right, and to do all the stuff you're interested in. If you have to package things yourself that more than negates the benefits.
The/usr/bin,/etc,/usr/man, and so on system that *nix has used is a flaw in the design: necessary to avoid searching 10,000 dirs in the path, as an above post said, but problematic for maintenance and not helpful to users looking for program associativity.
packaging is a partial solution, but not a whole one, and introduces flaws of its own. Putting each application in its own directory, as ROX's AppDirs, GNU Stow, and GoboLinux do, is the proper way to do things. The problems introduced are how to find the thing in your path, and getting the vast amount of existing code to work in the new system without having to be changed (which is, after all, one of the problem-causers of the packages.)
ROX just uses GUI, so it doesn't deal with the path issue, and has to repackage anyway. Not a solution.
Stow uses symlinks to deal with the path, with an intelligent system to automatically remove symlinks to applications that have been removed. It can be used with any package using autoconf, the vast majority out there, so no repackaging necessary.
GoboLinux has an even more radical modification to the standard hierarchy. I believe that it also uses symlinks for the path.
No, it's not like just installing in a common bin. Symlinks into contained application directories mean that uninstallation and upgrading can be done without worrying about leaving parts around your system. This is basically the approach taken by GNU Stow, an under-appreciated program.
If you want multiple versions, one of them is going to be the one that gets called by the app's name, you can't avoid that. I'd probably make a system where it selects the latest one.
This just answers the problem with performance hits by traversing a crapload of path directories. If you have a script to symlink everything after any installation, the problem goes away.
That's a matter of preference. It's perfectly possible for the system to ask "libsuch-and-such is not being used by any programs, do you want to remove it," if you want to deal with the overhead of keeping track of such things.
Of course, part of the point of zeroinstall is that nothing is really INSTALLED in the first place, just cached on your system. So uninstallation is sort of a moot point -- you can delete all the files in your cache if you want, and the programs are just as accessible as before.
What they mean by that statement is that the entirety of the application is in one directory, instead of being split all over the filesystem as is current.
This means, for example, that "uninstalling" is simply deleting one folder, and upgrading in place is sublimely easy.
It doesn't mean that libraries from other programs won't still be necessary. But the applications ARE self-contained in their own directory, in that all the files that come with them are in one place, instead of all over.
And who the hell wants to delete all the files the program relies upon when you uninstall it? That would delete the whole operating system! You just want to get rid of everything that program ADDED, so as to avoid building up cruft. This takes care of that.
I'm sure that my graphic calculator can update as quickly as any computer could 10 years ago, and my graphing calculator can move far too quickly to be read.
"RMS and FSF are seeking power, not freedom."
-Steve Dimse
Offtopic, but bullshit. RMS has given up dozens of chances to have more power, influence, and money in order to stick to his principles and work for freedom. Whether you agree with those principles or not, you can't claim he hasn't served them completely unswervingly.
Slashdot Mirror
I'd see this mostly as SuSe posturing.
Xfree86 and X.org are compatible. The current nvidia and ati drivers work fine on both. There is no need for them to change anything.
Please stop your fud.
A windows user runs such a script, it destroys a system.
A unix user runs such a script, they get "permission denied." Your example would be entirely harmless.
I suppose it's different in the windows world.
You name your hard drives?
(insert raised eyebrow here.)
Yes.
Safari isn't Gecko.
This is just an IE bug.
it's pretty easy. This procedure should work for most packages:
./configure
.gz) .bz2)
./configure --help if you run across problems, there may be options that can help.
1) Download the tar.gz or tar.bz2 (for instance, foo-1.2.tar.gz)
2) unpack the tarball: tar xvzf foo-1.2.tar.gz (or tar xvjf foo-1.2.tar.bz2)
3) enter the program directory: cd foo-1.2
4)
5) make
6) become root: su
7) make install
Most packages have a file called INSTALL, which directions for installation. Almost always, this is the same text, detailing what I said above. If it's different, pay attention! If there's no INSTALL, the README will usually have directions.
I suppose the "tar xvzf" could be hard to remember the first few times. For reference:
x - extract
v - verbosely (list files being extract)
z - unzip. (for
j- unbzip2 (for
f - from file [name]
It's worth reading
C'mon, let's be realistic...have you ever seen a sourceforge project NOT in beta? ;-)
So if Opera doesn't want to keep supplying 12 versions, they just have to open their source and supply a tar.gz, which EVERYONE can install. At that point, it's also trivial for disto maintainers to package it up as a binary so that their users can install it with $PACKAGE_MANAGER.
Anyway, the installers are more-or-less standard for a lot of things. Just swap one word. EG, to install gaim:
Gentoo - emerge gaim
Mandrake - urpmi gaim
Debian - apt-get install gaim
(and many other examples, I know.)
I mean, it's really difficult for it to get any simpler.
So, you better be SURE you're willing to do such a thing, so making more effort involved is helpful.
Bob never dies, does he?
That is BRILLIANT.
The /usr/bin, /etc, /usr/man, and so on system that *nix has used is a flaw in the design: necessary to avoid searching 10,000 dirs in the path, as an above post said, but problematic for maintenance and not helpful to users looking for program associativity.
packaging is a partial solution, but not a whole one, and introduces flaws of its own. Putting each application in its own directory, as ROX's AppDirs, GNU Stow, and GoboLinux do, is the proper way to do things. The problems introduced are how to find the thing in your path, and getting the vast amount of existing code to work in the new system without having to be changed (which is, after all, one of the problem-causers of the packages.)
ROX just uses GUI, so it doesn't deal with the path issue, and has to repackage anyway. Not a solution.
Stow uses symlinks to deal with the path, with an intelligent system to automatically remove symlinks to applications that have been removed. It can be used with any package using autoconf, the vast majority out there, so no repackaging necessary.
GoboLinux has an even more radical modification to the standard hierarchy. I believe that it also uses symlinks for the path.
If you want multiple versions, one of them is going to be the one that gets called by the app's name, you can't avoid that. I'd probably make a system where it selects the latest one.
This just answers the problem with performance hits by traversing a crapload of path directories. If you have a script to symlink everything after any installation, the problem goes away.
Of course, part of the point of zeroinstall is that nothing is really INSTALLED in the first place, just cached on your system. So uninstallation is sort of a moot point -- you can delete all the files in your cache if you want, and the programs are just as accessible as before.
Incidentally, I didn't say the stuff you quoted.
ln -s /opt/*/bin/* /usr/bin/
You can upgrade to new versions with bugfixes and security fixes without recompiling every single program on your system.
This means, for example, that "uninstalling" is simply deleting one folder, and upgrading in place is sublimely easy.
It doesn't mean that libraries from other programs won't still be necessary. But the applications ARE self-contained in their own directory, in that all the files that come with them are in one place, instead of all over.
And who the hell wants to delete all the files the program relies upon when you uninstall it? That would delete the whole operating system! You just want to get rid of everything that program ADDED, so as to avoid building up cruft. This takes care of that.
The problem with questions ensuring you're not doing something wrong is that they're actually suggesting all these cool things you can try.
You realize there's no way I can believe that.
I'm sure that my graphic calculator can update as quickly as any computer could 10 years ago, and my graphing calculator can move far too quickly to be read.
Then the slashdot effect would be no more!
Offtopic, but bullshit. RMS has given up dozens of chances to have more power, influence, and money in order to stick to his principles and work for freedom. Whether you agree with those principles or not, you can't claim he hasn't served them completely unswervingly.
It's a joke.