DragonFly BSD
DragonFly users List (threaded) for 2005-08
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index]

Re: Compatability with FreeBSD Ports [debian package tools]

From: Raphael Marmier <raphael@xxxxxxxxxxx>
Date: 2005年8月18日 20:44:37 +0200
Joerg Sonnenberger wrote:
On Thu, Aug 18, 2005 at 06:29:43PM +0200, Gabriel Ambuehl wrote:

If anything, it should be thought further (and some are already pressing
in that direction, notably Xen and VMware ESX): self contained
single purpose OS instances.


A nice hype, but IMO a nightmare for administration.


One machine might easily do both web and mailserving, but it would be
more secure to isolate the services...


It's called separate user accounts in Unix.


A package manager that can do something like that would be truly innovative. 


No, because it wouldn't be package mangement at all. You end up with
extracting a tarball into a location and removing it for uninstall,
pretty much like Windows, just without messing in
C:\Windows\System{,32}.

Certainly not. A sandboxed app would be built by installing packages _into_ it. As as said, this is why it must be managed by a high level program, that not only gives the operator a clear picture, but allows him to upgrade whole "sandboxes", upgrade a single packages, a single package in all "sandboxes", etc...

As per config files, sure, this can be a pain. But nothing prevents to be smart and inovative, and have the package manager provide a list of the config file of all installed instance of a given package, along with
the modification date, and why not, diff between them, revision conrol, . .. once the system is solid and predictable, you can put the wizardry in managing usefull info: the configs.

Frankly, are there so many dependency packages that need configuring beyond the defaults? Most of the time, I bet you need do so to taylor them to their dependent package. At this point, its really the same. I doubt there would be so much real config duplication.

All in all, you spend a little more energy and disk space at the install phase and maintenance phase, so you spend no energy in keeping the system from derailing, and no energy and disk space at the removal of components.

In the current scheme, you spend as little energy and disk space as possible installing. Then spend vast amounts of energy at keeping the system from gaining entropy, then spend a fair amount of energy and a some disk space at the removal of components.

In the end, we are no so far from the windows world ;)

Raphael


[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index]

AltStyle によって変換されたページ (->オリジナル) /