Slashdot Mirror
Petreley On Simplifying Software Installation for Linux
markcappel writes "RAM, bandwidth, and disk space are cheap while system administrator time is expensive. That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro." The summary paragraph gives some hint as to why this isn't likely to happen anytime soon.
"That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro."
Was it necessary to include the word count? It's hard enough to get slashdotters to read a small article and post intelligently, this cant help...
Autopackage comes to mind.
from the site:
* Build packages that will install on many different distros
* Packages can be interactive
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependancies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.
I just don't trust anything that bleeds for five days and doesn't die.
The first obstacle to overcome is the bad attitude many linux users have that if something is easy to install, or easy to use, it is therefore bad.
./configure
As I see it, many would like to keep the learning curve very, very steep and high to maintain their exclusivity and "leetness" if you will.
For instance, the post above mine displays the ignorant attitude that "easy to install" by definition equals "unstable software" and has only a jab at MS to cite as a reference.
That's truly sad (though that may just be a symptom of being a slashdot reader.)
As I see it, not everyone finds:
make
make install
to be intuitive, much less easy, never mind what happens if you get compiler errors, or your build environment isn't the one the package wants *cough*mplayer*cough*, or if you even have said development environment.
Nor does it mean the software is any more stable. Could be just as shitty. _That_ is a matter of the developer of the program, not the install process.
I tried it (gentoo) some time ago. After two weeks of frustration I moved back to debian.
For me it was more like
1. emerge
2 come back in 8 hours and then:
a. see whole bunch of compilation errors,
b. dependencies were not sorted out correct, so nothing works
c. combination of above
I specially liked (still do) the optimization potential (where debian is stuck at i386), but it didn't work for me.
this sig has intentionally been left blank
Thats the reason windows servers are more vulnerable to attacks, because they give you the idea that its easy to mantain them... Its the same thing saying that you dont need any pilot on an airplane (and that you can put there anyone) if you make a good autopilot engine... We need more knowledge in system administration, not more automatisms.
WARNING: Stupid Matrix reloaded spoiler in parent, in the middle of the 4th paragraph
Site slashdotted? Look here for mirrors, or even better: o
Did some of the suggestions remind anyone of the OpenStep frameworks idea?
Frameworks (very roughly) are self contained libraries containing different versions, headers, and documentation. Java jar libraries are somewhat similar.
The problem is that using frameworks requires major changes to the tool chain - autoconf et al, cc, ld etc.
Apple shipped zlib as a framework in OS X 10.0 (IIRC) but getting unix apps to use it was very difficult. Apple now only seem to use frameworks for things above the unix layer.
I suspect there are lessons to be learned from this. As another poster said, evolution rather than revolution is more likely to succeed.
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
Etc...
Who are you? The new #2 Who is #1? You are #617565. I am not a number, I am a free man! Muhahaha.
Important features of the way AmigaOS libraries worked:
* All libraries were versioned, but not on the file system level. Each library contained a version number in it's header.
* Versions of the same library were always backwards compatible. This was Law. Software using an old version of a library must continue to work on future versions. This also meant that developers had to think out thier library API beforehand (because you would have to maintain that API). Libraries could be extended though with extra functions.
* Application programs had to 'open' libraries before using them. When opening a library an application would specify the minimum version that it required of the library. (If no matching or later version was found then the program would have to exit gracefully).
* There tended to be few (compared to Linux anyway) libraries. Libraries tended to be biggish. A few big libraries instead of many tiny libraries. This made them manageable.
* The backwards compatibility rule/law for libraries meant that software could bring it's own version of a library and update the existing version of that library, but *only* if it was a more up-to-date version.
As a previous poster pointed out, a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname. I'm pretty sure that this is the way it was designed to work.
anyway, a FYI.
--
Simon