From: Tuomo Valkonen <tuomov@iki.fi>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [poll] Is the megafreeze development model broken?
Date: Tue, 13 Nov 2007 02:12:23 +0200 [thread overview]
Message-ID: <20071113001223.GA15663@jolt.modeemi.cs.tut.fi> (raw)
In-Reply-To: <20071112233955.GA25059@citd.de>
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
next prev parent reply other threads:[~2007-11-13 0:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 22:56 ciol
2007-11-07 23:06 ` Rik van Riel
2007-11-07 23:11 ` ciol
2007-11-08 1:36 ` Adrian Bunk
2007-11-08 20:45 ` ciol
2007-11-08 6:18 ` Stephen Hemminger
2007-11-08 13:38 ` David Newall
2007-11-08 14:26 ` Chris Snook
2007-11-08 20:41 ` ciol
2007-11-09 0:15 ` Chris Snook
2007-11-12 11:09 ` Eric W. Biederman
2007-11-12 13:51 ` Tuomo Valkonen
2007-11-12 15:20 ` Adrian Bunk
2007-11-12 16:02 ` Tuomo Valkonen
2007-11-12 16:56 ` Adrian Bunk
2007-11-12 17:16 ` Tuomo Valkonen
2007-11-12 17:34 ` Adrian Bunk
2007-11-12 17:42 ` Tuomo Valkonen
2007-11-13 10:11 ` David Newall
2007-11-12 17:37 ` Rogelio M. Serrano Jr.
2007-11-12 17:53 ` Tuomo Valkonen
2007-11-13 12:28 ` Radoslaw Szkodzinski
2007-11-13 13:09 ` Tuomo Valkonen
2007-11-12 16:13 ` Rogelio M. Serrano Jr.
2007-11-12 17:14 ` Adrian Bunk
2007-11-12 17:18 ` Tuomo Valkonen
2007-11-12 23:39 ` Matthias Schniedermeyer
2007-11-13 0:12 ` Tuomo Valkonen [this message]
2007-11-12 17:30 ` david
2007-11-12 18:25 ` Rogelio M. Serrano Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071113001223.GA15663@jolt.modeemi.cs.tut.fi \
--to=tuomov@iki.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=ms@citd.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®