While this is ridiculously cool, I think the project missed an opportunity by tying itself so tightly to x86 assembly. A system that is usable with 8MB of RAM? Hell yeah. Except you're not going to find a lot of PC hardware this under-powered; these kinds of systems are actually getting more expensive, as they're slowly getting relabeled as "vintage". You can of course run this on a much more powerful machine (say 1GB of RAM and maybe even a second core), but at that point you could also opt for a more featureful OS like OpenBSD or Haiku, which will actually make better use of the extra resources.
But what if you could run Kolibri on a tiny, DIY, microcontroller-based computer? An ATmega or Cortex-M0, throw in some SRAM and I2C peripherals, run it off a couple of AA batteries and browse the web on that? That'd be ludicrously cool.
ESP32 has no display hardware even if it is more powerful than many computers of the 80’s those did come with dedicated graphics/display cards.
Modern display signaling takes a lot of compute power simply due to the sheer complexity of it and even emulating something like VGA over I/O pins would eat most of not all the compute power available on an MCU.
So you’re essentially stuck with a terminal over the network with an ESP which if you again make graphical would cost more in rendering and stream compression than there is compute so you’re stuck with text based terminals.
You can run a passable GUI over SPI using displays with an integrated frame buffer. LVGL in particular is a GUI lib optimized to render strips of updated data rather than full frames and it performs well with such devices.
Yes, I've been doing that. LVGL is amazing. Still, I'm waiting for the time when we have a GUI-based OS available. The possibility of running scripts that work as apps from a memory card and so on.
My apologies but that statement is the same as saying that a Pentium IV has no display hardware. You are right that a CPU has no display card but missed the point because we speak here about support for running an OS on that CPU in connection with peripherals.
Don't even understand what you mean with "a lot of compute power". We've been using LVGL for GUI apps and playing movies on these devices since a long time just fine. Here is a demonstration of that board: https://www.youtube.com/watch?v=0AVyvwv0agk
I've been wondering for a long time when we're going to get an open OS for making app-capable ESP32 stuff. We've got the Cardputer and the t-keyboard, the hardware is there.
This stuff even has mesh networking, and yet we still don't have Cybikos!
This is the floppy to bring onto the DeLorean. Relatively, today that would go to the early nighties. Pop that into into the Aptiva/AST, and go blow your own mind with this, and probably the timeline too.
This reminds me the time when Linus said that linux will be hard to port to other architectures, since it is tightly coupled with the 386 architecture...
Just shows that he didn’t have much knowledge of other platforms or didn’t have much vision about where his project would go. Fact is if you squint enough every modern system looks like a VAX. The same abstractions fit nearly every architecture.
> Yep. I imagine adding support for different CPU architectures will be... well good luck with that.
Extremely hard indeed, probably more like a 95% rewrite. Might however make sense as a killer application for small ARM or Risc-V boards where Linux would be either overkill or too demanding.
> Except you're not going to find a lot of PC hardware this under-powered
You don't need a machine with exactly 8MB. Nowadays having 1GB RAM is under-powered enough that you'll probably have more fun with Kolibri than with a regular OS.
A cool DIY computer project could be a free re-creation of computers of the past. I believe it would make sense re-running the path of computer history, but pushing more and more open-source in it. You already can buy a NuXT, based on Sergey Kiselev's work to provide DIY resources to create a PC XT computer (including the BIOS).
I thought someone could enlarge the design to a more modern architecture when I found an old Compaq internal documentation showing the internal design of the first commercially available 80386 computer (Compaq Deskpro 386). I have just posted the reference on HN: https://news.ycombinator.com/item?id=38480275
Such new re-created computers would certainly be interesting to run legacy software, but it would also be very interesting to have modern and light-weigth software like KolibriOS (I know it requires a Pentium or more, but there is certainly little to change to downgrade to 80386).
Thank you. I have been interested in micro vms (as a layman curious) since I've heard of firecracker but was never able to find any similar projects. Maybe i should have been looking for nano vms. Cheers.
> What sort of "opportunity" did authors miss? They're not a business.
From GP:
> Except you're not going to find a lot of PC hardware this under-powered; these kinds of systems are actually getting more expensive, as they're slowly getting relabeled as "vintage"
Yeah but it’s hard to find the hardware this OS is designed for. There’s little need for it. Compared to the oodles or low powered arm boards out there that would love this. So the missed opportunity is just that a lot of effort has gone into a very narrow platform that would probably be more appreciated on a diff platform
It's a shame that the embedded x86 market died with the Geode and the C7, for a while you could legitimately find fairly cheap embedded devices with x86 chips under the hood.
Oh, very nice :) Even higher-res than what I found. Thanks! Didn't expect someone at ETH Zurich to host these wallpapers. I like this version without the spaceship a bit more.
Yeah, thanks! Found the name of the game at around the same time you answered me, and was able to access the actual screenshot with Web Archive. The original includes a small spaceship which is missing on the KolibriOS version.
If you like the art you should try and play Cosmic Osmo! It was my favorite game to play on the Performa PowerPC macs my elementary school had. It’s a very short and silly game made with hypercard. The creators later made Myst using the same technology.
I should, yeah, just saw that it's available on Steam :) Would probably be the oldest game I've ever played. Well, except Pong, Tetris etc.
> The creators later made Myst using the same technology
Tried to play Myst as a 10 year old, but wasn't smart enough to figure it out. Maybe Cosmic Osmo is more on my level ;) Really want to try it out this weekend, according to Wikipedia it was a pretty revolutionary game. Also never heard of Hypercards before today (the last Hypercard update was released the year I was born).
Perhaps I'm selling them short, but I was under the impression that both are hobby projects done for their own sake, so it's not really "wasted" effort.
Isn't hobbyist effort still effort? Human labour, being duplicated?
This is a feature of many FOSS projects, sadly, and I don't really get what aspect of human nature drives it, but it must be something.
Not counting efforts where someone forks an old version because they don't like where the team are taking the new version (Trinity vs KDE, MATE vs GNOME)...
There are 2 current forks of Mandriva doing much the same: Mageia and OpenMandriva. (There are others but with deeper differences.)
Claws is a fork of Sylpheed, both continuing separately.
Cinnamon, the Zorin OS desktop, and GNOME Flashback are all doing more or less the same things with the same codebase.
Hobbyist effort is human labor for the hobbyist's benefit, not someone else's benefit.
If the Kolibri OS folks experience unique enjoyment from developing this project that they would not obtain from Menuet OS, then the labor would not be duplicated.
The other examples you give are all software that people use "in the real world" as a means to solve problems. The value comes from using them. The developers may also enjoy working on them, but that's mostly incidental.
I can't speak for the kolibrios contributors, but I imagine that to them, the value comes from the development process itself. They do it because they enjoy it. Any practical usefulness of the resulting software is mostly incidental.
If your goal was to develop useful software in 2023, you wouldn't be writing pure x86 assembly within the constraints of a floppy disk.
> Isn't hobbyist effort still effort? Human labour, being duplicated?
This is a feature of many FOSS projects, sadly, and I don't really get what aspect of human nature drives it, but it must be something.
The reason why Kolibri forked is precisely because MenuetOS stopped being F/OSS when they made the transition to 64-bit while simultaneously advertising the 64-bit version as "the future" and 32-bit as legacy.
Not if you had a hard drive. I can't find a decent video on YouTube showing how long booting from a hard drive took. Does anyone know of one? Otherwise I might have to get a pile of junk out of my loft and record a video myself. From memory, I'd say my A1200 with IDE disk took about 10 seconds to boot - from power on to sitting idle in the Workbench GUI.
An early Archimedes booted directly into the GUI from ROM and was even faster.
10 seconds with a hard drive sounds plausible. Still, I would prefer a 1-second instant-on like with the C64 (ok, not a GUI). In practice though, Windows waking up from S4 hibernation is actually pretty good, only 3-4 seconds on my desktop PC.
Reportedly pretty much stable after a few earlier iterations - there's no mention in The Register article about boot time - but I'd imagine crap stripping has to speed things up.
But just because you can does not necessarily mean you should. For one, Tiny11 2311 is not free – you will need a Windows 11 license. Microsoft also does not support it, and the company could easily roll out an update that comprehensively breaks the project.
the hard part here is to find a floppy disk... (or something to read it)
but it is refreshing to see some effort done to have some some small size OS for general use.
Even if so, ARM or RISC-V are more attractive architectures in many respects; and there are proof of concepts demonstrating that very lean operating systems with GUIs can be built with high-level languages, even with GC (see e.g. https://github.com/rochus-keller/OberonSystem3/); so writing such a thing in assembler is certainly impressive, but also a cul-de-sac.
When the original project, MinuetOS, was started, RISC-V didn't exist yet and I don't think ARM was common enough. Even when this was forked from MinuetOS four years later the status quo hadn't really changed. If anything, it was moving more toward x86 because Apple was switching away from Power at the time.
I don't think the lack of portability is much of a hindrance tbh. Portability doesn't seem to have been a goal of the project at all, so I'm not sure why we're judging it on a criteria they don't care about.
> so I'm not sure why we're judging it on a criteria they don't care about.
It's not judging, but wondering and regretting that architecture independence was not a requirement. Personally, I have started in the late nineties to free my projects from the dependencies (or rather "shackles") of specific platforms and vendors. This has more than paid off. Otherwise, a large part of my many years of work would have been lost.
There are different philosophies regarding software development. The project as it seems follows Chuck Moore's idea which says one must re-write more often (vs abstract away, patch over, extend above etc.), and be more focused on particular usages (vs betting on hypothetical future cases) to keep software unbloated, quick, and truly navigable by developers. Apparently, this approach is far from being popular (majority of devs probably doesn't even know such thing exists) because programmer's time has been very expensive for decades. So code quality, speed, and especially size became much lesser concern compared to time spent. But people do practice it as an art form in non-commercial projects, and to enhance their skills in optimization. Writing a whole OS with GUI, and apps in FASM apparently is one of such exercises.
You can (and in some cases should) also rewrite and simplify code written in a plattform independent high-level language. And even Forth has re-usable parts not written in assembler (though re-use and generality aren't Chuck's thing).
You're absolutely right to do it. There's one platform that's for all intents and purposes not portable (Windows) that has been extremely successful, but outside of that no one has survived by being wedded to only one architecture.
I guess its a lesson for all those companies on ARM: always have a plan B.
Well, at least there are many independent chip providers, and that they use the same ARM architecture (i.e. detail design specifications, etc.) even has the advantage that tools and know-how are re-useable by the companies using these chips (and that each of these chip providers has the ARM detail design at hand is even an advantage compared to RISC-V, where "only" the ABI is open source); in contrast MS is indeed a single provider keeping the source code of most of its products closed (which virtually makes it a potential "single point of failure" for a large market).
Both Windows NT kernel API and Windows userspace API are designed to be portable across processor architectures, minus a few non-essential assumptions that are sadly assumed to be invariants by some userspace applications.
Trying it out in https://copy.sh/v86/?profile=kolibrios , it's also clearly a love letter to Windows 95 in particular. That could be an unstated goal here, create a very particular PC experience under very particular constraints.
I don't know anything about the creator but it's very possible that this kind of work was actually their career in the 90s. Most of the people who built those experiences are still around today, and not all of them have the visibility of Dave's Garage.
It's incredible how much work was done. Maybe this should be an internet curiosity like how TempleOS has become, though Terry's personality was a unique factor.
In some ways, ARM and RISC-V are also way less attractive architectures. The level of platform standardization is very small compared to x86. Market penetration (in personal computer market) is still small.
By relying on x86 standardization (BIOS, VESA, ACPI...), KolibriOS can run on pretty much any PC without having to write a lot of platform-specific code. OTOH take some ARM machines - MacBook, PineBook, Raspberry Pi - what do they share in common besides ISA?
I tried running it on MacOS Sonoma on Intel using UTM but it always loads to a black screen, regardless of the video settings I use. Did anyone have better luck with UTM?
Probably because the so-called "low level" work and skills are underrated:
Have you ever wondered why your modern computer makes you wait for so many things? ... while you or other people were doing so many of the same things like 30 years ago on computers hundreds times slower.
Is it that your computer is getting old? ... No way! Hardware does not slow down when aging: software does. And it does because most developers have no idea of what happens under their feet in lower software and hardware layers - or worse, they just do not care.
I am so sure we would get so much better software if most developers were skilled in so-called "low level" stuff... Because "low level" skills are exactly the opposite: they are high level skills.
Because the people building it find value in doing so.
Why does someone learn woodworking and make a chair when they can buy one from a store? Or why do they come up with their own design when they could follow someone else's plan?
Creativity can be a lot of fun, particularly when not bounded by practical concerns.
But what if you could run Kolibri on a tiny, DIY, microcontroller-based computer? An ATmega or Cortex-M0, throw in some SRAM and I2C peripherals, run it off a couple of AA batteries and browse the web on that? That'd be ludicrously cool.