Ask Slashdot: If You Could Assemble a "FrankenOS" What Parts Would You Use?

rnws writes: While commenting about log-structured file systems in relation to flash SSDs, I referenced Digital's Spiralog [pdf], released for OpenVMS in 1996. This got me thinking about how VMS to this day has some of, if not the best storage clustering (still) in use today. Many operating systems have come and gone over the years, particularly from the minicomputer era, and each usually had something unique it did really well. If you could stitch together your ideal OS, then which "body parts" would you use from today and reanimate from the past? I'd probably start with VMS's storage system, MPE's print handling, OS/2's Workplace Shell, AS/400's hardware abstraction and GNU's Bash shell. What would you choose?

Comments

Re:Duh

[JWSmythe]

I'm pretty sure that was a high altitude joke sailing by at mach 1.

Re:VMS queue manager and VMS breakin evasion

[Nkwe]

DCL (the VMS CLI) could also do with a major rework and enhancements.

True, but there are elements of DCL that are worth bringing forward as well - particularly the ability to define the command syntax at operating system (shell) level and bind it to programs. For those who who haven't developed under VMS, there is operating system (shell) defined syntax with which you declare what parameters, switches, options, etc. that your program desires. The syntax is robust enough to specify which options are optional, required, mutually exclusive, etc. When you build your program, you "compile" in your command syntax and at run time DCL handles syntax checking for you. Coding work for processing command line parameters is greatly reduced. You also get bonus stuff like integration to the help system and automatic shortening of non ambiguous switches.

File versioning and backup flags

[Nkwe]

VMS supports very elegant file versioning, which I found a very useful feature. By default, every time you open a file for write (and you modify the file) you get a new version of the file (kind of like copy on write at the file level). When you list the files in a directory, you can see all the versions of the file with the version number being an actual part of the file name(file.text;1, file.text;2). On a per file basis you can set how many versions you want to keep around and the file system will automatically purge the old versions as new ones are created. When opening a file you can specify any version you want, or if you don't specify a version you just get the latest.

The file system also supports specific backup related attributes that integrate with the backup system. This lets you specify that a file should be excluded from backup and if I recall, tracks if the file has been modified since the last backup.

Re:I want...

[BevanFindlay]

You do realise that most of those wishes are granted with any modern Linux install? Hardware support has gotten a lot better (mostly it's just "install and go" now), software support is either (a) native versions of the stuff you want, or (b) installable using WINE (not everything works well with WINE, but it also is much better than it used to be). Installing software on Linux is in my opinion easier than most OSes, as long as it's in the main catalogues: just go to your software manager, do a search, click install. Even for more obscure stuff, it's maybe just adding a repository, which is a simple "Google for it, then copy and paste a line or two of text". Apparently, Linux also has native ZFS support.

Or am I missing something here?

Re:Duh

[TheRaven64]

Windows threading and synchronisation primitives

What windows synchronisation primitive allows:

• Timed wakeup (i.e. try to lock, time out if you fail).
• Adaptive mutex behaviour (spin in userspace for a bit before calling the kernel).
• Can atomically be released when you sleep on a condition variable and reacquired when you wake.

Give up? So did the developers of the Microsoft C++ stack, which is why their std::mutex uses something custom, whereas implementations for POSIX systems just use pthread_mutex.