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

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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.
>
> 						-Matt

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.

;-)

Bill