home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / atari / st / tech / 6332 < prev    next >
Encoding:
Text File  |  1992-12-20  |  2.7 KB  |  74 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!uunet.ca!geac!zooid!stramba
  3. From: Mike Stramba <stramba@zooid.guild.org>
  4. Subject: Re: MiNT, which way forward...
  5. Organization: The Zoo of Ids
  6. Date: Fri, 18 Dec 1992 04:29:05 GMT
  7. Message-ID: <1992Dec18.042905.2154@zooid.guild.org>
  8. References: <1992Dec11.185521.26575@bas-a.bcc.ac.uk>
  9. Lines: 63
  10.  
  11.   In article <1992Dec11.185521.26575@bas-a.bcc.ac.uk>,
  12.   ucacmsu@ucl.ac.uk (Mr Stephen R Usher) writes:
  13.  
  14. >
  15. >Here's a copy of a discussion document I sent to the MiNT mailing list
  16. >earlier today...
  17. >
  18. >---- Start of included message ----
  19. >From reading the comp.sys.atari.st* groups it has become increasingly clear
  20. >that there are two distinct groups of MiNT users, each of which have
  21. >differing priorities for future developments.
  22. >
  23. >The two groups are as follows:-
  24. >
  25. >1) People who are looking for MiNT to provide a multitasking kernel
  26. >    underlaying GEM so as to give the same sorts of functionality as MS
  27. >    Windows, Windows NT or Apple's MultiFinder.
  28. >
  29. >2) People who are looking to use MiNT as the basis for a cheap substitute
  30. >    for Unix as a development environment and possibly as a multiuser
  31. >    service.
  32. >
  33. >Group (1) have the following priorities:-
  34. >
  35. >    (1) compatability with the old Mono-TOS/GEM
  36. >    (2) process protection
  37. >    (3) rudimentry virtual memory (ie monolithic, merely giving the
  38. >        processes in total a machine with a virtually bigger RAM
  39. >        size)
  40. >    (4) networking (virtual drives)
  41. >
  42. >Group (2) have these priiorities:-
  43. >
  44. >    (1) Process protection (including user id access control)
  45. >    (2) Close emulation of Unix at library/OS levels.
  46. >    (3) Internal Unix-like networking stubs (ie sockets, both UNIX and
  47. >        INET Domains). Drivers for networking itself could be loaded
  48. >        at boot time, but the code for inet stuff etc should be in
  49. >        the kernel and multithreaded so as to be able to guarantee
  50. >        as fast a response as possible. The INET loopback device
  51. >        should be in the kernel as standard too.
  52. >    (4) Per-Process, highly efficient virtual memory (giving a process a
  53. >        virtual machine)
  54. >    (5) Shared libraries
  55. >    (6) Mountable file systems (so only those file systems which the
  56. >        operator wants to appear are actually visible, and they can
  57. >        be placed where they are needed)
  58. >    (7) Hardware specific terminal/serial drivers (which can take full
  59. >        advantage of the higher specification hardware available on
  60. >        the Mega STE, TT and Falcon)
  61. >    (8) Multithreaded file systems
  62. >    (9) Less granularity for scheduling. (MiNT currently feels to have
  63. >        very coarse context switching.)
  64. >
  65.  
  66. I am interested in both groups, at the moment I'm concentrating more on
  67. group 2.
  68.  
  69. I have not been using MiNt much yet, having only 1 meg and one floppy.
  70.  
  71. What is the current state of MiNt in regard to the above items?
  72.  
  73. Mike
  74.