I hate this fanatical love of the UNIX way. I really hate that as of today Windows is the only non UNIX OS. I trully believe that this fact set us back. No more exciting new OSes only boring unix.
But more seriously, what do you want from an OS? Cleaner design? Plan 9 comes to mind. QNX is very elegant, too. Some microkernel thing? Fuchsia, but some say it's inelegant and overdesigned right off the bat. Minix has some nice properties but somehow nobody but Intel seems to use it. Also, QNX again (but as the name suggests it's similar to Unix)... Distributed computing? I don't know, seems OK to run it mostly in user space.
My favorite alternatives are Plan 9, QNX and L4 (I know it's not an OS), of which QNX is the only one I have actually used. Shame about Fuchsia, I believe the negative opinions because I looked at some documentation and code before I read them and had a sort of "THAT is supposed to be Google's better OS?!" moment.
It seems strange that we are essentially trading on isotopes of OS thinking from about 2000 when Linux took the mantle of UNIX and Windows converged on the XP code.
Is this it? Is producing an OS now so incredibly expensive and hard that we are never going to try again, and just keep bolting things on to what we have? I feel a little sad at that, even if the reasoning is impeccable.
The latest release has included "flakes", promoted from an add-on to an opt-in feature and which, among other things, lets me pin my dependencies and the environment I need to build my private projects. I then don't have to worry about going out of sync with the main package set, and I can share private projects in a (hopefully) fully reproducible way, with people using different versions of nix.
Overall, really cool idea (dropped my jaw when I first saw it in action), but poorly implemented.
What's rather messy about Nix is nixpkgs with its helper functions all over the place alongside pretty shallow / non-existent documentation (which is unrelated to the language). Thankfully they've started to work on that recently: https://discourse.nixos.org/t/documentation-team-flattening-...
Well, there's Haskell, and I expect any Haskell programmer to be able to pick up Nix very quickly.
Guix has gone with a strict language, Scheme, but I understand they have their own monadic DSL to cope with the peculiarities of following the Nix model. So again, not something that a mainstream language can do well, and even as a Schemer, you're going to have to learn their macro language.
I think it's also really easy to underestimate all the tooling built around text. As soon as you try out some other way, you loose out on version control, diffing, grepping, and a whole bunch of other general tools built for text.
I think the only way to get around this is to build generalized tools for working with binary data as a data structure. The problem with this approach is that now you need to maintain a database that describes every possible binary format, where text editors only really have to concern themselves with ASCII & unicode to be useful for most cases.
If you lament this as a programmer, build applications that only work on your OS of choice, make them so good or take a dependency on a feature not available with macOS or Windows so that it can’t be ported, and then you can show the world the light of the UNIX mentality or whatever.
The flip side of this argument is that the experience of using computers for that 99.9% of users sucks.
As software engineers, it's almost our responsibility to argue in favor of better platforms, because every day not spent fighting the platform is a day we could be building better experiences for our users. (Not to mention, every day the platform doesn't inadvertently mess up the user experience is a day of smaller support costs.)
Secondly with device drivers being tied to the registry there is not a simple system upgrade of taking out the hard drive and placing it into a new computer.
Just not everyday occurrences for most but still exist.
And cumulatively I spent significantly less time on Linux than I did on Windows.
I personally do this all the time. At most you get an extra restart the first time the drive is in a new set of hardware and after that you're good to go.
My main Windows install is probably 8 years old at this point, it's gone between multiple motherboards.
The biggest annoyance is a few pieces of software that tie activation to the motherboard.
If you want to make it even more portable you can install Windows to a vmdk.
And if you want to get a special complicated, you can have that vmdk act as essentially a secondary variant of your main operating system complete with symlinking most of the files and application info, to both save space and so you have most of the same state across both os's, but still can play around and easily roll back any changes.
Of course most people don't care about those things, but as a developer, the main issue I see with Windows and macOS, is that they build specialized interfaces that lock you into certain ways of doing things, which may be convenient, but are difficult to migrate away from, and a pain to automate and reproduce.
I really value that the UNIX philosophy is geared more towards building simple tools that are designed to be combined with other simple tools to solve a more complex problem, and that it doesn't try to lock you into using any particular tool to solve a problem.
So no, I may not provide binaries for Windows & Mac for personal projects, but I'm not going to be openly hostile towards people who want to build things from source or contribute fixes for Windows & macOS.
The baseline is only text and files on systems that don't have anything better to offer.
Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.
Also pretty much all external programs on Windows. Anything that isn't itself implemented as a PowerShell cmdlet has this problem. And it's all shell-specific.
But in tons of situations actually doing anything that way involves a ton of boilerplate, and it's very clunky. It's acceptable for automation, but it's not something that feels very good to do in an interactive shell.
Stuff like Convert-FromJson is nice, but it's not as nice as whole ecosystem there the interchange format for external programs is sort of just 'understood'. It's also not streaming— it reads in a single JSON object as a string. So you need some extra boilerplate if the expectation is that you're piping output from a command that yields a stream of data.
PowerShell is great, but an environment where streaming objects in some other format between different programs, regardless of the languages they're in or the runtimes they use, would be better and closer to a real version of 'Unix pipelines but with objects'.
The bet on "everything is an object" was a honest and competent one, but unfortunately it didn't work. "Everything is a file" works better on practice. Unfortunately, that was the last real attempt on Windows to improve things.
Yes, the lack of diversity in OSes is bad. But Windows doesn't fix it. (Android and iOS were the last large attempt of innovation there, and implemented some really good things, but it's also useless to have the OSes completely managed by large corporations that antagonize both their customers and society as a whole.)
With the right interface, the object approach can be more pleasant to use. Administration via PowerShell is way more consistent than in Bash.
Unless you meant OS/2? My understanding is the original intent there was very much to make everything an object,and the UI fully composable based on that ( in the sense of being able to link things together semi-arbitrarily, like pipes, only they never got that far )
But that's based on a half remembered article from years ago, I may have that completely wrong.
Agree with the other post that PowerShell's object view of the environment is pretty nice - not always a panacea of course, but mostly highly functional and productive
Plan 9 was supposed to be the better designed UNIX all around and it did not even dent it. It wasn't significantly better that UNIX to displace it.
http://www.catb.org/esr/writings/taoup/html/plan9.html
> We know what Unix's future used to look like. It was designed by the research group at Bell Labs that built Unix and called ‘Plan 9 from Bell Labs’.[154] Plan 9 was an attempt to do Unix over again, better.
> The long view of history may tell a different story, but in 2003 it looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
UNIX was also written to run on minimal hardware. Even if Multics had been open-sourced, UNIX would still have won.
https://distrowatch.com/dwres.php?resource=links
It's just that they don't have market share or a raison-d'etre for widespread adoption.
I would actually not even compare it to them, and just say it's flat out Radical.