9 ms·
>there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even
by omginternets 10y ago
>there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even modern Unix.
Yeah, that's what I'm curious about. Could you name names? :)
- walshemj 10y agoITS is often mentioned and I suppose PR1MOS (which was descended from ITS)
- DonaldFisk 10y agoI'm familiar with ITS, but haven't heard this before, and am highly skeptical of any connexion with PRIMOS. The Wikipedia article on PRIMOS says "Legend has it that the unusual choice of FORTRAN for the OS programming language had to do with its history. Allegedly, the founders of Prime had worked for Honeywell on a NASA project. However, Honeywell at that time was uninterested in minicomputers, so they left and founded Prime, taking the code with them." ITS was written at the MIT AI Lab in MIDAS assembly language.
- larsbrinkhoff 10y agoIt seems more likely that PRIMOS would have been influenced by Multics.
- pjmlp 10y agoAmiga OS, BeOS
- vidarh 10y agoI still miss things from AmigaOS (still being developed, but ultra-niche; with "clones" in the form of AROS - which is open source - and MorphOS). Things like ubiquituous scriptability of apps via Arexx (the language is awful, but you don't need to use the language much to call the APIs), heavy multi-threading throughout the OS, datatypes (new image format? drop a library in the right directory and every application that knows how to load images via datatypes can load it; same for text/documents, sound etc.), assigns (think of it a bit like $PATH, but not limited to a single variable, and enforced OS-level, so e.g. C: in AmigaOS works roughly like $PATH, but by default there's also LIBS: for libraries, T: for temporary storage, CLIPS: for the clipboard, and by convention people tend to have e.g. WORK: pointing wherever you want your project data - you can define your own, and redefine them at will, and they can refer to eachother, so e.g. your "C:" may refer to System:C and Work:C (at the same time), and either System: or Work: or both can be either partitions or labels assigned to removable media (in which case the OS may ask you to insert the right disk if you reference it - it can reference a specific disk rather than just the drive), or to another assign). Or workspaces as an OS-level construct (Screens) that applications can open, close and manipulate, either for "private" use for just its own windows or by opening public screens that can be used to combine windows from multiple applications. Or third party standards like XPK, which lets any application transparently support file compression - similar to datatypes you can drop in a library forany compression algorithms and all the apps gains support for it (there are several similar standards for e.g. archivers, disk images etc.). Current mainstream OS's still feel very backwards in many ways after being used to those things.
- RBerenguel 10y agoAssigns sound a bit similar to how Plan9 handles the "everything is a file" thing
- spc476 10y agoFurther more, you get a new application on floppy. The disk is named FOOAPP. The application can then request data files such as FOOAPP:data1.dat and FOOAPP:data2.dat. If the program is running and you remove the floppy, no issue. When the program tries to open FOOAPP:data3.dat, the operating system will then ask you to insert disk FOOAPP (and there's no having to dismiss the alert box or anything---the system will detect the inserted disk and dismiss the alert box automatically). Later, when you get a harddrive (or decide you like the app and want to continue using it), you can copy it to the harddrive (wherever you want) and add an assign "FOOAPP=MY_APPS:new/fooapp" and the application will still work just fine. It's still something I miss.
- throwanem 10y agoLisp machines turn up pretty frequently in this context, and I understand why - some of their capabilities still haven't been replicated anywhere else, nor are they likely to be, and that's a real loss; in particular, there is a great deal to be said for a model in which changing the behavior of the running system, right down to the microcode, can be as simple as writing up the changes you want and evaluating them. No compile step, no restart, no nothing - you just point at something and say "do this instead from now on". If you like it, save it and hang it off the boot process; if you don't, reverting the change is as easy as evaluating what you replaced; if you discover you've broken the running environment, you can usually fix it without a reboot, and in extremis a (fast!) reboot cures all such ills. About as close as you can get and stay relevant to the modern world is Emacs, which, while a lot of fun, I gather from those with real Lisp-M experience isn't really all that close. And it says something, I think, that the next former Lisp-M user I meet who has a bad word to say about that platform will be the first one. In general, the book does these systems more justice than I can, and it's a fun read in general. I recommend it quite highly - in those areas it covers where I have experience of my own, I found little with which to disagree and much with which to laugh.
- mamon 10y agoLive modifications of OS code sounds like a recipe for disaster. Unless you are an expert that codes himself an OS before breakfast
- throwanem 10y agoIt's not something one would probably use every day, or without due care. But it is something you can. And, as I said before, unless you take explicit steps to persist the change across boots, one flick of the big red switch and it's gone.
- mikelevins 10y agoBear in mind that LispMs had well-designed tools for supporting this kind of development. For example, they had version control that tracked all changes everywhere at all times, even changes that were not saved in any file. Also bear in mind that they were designed by programmers for programmers. They were not intended for the general public.
- notalaser 10y agoOpenVMS: distributed locking (we're barely catching up with it, in 2017!) -- see e.g. http://download.oracle.com/otndocs/products/rdb/pdf/rdbtf05_locking.pdf http://download.oracle.com/otndocs/products/rdb/pdf/rdbtf05_... , filesystem versioning (we still have nothing like it, and applications like ClearCase (very poorly) try to implement their own over filesystems that don't support it). ASTs (see https://en.wikipedia.org/wiki/Asynchronous_System_Trap https://en.wikipedia.org/wiki/Asynchronous_System_Trap ) are also great, but I think something akin to them exists in Windows.
- twistedpair 10y agoSee Show Stopper!: The Breakneck Race to Create Windows NT by Zachary. Gives you an idea what the Unix landscape was like, and how primitive Windows was when Dave Culter's team from Digital began building NT (after the VMS at Digital), which became Windows XP (when Windows stopped crashing every hour). Much of what we assume every OS does today was cutting edge development in 1990.
- throwanem 10y agoNitpick: NT became Windows 2000, and that's where Windows stopped crashing every hour. XP came next, and was where the 2000/NT line entirely superseded the 95/98/Me line, whereupon there was much rejoicing.
- chubot 10y agoYeah everyone seems to rag on C for being ancient. They don't realize that, in 1990, writing a kernel in C was an huge improvement over assembly language! And it still is today -- there's really no other option. If your only other choice is assembly language, then C starts to look really good. You don't complain about weird function interfaces, because at least you have functions!
- twistedpair 10y agoThe original NT graphics code was in newfangled C++. The books goes into detail on the time lost teaching the team C++, and that they should have stuck with C. ;)