DragonFly kernel List (threaded) for 2007-06
DragonFly BSD
DragonFly kernel List (threaded) for 2007-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: implemented features (Re: Decision time....)

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Thu, 07 Jun 2007 04:02:49 -0400

Matthew Dillon wrote:
    PkgSrc is something I agonized over for a long time.  I really wanted
    to develop my own.  But the reality is that it would take a person
    100% dedicated to that one aspect of the system to be able to do anything
    good, and maintaining a large enough package pool is impossible for a
    single person.

I doubt it is 'possible' for fewer than 5 or 6 *minimum* IF it is to be kept current.

'Wetware' needs sleep now and then.

This means we really have no choice but to pool resources with someone. Despite its major shortcomings (wanting a writable /usr/pkg directory tree, and an inability to update packages without putting the system into a half-upgraded state which might then fail to complete)... despite that, it is the best we can do without limited resources.

The installer is one of those things where it is simply not possible to please everyone. It just can't be done. There are too many variables. My only major requirement for the DragonFly installer is that it have an install-from-scratch feature that blasts the system and that it be possible to boot the live CD (hence 'Live') into a fully working environment.

> Supporting multi-system installs is not on my list,

Even if sole user of a dedicated HDD DFLY DOES need 'friendlier' inspecting, slicing, partitioning, boot-sectoring and disklabeling tools.

Think of a disk that is NOW going to becoem all-DFLY, but was previously used for some other OS or combination of them, and/or with soem other boot manager. At present DFLY cannot blow *all* such away for a clean start.

    primarily because it is impossible to get it right but also because
    one has to operate under the expectation that users who do multi-OS
    installs have some idea what they are about when they do it.

I have no issue with that at all. Unix/BSD variants have been described as 'expert friendly' not user friendly, and there is probably no way around that without giving up too much of why one selects them in the first place.

'Appliances' they are not, though a 'packager' can build such if they wish to by placing limits on what they target.

> We also
    have a cop-out now, which is that it is much safer to do a single-OS
    install in a virtual machine environment then it is to do it for real.

    For any serious work a machine really has to be dedicated.  If high
    performance isn't an issue, then a virtual machine environment is just
    as good.


I don't see the relevance there.

*Something* has to be installed to support either, and I don't think you meant virtualizing DFLY on a Linux or Windows - or even *BSD host.... DFLY or 'other'.

Any 'host' can take as long - or much longer - to install than native DFLY in any case, so that becomes a Chicken and egg problem.

The 'live CD' - feature-rich, as with Knoppix or Morphix et al, makes more sense to me - as does the same, perhaps *much* enhanced - installed to the now usually-much-larger-than-CD USB memory sticks.

Wouldn't be rocket science to publish a couple of stable variants of those, directly copiable to 2GB or 4GB USB gadgets - say with and without 'X' and with pkgsrc ready to roll. Most recent Minix has something similar w/r putting 'X' into place.

I'm not of the opinion that any of this is in need of an 'immediate' fix, as my gut feeling is that a knock-their-socks-off DFLY that would *benefit* from an enlarged interest pool is still about a year away.

Too much attention from the peanut gallery too soon and all that happens is developers are distracted by the carping and whining about MP3's that don't play and such trivia.

Side note, but with MP3 players starting at US$14 and not much bigger than a Bic lighter, who *cares* if a 'puter can do sound?

I'll go back to reading a mystery novel now... 'Dead tree', BTW. Feels better.



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