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.
Yes it should be automated to install software, especially in the case of Java. Anybody wanting to run LimeWire has to download a 20MB file, then mess around in a terminal. Not good. Though Synaptic is close to full automation....
If you're happy and you know it read my blog
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.
emerge
Doesn't get any simpler than that. Come back in a minute to 12 hours (Depending on the package), and *poof* new software. Ditto BSD ports.
TODO: Something witty here...
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
In descending order of (my) preference:
Nicholas Petreley writes:
Linking libthingy statically into application foo does not preclude the sharing. Each of the instances of application foo will still share all the code of that executable. So if libthingy takes up 5K, and you launch 10 instances, that does not mean the other 9 will take up separate memory. Even statically linked, as long as the executable is in a shared linking format like ELF, which generally will be the case, each process VM will be mapped from the same file. So we're still looking at around 5K of real memory occupancy for even 1000 instances of application foo. The exact details will depend on how many pages get hit by the run-time linker when it has to make some address relocations. With static linking there is less of that, anyway. Of course if libthingy has its own static buffers space it modified (bad programming practice in the best case, a disaster waiting to happen in multithreading) then the affected pages will be copied-on-write and no longer be shared (so don't do that when developing any library code).
Where a shared library gives an advantage is when there are many different applications all using the same library. So the "shared" part of "shared library" means sharing between completely different executable files. Sharing between multiple instances of the same executable file is already done by the virtual memory system (less any CoW).
The author's next point about sharing between other applications is where the size of libthingy becomes relevant. His point being that if libthingy is only 5K, you're only saving 45K by making it a shared (between different executables) library. So that's 45K more disk space used up and 45K more RAM used up when loading those 10 different applications in memory. The idea is the hassle savings trumps the disk and memory savings. The situation favors the author's position to use static linking for smaller less universal libraries even more than he realized (or at least wrote about).
For a desktop computer, you're going to see more applications, and fewer instances of each, loaded. So here, the issue really is sharing between applications. But the point remains valid regarding small specialty libraries that get used by only a few (such as 10) applications. However, on a server computer, there may well be hundreds of instances of the same application, and perhaps very few applications. It might be a mail server running 1000 instances of the SMTP daemon trying to sift through a spam attack. Even if the SMTP code is built statically, those 1000 instances still share unmodified memory mapped from the executable file.
now we need to go OSS in diesel cars
Basically your suggestion amounts to building a binary package from a source package as a stage to having it actually installed. While that is something I actually do (using Slackware package.tgz format), and even recommend it to many people, it's not necessarily suitable for everyone or every purpose. I still run an experimental machine where everything I install beyond the distribution is installed from source. That's good for quickly checking out some new package to see if it really does what the blurbs imply (quite often this is not the case).
Building your own binary packages in whatever is your preferred package format is definitely a plus when managing lots of computers. And this way you have the plus that the MD5 checksum of all the binary files will be the same across multiple computers, making it easy to check for trojans.
As for making the recipe or spec file, I've actually figured out a way to do that when I build source packages into binary packages. It's slow but it works. I first construct a subdirectory consisting of a copy (never a hard link or bind mount) of the system root tree (or just enough to accompish the building). Then I scan that directory modifying every file object to some weird date way in the past. For symlinks which cannot have their date changed, I just note the current time as all new symlinks will have a timestamp after this. Then the installation is executed under chroot and thus will be installed within the subdirectory (as long as the package author didn't slip in some program to crack out of the chroot, which can be done easily). A rescan compares everything against the previous scan. Every file and every symlink changed or created will be detected. It's not perfect in theory (if the source package elects to not install something because it already exists in your root template, then you'll miss it), but so far I've been totally successful with it.
now we need to go OSS in diesel cars
M$OfficeXP's voice recognition component disables some WP functions. There's even an article about it in the M$ KB. Somehow this wasn't regarded as a bug or problem, so I have to consider it as left deliberately unfixed. On WinXP, even going back to a restore point before OfficeXP does not fix the problem -- OXP is allowed to clobber system files.
:)
:)
.MSI issue, depending on the Windows version under it. .MSI on Win98 doesn't clean up after itself, and leaves stuff in half-baked condition. The WP10 installer knows about the problem and has a repair option, but OmniPage10 and some others don't -- when after a couple uses the shortcuts stop working, you have to fix 'em by hand.
Back in the Win16 day, M$Office/WinWord didn't play nice with anything if it could avoid it. The trick was to install M$Office or WinWord *first*, because otherwise it would disable any other word processors it found (observationally, I'd say this was deliberate, but that was during the height of the OS/Word Processor wars, too.. remember the DRDOS and Win3.11-not-Workgroups vs OS/2 debacles?) So long as M$O/WinWord was installed *first*, nothing else ever had a problem coexisting with it.
WPWin6.0 wasn't anyone's idea of well-made, but Novell's incarnation of WPWin6.1 was pretty well fixed (tho you need the POUPDT* patch to make it play nice with Win32). I used WP6.1 extensively on my WFWG system (which was so loaded up that WFWG was maxed out, I could not install any more software!) without any problem, and I think running every program you own all at once is "normal"
"... you can't have WP and 10 on at the same time either" -- Did you mean WP8 and WP10? simultaneously installed or running? As a WP user who owns just about every version since 4.1, such things are of great interest.
If merely "installed" -- could be an
~REZ~ #43301. Who'd fake being me anyway?
If you're looking for a super-easy install, why not just use FreeBSD?
You can install it from two floppies, and installing new software is easy as:
cd
make install
Or for those who don't have "compile time" you can grab binaries off the net:
pkg_add -r new_package
I recently converted my P133 fileserver to FreeBSD and it'll never run Linux again. Whole install took 15 minutes, then about another hour getting stuff setup.
My specialty is software installation. I've written dozens of installers on a multitude of platforms. On the windoze platform, DLL happens for two reasons:
1. No backwards compatibility. All too often, new versions are released that break older programs. Even Microsoft has done this with major DLLs.
2. Stupid installer writers. You're supposed to check the version number of a file before overwriting it. All too often the file is overwritten without regard to the version numbers.
So to overcome these two problems, the smart installer coder would put all the DLLs in a private directory of the application (not in system/system32).
Of course, Microsoft came up with a new system that broke this simple fix. Registered libraries. Instead of using a specified path to get a DLL, you would ask the system to load the DLL (using registry information). The path was no longer considered. One, and only one, version of the DLL was allowed on the system, and there was no feasible way to get around this limitation. Someone came up with a fix. It would have been a major pain to implement and would require cooperation amongst the DLL coders, which isn't about to happen since the lack of cooperation was one of the core problems in the first place.
For a commercial level installer, missing libraries was absolutely unacceptable. My personal rule was to ALWAYS include dependencies in the installer package. This meant the installer was bigger and more complicated, but it guaranteed the application could be successfully installed without the user having to run off to find a missing library. Or did it? No - Microsoft decided that some libraries could not be independently distributed. The only legal means of getting the library was through the official Microsoft installer. And no suprise here, half the time the only official installer for a library was the latest version of Internet Explorer.
Requiring an upgrade to IE is a major problem for large companies. They standardize on specific software and don't allow the users to change it. Requiring a site-wide upgrade of something like IE (or the MDAC package) was not to be taken lightly. Especially when it was dicovered that the required upgrade would break other applications (back to DLL hell).
FYI, when a major customer pays your mid-sized company a couple of million dollars a year in license fees, they can definately tell you they won't upgrade IE. It's our job to come up with a work around. Too bad a measly few million paid to Microsoft wasn't enough to get them to change their ridiculous library polices.
-- Will program for bandwidth
Nice try!
but 1$ -> 45 Indian Ruppes
So you wouldn't be able to hire 1000 Indian programmers with that exchange rate.
Also your racist comments show how little you know about Indian programmers some of who are big names in the American Computer Industry.
Also almost every Indian programmer is well versed with English language and most of them can understand/write better english than you, so you won't have to hire a crappy american undergrad to do the translation work.