We already had it in 1961 as ESPOL and NEWP.

http://www.liquisearch.com/burroughs_large_systems/algol/esp...

Followed by many others, before UNIX's adoption due to its source being available for free.

> I'm not sure I want another UNIX implementation.

Yeah, they just keep repeating what was already done and without much research besides adding mainframe features.

As Rob Pike puts it:

"We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy."

from https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...

What we really need are OSes that take the ideas from human-computer interaction from Xerox PARC and Viewpoints Research Institute and take them further into mainstream, using safe languages in the process.

> What we really need are OSes that take the ideas from human-computer interaction from Xerox PARC and Viewpoints Research Institute and take them further into mainstream, using safe languages in the process.

How are modern OSes prevented from using said ideas (which ideas exactly?) simply because they are a UNIX implementation?

http://pubs.opengroup.org/onlinepubs/9699919799/

Everything else is fluff, and could stay just like it was on UNIX System V.

Hence why for macOS, iOS, tvOS, Android and ChromeOS, having an UNIX kernel is just a matter of convenience, given their application models and programming languages.

Apple and Google could eventually migrate to something else as kernel while keeping their Objective-C, Swift, Java and JavaScript APIs.

NeXT based NeXTStep on UNIX as a door into the then new UNIX worksations market, but it never had a CLI culture like the other UNIX vendors.

GUI workflows like on Xerox PARC were always important to Steve.

Is your answer to my question: "Modern UNIX OSes cannot take advantage of said ideas because they are POSIX compatible."?

So, each UNIX clone project ends up replicating POSIX and doesn't move beyond what is actually yet another TWM clone with pretty graphics.

GNOME, KDE, Unity are the only ones that try to somehow modernize the experience and tend to get pretty vocal pushback.

The UNIX culture, is the culture of the command line and something like XFCE is probably the GUI a TWM user is willing to accept to manage its XTerms.

This is something that's been interesting me lately. I've been working with the excellent futures and tokio libraries, and I've wondered what would it be like if that was the primitive for all OS interactions?

Basically, imagine a message passing system like Mach, but where the fundamental messages are all futures based. There might be some interesting things possible without holding locks in the kernel.

Prove that an existing RTOS style library can be written with a simple scheduler working well.

That would go a long way to it gaining adoption in the embedded world, show that traditional solutions work correctly with the new language first.... then move on to an innovative OS.

In the case of this hypothetical OS idea.... Most of what people "would want" from an OS is a made up thing they can't really express. There is no working backwards from a generalization. You work backwards from concrete ideas.

Realistically, the OS everyone wants is "one that runs all of their software." They would prefer one that "doesn't crash." However, starting over with no real software is a non-answer.

This need not throw everything away that we have today. Why not make the equivalent of higher level bindings over a C API for command line programs? Or maybe any of a hundred other options that might improve over what we have now? Is unix really the end stage evolution for user space?

The solution is incrementally improving these things. What you're talking about is absolutely the kind of thing I'm interested in. Arguably PowerShell is one piece of the right direction. Show me a better way with compilers etc. and I'm interested (I work in Scala and compile time is a big issue, but I couldn't stand to have SBT as my framework).

> This need not throw everything away that we have today. Why not make the equivalent of higher level bindings over a C API for command line programs? Or maybe any of a hundred other options that might improve over what we have now? Is unix really the end stage evolution for user space?

If you've got a way to introduce one of those things incrementally, I'm interested.

I want an OS that's easy to program to the point I don't actually have to rely on third party software too much. This might be a pipe dream but I'm not convinced it's not achievable on some level.

> They would prefer one that "doesn't crash." However, starting over with no real software is a non-answer.

I'm trying to open a discussion about what ideas have been tried in the past, seem good, but for one reason or another didn't catch on.

Move that to other areas. My car? Forget about it. I could have a fighting chance at building a bike. However, to build a good one, not a chance.

So... why is this something that is even desirable in the computer?

Now. Do I want to be able to fix what I can? Of course. I run emacs, in part because I like that I can pull up the source, quite easily, of any component I am using. I still rely majority on code written by others. And have no shame or concern in doing so.

