From: ucacmsu@ucl.ac.uk (Mr Stephen R Usher)
Newsgroups: comp.sys.atari.st.tech
Subject: MiNT, which way forward...
Date: 11 Dec 92 18:55:21 GMT
Organization: Bloomsbury Computing Consortium, London


Here's a copy of a discussion document I sent to the MiNT mailing list
earlier today...

---- Start of included message ----
From reading the comp.sys.atari.st* groups it has become increasingly clear
that there are two distinct groups of MiNT users, each of which have
differing priorities for future developments.

The two groups are as follows:-

1) People who are looking for MiNT to provide a multitasking kernel
	underlaying GEM so as to give the same sorts of functionality as MS
	Windows, Windows NT or Apple's MultiFinder.

2) People who are looking to use MiNT as the basis for a cheap substitute
	for Unix as a development environment and possibly as a multiuser
	service.

Group (1) have the following priorities:-

	(1) compatability with the old Mono-TOS/GEM
	(2) process protection
	(3) rudimentry virtual memory (ie monolithic, merely giving the
		processes in total a machine with a virtually bigger RAM
		size)
	(4) networking (virtual drives)

Group (2) have these priiorities:-

	(1) Process protection (including user id access control)
	(2) Close emulation of Unix at library/OS levels.
	(3) Internal Unix-like networking stubs (ie sockets, both UNIX and
		INET Domains). Drivers for networking itself could be loaded
		at boot time, but the code for inet stuff etc should be in
		the kernel and multithreaded so as to be able to guarantee
		as fast a response as possible. The INET loopback device
		should be in the kernel as standard too.
	(4) Per-Process, highly efficient virtual memory (giving a process a
		virtual machine)
	(5) Shared libraries
	(6) Mountable file systems (so only those file systems which the
		operator wants to appear are actually visible, and they can
		be placed where they are needed)
	(7) Hardware specific terminal/serial drivers (which can take full
		advantage of the higher specification hardware available on
		the Mega STE, TT and Falcon)
	(8) Multithreaded file systems
	(9) Less granularity for scheduling. (MiNT currently feels to have
		very coarse context switching.)

Now, the question I'm asking is.. which way should MiNT go in the future?

Much of the stuff on group (2)'s wish list would help group (1), eg real
virtual memory, networking available in kernel (anyone wana use NFS over
UDP/IP on top of X25 on the MSTE/TT/Falcon network port?).

Other things clash, such as group (2)'s wish for disk devices to be
invisible until mounted whilst group (1) wanting them to appear as
MS-DOS/GEM-DOS-like devices.

The advantage of using the INET protocols for networking is that once a
person has a device driver for thier network interface hardware (eg an
ethernet controller of some kind or even a serial line for SLIP or PPP or
Packet Radio) they could just plug into their nearest network and be away.
Also the INET protocols and NFS are in the public domain.

Networking using INET protocols takes up space which small machines would
have problems coping with, however, especially if they were on non-68030
machines with less than 4 megs of RAM. In which case, should there be two
MiNTs, the normal one and VMMiNT with all the networking and VM stuff in
there? Or should there be three or four?

I think the question which sums this all up is:-

	Which way now?

I hope this posting has given you something to think about and discuss. I'm
posting to the MiNT group because this is where the steering is going to
come from, also Eric gets a copy in his mailbox so he doesn't have to wade
through all the Usenet News to see it.

Steve

-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth. Tel: Oxford (0865) 282110.
---- End of included message ----

What do you think?

Steve
--
Addresses:-
JANET:-		ucacmsu@uk.ac.ucl or	steve@uk.ac.ox.earth (preferable)
Internet:-	ucacmsu@ucl.ac.uk or	steve@earth.ox.ac.uk (preferable)