This is fantastic. The problem with Linux is the dev culture at the top. I've long wished for an alternative kernel project that might serve as a better dev model. This has the potential.
A lot of the top maintainers have probably been in that role for too long. 30-40% fresh blood (read: replacements) within a few months would probably do wonders.
Nice! Looks like an interesting mid-point between xv6 (modern reimplementation of Sixth Edition Unix from 1975 e.g. Lion book) and a full Linux kernel.
Great to see it runs on the LicheeRV Nano, a $9 RISC-V board with 1.0 GHz 64 bit CPU (C906) with MMU, FPU, 128 bit vector unit (RVV draft 0.7.1) and 256 MB of in-package DDR3. That's comparable to a midlife Pentium III or PowerPC G4.
It should be a very easy port to the Milk-V Duo 256M (same SG2002 SoC) or Duo S (SG2000 with 512 MB RAM for $9.90) or original Duo (closely related CV1800B with 64 MB RAM for $5).
No network or block device support at present, and no multi-core either, by the looks.
It is interesting, although the lack of multiuser support is unfortunate. I really hope that the author reconsiders his stance on multiuser support, even if it is merely to allow things like chmod/chgrp to set file ownership to other users and groups. That would open the door to hosting a NFS server.
Very nice. Its great to see how fast it boots, and it can run doom (framebuffer): https://www.youtube.com/watch?v=Ce1pMlZO_mI (also nice to see the dev takes the time to reply to an aspiring CS student on what it takes to grow in this field - comments in youtube)
A kernel is mostly "hardware drivers" with an ABI.
That's why performant "standard" hardware programing interfaces are so much important. Those interfaces should be the simple and stable in time as much as possible.
Many hardware realms have such _performant_ interface: nvme, usb, etc.
Basically it means DMA, doorbells/IRQ "ring buffers", command ring buffers("queues").
Because for those alternative kernel initiatives, this would allow them to become 'real-life' much faster.
And a NOTE related to RISC-V hardware: keep an eye on arm piggybacking RISC-V chips(they are the bad guys with their blocking/$$$ intellectual property), but the target goal does include AV1 video dec/enc blocks instead of mpeg, and DisplayPort instead of hdmi, because those are hardly less worse than arm.
And some hardware is going even further, the "next step": user level hardware queues (look at AMD GPUs which started to implement those). I know there is 3D pipeline programming behind this hardware interface, but I believ that if they started to clean the base hardware interface, they will cleanup their 3D pipeline programming too.
15 comments
[ 2.5 ms ] story [ 38.1 ms ] threadTilck is not like that!
Tilck is a real operating system. It runs on real hardware.
The space for the former is overly crowded but I think Tilck really fills a gap that has been mostly unoccupied before.
Great to see it runs on the LicheeRV Nano, a $9 RISC-V board with 1.0 GHz 64 bit CPU (C906) with MMU, FPU, 128 bit vector unit (RVV draft 0.7.1) and 256 MB of in-package DDR3. That's comparable to a midlife Pentium III or PowerPC G4.
It should be a very easy port to the Milk-V Duo 256M (same SG2002 SoC) or Duo S (SG2000 with 512 MB RAM for $9.90) or original Duo (closely related CV1800B with 64 MB RAM for $5).
No network or block device support at present, and no multi-core either, by the looks.
3 years ago, 75 comments. https://news.ycombinator.com/item?id=34295165 (no riscv64 then)
5 years ago, 7 comments. https://news.ycombinator.com/item?id=28040210
That's why performant "standard" hardware programing interfaces are so much important. Those interfaces should be the simple and stable in time as much as possible.
Many hardware realms have such _performant_ interface: nvme, usb, etc.
Basically it means DMA, doorbells/IRQ "ring buffers", command ring buffers("queues").
Because for those alternative kernel initiatives, this would allow them to become 'real-life' much faster.
And a NOTE related to RISC-V hardware: keep an eye on arm piggybacking RISC-V chips(they are the bad guys with their blocking/$$$ intellectual property), but the target goal does include AV1 video dec/enc blocks instead of mpeg, and DisplayPort instead of hdmi, because those are hardly less worse than arm.
And some hardware is going even further, the "next step": user level hardware queues (look at AMD GPUs which started to implement those). I know there is 3D pipeline programming behind this hardware interface, but I believ that if they started to clean the base hardware interface, they will cleanup their 3D pipeline programming too.