Re: MiNT goes UNiX, UUCP, standardizing...

[Chris Herborth <herborth@53iss6.waterloo.ncr.com>]

What you wrote:
>  (but still would suffer from GEMDOS other problems, like speed
> (complete lack of), no link(), no x-bits, no sparse files, unliked open
> files still visible to later open()s, `random' data loss on writes to
> multiple opened files even with O_APPEND...  why would anyone want to
> live with such a thing with MiNT where he can as well use minixfs?)
 
I'd rather have all of my partitions minixfs; the only reasons I have to
keep FATfs partitions around are g++ (that's a stupid RAM limitation
problem and not an fs problem) and Hermes UUCP.  Hermes would get a big
win if it'd run under MiNT reliably; all those tiny files fragment a FAT
disk in seconds and they're _really_ slow to access.

>  well... i now have hacks/ports of taylor uucp 1.03, smail 2.5, elm 2.3,
> cnews-xt 1.3, nn 6.4.11.  the question is, should we i) standardize this
> un*xoid-mint thing so tight that you could really have some `plug-in',
> say, cnews binary tree that you put in /some/fixed/dir, edit active,
> explist, batchparms, sys etc. in /another/fixed/dir and everything is
> right so it would run?  or should we ii) concentrate more on a working
> set of tools, shell, mintlib, compiler... so you could take the source
> and patches for MiNT and configure directories and other things yourself
> that otherwise would be cast in stone when using binaries.  i think that
> would make more sense, what do others think?

Definitely the second option, but I'd certainly settle for #1 in the
mean-time.  :-)

IMHO, we should quickly get a handle on this "standard directory tree"
thing; someone should propose a standard (that's still general enough
for people to customize however they see fit) and we should vote on it.

-- 
----------============_   /\ ========================================----------
Chris Herborth        \`o.0'                   herborth@53iss6.Waterloo.NCR.COM
Information Products  =(___)=
NCR ISD Waterloo         U