linux-kernel - Re: [poll] Is the megafreeze development model broken?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071113001223.GA15663@jolt.modeemi.cs.tut.fi>
Date:	Tue, 13 Nov 2007 02:12:23 +0200
From:	Tuomo Valkonen <tuomov@....fi>
To:	Matthias Schniedermeyer <ms@...d.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [poll] Is the megafreeze development model broken?

On 2007-11-13 00:39 +0100, Matthias Schniedermeyer wrote:
> That's the problem(tm).
> 
> Contrary to Closed Source Software all(!) OSS-Software is 
> interdependent. There is no "Stand-Alone"-Software. There is always at 
> least "libc". (Scripts depend on a script-interpreter, which in turn 
> depends at least on libc, so there is nothing(tm) that doesn't depend on 
> libc)

Closed source software also depends on other software, but the
non-standard dependencies are usually distributed along with the
main program, which are more often big applications than small 
combinable utilities, than in FOSS.

In FOSS, OTOH, dependencies are no distributed along with the main
software, and now when programs depend on different versions of
a library, the brain-damaged all-in-one-basket *nix file system 
hierarchy results in trouble.

An intermediate is needed between those two extremes: separately
distributed dependencies that do not conflict. If packages lived 
in their own directories, and were relocatable, multiple versions
could more easily coexist, and packages specify the versions they
work with (or rather, more abstract cryptographically identified
capabilities that they require). Of course, there are other 
potential conflicts besides library versions and their locations,
such as the protocol used by some essential system daemon, but 
these are encountered far less often, and could sometimes be 
solved by e.g. a package providing a wrapper capability.

Also, what if distributions would simply go in, say, /debian-etch/,
/fedora-core4/, and so on? You could then to a great extent run 
multiple simultaneously, just having to choose a few services 
from one of them that the others would have to use, and hopefully
work with, as well as a kernel. The problems are not insurmountable:
you can already run another OS in a virtual machine and set DISPLAY 
point to your main OS, although it's a bit cumbersome.

-- 
Tuomo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/