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.
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.
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?
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.
The XP era security was a joke. I used to open notepad, bring up the dialog to open a file, right click on an executable that was "blocked" and run it from there.
I was once using a public library computer that was loaded full of malware despite all of the "security" software, and I asked the library staff if they were okay with me working around it, to could uninstall the malware. I was expecting that they'd defer to some policy only allowing the county IT department to mess with the computers, but instead they were excited that I new how to do so and had no complaints.
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.
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.
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).
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 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 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.
Try being frustrated by a really basic USB stack with no hot-plug USB support. Or by no unicode support, no vector fonts, or a multi-user security model. Is that frustrating enough for you? Okay, how about no process isolation or memory protection? Does that sound like macOS to you?
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.
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...
reply