That's the point, you don't have much capability to alter the OS you are running. But you should. It's not unachievable but the languages, tools and OS (and maybe HW) have to come together to allow for this.

> Move that to other areas.

Computer is different from any of those since it's fundamentally a machine to model human mind. I always feel like my OS is somewhat restrictive as to what it lets me to do easily and what alterations it lets me to make.

> Now. Do I want to be able to fix what I can? Of course. I run emacs, in part because I like that I can pull up the source, quite easily, of any component I am using. I still rely majority on code written by others. And have no shame or concern in doing so.

Right. But the languages and tools that we use currently don't lend themselves to terseness and correctness. I think that that's the direction of future languages.

And i don't think languages really help here. Given that many advanced languages have products that are, again, beyond me.

Directly, what sorts of edits do you wish you could do, but feel prevented from doing?

Part of this is that setting up a development environment is kind of tricky.

> And i don't think languages really help here.

They really do actually.

> Directly, what sorts of edits do you wish you could do, but feel prevented from doing?

Imagine an OS where you can do something like "view source" with html, you can edit it, and immediately re-execute it. I think that the list of things I wouldn't look into tweaking would be shorter.

And that is the thing, I rarely want to. Or, I'll want to, but it isn't easy enough to do that I can get it done. Often, the thing I would like to do is a melpa install away. And the amount of code involved with many features is far beyond my skillset, it usually seems.

So can you give maybe a top 3 concrete examples of things you would change?

Do you mean view the kernel's source? Or user program source? Either way, this already exists, it's just often unsuitable for OS software.

http://squeak.org/

I basically want a simple RTOS and HAL/Driver body. I want timers and clocks. I want some block devices and perhaps file-system-primitives etc. I want TCP/IP and a USB stack. I don't want anything nearly as complex as a Unix, nor need it be Posix compliant etc. I would like it to be runnable from uboot, as it's ARM time now, and arm64 support should be a given.

I would think there is a substantial market for a minimalistic ultra-simple braindead-easy alternative to the "embedded linux" (LOL) wave that seems to be proliferating on all "a" class arm processors...

i need determinacy more than thoroughput, but a 64k ram microcontroller with 500mips isn't going to cut it either. there is a serious hole in the OS market for CPU's where *nix is overkill or unsuitable (and no, RTAI nor a realtime patched kernel count. the complexity of the entire codebase is still there)

I've heard about MirageOS from the oCaml people, but I have not been able to find out any info about timing and concurrency etc...

any info on edgy projects highly appreciated, please!

- strongly typed syscalls.

- easier way to circumvent the kernel / OS (unikernels are very active and tangible space, see HFT) while potentially staying relatively safe

- safe zero copy IPC

- projects like https://zinc.rs/ which fold Embedded Linux' Device Tree concept into a coherent declarative HW description that is consumable by the bootstrapper

Driver developer is soooo far out of my frield but it's always fascinated me. I'm curious why hardware companies didn't go with something like an interface for products versus these highly complex drivers; wouldn't it be possible for each type of device a group comes together, decides on an interface, and now anytime you plug a device in it would work (and if a specialized driver could be better you could install that separately but the goal is making everything magically work, immediately).

But since no one has done it I feel like my idea is either horrible or short sighted. But I do want to look into how it all works one day.

There really is not that much savings or advantage to this approach so there are not a lot of Open Firmware and EFI drivers out there. You really do not want hardware manufacturers writing drivers either - they tend to be terrible and full of bugs. Having the manufacturer publish the hardware specifications so that drivers can be easily implemented by developers is a much better approach, sadly a lot of manufacturers cannot be bothered with this.

-- sound cards being compatible with AdLib and/or SoundBlaster and/or SoundBlaster Pro;

-- network cards being compatible with NE2000;

-- video cards being compatible with VESA standards.

Then Windows took over, buses changed, the shitfest started and never stopped. And now the shitfest comes with NDAs too.

Accelerated graphics is probably the biggest remaining disaster, honestly. At least with Vulkan/DX12 we might be getting thinner drivers...