Slashdot Mirror
MenuetOS, an Operating System Written Entirely In Assembly, Hits 1.0
angry tapir writes: MenuetOS, a GUI-toting, x86-based operating system written entirely in assembly language that's super-fast and can fit on a floppy disk, has hit version 1.0 — after almost a decade and a half of development. (And yes, it can run Doom). The developers say it's stable on all hardware with which they've tested it. In this article, they talk about what MenuetOS can do, and what they plan for the future. "For version 2.0 we'll mostly keep improving different application classes, which are already present in 1.00. For example, more options for configuring the GUI and improving the HTTP client. The kernel is already working well, so now we have more time to focus on driver and application side."
I'm not reallyd sure that I understand that point. To me, thst would sound reasonable for educstionsl Ãr entertainment purposes, but are there any other meaningful reasons for writing an entire OS in assembler?
It's an object lesson in using pure assembly. By the time you get anything useful done, technology has moved on.
Not really. I have some computational code that I wrote in assembly 4 Pentium architectures ago. Every new architecture I run it against the C implementation, freshly recompiled with a current compiler. The assembly is still faster given all the hardware and compiler improvements. Now the performance improvement is getting much smaller but it is still a win.
I wonder what use they're thinking at all. Minix 3 is a step forward: were we to port Linux interfaces for udev, kevents, and such onto Minix, we could drop a Linux userland onto it wholesale, with systemd and all, and benefit from a core operating system which lends itself to drastic rearchitecting.
Consider that running Minix as an OS-level virtualizer--OpenVZ, LXC--is a trivial task, one which requires only providing a different network server and different security features (e.g. users and groups, and their flow through the file system driver and such), largely doable on the existing code base. You could even run Xen on top of Minix with a minor tweak.
Consider that Minix is a collection of services which may be extended by adding other services. It is interfaces and features, not tightly-bonded kernel code. The shape and form of the OS can be changed without commitment: to add services to handle Linux services is not to change Minix, for you may simply not use those services; you could instead add services to make Minix pretend to be OpenBSD. You could replace its threading model or scheduler by swapping out a service, providing a system that uses the advanced features of DragonflyBSD.
There, again, we see a step forward: DragonflyBSD, with its non-locking semaphores, its highly-efficient threading model, its ability to freeze an application and thaw it after a reboot, to checkpoint running applications--a feature Minix does not possess, but could simply by adding a new kernel service--and even to move applications between machines. Extending some of these things would be to bring the features of OpenMOSIX: check pointing and running an application on a different boot cycle or different machine brings the magic of scheduling applications across a cluster of machines acting as one.
Why, then, do we persist in creating these tinker toys, instead of extending, cannibalizing, or imitating those things which show real progress? Why has Minix not embraced the great strides forward made by Linux and integrated its interfaces so as to integrate its user space in distribution? Why has Linux not subsumed the threading model of Dragonfly BSD? Why has someone chosen to create an OS to no purpose, rather than to create a unified system carrying and integrating the lessons from all prior systems?
Support my political activism on Patreon.
And you're assembly is probably easy to beat with even pretty crappy SSE2 code.
Apparently not by compilers.
You don't seem to understand the purpose of writing in assembly language. Its not to optimize for the current state of the art box. It is to get acceptable performance from old legacy boxes. Some assembly in the right spot(s) can make the difference between an old architecture making the cutoff in terms of acceptable performance, of being able to include that segment of the market in your minimum system requirements.
My point is that such optimizations for the sake of the old boxes doesn't necessarily do any harm to the new boxes. That worrying about future architectures is a red herring of sorts.
Check out the memory footprint of Linux sometime.
Two megabytes. Four, really, when using a single 4MB huge page to allocate the entire kernel in one go. A few bytes to maintain each task's information, each cached disk page, each handle held by an application.
Linux uses so little memory you can run it on a microcontroller with a megabyte of RAM. When you build up all the services needed to supply network management, graphical systems, user log-on, audio mixing, and so forth, you get maybe 100MB. When you then run a Web browser and go to a few open tabs, you need a gigabyte or three.
Support my political activism on Patreon.