I have been thinking about switching to Ratpoison but I think it would be better for existing window managers to have an easily-accessible full screen mode - then you get the best of both worlds. There are some apps (the Gimp?) where a single window isn't really what you need.
Ratpoison's key bindings seemed a bit obscure, even if they do follow ancient Unix conventions. Couldn't people agree that Alt-Tab is now the de facto standard to switch between apps?
If there is a patch out there to add a full screen mode to Icewm, I'd never need to use anything else.
If you want to switch between console applications but you don't need a 'windowing' environment, you can use screen(1). What I do is this on every ssh login:
% exec screen -E '^Z^Z' -D -R
This brings up my applications exactly how I left them last time. Then C-z c starts a new screen, C-z 0 through C-z 9 switches between screens, C-z C-z sends a literal ^Z, and C-z d disconnects. I normally have pine running in terminal zero, XEmacs in terminal one, then top(1) and maybe a shell in two more terminals. This is much handier than having to start applications every time you log in, and essential over a noisy modem line where the ssh connection might suddenly cut out. If it does, just reconnect, run the above command and everything is just as you left it.
Speaking of Emacs, you can do most things inside that including making shell and terminal buffers, so in a way it provides a windowing system like Twin.
Re:Journaling File System: for those who don't kno
on
Looking at Longhorn
·
· Score: 1
You're right, locking could be a real pain with such a transactional filesystem. For read-only access I think it would be okay, you could use multi-version concurrency control like Oracle and Postgres. But for multiple programs that want to open some files read-write...
Still is this any worse than using advisory locking, which the programs should be doing anyway?
Re:Journaling File System: for those who don't kno
on
Looking at Longhorn
·
· Score: 1
Yes, you're right, the business with renaming the existing file to a backup filename and then writing a new one is not safe. It could happen that you rename/etc/passwd to/etc/passwd~ but then there is no disk space to write the new version.
However, what you propose is technically not changing the contents of the existing 'file' but making a new file which happens to be linked as the same pathname. Whether this really matters, I don't know for sure - it would break if you were writing to a named pipe, for example, but that is pretty unusual for an application. It would also break with symlinks, and destroy hard links (if you do 'ln a b' then save a new copy of 'a', your renaming scheme would make 'a' and 'b' point to different files).
But it might be the least bad option to do it this way because the most important thing is to guarantee that data is not lost. Niceties about filenames versus files and different kinds of links can be ignored if necessary.
Still, with a transactional filesystem the code could be a lot simpler: begin transaction, write the new file contents, end transaction.
Re:Journaling File System: for those who don't kno
on
Looking at Longhorn
·
· Score: 4, Interesting
Well, ext3 has the data=journal option which journals _everything_ including file contents. There is no disk write cache.
About this 'transaction based' stuff... the question is does any user application support transactions? If I run 'rm *.o' in a directory and the system crashes halfway through the rm command, is the state rolled back to what it was before the command started? I doubt it. Each individual unlink() call might count as a transaction, but unlink() is supposed to be atomic anyway.
It would be neat if filesystem transactions were available to applications. For example, take the most obvious way to save a file that is currently open in an editor: truncate the file and write it out again. Without transactions this is horribly unsafe, the system might crash after truncating or there just might not be enough disk space to write the new version. But if you could write code to do:
it would be just fine. (Of course, you'd need to check the return value from end_transaction() to make sure everything went okay... you might even check the individual ftruncate() and write() calls in order to bail out early.)
Similarly, shell commands could be an individual transaction. So if you said 'tar x archive.tar' then it would be guaranteed that either the whole archive unpacks successfully, or the filesystem is untouched. Who knows, this might even make shell scripts a reliable way to write small programs.
Even a simple configure script can easilly check if a library is available.
True, I guess. But as you know, most configure scripts (especially autoconf ones) do all sorts of devious and complex things to look for libraries. That stuff has its place, but for package installation it seems cleaner to keep track of everything that is installed, and then you can quickly give a yes or no answer to 'is libfoo installed?'. I imagine that if managing a mixed RPM / hand-rolled system had been an explicit design goal of RPM or other package manager, it might have some way of checking these things.
Hang on a minute - ISTR that RPM _does_ have some way to check library dependencies based on filename and not on package name. So you can say 'I require libfoo.1.so' rather than 'I require the foolib package'. Ah, but the trouble is that this check is made against the RPM database rather than the filesystem.
It would be an interesting project to modify RPM so that as well as the package database it could look at the current filesystem to satisfy dependencies. But the trouble is being unable to track them fully. This is what I meant with the 'check every 24 hours' suggestion (which wasn't serious): if RPM did use some file in/usr/local to satisfy a dependency, it has no way of checking that the file will still be there later. Whereas if the library itself is under package management, it won't be removed if there are applications that depend on it. In other words, RPM wants to ensure that if a package is installed then it works and will remain working. Depending on files outside package management would not let you guarantee that property.
In other words I am saying that RPM wants to check dependencies during package installation but also during package uninstallation. OTOH, many users would be happy to do without that if it made life easier for installing mixed RPMs and 'make install' stuff.
That's not the job of the packager. You can always just do an ldd gdm and get a nice list of the libraries it depends on.
Here I must disagree. Just as a reasonable API will document the preconditions that must be met before calling a function, so a well-built package should always state what it requires from the system in order to run. Yes, I could run ldd myself and examine entrails to work out what extra packages to install, but I shouldn't have to - let the machine do the work of downloading and installing the necessary dependencies. And the mythical 'Grandma' certainly shouldn't have to. My feeling is that a package should either install and work immediately, or refuse to install. Installing a package in a broken state is Wrong.
Package installation is a simple prospect on the Windows platform for the simple reason that the platform has little diversity.
WTF? Package installation on Windows is anything but simple. Every app has its own installer, which is a program you have to run (so there's no way to unpack an untrusted package to inspect the files in it, for example - you just have to run the.exe and trust it won't trash your system). The installer can do any strange thing it likes and often will. There are two separate install destinations to keep track of, the filesystem and the registry, and if you delete the files from one you probably won't remove the app from the other.
Microsoft has taken steps to fix this with its own Windows package format, I think. And there is now a common 'uninstall software' part of Control Panel - but I think that is again just a wrapper around a different executable for each application.
And finally, the differences between Win95 and Win2k are rather greater than those between most modern Linux distributions. Although I admit that many of these differences will not affect installers, because they are more under the hood.
You think RPM should grovel around in the filesystem to see whether a library is installed? Well, it's possible, but what happens when you want to remove that library or perhaps install it in a different place (/opt versus/usr/local, or whatever)? Should RPM re-scan the filesystem every 24 hours to check that random files which are depended on by packages are still there and haven't moved? It is surely saner to have the library itself under package management as well.
I see your point - RPM and other package managers are something of a bondage-and-discipline, all-or-nothing system. RPM is rather awkward to use when you want to have a mixture of automatically and manually installed files. But there is always the --force option if you wish to ignore its warnings, install anyway and check the dependencies yourself: it is no worse than unpacking a binary tarball into/usr/local/, anyway. And if you do choose to go the 'RPM way', the dependency tracking can be very useful, particularly for automated or unattended package installation.
Part of your post seems like the common error of blaming the messenger. RPM is telling you that some dependencies are needed: if you choose to ignore it, that's up to you. But using a different means to install packages doesn't make the dependencies go away.
(On Slackware, for example, I installed gdm and it didn't work. I had to install gnome-libs, which is reasonable, and then a whole bunch of other stuff including sound support (on a machine with no soundcard). And I had to find these packages by hand, because the installer gave no help in tracking what libraries were needed by gdm. Personally, I'd rather let the machine do some of the work and catch these problems early, rather than installing a package which then turns out to be broken.)
On the 'only one version' - yes, a problem, but one that's common to most binary-package systems, even Slackware's.tgz. Ports and compiling from source are one way to give more flexibility, but you can also make your own custom spec files for RPM packages fairly easily and build your own RPMs from source. (Whether this is worth the effort depends on whether you have a single machine or a whole network to update, and whether you want to use RPM to track installations or just install manually.)
I dunno - in a way, being 'anal-retentive' about packages required is a good thing, it's good to list every itty bitty thing that is needed for the package to work, because you know that otherwise somebody somewhere will try to install on a system that doesn't have/bin/true and the package will break. This is the same principle as checking the return value of every system call, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers.
But I see your point about specifying a package as 'required' even though it is just 'nice to have'. Debian works around this with its weak dependencies. But another approach would be to split off these extra features into separate pseudo-packages. So you could install 'XFree86' which doesn't have many dependencies, and the pseudo-package 'XFree86-drm' requires XFree86 and kernel-drm, and turns on OpenGL acceleration.
For example, RPM, when building a package likes to list the library dependancies for the software in the package, but also the libraries that that libraries depend on. (Which is why sometimes you see packages with a dependancy on libopenGL.x or so. That lib is not on most people's machines. It's a case of RPM picking up a dependancy on part of the nVidia drivers installed on the build machine.)
Must be a bug in the 'find-requires' script that comes with rpm. I wonder if Red Hat knows about it?
Why does everyone feel the need to insert 'infidels' into those oh-so-funny Information Minister quotations? I don't think he ever spoke in those terms, any more than Rumsfeld would.
Also the dependencies suck rocks. I wanted to build a minimal setup and get it working, so I decided to install links. Bad move. It pulled in svgalib (??), most of X and about a million fonts - for a *text mode* browser.
Hmm, this seems to ignore one of the big advantages of an always-build-from-source distribution. If you were using Debian or RedHat and the links package required svgalib, I'd think 'fair enough: it was probably built with the svgalib drivers'. But if you are building from source there should be the choice of using svgalib or not.
Compile-time feature choices aren't handled very well by most package managers. The usual approach is to turn on every possible feature, but this leads to some odd dependencies as you observed (on my Slackware box I needed to install the Enlightenment sound daemon to get gdm working). Maybe a better approach would be to split the features into pseudo-packages. Something like:
% inst links
[builds and installs links with minimal features]
% inst links-svga
[rebuilds links with svgalib support and installs that - also installs svgalib if needed]
% inst links-x11
[ditto for X11 support]
% uninst links-svga
[turns off svgalib support and rebuilds links yet again, so now it has X11 support but no svga]
Alternatively the links package could be split into a bunch of libraries (links_svgalib_driver.so, etc etc) which it checks for at run time. Then the links-svga package would contain that library. But this approach requires changes to the application.
You could. If an application were distributed as a bunch of object files then you could relink it. Or if it statically linked with zlib because it had its own copy of zlib in the source tree, you could patch that zlib, type 'make' and effectively do a relink because all the non-zlib-related object files would be reused.
But much easier to build the apps with dynamic linking to start with. Then the program links with its libraries every time it starts, so you just need to replace the library in a central location and the job is done. (OK, restarting some running processes might be necessary if you want to start using the new library *right now*.)
a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname.
Or at the very least, updated the soname when the interface changes. If a library author doesn't want to provide stable APIs (and there can be legitimate reasons for this, as when a library was originally part of an application and then other people started using it 'clandestinely' - I think rpm itself had a library like this) then at least they can bump the number with each change to the header files.
On the whole I think library authors do maintain backwards compatibility within a major version number, it's not that bad. There's certainly no reason for an app to statically link or include its own private pile of shared objects.
If an application needs a particular version of the library, it can say so. The package can say 'I need libfred1-1.8 or later'. Then if a new release of libfred is not compatible with that version, it gets packaged as libfred2, libfred3 and so on. There's no need to resort to multiple library copies just for this. Let the machine do the work - let the package manager install several libfreds if they are needed.
'If libthingy needs to be updated, the install procedure should do a search and find all instances of the library, back up existing versions and then update all of them.' - this sounds crazy to me, if you start ferreting around and updating libraries, even those that 'belong' to applications, then you might as well have used a central location to start with.
For well-behaved packages, your method shouldn't be needed: you can just tell them 'make install DESTDIR=/tmp/aaa' and then look at what is in that directory.
Hmm, the kernel has a good reason to statically link zlib but the applications? Red Hat could have made sure they were dynamically linked with zlib when packaging them. This would have reduced the number of errata they had to issue later on.
Emerge is nothing special. 'rpm --rebuild whatever-1.2.3.src.rpm', come back in a few minutes and *poof* a freshly built package.
Although I will admit, you need to have the BuildRequires packages installed - rpm tells you if they're not, but won't download and install them automatically... some tool like urpmi or apt-rpm would be needed for that part.
But some of the problems another person mentioned with emerge can sometimes apply to rpm --rebuild too. That is, a package doesn't state its build dependencies fully, so you try to build it and it craps out for lack of some header file. The package's author should have specified the library used with a BuildRequires: line in the spec file, then this can be checked and reported friendly before the build starts.
'./configure && make install' is not an installation process. It's the first stage in building some sources and making them into a package such as an RPM, Debian package or Slackware.tgz. Then you use your system's package manager to install, and it tracks where the files go so you can easily uninstall later.
People who want to change the build process to make 'installation' easier are barking up the wrong tree. Building the software from source is something that the packager should do, or at least the package manager (rpm, dpkg, Gentoo's emerge) should encapsulate that step in a single 'build' command. Installation means installing the resulting package on your system, keeping track of its dependencies automatically, adding the application to system menus and so on.
True, someone has to do the initial job of making a source package, recipe or spec file. But that is only once per distro or once between fairly similar distros.
Static linking is a seriously bad idea. Part of the job of a packager is to arrange the app so it doesn't include its own copies of packages but uses the standard ones available on the system (and states these dependencies explicitly, so the installer can resolve them automatically).
Take zlib as an example of a library that is commonly used. When a security hole was found in zlib a few months ago, dynamically linked packages can be fixed by replacing the zlib library. This is as it should be. But those that for some reason disdained to use the standard installed libz.so and insisted on static linking needed to be rebuilt and reinstalled.
(OK I have mostly just restated what the parent post said, so mod him up and not me.)
Quite apart from the stupidity of having ten different copies of the same library loaded into memory rather than sharing it between processes (and RAM may be cheap, but not cheap enough that you want to do this... consider also the CPU cache).
A similar problem applies to an app which includes copies of libraries in its own package. This is a bit like static linking in that it too means more work to update a library and higher disk/RAM usage.
Finally there is a philosophical issue. What right has FooEdit got to say that it needs libfred exactly version 1.823.281a3, and not only that exact version but the exact binary image included in the package? The app should be written to a published interface of the library and then work with whatever version is installed. If the interface provided by libfred changes, the new version should be installed with a different soname, that is libfred.so.2 rather than libfred.so.1. It's true that some libraries make backwards-incompatible changes without updating the sonames, but the answer then is to fix those libraries.
There are an infinite number of random strings but also an infinite number that will trigger a particular bug (it's very rare to find a bug that manifests itself on one and one only input file... if you embedded that dodgy HTML form in a larger page it would still crash IE).
Fuzz testing is a useful tool, of course it can't guarantee to catch all bugs, but it can often catch a worthwhile few. You just leave the machine running overnight and see what it comes up with. If ten million randomly created strings of junk HTML don't cause any problem, you can be reasonably confident that the code is of high quality, although of course you can't _prove_ that it is uncrashable this way.
On the other hand, one of the big advantages of free software is that you can find a *named person* responsible for each line of code and if necessary contact that person directly, rather than some moronic 'helpline'. So the list of credits should definitely be there... But I don't agree that this goal, however desirable, should be enforced by licensing.
Why does an organic grower have to use cinnamon oil or other 'it's poisonous to plants, but it doesn't come from petrochemical sources so that makes it okay' kind of weedkiller? Can't they build a robot that physically picks the weeds instead? Even if it can't uproot them it could cut the stems, and that would be good enough if done regularly.
Or you could just genetically engineer your crop so that it recognizes surrounding weeds and reaches out pincers to destroy them itself.
I just suddenly think of the mildly disappointing 'Blackadder Back and Forth' time-travel Y2k episode, and how much better it would have been if they'd commissioned a new Dr Who episode instead. I think Atkinson might do a good job as one of the 'bad' Time Lords, the Master / Valyard / etc.
Slashdot Mirror
I have been thinking about switching to Ratpoison but I think it would be better for existing window managers to have an easily-accessible full screen mode - then you get the best of both worlds. There are some apps (the Gimp?) where a single window isn't really what you need.
Ratpoison's key bindings seemed a bit obscure, even if they do follow ancient Unix conventions. Couldn't people agree that Alt-Tab is now the de facto standard to switch between apps?
If there is a patch out there to add a full screen mode to Icewm, I'd never need to use anything else.
If you want to switch between console applications but you don't need a 'windowing' environment, you can use screen(1). What I do is this on every ssh login:
% exec screen -E '^Z^Z' -D -R
This brings up my applications exactly how I left them last time. Then C-z c starts a new screen, C-z 0 through C-z 9 switches between screens, C-z C-z sends a literal ^Z, and C-z d disconnects. I normally have pine running in terminal zero, XEmacs in terminal one, then top(1) and maybe a shell in two more terminals. This is much handier than having to start applications every time you log in, and essential over a noisy modem line where the ssh connection might suddenly cut out. If it does, just reconnect, run the above command and everything is just as you left it.
Speaking of Emacs, you can do most things inside that including making shell and terminal buffers, so in a way it provides a windowing system like Twin.
You're right, locking could be a real pain with such a transactional filesystem. For read-only access I think it would be okay, you could use multi-version concurrency control like Oracle and Postgres. But for multiple programs that want to open some files read-write...
Still is this any worse than using advisory locking, which the programs should be doing anyway?
Yes, you're right, the business with renaming the existing file to a backup filename and then writing a new one is not safe. It could happen that you rename /etc/passwd to /etc/passwd~ but then there is no disk space to write the new version.
However, what you propose is technically not changing the contents of the existing 'file' but making a new file which happens to be linked as the same pathname. Whether this really matters, I don't know for sure - it would break if you were writing to a named pipe, for example, but that is pretty unusual for an application. It would also break with symlinks, and destroy hard links (if you do 'ln a b' then save a new copy of 'a', your renaming scheme would make 'a' and 'b' point to different files).
But it might be the least bad option to do it this way because the most important thing is to guarantee that data is not lost. Niceties about filenames versus files and different kinds of links can be ignored if necessary.
Still, with a transactional filesystem the code could be a lot simpler: begin transaction, write the new file contents, end transaction.
Well, ext3 has the data=journal option which journals _everything_ including file contents. There is no disk write cache.
About this 'transaction based' stuff... the question is does any user application support transactions? If I run 'rm *.o' in a directory and the system crashes halfway through the rm command, is the state rolled back to what it was before the command started? I doubt it. Each individual unlink() call might count as a transaction, but unlink() is supposed to be atomic anyway.
It would be neat if filesystem transactions were available to applications. For example, take the most obvious way to save a file that is currently open in an editor: truncate the file and write it out again. Without transactions this is horribly unsafe, the system might crash after truncating or there just might not be enough disk space to write the new version. But if you could write code to do:
begin_transaction();
ftruncate(fh, 0);
write(fh, buf, size);
end_transaction();
it would be just fine. (Of course, you'd need to check the return value from end_transaction() to make sure everything went okay... you might even check the individual ftruncate() and write() calls in order to bail out early.)
Similarly, shell commands could be an individual transaction. So if you said 'tar x archive.tar' then it would be guaranteed that either the whole archive unpacks successfully, or the filesystem is untouched. Who knows, this might even make shell scripts a reliable way to write small programs.
True, I guess. But as you know, most configure scripts (especially autoconf ones) do all sorts of devious and complex things to look for libraries. That stuff has its place, but for package installation it seems cleaner to keep track of everything that is installed, and then you can quickly give a yes or no answer to 'is libfoo installed?'. I imagine that if managing a mixed RPM / hand-rolled system had been an explicit design goal of RPM or other package manager, it might have some way of checking these things.
Hang on a minute - ISTR that RPM _does_ have some way to check library dependencies based on filename and not on package name. So you can say 'I require libfoo.1.so' rather than 'I require the foolib package'. Ah, but the trouble is that this check is made against the RPM database rather than the filesystem.
It would be an interesting project to modify RPM so that as well as the package database it could look at the current filesystem to satisfy dependencies. But the trouble is being unable to track them fully. This is what I meant with the 'check every 24 hours' suggestion (which wasn't serious): if RPM did use some file in /usr/local to satisfy a dependency, it has no way of checking that the file will still be there later. Whereas if the library itself is under package management, it won't be removed if there are applications that depend on it. In other words, RPM wants to ensure that if a package is installed then it works and will remain working. Depending on files outside package management would not let you guarantee that property.
In other words I am saying that RPM wants to check dependencies during package installation but also during package uninstallation. OTOH, many users would be happy to do without that if it made life easier for installing mixed RPMs and 'make install' stuff.
Here I must disagree. Just as a reasonable API will document the preconditions that must be met before calling a function, so a well-built package should always state what it requires from the system in order to run. Yes, I could run ldd myself and examine entrails to work out what extra packages to install, but I shouldn't have to - let the machine do the work of downloading and installing the necessary dependencies. And the mythical 'Grandma' certainly shouldn't have to. My feeling is that a package should either install and work immediately, or refuse to install. Installing a package in a broken state is Wrong.
WTF? Package installation on Windows is anything but simple. Every app has its own installer, which is a program you have to run (so there's no way to unpack an untrusted package to inspect the files in it, for example - you just have to run the .exe and trust it won't trash your system). The installer can do any strange thing it likes and often will. There are two separate install destinations to keep track of, the filesystem and the registry, and if you delete the files from one you probably won't remove the app from the other.
Microsoft has taken steps to fix this with its own Windows package format, I think. And there is now a common 'uninstall software' part of Control Panel - but I think that is again just a wrapper around a different executable for each application.
And finally, the differences between Win95 and Win2k are rather greater than those between most modern Linux distributions. Although I admit that many of these differences will not affect installers, because they are more under the hood.
You think RPM should grovel around in the filesystem to see whether a library is installed? Well, it's possible, but what happens when you want to remove that library or perhaps install it in a different place (/opt versus /usr/local, or whatever)? Should RPM re-scan the filesystem every 24 hours to check that random files which are depended on by packages are still there and haven't moved? It is surely saner to have the library itself under package management as well.
/usr/local/, anyway. And if you do choose to go the 'RPM way', the dependency tracking can be very useful, particularly for automated or unattended package installation.
.tgz. Ports and compiling from source are one way to give more flexibility, but you can also make your own custom spec files for RPM packages fairly easily and build your own RPMs from source. (Whether this is worth the effort depends on whether you have a single machine or a whole network to update, and whether you want to use RPM to track installations or just install manually.)
I see your point - RPM and other package managers are something of a bondage-and-discipline, all-or-nothing system. RPM is rather awkward to use when you want to have a mixture of automatically and manually installed files. But there is always the --force option if you wish to ignore its warnings, install anyway and check the dependencies yourself: it is no worse than unpacking a binary tarball into
Part of your post seems like the common error of blaming the messenger. RPM is telling you that some dependencies are needed: if you choose to ignore it, that's up to you. But using a different means to install packages doesn't make the dependencies go away.
(On Slackware, for example, I installed gdm and it didn't work. I had to install gnome-libs, which is reasonable, and then a whole bunch of other stuff including sound support (on a machine with no soundcard). And I had to find these packages by hand, because the installer gave no help in tracking what libraries were needed by gdm. Personally, I'd rather let the machine do some of the work and catch these problems early, rather than installing a package which then turns out to be broken.)
On the 'only one version' - yes, a problem, but one that's common to most binary-package systems, even Slackware's
I dunno - in a way, being 'anal-retentive' about packages required is a good thing, it's good to list every itty bitty thing that is needed for the package to work, because you know that otherwise somebody somewhere will try to install on a system that doesn't have /bin/true and the package will break. This is the same principle as checking the return value of every system call, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers.
But I see your point about specifying a package as 'required' even though it is just 'nice to have'. Debian works around this with its weak dependencies. But another approach would be to split off these extra features into separate pseudo-packages. So you could install 'XFree86' which doesn't have many dependencies, and the pseudo-package 'XFree86-drm' requires XFree86 and kernel-drm, and turns on OpenGL acceleration.
Must be a bug in the 'find-requires' script that comes with rpm. I wonder if Red Hat knows about it?
Why does everyone feel the need to insert 'infidels' into those oh-so-funny Information Minister quotations? I don't think he ever spoke in those terms, any more than Rumsfeld would.
Hmm, this seems to ignore one of the big advantages of an always-build-from-source distribution. If you were using Debian or RedHat and the links package required svgalib, I'd think 'fair enough: it was probably built with the svgalib drivers'. But if you are building from source there should be the choice of using svgalib or not.
Compile-time feature choices aren't handled very well by most package managers. The usual approach is to turn on every possible feature, but this leads to some odd dependencies as you observed (on my Slackware box I needed to install the Enlightenment sound daemon to get gdm working). Maybe a better approach would be to split the features into pseudo-packages. Something like:
% inst links[builds and installs links with minimal features]
% inst links-svga
[rebuilds links with svgalib support and installs that - also installs svgalib if needed]
% inst links-x11
[ditto for X11 support]
% uninst links-svga
[turns off svgalib support and rebuilds links yet again, so now it has X11 support but no svga]
Alternatively the links package could be split into a bunch of libraries (links_svgalib_driver.so, etc etc) which it checks for at run time. Then the links-svga package would contain that library. But this approach requires changes to the application.
You could. If an application were distributed as a bunch of object files then you could relink it. Or if it statically linked with zlib because it had its own copy of zlib in the source tree, you could patch that zlib, type 'make' and effectively do a relink because all the non-zlib-related object files would be reused.
But much easier to build the apps with dynamic linking to start with. Then the program links with its libraries every time it starts, so you just need to replace the library in a central location and the job is done. (OK, restarting some running processes might be necessary if you want to start using the new library *right now*.)
Or at the very least, updated the soname when the interface changes. If a library author doesn't want to provide stable APIs (and there can be legitimate reasons for this, as when a library was originally part of an application and then other people started using it 'clandestinely' - I think rpm itself had a library like this) then at least they can bump the number with each change to the header files.
On the whole I think library authors do maintain backwards compatibility within a major version number, it's not that bad. There's certainly no reason for an app to statically link or include its own private pile of shared objects.
If an application needs a particular version of the library, it can say so. The package can say 'I need libfred1-1.8 or later'. Then if a new release of libfred is not compatible with that version, it gets packaged as libfred2, libfred3 and so on. There's no need to resort to multiple library copies just for this. Let the machine do the work - let the package manager install several libfreds if they are needed.
'If libthingy needs to be updated, the install procedure should do a search and find all instances of the library, back up existing versions and then update all of them.' - this sounds crazy to me, if you start ferreting around and updating libraries, even those that 'belong' to applications, then you might as well have used a central location to start with.
For well-behaved packages, your method shouldn't be needed: you can just tell them 'make install DESTDIR=/tmp/aaa' and then look at what is in that directory.
More than 120 Dutch guilders? Wow! It's a good job you didn't express the amount only in those obscure euros.
Hmm, the kernel has a good reason to statically link zlib but the applications? Red Hat could have made sure they were dynamically linked with zlib when packaging them. This would have reduced the number of errata they had to issue later on.
Emerge is nothing special. 'rpm --rebuild whatever-1.2.3.src.rpm', come back in a few minutes and *poof* a freshly built package.
Although I will admit, you need to have the BuildRequires packages installed - rpm tells you if they're not, but won't download and install them automatically... some tool like urpmi or apt-rpm would be needed for that part.
But some of the problems another person mentioned with emerge can sometimes apply to rpm --rebuild too. That is, a package doesn't state its build dependencies fully, so you try to build it and it craps out for lack of some header file. The package's author should have specified the library used with a BuildRequires: line in the spec file, then this can be checked and reported friendly before the build starts.
'./configure && make install' is not an installation process. It's the first stage in building some sources and making them into a package such as an RPM, Debian package or Slackware .tgz. Then you use your system's package manager to install, and it tracks where the files go so you can easily uninstall later.
People who want to change the build process to make 'installation' easier are barking up the wrong tree. Building the software from source is something that the packager should do, or at least the package manager (rpm, dpkg, Gentoo's emerge) should encapsulate that step in a single 'build' command. Installation means installing the resulting package on your system, keeping track of its dependencies automatically, adding the application to system menus and so on.
True, someone has to do the initial job of making a source package, recipe or spec file. But that is only once per distro or once between fairly similar distros.
Static linking is a seriously bad idea. Part of the job of a packager is to arrange the app so it doesn't include its own copies of packages but uses the standard ones available on the system (and states these dependencies explicitly, so the installer can resolve them automatically).
Take zlib as an example of a library that is commonly used. When a security hole was found in zlib a few months ago, dynamically linked packages can be fixed by replacing the zlib library. This is as it should be. But those that for some reason disdained to use the standard installed libz.so and insisted on static linking needed to be rebuilt and reinstalled.
(OK I have mostly just restated what the parent post said, so mod him up and not me.)
Quite apart from the stupidity of having ten different copies of the same library loaded into memory rather than sharing it between processes (and RAM may be cheap, but not cheap enough that you want to do this... consider also the CPU cache).
A similar problem applies to an app which includes copies of libraries in its own package. This is a bit like static linking in that it too means more work to update a library and higher disk/RAM usage.
Finally there is a philosophical issue. What right has FooEdit got to say that it needs libfred exactly version 1.823.281a3, and not only that exact version but the exact binary image included in the package? The app should be written to a published interface of the library and then work with whatever version is installed. If the interface provided by libfred changes, the new version should be installed with a different soname, that is libfred.so.2 rather than libfred.so.1. It's true that some libraries make backwards-incompatible changes without updating the sonames, but the answer then is to fix those libraries.
There are an infinite number of random strings but also an infinite number that will trigger a particular bug (it's very rare to find a bug that manifests itself on one and one only input file... if you embedded that dodgy HTML form in a larger page it would still crash IE).
Fuzz testing is a useful tool, of course it can't guarantee to catch all bugs, but it can often catch a worthwhile few. You just leave the machine running overnight and see what it comes up with. If ten million randomly created strings of junk HTML don't cause any problem, you can be reasonably confident that the code is of high quality, although of course you can't _prove_ that it is uncrashable this way.
On the other hand, one of the big advantages of free software is that you can find a *named person* responsible for each line of code and if necessary contact that person directly, rather than some moronic 'helpline'. So the list of credits should definitely be there... But I don't agree that this goal, however desirable, should be enforced by licensing.
Why does an organic grower have to use cinnamon oil or other 'it's poisonous to plants, but it doesn't come from petrochemical sources so that makes it okay' kind of weedkiller? Can't they build a robot that physically picks the weeds instead? Even if it can't uproot them it could cut the stems, and that would be good enough if done regularly.
Or you could just genetically engineer your crop so that it recognizes surrounding weeds and reaches out pincers to destroy them itself.
I just suddenly think of the mildly disappointing 'Blackadder Back and Forth' time-travel Y2k episode, and how much better it would have been if they'd commissioned a new Dr Who episode instead. I think Atkinson might do a good job as one of the 'bad' Time Lords, the Master / Valyard / etc.