Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

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

  • Subject: Re: [News] New NVIDIA Driver, 6 GNU/Linux Distributions Released
  • From: Homer <usenet@xxxxxxxxxx>
  • Date: Sun, 13 Apr 2008 22:07:25 +0100
  • Bytes: 6973
  • In-reply-to: <1782037.ZCVxak6aI3@xxxxxxxxxxxxxxx>
  • Newsgroups: comp.os.linux.advocacy
  • Openpgp: id=BF436EC9; url=http://slated.org/files/GPG-KEY-SLATED.asc
  • References: <1782037.ZCVxak6aI3@xxxxxxxxxxxxxxx>
  • User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080226 Fedora/2.0.0.12-1.fc7 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
  • Xref: ellandroad.demon.co.uk comp.os.linux.advocacy:631948
Verily I say unto thee, that Roy Schestowitz spake thusly:

> NixOS: A Purely Functional Linux Distribution
[...]
> http://people.cs.uu.nl/andres/NixOS.pdf

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

[quote]
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 “DLL hell” or “dependency hell”.
[/quote]

Rubbish. The RPM spec file, and subsequently the local RPM database,
contains "Depends: foo >= 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
machines.

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

[quote]
~]# man alternatives

DESCRIPTION
       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’s update-dependencies script. This man page is a
       slightly modified version of the man page from the Debian
       project.

       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.
[/quote]

For example:

[quote]
~]# 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:
[/quote]

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:

[quote]
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.
[/quote]

Has the author never heard of "Buildrequires"? The circumstances he is
describing is broken SRPMs that should be fixed, not normal conditions.

Also his criticism of nominal build environments is rather obtuse. If
there is a "Buildrequires: foo-devel >= 2.4", then there will naturally
also be a corresponding "Requires: foo >= 2.4" in the resultant build,
if "foo" is actually required at all (usually but not always). Again,
I'd consider anything else a bug which should be fixed. This is not a
normal condition.

There's a lot to absorb in this highly technical paper, but from what
I've read so far it just seems to be an attempt to track configuration
changes using profiles, which in and of itself is not necessarily a bad
idea, but the implementation looks rather convoluted, and it would seem
to badly break some important aspects of Linux, such as the FHS and
prelinking. IMHO it's cracking a nut with a sledgehammer.

Personally I'd rather just backup /etc with dump, do a dist upgrade,
then restore individual configs as and when I need them. This approach
is simple and it works. The linear filesystem layout suggested by this
paper seems rather too much like MacOSX for my tastes. Indeed the entire
concept is reminiscent of the Mac-ification of UNIX. No thanks.

-- 
K.
http://slated.org

.----
| 'When it comes to knowledge, "ownership" just doesn't make sense'
|     ~ Cory Doctorow, The Guardian.  http://tinyurl.com/22bgx8
`----

Fedora release 8 (Werewolf) on sky, running kernel 2.6.23.8-63.fc8
 22:07:05 up 114 days, 18:42,  5 users,  load average: 0.00, 0.00, 0.00

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index