MiNT TO UNIX

[Christian Lynbech <lynbech@daimi.aau.dk>]

I do not agree with Annius that 
> "Re: If MiNT goes UNIX then Atari goes down the Trash Can (remember that?)"

Different people has different preferences, and there is going to be
many ordinary GEM/MULTITOS/MiNT users left which are perfectly happy
with their TOSfs systems. MiNT is such an improvement, even to
ordinary TOS users, and not everybody wants to put their data under
some obscure, unknown new file format (though superior in many ways).

He also said:
> You're not going to admit in your next letter that you are satisfied
> with a 80x25 column terminal screen, are you?

No, but given the size of the standard atari B/W monitor, the text
screen isn't that bad. There are limits to the number of windows you
can conveniently use on such a small screen. And for a die-hard emacs
and latex user as me, I can (and do) live with it.


Chris Herborth writes:
> But wouldn't it make more sense, for you, to find a really cheap used
> '386 with 4M of RAM (_very_ common, and should be < $1000 almost anywhere)
> and run Linux?  You'd be able to set it up 100% UNIX right now, and you
> wouldn't have to wait for the "MiNT goes UNIX" group (if it ever formed)
> to get around to setting everything up.

I *really* don't have the money at the moment. My financial situation
is shakey enough as it is :-(, but this is of course the way to go,
since any 68000 box is lacking power and ressources. 

But this isn't really the issue. I'm not the only one interested in a
unix-like solution, and MiNT is so deceivingly close already now. I
will not be satisfied with the old ways, I just can't help it :-).


Chris also writes:
> > [...stuff about i) fs standards or ii) making porting/configuring easy...]
> Definitely the second option, but I'd certainly settle for #1 in the
> mean-time.  :-)

I do not see a contradiction here. For one, a decent bourne shell and
a fully working test program, lets you configure most GNU software
pretty easy, already now. But some fs standard would give additional
benefits:

1) Less need of patching.
Adding some environment variable requirement, probably means that you
still need to patch even GNU packages, and this is somewhat a pain,
when the next version of (say) the fileutils are out.

2) Not absolutely dependent on sources.
If you want a UNIX setup, you are pretty much required to have the
sources so you can configure to your specific setup. There is no
standard, so in theory you risk that one guy uploads the GNU diffutils
configured with all programs in /usr/local/bin and another guy uploads
RCS which expects diff to be A:\GNUBIN so that you just can't win.
This project is also a commitment to ensure that there are utilities
working within the standard (me thinks).

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

Very true indeed, lets get this issue out of the way.


Still dreaming,


------------------------------------------------------------------------------
Christian Lynbech               | Hit the philistines three times over the 
office: R0.33 (phone: 3217)	| head with the Elisp reference manual.
email: lynbech@daimi.aau.dk	|        - petonic@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------