>How do you take someone seriously that opens with that?
By reading the whole article and responding to it on its merits, and not on a single three-word sentence that isn't that relevant to the core point of the article.
By reading the whole article and responding to it on its merits, and not on a single three-word sentence that isn't that relevant to the core point of the article.
The computing world loves to be relentless positive about things. Ergo all the over-promising and hype-cycles and whatnot. I don't want to descend into nihilism, but I think we need more criticism to balance it out. If people don't know what's bad, how can that appreciate what is good?
A lot of people revere Bell Labs a lot. I dunno, I think the original version in Manhattan with a train running through the building might have been cooler! There was a huge diversity of computers and operating systems in the late 1960s and 1970s. It can easily be argued that technical merits had less to do with Unix's winning than the monopoly law that preventing AT&T from commercializing it.
Starting with an elementary schooler's negative sentence is a good way as any to break from the relentless positivity and widespread Unix worship :)
On the light experimentation front, a longstanding goal of mine is to see NixOS support multiple kernels, because the status quo of having to cobble together a userland from parts for each kernel is a huge productivity drag. Having a "userland assembly toolkit" that lets you plan out what software you want to support with what patches could dramatically lower the barrier to entry.
Trying to carve out a driver layer would also be fantastic. This should be analogized to LLVM making a reusable compiler backend, and the dramatic effect that had on programming language diversity allowing things like Rust to come into existence.
At the same time, kinda what I am saying here is that maybe it isn't quite a local maxima.
Today most kernel work is motivated by performance, maybe security. The mistakes that are already worked around with more ugliness in other layers is usually not prioritized --- we have the workarounds, what's the problem? If more OS work was thought of in productivity terms --- we want to make writing correct, secure, performant, etc. software easier and more natural --- I think we would find the gradient might be bad in many directions, but still good in others.
The stuff I include here is are all things that I think could be refactored into existing "heritage" kernels without much difficulty. I actually looked a bit at FreeBSD and Linux for the process-spawning parts, for example. Just need to slice up the fork/exec code and then call it in a different order.
And then you continue with “ But file descriptors are good.”
Which arguably could be one of the points against UNIX IMHO. As opposed to object-oriented interfaces like for example Windows NT, which allows for elegant shells like PowerShell.
Now let the downvotes flow in… ;)
I don't believe "object-oriented" has any concrete meaning, so I have a hard time interpreting what you mean by that. Window's HANDLE * is good though, and I recall in some cases NT made some things handle-based ahead of Linux / BSDs doing so. (e.g. is `NtCreateFile` older than `openat`? Maybe?)
Powershell is nicer than bash, but doesn't PowerShell run on linux? I would think the integration with a proper standard library and language runtime (C#'s, CLR) is more important than what the system calls look like.
No downvote from me :)
So with the example of PowerShell (on Windows), I like that I can actually pass around objects which I then can query for details if I want to, but which can also hide their details if they’re not needed.
In contrast to files (or rather text), where details are always exposed. This is often seen as an advantage as it’s directly “human readable”, but in my experience it often makes for more complex command lines.
As said, both philosophies have their pros and cons, I just don’t see the UNIX one as the one and only truth.
But I generally try to be pragmatic and will happily use Windows or some UNIX derived system (or something else) depending on the use case.
When you say "pass around", what do you mean? Is this some userland struct future syscalls will inspect manipulate? Or are you passing HANDLE * references to an opaque resource?
I very much agree text is bad. :)
Microsoft really should push that harder and create some sort of standardized /usr/bin-alike so people can install CLI tools (both local user equivalent to ~/bin and globally requiring admin) in a controlled manner.
PowerShell is an awesome shell.
This is called C:\Program Files.
> ~/bin
This is called %LOCALAPPDATA%, which lives in C:\Users\<Username>\AppData\Local.
There are exact equivalents to Unixisms on Windows; it's just that Unix developers don't want to use these equivalents.
Now let the downvotes flow in…
No downvote from me!
I always found UNIX's everything-is-a-bag-of-bytes to be a huge pain, and file descriptors even worse.
This is a hard pill to swallow for many *nix die-hards, but I would say that objectively speaking, Windows NT has a better core OS model than Unix-like OSs, including the driver model, the filesystem API, the process management API[1], and the overall plug-and-play-ness of NT.
[1]: The OP article mentions this paper by Microsoft Research, but claims it doesn't offer alternatives—it does. It explicitly mentions posix_spawn and CreateProcess. https://dx.doi.org/10.1145/3317550.3321435
On the surface it seems like madness, but taking a proper look quickly shows there were and are very smart and wise people behind Windows's core.