Always love hobby operating systems which leave UNIX and POSIX behind. It's really a shame that we're slowly converging on POSIX being the basis of _all_ operating systems since it forces some bizarre and undesirable design decisions [1]. Dropping POSIX and building something new gives us a chance to actually explore novel ideas in operating systems design.
The cloud OSes have long left classical UNIX behind, Kubernetes or managed languages on top of type 1 hypervisors are the name of the game, even if there is some POSIX based kernel somewhere on the stack.
On the mobile side, although Android and iOS have some POSIX support, it hardly matters for app development.
Even on macOS, which is a certified UNIX, if you want access to some of the modern networking APIs, they are only exposed at Objective-C level.
So while POSIX kind of has won, long term it has been yet another phase in the history of computing, thus looking forward to such alternatives.
> In this paper, we argue that fork was a clever
hack for machines and programs of the 1970s that has long
outlived its usefulness and is now a liability.
I have really fond memories of playing with this sometime around 2005.
I would download as many ISOs as I could get my hands on during the week at one parent’s house (where we had the better PC and broadband) and then at the weekend staying with the other parent I would try out all kinds of linux distros and hobby OSes.
Menuet was incredible to me at the time, it was fast as hell. I played with it for hours and probably would have stuck with it over the crappy Win ‘95 install if not for the fact it basically didn’t have any useful software at the time. It was great fun to tinker with and explore though.
I’ve come across it every few years since and I’m always happy to see it still worked on.
The author seems to be violating the GPL with Menuet64? Menuet64 is pretty clearly a derivative work of Menuet32, which is GPL. However, Menuet64 is released under a non-free license.
Originally I believed the author may be the sole author of Menuet32, and thus could relicense to whatever they wanted. However, the release notes (https://www.menuetos.net/relnotes.htm) credit many other authors with their contributions.
No, M64 was never free, as far as I can tell. I remember stumbling over M32 around 2006, when I was interested in OS development while being a CS student. I kept interest, and some time later a 64 bit version was published, but no source code, unfortunately.
The project kept growing a bit, very slowly. Seems like after v1.00 the author lost most interest. So if it is still a prototype work without any commercial usage, it would be great to have it published with source code.
It blows my mind (in a good way) that people are still posting this to Hacker news. I remember writing code for MenuetOS in both my Operating Systems and Hardware classes in ~2002. Love it!
The numbers are not for through latency (-> audio interface -> cpu -> audio interface ->)
Instead they are for "half-duplex" latency (-> audio interface -> cpu OR cpu -> audio interface ->).
The 48kHz number represents a buffer size of 32 samples, which is entirely possible with Linux and macOS. The note also does not indicate how h/w specific these numbers are: there can be many h/w level issues with very low latency numbers that can't be solved by the OS (a classic example is a wifi chipset or video interface hogging the PCI bus for too long). On the "right" h/w, 32 samples for input latency is not really that remarkable.
What would be remarkable is if MenuetOS can get this performance from arbitrary intel hardware.
by the creator of flat assembler[1] or community, if i am not mistaken. not an assembly programmer, but the syntax of flat assembler looks clean and nice.
I would expect it would boot and work fine. Drivers is where most hobby OSes fall down. Your sound card might not work. Or your USB chipset etc. And hobby OSes like this often do a lot of things in software that are available in hardware, which ruins their performance.
Well, it's of course a slight exaggeration, but our desktop computers have had hardware support for virtualization for a long time now. Even our GPUs are getting hardware support for virtualization. Does it really have to be a problem any more that "your operating system has no drivers for this thing"?
That's a very cool project for tinkering. It's a small niche, especially that it's written in assembly, it limits the scope of the things one can play with. But nevertheless, it's a very enriching experience as well as a very unusual one.
Same. And to be honest, since I played with it as a teenager, MenuetOS pretty always come to my mind when I see how we waste computing ressources nowadays.
Of course I know that MenuetOS fitting in a floppy is more a challenge for the author than something we should aim for for regular software. But still, I sometimes calculate in my mind "how much MenuetOS floppies is this" when I download and use some basic app written in Electron. Even a lot of websites are heavier than that.
I think MenuetOS and a modern app are two extremes and I say to myself that we should aim for some just middle.
Has anyone here used this as their main OS (or at least made some reasonable use of it rather than simply "install to check it out")?
I'm always curious to install and try out such "alternative" OSes, but usually the novelty wears off quite quickly, as the bar to using it for anything nontrivial is usually too high to justify the time investment.
Probably standard legal copy. Most if not all proprietary EULAs have something like that. More interestingly, they're invalidated by the laws that permit RE in many countries.
...and on a somewhat related tangent, look at how many appliances have a "do not open/no user-serviceable parts inside" warning.
A purist might prefer to say that it needs to be "assembled" and that "disassembly" is prohibited; but I don't think many people these days would quibble that the assembler -> machine code process isn't "compiling".
Assembly language is still a textual, human-friendly language where you can give memory locations symbolic names, you use mnemonics for the different machine instructions, many assemblers have various forms of macro support, etc. That all gets "assembled" or "compiled" into the machine code.
Thought that something like this would be good as a pre-boot environment. A lot smaller than EFI and perhaps more functional. Though debatable how good an idea that is. Guessing most folks don't want to program asm however.
[1] https://www.microsoft.com/en-us/research/uploads/prod/2019/0...