home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / atari / st / tech / 6211 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  4.2 KB
  1. Path: sparky!uunet!pipex!warwick!doc.ic.ac.uk!uknet!bcc.ac.uk!news
  2. From: ucacmsu@ucl.ac.uk (Mr Stephen R Usher)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: MiNT, which way forward...
  5. Message-ID: <1992Dec11.185521.26575@bas-a.bcc.ac.uk>
  6. Date: 11 Dec 92 18:55:21 GMT
  7. Sender: news@ucl.ac.uk (Usenet News System)
  8. Organization: Bloomsbury Computing Consortium, London
  9. Lines: 97
  10.  
  11.  
  12. Here's a copy of a discussion document I sent to the MiNT mailing list
  13. earlier today...
  14.  
  15. ---- Start of included message ----
  16. From reading the comp.sys.atari.st* groups it has become increasingly clear
  17. that there are two distinct groups of MiNT users, each of which have
  18. differing priorities for future developments.
  19.  
  20. The two groups are as follows:-
  21.  
  22. 1) People who are looking for MiNT to provide a multitasking kernel
  23.     underlaying GEM so as to give the same sorts of functionality as MS
  24.     Windows, Windows NT or Apple's MultiFinder.
  25.  
  26. 2) People who are looking to use MiNT as the basis for a cheap substitute
  27.     for Unix as a development environment and possibly as a multiuser
  28.     service.
  29.  
  30. Group (1) have the following priorities:-
  31.  
  32.     (1) compatability with the old Mono-TOS/GEM
  33.     (2) process protection
  34.     (3) rudimentry virtual memory (ie monolithic, merely giving the
  35.         processes in total a machine with a virtually bigger RAM
  36.         size)
  37.     (4) networking (virtual drives)
  38.  
  39. Group (2) have these priiorities:-
  40.  
  41.     (1) Process protection (including user id access control)
  42.     (2) Close emulation of Unix at library/OS levels.
  43.     (3) Internal Unix-like networking stubs (ie sockets, both UNIX and
  44.         INET Domains). Drivers for networking itself could be loaded
  45.         at boot time, but the code for inet stuff etc should be in
  46.         the kernel and multithreaded so as to be able to guarantee
  47.         as fast a response as possible. The INET loopback device
  48.         should be in the kernel as standard too.
  49.     (4) Per-Process, highly efficient virtual memory (giving a process a
  50.         virtual machine)
  51.     (5) Shared libraries
  52.     (6) Mountable file systems (so only those file systems which the
  53.         operator wants to appear are actually visible, and they can
  54.         be placed where they are needed)
  55.     (7) Hardware specific terminal/serial drivers (which can take full
  56.         advantage of the higher specification hardware available on
  57.         the Mega STE, TT and Falcon)
  58.     (8) Multithreaded file systems
  59.     (9) Less granularity for scheduling. (MiNT currently feels to have
  60.         very coarse context switching.)
  61.  
  62. Now, the question I'm asking is.. which way should MiNT go in the future?
  63.  
  64. Much of the stuff on group (2)'s wish list would help group (1), eg real
  65. virtual memory, networking available in kernel (anyone wana use NFS over
  66. UDP/IP on top of X25 on the MSTE/TT/Falcon network port?).
  67.  
  68. Other things clash, such as group (2)'s wish for disk devices to be
  69. invisible until mounted whilst group (1) wanting them to appear as
  70. MS-DOS/GEM-DOS-like devices.
  71.  
  72. The advantage of using the INET protocols for networking is that once a
  73. person has a device driver for thier network interface hardware (eg an
  74. ethernet controller of some kind or even a serial line for SLIP or PPP or
  75. Packet Radio) they could just plug into their nearest network and be away.
  76. Also the INET protocols and NFS are in the public domain.
  77.  
  78. Networking using INET protocols takes up space which small machines would
  79. have problems coping with, however, especially if they were on non-68030
  80. machines with less than 4 megs of RAM. In which case, should there be two
  81. MiNTs, the normal one and VMMiNT with all the networking and VM stuff in
  82. there? Or should there be three or four?
  83.  
  84. I think the question which sums this all up is:-
  85.  
  86.     Which way now?
  87.  
  88. I hope this posting has given you something to think about and discuss. I'm
  89. posting to the MiNT group because this is where the steering is going to
  90. come from, also Eric gets a copy in his mailbox so he doesn't have to wade
  91. through all the Usenet News to see it.
  92.  
  93. Steve
  94.  
  95. -- 
  96. ---------------------------------------------------------------------------
  97. Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
  98. E-Mail: steve@uk.ac.ox.earth. Tel: Oxford (0865) 282110.
  99. ---- End of included message ----
  100.  
  101. What do you think?
  102.  
  103. Steve
  104. --
  105. Addresses:-
  106. JANET:-        ucacmsu@uk.ac.ucl or    steve@uk.ac.ox.earth (preferable)
  107. Internet:-    ucacmsu@ucl.ac.uk or    steve@earth.ox.ac.uk (preferable)
  108.