There's a common assumption out there that it's either Unix or Windows, that if you hate one then you must necessarily like the other. Well, that's not true.
There's another common assumption that Unix and Windows are different, very significantly different, well that's not true again.
This page is dedicated to the realization that both Unix and Windows are very, very similar and that they should both be bashed in unison.
- Both have hierarchical filesystems that make it impossible to neatly categorize anything.
- How about the BeOS semi-database-filesystem?
- Much better than Unix or Windows, proving the point. From a theoretical POV, BFS isn't anything special. You can easily reimplement the same functionality in a cleaner manner if you simply allow directories to be used in place of files (ie, as objects with definite types). And of course, it falls far short of OODBs. BFS manages the same functionality by magically indexing attributes but all of this magic and asymmetry, none of it user visible or user controllable, is annoying.
- Related: FileSystemAlternatives
- Perhaps the file system should be orthogonal to the OS. See SplitOperatingSystemIntoServices.
- Calling it 'orthogonal to the OS' and splitting it into a 'separate service' are two very different things.
- Both have flat, useless WIMP GUIs; WimpIsBroken.
- Neither has security, both are based on ACLs; have you seen the number of exploits on both.
- Both are written in an obsolete broken language, which introduces many, many flaws.
- Both are single-user systems that make it impossible to share objects between multiple users in a clean and secure manner.
- Neither is usable by someone who isn't thoroughly familiar with their limitations and weird little idioms.
- Neither is consistent. Neither is based on sufficiently general principles.
- Both are overly complex.
- Neither is reflective.
- You can't learn programming from either Unix or Windows. You can learn it from other applications and from tons of books, but you can't learn it from the OS.
- Neither has a programmable GUI.
- Neither has an interactive or usable CLI.
- What do you mean, "usable"? I "use" Unix's CLI all the time.
- By your own admission, you "use" it, which makes you a "user", and as we all know, all users are clueless, therefore you are in no position to judge whether it is "usable". That's logic! -- Tweedledum
- Yeah, and I "use" Windows' CLI all the time. Unix shells fall far short of what JefRaskin wanted.
- Neither have been designed well, both are the products of random evolutionary pressures.
- Neither is versioned, both are irreversibly destructive.
- Neither has TransparentPersistence.
- Good.
- How so? Both Unix and Windows, due to lacking this feature, have created buggy 80% solutions to 'Hibernate' that have inconsistent integration with processes. Further, the lack of TransparentPersistence requires that processes integrate with the FileSystem through a NameSpace, which is ultimately the root cause of many security holes (compare ObjectCapabilityModel).
- As a user, I do not want things saved until I tell it to save. Besides, I want to be pretty darn certain which disk my important data is on. I do not believe these things are compatible with transparent persistence.
- The first request is incompatible with use of virtual memory or any sort of non-volatile memory, and would probably be better expressed as a security/privacy concern (which the OS could then handle independent of the memory resource by ensuring the data is encrypted in memory and thoroughly erased later). The latter request is best handled by resisting ReinventingTheDatabaseInApplication and placing certain 'database' actors/objects in charge of your 'important data', such that they can (at request or as a matter of course) provide a minimal backup of the data without persisting huge object trees; however, this could also be handled as an orthogonal pair of concerns for physical redundancy (having your data available on a particular device) and physical security (not having your data on another device) if you aren't feeling so picky about which data is or is not 'important'. Neither of your concerns is incompatible with TransparentPersistence so long as the program environment allows one to (independently of the process being executed) express security and redundancy concerns along with physical aspects thereof. In practice, these could be done with some set of environment variables that are automatically threaded through the program except where explicitly overridden (ExplicitManagementOfImplicitContext).
- You're right. I don't use swap partitions or files, and occasionally I use ram drives.
- In any case, as a user I want the ability to fire up my laptop and get back to work within a second or two, which isn't really possible without TransparentPersistence.
- Neither takes account of any modern research, both are stuck in the 70s. Both are FROM the 70s.
- Neither is object-oriented. Even PlanNine isn't object-oriented, which shows what DennisRitchie learned since the 70s; nothing. So why would the guy responsible for VMS / NT have learned anything?
- Not certain how being internally ObjectOriented is relevant to an OperatingSystem, but it would be nice to have a common 'message' format with which files and processes and other OS 'objects' can be integrated. The use of octet streams as the only message and file format severely hinders integration of unrelated OS components.
- Something Amiga solved, probably in the first week of being on the market, via the InterchangeFileFormat?, which it used for everything, including the clipboard format. Inspired by MacOS metadata forks and AIFF (giving credit where it's due), we Amigans simply never had any interchange issues except when dealing with foreign systems. But, no, y'all pro-PC wack-jobs just had to ignore the technology and gesture (IFF positively was NOT Amiga-specific, contrary to some claims). Microsoft had to go and invent RIFF for multimedia stuff, which was deliberately incompatible with IFF, and Microsoft strongly discouraged its use for non-media applications by simply refusing to use it themselves for anything but. Apple had to go and invent QuickTime, their own, umm, "competition", but even here, it was still purpose-built (specifically for multimedia, to compete against both RIFF and IFF ANIM). I could go on. But it's safe to say, you and the markets you supported brought this on yourselves.
- Hey, hey... You can't blame competitive market forces on the humans subjugated by them. Most people aren't equipped to make technical decisions, Amiga didn't equip them, and the rest of us suffer the tyranny of the majority. Those of us who recognize it generally aren't in this 'UnixAndWindowsHell' by choice.
"Sure, sure, but other than that, how did you like the play, Mrs. Lincoln?" :-)
I don't. :p What's left to like?
Funny, that's what Mrs. Lincoln said, too.
Unbundle Services
It has been suggested that the different services that OS's provide should perhaps be split such that they can be mixed and matched as needed. Thus, the file system, the GUI, the security model, etc. are different things similar to the way a web server is considered a different thing than a database (server) these days. Choosing one does not force using the other. I think there is an existing wiki topic on it, but I could not readily find it.
ExoKernel and LibOs? probably. Now, if by "unbundling OS services" you mean something beyond run of the mill modularization then it will get you a radically inconsistent OS. IOW, the most horrific OS imaginable, by definition. Oh, and security cross-cuts every other component of the OS, it can't be unbundled. Unless of course you've got something like KeyKos that centralizes security <shudder> and even then it would still cross-cut every component.
[I didn't recall that you had written about (taken a strong position on) centralized vs. distributed security, which pages did I overlook or forget? -- Doug]
I'm not sure I've written it up, and if I have written it up it probably isn't clear. But yeah, I'm for distributed security and against centralization. The main reason for this is because it's gratuitous. Every component that wants to export objects or services has to possess a deep knowledge of security, even if some centralized component is supposed to provide security for everybody. Plus, centralization involves too much gratuitous indirection.
In a centralized system, if component A wants a cap to object 3 from component B, then it first asks its cap of the kernel for a cap of component B, which is duly returned, then it asks this cap of component B for a cap of object 1, which is duly returned, and so on. For every cap in the chain, the kernel is involved right in the middle of the dereference, so by the end of it you've been in and out of the kernel 5 times. If that chain involves passage through the network, then this is death.
In a decentralized system, things are simpler and more direct. You don't ask the kernel for a cap to component B, you tell the kernel to pass on a message to component B, which it does, and upon reception component B passes the message to object 1 which passes it to object 2 and so on. At the end of the chain, the results return. Any dereferences are made in-place so they stay hidden, and the kernel only gets involved a single time. The end result is that the kernel has no knowledge of caps to objects 1, 2 or 3, and they can be implemented in any way that component B wishes.
The centralized example is how I've figured out KeyKos works but it's difficult to be sure given how absurd it seems to be. It could be that the system isn't as centralized as it claims or that components don't have internal caps. The latter would mean that security is much coarser-grained than it appears. Or it could just be absurd. -- RK
See: SplitOperatingSystemIntoServices
Unix And Windows Hell