[News] New NVIDIA Driver, 6 GNU/Linux Distributions Released

[News] New NVIDIA Driver, 6 GNU/Linux Distributions Released

Post by Roy Schest » Mon, 14 Apr 2008 23:53:53

NVIDIA 173.08 Linux Display Driver

,----[ Quote ]
| The new NVIDIA products supported by this 173.08 binary driver update include
| the GeForce 8400, 8400GS, 9500M GS, 9600GT, 9800GTX, and 9800GX2.


A wave of new (and important release):

Nonux 4.4


Slax 6.0.5


gOS 2.9


(R)ecovery (I)s (P)ossible Linux 4.4


Berry 0.89


New kid on the block:

NixOS: A Purely Functional Linux Distribution

,----[ Quote ]
| We have implemented this model in NixOS, a non-trivial Linux distribution
| that uses the Nix package manager to build the entire system configuration
| from a purely functional specification.




,----[ Quote ]
| When someone says a recent Linux Distro is 100 times better than another
| recent Linux distro, I worry a little that schism has lead to computer
| religion. Taken on its face, examined rationally, you have to ask "how can
| that be?". They all feed off the same kernel stock, and pull in the same sets
| of office projects and same GUI projects and so forth.


[News] New NVIDIA Driver, 6 GNU/Linux Distributions Released

Post by Home » Tue, 15 Apr 2008 06:07:25

erily I say unto thee, that Roy Schestowitz spake thusly:


This looks very interesting in principle, but some of the assertions
about current package management systems are blatantly wrong:

For instance, upgrading some application might trigger an upgrade of
/usr/bin/perl, which might cause other applications to break. This
is known as the LL hellor ependency hell

Rubbish. The RPM spec file, and subsequently the local RPM database,
contains "Depends: fo> >= 2.14" type entries that would preclude this
kind of behaviour. If the installation of a new package would "break"
existing packages, then RPM will refuse to install that new package
without the "--nodeps" option. Using "--nodeps" is tantamount to saying
"I no longer wish to use RPM to manage the software on my system", much
like bypassing RPM and installing from tarballs, for example.

Having multiple profiles with parallel dependencies would not fix this
problem, unless one is prepared to reboot into different installs (since
the root dependency might drill all the way down to libc or the kernel),
and I can do that already without NixOS, or I can run multiple virtual

Similarly the paper's assertions regarding multiple versions or
supposedly conflicting software is also wrong:

~]# man alternatives

alternatives creates, removes, maintains and displays information
about the symbolic links comprising the alternatives system. The
alternatives system is a reimplementation of the Debian
alternatives system. It was rewritten primarily to remove the
dependence on perl; it is intended to be a drop in replacement
for Debian update-dependencies script. This man page is a
slightly modified version of the man page from the Debian

It is possible for several programs fulfilling the same or
similar functions to be installed on a single system at the same
time. For example, many systems have several text editors
installed at once. This gives choice to the users of a system,
allowing each to use a different editor, if desired, but makes it
difficult for a program to make a good choice of editor to invoke
if the user has not specified a particular preference.

For example:

~]# alternatives --config java

There is 2 program that provides 'java'.

Selection Command
*+ 1 /usr/lib/jvm/jre-1.7.0-icedtea/bin/java
2 /usr/lib/jvm/jre-1.5.0-gcj/bin/java

Enter to keep the current selection[+], or type selection number:

So you see it is perfectly feasible to have multiple applications,
providing the same function, with the same name, or even multiple
versions of the same application on the same system (the latter would
require a special naming convention for the RPM, and a parallel set of
"Requires" entries).

This next bit is also nonsense:

First, it is hard to guarantee that the dependency specification is
complete. If, for instance, the package calls the python program, it
will build and run fine on the build machine if it has the python
package installed, even if that package is not listed as a dependency.
However, on the end user machine python may be missing, and the package
will fail unexpectedly.

Has the author never heard