[HN Gopher] Tilck: A tiny Linux-compatible kernel
___________________________________________________________________
Tilck: A tiny Linux-compatible kernel
Author : chubot
Score : 261 points
Date : 2025-07-16 03:50 UTC (19 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jlundberg wrote:
| The README was surprisingly lengthy and interesting. Worth a read
| for osdev people!
| adastra22 wrote:
| 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.
| marsven_422 wrote:
| The kernel dev culture is excellent, it's pure meritocracy.
|
| We all know that Rust in the kernel is a political operation to
| change this to woke.
| adrianN wrote:
| I'm not even sure what that's supposed to mean. Is it a joke
| that I'm not getting?
| yjftsjthsd-h wrote:
| > I've long wished for an alternative kernel project that might
| serve as a better dev model.
|
| Do you have something against FreeBSD, NetBSD, OpenBSD,
| illumos, Redox, or (if you don't need a unix-like) Haiku?
| adastra22 wrote:
| Linux syscall compatibility.
| Cloudef wrote:
| Doesn't BSD have that?
| cestith wrote:
| Some of them do.
| yjftsjthsd-h wrote:
| FreeBSD, NetBSD, and illumos have that.
| numpad0 wrote:
| Linux won BECAUSE of whatever dev culture at the top you
| mention, not DESPITE. There are plenty other more
| permissive Unix-like OS, and none are more relevant than
| Linux.
| peterfirefly wrote:
| 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.
| weinzierl wrote:
| Every couple of months a new "Operating System" kernel which does
| not provide hardware abstraction and only runs in a VM pops up.
|
| Tilck 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.
| userbinator wrote:
| Doesn't look like you can run WINE on it, which would make for an
| interesting Windows replacement.
| lukaslalinsky wrote:
| Why would you just not use Linux to run WINE. It's not
| realistic to replace all the drivers that make Linux so
| universally usable as it is. If you specifically want it as a
| Windows replacement, the Linux distro that Valve is building
| seems like the best bet.
| hnlmorg wrote:
| The readme explicitly states it's not suitable for desktop
| usage. For staters, it doesn't support all the features needed
| to run x11.
|
| This looks like a very interesting project for OS devs but if
| you're after a Windows replacement then there's already a few
| options out there from ReactOS to Linux-distros that come with
| Wine configured as part of the base install.
| ryao wrote:
| Details on what is missing that a X11 server needs are here:
|
| https://github.com/vvaltchev/tilck/discussions/81
| hnlmorg wrote:
| To be honest, that reads less like details on what's
| missing to port x11, and more like a frustrated exchange
| between a project author who's clearly stating what the
| project cannot do, and an overly enthusiastic member of the
| community who's vastly underestimated the amount of work
| required to run x11.
|
| Credit to the authors patience throughout that exchange,
| though. I've had similar exchanges with some of my open
| source projects too. It's great when people do want to try
| things but it can cost the author a lot of time and effort
| helping people on endeavors that you already know will fail
| and already know it isn't where you're time should be
| spent. And can be particularly frustrating when you know
| those participants are unlikely to contribute any code that
| would further the project's goals. But you still have to
| show them courtesy because the last thing you want to do is
| kill their enthusiasm for open source.
| Sammi wrote:
| Once you're running something as heavy as a desktop application
| or game, then the full Linux kernel is not the heavy part
| anymore.
| brucehoult wrote:
| 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.
| anthk wrote:
| A G4 with Altivec was almost on par on a PIV with SSE2 for
| multimedia.
| brucehoult wrote:
| Multimedia is important for some uses, not for others.
|
| And what speed G4, against what speed Pentium 4?
|
| G4 started from 450 MHz and went to 1.6 GHz, with several
| different uarch along the way.
|
| Conversely, the Pentium 4 ranged from 1.3 GHz to 3.8 GHz.
|
| G4 and P3 at least covered a nearly identical MHz range, and
| with similar MHz in the market at the same times.
| bayindirh wrote:
| Pentium 4 had an exceptionally long pipeline to be able to
| hit higher frequencies, trading-off high IPC numbers in the
| process, most of the time. On top of that, Pentium 4 also
| "looped" the same instruction while waiting data resulting
| in lower efficiency and higher heat output.
|
| So, I assume, they are "step by step" comparable. i.e.
| slowest P4 equal to slowest G3 and they are again equal at
| next stepping and so on.
| anthk wrote:
| Core Duo's are almost duct-taped PIIIs.
| bayindirh wrote:
| Isn't Core Duo is an evolution of Pentium-M which is an
| evolution of Pentium 3, omitting Pentium 4 in the process
| like an unwanted child?
|
| Feels like they rolled back a couple of commits, forked
| to a new branch and started over...
| hypercube33 wrote:
| The a version of the Pentium 4 was slower than the Pentium
| IIi per clock (launch model) and used goofy rambus memory
| anthk wrote:
| It actually was between PIII and IV on capabilities.
| Altivec allows to play h264 videos on some settings. A
| Pentium III, well, SSE and FFMPEG can do magic, but not as
| well as Altivec. SSE2 it's better, much better. Basically
| the minimum for x86 and 'modern' browsers.
|
| On the architecture itself, PowerPC did far more per cycle.
| seabrookmx wrote:
| I recall folks claiming the G5 outperformed Pentium D, but I
| had both and not only was the Pentium snappier, "Roxio Toast"
| could burn a DVD in half the amount of time on it.
|
| Maybe it was a software optimization issue and Toast just
| didn't use Altivec, but I was not surprised at all when Apple
| moved to Intel.
| weinzierl wrote:
| _" No network or block device support at present, and no multi-
| core either, by the looks."_
|
| The first versions of Linux I used did not have multi-core
| support and I can imagine a Linux without networking, but no
| block devices?
|
| Does that mean just character devices? How does the FAT driver
| work then?
| brucehoult wrote:
| It supports a read-only boot drive, but other than that just
| tempfs -- just like running a LiveCD version of Ubuntu etc.
|
| Implementing those things is on the TODO list.
| bitwize wrote:
| The earliest versions of Linux were pretty much just a
| terminal emulator for the PC console. Gotta start somewhere!
|
| It looks like TILCK uses RAM images to provide FAT support,
| which is mainly used for initrd.
| ryao wrote:
| 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.
| hnlmorg wrote:
| Its file system compatibility story is a bigger hurdle there.
|
| To be honest, you're much better off with a battle hardened
| platform for your use case. Tilck is meant to be educational,
| not secure in either the InfoSec nor data robustness sense.
| ryao wrote:
| Upon seeing this, thoughts keep occurring to me such as:
| * "It could be fun to be the author of a block layer, VFS and
| an AHCI driver for SATA. NCQ support is a must if I do."
| * "It could be fun to port ZFS: ztest and zdb, plus the
| userland version of the driver into which they hook need
| pthreads, but the important userland utilities do not. Having
| to statically link everything would be a pain. I would
| probably have to reimplement the entire SPL for this to work
| and that would probably be at least 10,000 lines of code."
| * "If I port ZFS, a NFS server needs to follow so ZFS has an
| application. This will need support for setting/getting
| user/group ownership and mode bits. If I rewrite the VFS, I
| could maybe sneak that feature into it for a NFS server to
| use while preserving the documented syscall behavior that
| requires everything be root. If I port the NFS server from
| illumos, it could share the SPL code with ZFS. NFSv4
| permissions will be needed to make it fully happy. Beyond
| that, I will need a network stack." * "It could be fun
| to port a network stack. Maybe LwIP could be used." *
| "It could be fun to write an e1000 driver."
|
| I have already found the documentation I need if I actually
| were to implement AHCI and e1000 drivers:
|
| https://www.intel.com/content/dam/www/public/us/en/documents.
| ..
|
| https://www.intel.com/content/dam/doc/manual/pci-pci-x-
| famil...
|
| If I were to do all of this, I would likely try my best to
| make it a production platform. The purpose would be fun.
|
| Anyway, I wonder if these thoughts will continue if I sleep
| on them.
| MonkeyIsNull wrote:
| Go for it. All that sounds like fun.
| hnlmorg wrote:
| If you're serious and the maintainer is willing to accept
| these contributions, then go for it.
|
| It's a lot of work but definitely rewarding stuff. And
| you'll learn a lot along the way too.
| gjvc wrote:
| Won't be big and professional like GNU
| hnlmorg wrote:
| Different era then.
|
| Your options were basically just:
|
| - GNU: which didn't have a kernel
|
| - BSD: which had massive question marks over ownership
|
| - Minix: which wasn't free back then
|
| - or a commercial Unix
|
| These days you have a dozen BSDs, Darwin, several
| OpenSolaris forks, hundreds of Linux distros as well as
| non-commercial licenses for many commercial Unixes. Minix
| is free. Free reimplementations of BeOS too. And that's
| before you count the plethora of free non-POSIX systems
| like Plan 9, ReactOS, and so on and so forth.
|
| And, ironically, there's now less of a need for competition
| in this space because web engines have replaced OS kernels
| for a lot of common use cases and WASM is fast becoming the
| new ABI.
|
| To be clear, I'm not saying this project has no merit. Nor
| am I saying there is zero chance this project might evolve
| into something big. I'm just saying that quoting Linus like
| you have is extremely simplistic.
| gjvc wrote:
| Your comment goes on and on about different variants but
| fails to see the germ of a good idea. Sorry to say.
| hnlmorg wrote:
| Oh I see the good idea. I also read their readme, which
| is how i know it's not yet ready to work as a file server
| ;)
| gjvc wrote:
| >Oh I see the good idea. I also read their readme, which
| is how i know it's not yet ready to work as a file server
| ;)
|
| this is called "judging a book by its cover"
| hnlmorg wrote:
| > this is called "judging a book by its cover"
|
| So you think they're lying about not having implemented
| block devices nor a network stack...? Or are you
| suggesting that NFS doesn't need network nor file system
| support?
| yjftsjthsd-h wrote:
| Could probably just record user:group in the filesystem and
| ignore it at runtime except when serving clients? Ex. a Linux
| file server running as root can still check permissions and
| ownership without having to change its own user. (Although as
| an interesting thought experiment, forking per session and
| switching to the client user _would_ give you file permissions
| for "free" by way of the kernel imposing them on you...)
| ryao wrote:
| As long as the VFS permits those calls to go to the
| filesystem driver, that is doable. A casual inspction of the
| documentation suggests that doing this will return an error
| from the syscall. I am not sure what a kernel driver calling
| the VFS can do in terms of getting/setting these yet.
| marto1 wrote:
| I can see it's marked "educational", but would it be also
| suitable for smallish embedded devices ? Assuming the bootloader
| part is swapped out, etc.
| rurban wrote:
| Previous discussions:
|
| 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
| CaseFlatline wrote:
| 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)
| bartvk wrote:
| Nice and short video. Demonstrates Vim, which seems like a
| sizable piece of software to get compiled with a subset of all
| Linux syscalls.
| sylware wrote:
| 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.
| netfortius wrote:
| For us, the "elderly", who grew up with Minix in the educational
| space, how useful is Tilck in this regard?
| cestith wrote:
| Tilck is a small and deterministic monokernel that currently
| implements around 100 Linux syscalls in a Linux-compatible way.
| It's a good educational tool, but is planned to be a Linux-
| compatible RTOS kernel. It currently supports statically linked
| binaries built against musl and boots and runs in about 3 megs
| of RAM.
|
| One of the goals is to be small enough and simple enough of a
| codebase to be useful for educational purposes. Another is to
| eventually be useful in production in embedded systems.
| hk1337 wrote:
| This is really cool. It reminds me of the running linux on a 3.5"
| floppy as a NAT firewall.
___________________________________________________________________
(page generated 2025-07-16 23:00 UTC)