Is that you, Dave Cutler?

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.

QNX got a lot of things right, mainly in the area of interprocess communication. Interprocess communication came late to Unix/Linux, and it shows. Microservices under QNX work much better than under Linux. Interprocess communication is fast and works like a synchronous function call. Hard real time actually works with QNX. But QNX had nothing new on the database side.

My concern isnt about Windows or Linux specifically but that something is lost when the garden only grows two plants. In, say, 1980 there were several unique OS streams, each with their own quirks: UNIX, Pick, VMS, etc.

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.

Maybe it converged, just like other industries? Say, cars or planes have not fundamentally changed in decades. But would there be other designs that would make them so much better that it would be worth changing? That's not clear to me...

There's no money to be made in making an OS. Back when I was a child people were literally waiting outside stores for a new Windows. Windows 11 is given away for free.

We'll always have TempleOS ! /ducks (RIP)

RIM (The Blackberry people) bought QNX. Do you know, if they have been good shepherds? Has that helped, or disadvantaged QNX as a viable solution proposal in the project space it had?.

I'm not well informed. AFAIK customers like Porsche and Ford (with the fairly successful Sync 3 infotainment system) are still using it. I do know that Dan Dodge, QNX founder, developer 1 and great guy (speaker of my all time favorite conference keynote), has left Blackberry. Rumor has it that he was unhappy with the new leadership and direction for QNX.

The people at nixos and guix are doing it differently. No longer is the configurarion just state in files, scattered who knows where that cannot be understood fully by anyone. Insteady everything is defined centrally and then neatly versioned and managed by the system. If you think the unix way of throwing files in a directory sucks, check them out!

Unfortunately, Nix's documentation sucks. Plus, there's a steep learning curve to the Nix programming language. I don't understand why they couldn't just use a language instead of inventing one that is only usable within the Nix system.

Overall, really cool idea (dropped my jaw when I first saw it in action), but poorly implemented.

Wouldn't say there's a steep learning curve for the language itself, it's pretty easy to get a grasp around it imo. Here's a helpful page I used to quickly get familiar with the language: https://github.com/tazjin/nix-1p

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-...

I think it's all too easy to say they should have just used an existing language. The most obvious feature of the nix language is that it's lazy, because they want their enormous collection of configuration dictionaries computed on demand. There are no mainstream languages that are lazy.

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.

This sounds incredible, assuming there's a clean way to pin versions/source of applications. It might make the fabled idea of a reproducible system possible.

They're already getting decent reproducibility of their curated package set, but some of us want to pin to a particular version of this, especially when creating our own private packages. That's where I'm finding I really want pinning.

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.

https://xeiaso.net/blog/nix-flakes-1-2022-02-21

Guix makes a big deal out of being fully reproducible. It is possible to pin versions, you basically state "I want package X while the guix repository is at commit hash Y". Every dependency of the package will be built and made available at the appropriate version and everything will work out. I used this to roll back fprintd when it broke due to a broken dependency and it worked without problems.

I get where you're coming from, but I think the biggest pro for the "UNIX way" is that text on a filesystem extremely accessible. You don't need a specialized tool to read & modify configuration, you just need a text editor. And while there's no standard for how the data is structured, it's usually pretty easy to figure it out from context.

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.

General Linux tools built for text, in a world where everything is plain text and the shell doesn't know how to navigate anything other than a file system. In PowerShell you can cd into HKEY_LOCAL_MACHINE as easily as any drive, and Select-String is perfectly capable of searching registry keys.

The baseline is only text and files on systems that don't have anything better to offer.

Isnt there FuseFS for that? It can show the gconf registry as a file tree, allowing you to use tools like recursive diff etc. https://metacpan.org/release/LSIM/GConf-FS-0.01

Something flexible like FuseFS is sorely missing on windows, the stuff google drive had to do creating a new letter drive is pretty gnarly.

You mean https://docs.microsoft.com/en-us/windows/win32/projfs/projec...?

Interesting, I hadn't seen that. Did Google Drive go with the virtual drive letter thing mainly for backwards compatibility to older windows?

> The baseline is only text and files on systems that don't have anything better to offer.

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.

Not really, if it’s a .NET assembly Powershell can dynamically load, call and use types from it. Not to mention first-class support for standard data interchange formats like JSON, XML etc without having to convert back/forth from text or use tools to process it.

In a few situations, actually calling .NET code from PowerShell doesn't suck, like setting persistent environment variables.

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'.

Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life.

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.

> Windows and macOS dominate because 99.9% of users do not care about the difference between registries, file systems, text or binary tools, UNIX-like, POSIX, etc… none of these things matter to them! They just want to use a computer and get on with their life.

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.)

The registry does not impact those users' experience. Needing to learn how to use a shell, does.

I would disagree that it does impact users' experience because when the registry gets corrupt you have to start by installing Windows from scratch. Nothing like Windows 10 update disabling registry backups to save space on low capacity storage and finding out after the fact when attempting to recover Windows 10.

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.

Windows these days works extremely well with just taking out the hard drive and placing it into a different computer, even across different processor brands completely different hardware etc.

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.

The registry does not get corrupt. This is not a thing that happens without the system files themselves being corrupted. People blame any old problem on the registry the way they blame any old problem on /etc. Nor, in the case of an actual registry problem, do you have to reinstall Windows from scratch; restoring the registry from backup is the entire point of system restore points, which are created on every update and most program installs. As a bonus, yes, I did upgrade my computer that way. This stuff is pure superstition.

I've reinstalled Linux due to borked sound on update way more times than I reinstalled Windows due to corrupt registry.

And cumulatively I spent significantly less time on Linux than I did on Windows.

I'm not saying the UNIX philosophy is the "best" way, I'm just stating why it's valuable.

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.

What good does having a non-UNIX OS do if it insists on doing everything worse than UNIX?

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.)

> 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.

With the right interface, the object approach can be more pleasant to use. Administration via PowerShell is way more consistent than in Bash.

In what way did it "not work"?

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

The problem is that UNIX, while it reeks, it's good enough for most people to not care about it.

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.

I think also that BSD (and later Linux) made UNIX free, and I assume Plan 9 was not.

UNIX was also written to run on minimal hardware. Even if Multics had been open-sourced, UNIX would still have won.

UNIX has been free since V6, that is why it got adopted by everyone, and then AT&T sued Berkley when they got the opportunity to actually be allowed to charge for it.

I agree on this. There may be better ways to do things, but people are so sure that UNIX perfected everything 50 years ago that the alternatives don't get explored. Personally I'm not convinced that plain text is naturally better than other options, because what even constitutes plain text? We have ways of encoding our languages into bits on a disk, but without a decoder it really doesn't have any meaning. So how is that different from any other way you can encode data? Isn't the important thing that we have tools that make it easy and consistent to work with the data?

Actually there are lots of exciting non unix OS.

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.

Be and Morph are worth a look.

It's interesting though that "boring UNIX" has survived, while most non-UNIX operating systems have gone the way of the Dodo ;)

I'd complement it: the fact "that as of today Windows is the only non UNIX OS" AND "this fanatical love of the UNIX way" sets us back.

TempleOS is radically different than either Windows or Unixy OS's.

I would actually not even compare it to them, and just say it's flat out Radical.