Path: utzoo!attcan!uunet!ncc!lyndon From: lyndon@ncc.Nexus.CA (Lyndon Nerenberg) Newsgroups: comp.misc Subject: Re: OS/2 is the result of anticompetitive practices by IBM and Microsoft Message-ID: <10221@ncc.Nexus.CA> Date: 11 May 88 22:48:55 GMT References: <1925@sugar.UUCP> <1612@looking.UUCP> Reply-To: lyndon@ncc.Nexus.CA (Lyndon Nerenberg) Organization: Nexus Computing Inc. Lines: 116 In article <1612@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >Like I said, it's not an easy target that is being aimed at, and OS/2 >misses in many of the following places, but here are areas where Unix >would require a total rewrite to hit dead on: > > a) Administration - this has been discussed a lot, so I won't > go into details here. Have you tried installing something like Wordstar under DOS in such a way that it can be accessed from within any directory? Even better, have you documented it in such a manner that a "novice" can duplicate this easily? Trivial applications are (generally) trivial to maintain. As DOS applications (and the DOS environment) grow in complexity, so will the administrative burden. > b) File system integrity: > Unix can't just be turned on and off with a switch like > DOS can, and like users expect. A UNIX box running in single user mode will survive a power down nearly as well as a DOS machine in single user mode. The only reason UNIX is a bit less reliable is due to the use of the disk cache. You could eliminate the problem by eliminating the cache. Is this a reasonable solution? When OS/2 starts supporting multiple users, what will make it immune to FS problems when someone hits the power switch? > c) Fragmented file systems: > Unix fragments file systems heavily, and that means you > don't want to run it on anything but a fast disk drive. > Most people have slower (50-60ms) disk drives. The BSD file system has done a lot to reduce disk fragmentation. If UNIX were limited to 30 meg partitions (ala DOS - I don't know the OS/2 restrictions) it wouldn't (couldn't :-) fragment files much either. > d) Running DOS programs > Unix for the 286 might be able to do this the way that > OS/2 does, but nobody has done it. That's partly because > everybody is interested in the 386 way of doing this, since > it isn't a kludge on that chip. Implementing virtual machines has never been a replacement for running the "real thing." If you insist on doing it you're going to have to accept the performance hit. Hardware assist (on the 80386) always helps. This is not a "UNIX" issue. > e) Real time > DOS programs can do real time applications because they > own the machine. Not so under Unix Most real time applications involve fast response to *external* events. What DOS gains by having exclusive access to the CPU is contradicted by the poor I/O performance of the typical XT/AT hardware environment. If you want to achieve *fast* I/O you're going to have to write your own driver. Odds are the driver will completely bypass the BIOS, there- fore this is no longer a DOS issue - it's a hardware problem. Of course, UNIX is just as much of a pain in the ass when doing things like this. > f) Easy device driver installation. > Typical DOS machines, if they get fancy, have special > peripherals, all with their own drivers. All unusual > disk controllers come with their own drivers in rom. Try hooking up a Microsoft bus mouse, an HP scanner, a multi-port I/O card, a Cordata laser printer, and a hi-res Amdek monitor to an AT. Make it run Ventura Publisher while talking to the mouse, and don't forget to make sure print.com works. Do all of the above in such a manner that you don't have to reboot with and without the mouse and printer drivers loaded in various combinations depending on which application you want to run. Clearly document the procedure. Convince the user this is *easy*. > The link into the kernel method is just too much. Dynamic > mount (like QNX) would be best. Load from a list at > boot time is what DOS does, which is not as good as > dynamic mount, but better than relinking the kernel and > rebooting. Dynamically loadable device drivers are available under CTIX - Convergent Technologies System V port (and on the 3B1 if I remember correctly). It would be nice if CT would license the technology out a bit more freely. > g) Still run software for the old filesystem, and still use old disks. > This is something people want, although they're wrong > to want it, and OS/2 was wrong to give it to them by > keeping the same file system format. But it is > something people want, they just don't know it's bad > for them. 8-) "Where do I plug in the card reader?" :-) > h) Convenient floppy disk use > The whole mount/unmount scheme is too much for a lot of > these users. "...and where does the punch go?" [ see above ] >Some of these things could be fixed with mods, but some of them require >essentially an entire rewrite. Which is the main reason why it will never happen. >Now, what they should have done was made an OS that supported both >the Unix and DOS system calls, and their almost identical directory >structure, but didn't use the same internal file system and process >structures. That would have been the answer. Quick, what does "cd; touch a:" do? -- {alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CA