hckrnws
Interview With Ville Turjanmaa, the Creator of MenuetOS (2001) (1)
Ville Turjanmaa: The current distribution fits to a single floppy and I plan to keep the basic OS functions that way.
— Man of his word!
1. https://www.osnews.com/story/93/interview-with-ville-turjanm...
My friends and I used Menuet back in 2003 to circumvent our highschool's OS restrictions. Impressive to see it's still around, great project!
I was in 10th grade in 2003. Time sure does fly.
Note that the 64-bit version is not open source.
KolibriOS (https://kolibrios.org/en) is an active fork of the open source 32-bit version.
To be honest, while KolibriOS is open-source, I wouldn't call it "active" that much. MenuetOS has progressed much further than KolibriOS over the years in both performance (it has SMP support!) and being 64-bit.
You can check the commit activity: https://git.kolibrios.org/KolibriOS/kolibrios/commits/branch... - last commit on the first page is already 10 months ago.
And compare it to "News" on the MenuetOS page: - 22.01.2026 M64 1.58.10 released - Improvements, bugfixes, additions
- 26.08.2024 M64 1.53.60 released - MPlayer included to disk image
- 24.07.2024 M64 1.52.00 released - Partial Linux layer (X-Window/Posix/Elf)
- 12.07.2024 M64 1.51.50 released - New graphics designs by Yamen Nasr
- 08.05.2024 M64 1.50.80 released - Fasm-G, many 32 bit apps & sources
last commit was a week ago https://git.kolibrios.org/KolibriOS/kolibrios/commit/dd9a7b9...
I wonder why that is. I imagine there's a number between 0 and 1 that reflects how many people have an interest in stealing and commercializing this project.
it's okay to want to be paid for effort.
if one doesn't want to pay, one can use 32 bit (with all that entails, which, really, isn't much on the sort of machine you'd want to boot from floppy); if one wants 64 bit, one can pay?
i don't see a problem.
The license says it's free for personal or educational use. The only real restrictions prohibit commercial use, redistributing, reverse engineering, disassembling, and decompiling without permission. While that is a a lot less restrictive than most licenses, most of those restrictions are also rather curious. It pretty much negates the value of the software as an educational tool, reducing it to a technology demo.
Prohibiting disassembling is worth about as much as "do not open, no user-serviceable parts inside" warnings ---- you are a true hacker only if you ignore them.
I suppose it's relatively easy to make a compact OS which has barebone hardware capabilities: VGA / VESA framebuffer graphics, SATA, 1-2 NICs, USB2, x64 only. Early versions of Unix were tiny by modern standards. NeXT's GUI worked well on hardware which would be considered a toy today. They all already contained the key features which MenuetOS has. I suppose it's the support of a large number of advanced features (many CPUs, various filesystems, virtual memory + page cache, advanced IP stack, a ton of drivers) that makes a modern Linux kernel large.
Previous discussions:
2023: https://news.ycombinator.com/item?id=38059961
2023: https://news.ycombinator.com/item?id=37514601
2022: https://news.ycombinator.com/item?id=31290789
2021: https://news.ycombinator.com/item?id=28988778
2017: https://news.ycombinator.com/item?id=15427848
2015: https://news.ycombinator.com/item?id=9595507
2013: https://news.ycombinator.com/item?id=6309696
I believe I run MenuetOS once over decade years ago. Now it's 26 years old since its first release. I can only be jealous of such stamina and wish it prosperous years ahead.
Has it had any commercial success?
I noticed Menuet maybe twenty years ago and I recommended to the forum at the time to put it into a boot manager of some kind, a bit like a backup OS that could read docs and download a file, etc. Don't think they did. Today, I guess it might run from an ESP (efi system partition).
Interesting license: https://www.menuetos.net/m64l.txt
But this is how you distribute source without accepting contributions! :)
Where is the source? I only see driver and application source.
https://www.menuetos.net/64bit.htm I assume, I downloaded the zip, but haven't looked at it yet.
It's just the user apps and the drivers. No kernel/core OS codes, though.
Yeah, it says it’s drivers and applications only.
I guess it wouldn’t make too much sense prohibiting reverse engineering if there was the source code :)
I remember stumbling uppon Menuet when it was still 32 bits only, (probably around 2006?). I tried it, booting from an actual floppy disk at the time. Nowadays, I don't even know where I would find a computer that still has a floppy disk drive. Time flies.
I remember doing this too, a little bit later. It would churn on the disk for minutes on end, and usually fail. I think I got it to work once or twice.
Floppy disks and drives were plentiful, but scrap in those days. So of course those were the machines I got to play with as a kid at that time. Many of my disks were not in the best condition, or they were some of the post-2000s ones that were low quality to begin with.
I remember people were making various editions of "mini windows" 3.11 on a floppy disk around that time also.
I bought a USB floppy drive specifically to run MenuetOS on a floppy in like 2007, they still sell them.
i would say that some cd burning software has the ability to make the cd bootable by copying syslinux and whatever else you need - or a floppy image. So you could just use the boot part of the CD-R.
however, only one of my machines has a permanent optical drive, so even this is going by the wayside.
now-a-days if i'd personally use this sort of thing for thin clients, with bootp/etc https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsro... unsure if that guide is correct, i just skimmed it. I've done this before, but not for GUI, for compiler farms (distcc-pump, et al)
I'd assume you can get USB floppy drives for 3½" disks pretty cheaply. I think I might've even seen that in my BIOS settings as an option.
I wish my MBP M3 Max was snappy like that
Is it still snappy when you're loading an 1Gb document though? And is it as secure as macOS when opening untrusted content?
Lots a bloat are caused by inefficient programming, but not all bloat is useless.
I doubt you’d wish for it if the price was the limitations and incompleteness of MenuetOS. While hobby operating systems are great for exploring possibilities, you quickly bump into an endless stream of tiny frustrating inconveniences.
Pretty much it. An modern OS is more than just a window and file manager, 90% of the work is in all the edge cases that we take for granted.
On the one hand it is pretty cool that this exists.
On the other hand ... to me it always felt as if I'd waste too much time writing assembler code. I like being able to express thoughts and ideas, via code, in a more easily manner, e. g. ruby. Or perhaps another language that may be even more expressive (and fast at the same time; I am talking about C-like fastness or even faster, why can't we combine both?).
I also wonder how adjustable MenuetOS is. It looks as if the default theming in all those screenshots is quite basic, always fitting to just one style only. This may be ok in 1980 but I kind of feel that the world moved on, what with HTML/CSS being so dominating everywhere. In fact: any aspect of the OS that relates to design, should be easily adjustable by a user at any moment in time, just as it is with HTML/CSS (JavaScript I don't care as much for - it is a very poorly designed programming language after all).
Part of the skill and challenge of writing in Asm is knowing how to simplify your problem so that you don't need to write so much of it (and beneficially, so that the machine doesn't have to execute so much either.) For example, a typical programmer raised on HLLs would think nothing of allocating and freeing a string object, and then another, and then another just to concatenate them and pass the resulting value to another function, in a loop that processes some data. That's a few dozen bytes of source code that compiles into a few hundred or even kilobytes or more if you include the memory allocator. The Asm programmer would for instance realise that the first string is a constant and the second is only a single character, and just allocate statically a single buffer big enough for both, and only modify the single character in the buffer, turning what the HLL'er would need a few hundred instructions to accomplish into a single instruction; and then write the dozen bytes of source code for that instruction, compiling into a few bytes of binary.
Repeat this process for everything, and you can easily see how an OS that might contain 1GB of compiler-generated code could fit in 10MB of handwritten Asm.
I also wonder how adjustable MenuetOS is. It looks as if the default theming in all those screenshots is quite basic, always fitting to just one style only.
Early versions of Windows, even 3.x, were quite themeable, and the base OS was only around 10MB, mostly a mix of C and Asm; of course, the C parts occupied far more space, but it's not hard to imagine e.g. rewriting Windows 95 in pure Asm and having all that functionality including theming in 1/10-1/50th the space.
I used to uninstall unneeded items and delete useless folders, go without swap, and Windows 95 did everything I could ask for at only 35MB of storage space on the HDD.
Then installing Office 97 added another 85MB and I was in business.
>"On the other hand ... to me it always felt as if I'd waste too much time writing assembler code. I like being able to express thoughts and ideas, via code, in a more easily manner, e. g. ruby"
Old fart here. Never mind assembler. I've started with machine codes directly. Anyway early on I'd written fairly big programs using assembly. Was not too difficult. First you developing little functions, like a lot of the, and then you call those and along with using macro facilities it looks almost high level.
A similar project discussed a couple days ago: https://news.ycombinator.com/item?id=46866544
Not even close.
Crafted by Rajat
Source Code