131–140 of 205 posts
This completely blows my mind, but also seems a natural fit considering the SGI lineage of the N64. It's like a super budget IRIX workstation ;P
But the N64 only has 4MB of ram, I think a GUI would be beyond it's capabilities. Still a cool project though.
Earlier quoted context omitted.
Fascinatingly, quite the opposite! For example, the original Macintosh had only a small fraction of that to work with, at 128 Kilobytes![1] Certainly a modern GUI a la KDE, Gnome and friends would be well outside of its abilities, but a functional GUI is possible on a shockingly small amount of memory! [1]: https://en.wikipedia.org/wiki/Macintosh_128K
Ok I should have clarified that, I meant available Linux GUI's in reference to OP and IRIX. You'd have to create something from scratch. I don't think you could cram a GUI on par with IRIX in 4mb.
Earlier quoted context omitted.
Linux wasn’t always this bloated. My first Linux system had 3 megs of RAM. This was back in 1993. A 386SX laptop with 1 meg on the motherboard plus a 2 meg expansion. I could barely run X.
I would argue that it isn't Linux that is bloated. Linux is the kernel. It is the desktop environments and the things added to them to make each distro distinct (and fat). There are significantly less bloated desktop environments, but people like their bling, and bling by default includes an accompanying increase in resource consumption. Look at Raspbian. It looks pretty good, but uses a lot less resources than gnome…
> "But why", I hear from the back. Having Linux available makes it easier to port emulators and fb or console games. > Most importantly, because I can. Good. All I can say is at least it is something different to what I keep seeing on HN. (React, Rust, Kubernetes, JAMstack, JavaScript, etc.) Probably present this somewhere in a conference (CCC, FOSDEM, etc). Who knows who could be looking at this.
Earlier quoted context omitted.
OS design methodology doesn't really have anything to do with its suitability for constrained environments. There are plenty of small monolithic and microkernel designs around.
I would argue that a microkernel would be a good fit because: "Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space." - https://en.wikipedia.org/wiki/Microkernel You want to throw out as many functionality as possible to get your kernel down in size to fit into e.g. 1 MiB of memory.
If you don't need those functions, you can remove them from kernel space in a monolithic kernel. It's possible to build Linux without TCP/IP support and with no on-disk filesystems.
Earlier quoted context omitted.
You assume microkernel means small, which is a bad assumption. Microkernels can be fat too, There are dozens of monolithic kernels smaller than the average microkernel.
There are always exceptions to the rules. As from Wikipedia: "In terms of the source code size, microkernels are often smaller than monolithic kernels. The MINIX 3 microkernel, for example, has only approximately 12,000 lines of code". But to satisfy your definition needs, I refer to small microkernels.
Earlier quoted context omitted.
There are always exceptions to the rules. As from Wikipedia: "In terms of the source code size, microkernels are often smaller than monolithic kernels. The MINIX 3 microkernel, for example, has only approximately 12,000 lines of code". But to satisfy your definition needs, I refer to small microkernels.
The kernel is small, because all the extra stuff is outside the kernel. It's still stuff that exists and consumes RAM.
If you have a very small microkernel, then you can very explicitly only install the software in user space that you need, without having them pre-installed via kernel.
Earlier quoted context omitted.
Don't forget the many ways in which Machine Learning will revolutionize X.
Could it finally revolutionize porting Linux to new architectures?