Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
noone_youknow
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
by
noone_youknow
2mo ago
This is open-source hardware, caveat emptor is implied. At this stage in a project like this, I’d expect the people who were getting boards fabbed to also have the skills to sanity check the schematics and layout before they sent the gerber
2.
▲
by
noone_youknow
2mo ago
For me, one of the saddest side-effects of modern generative AI is this apparent rise in an attitude of “I don’t know how to do this, therefore anyone who does this must have just one-shotted it with AI”. Even if we assume this _could_ be o
3.
▲
by
noone_youknow
5mo ago
It isn’t, actually.
4.
▲
by
noone_youknow
5mo ago
There would likely be value in a POSIX layer as you describe, at least from the point of view of porting existing programs. And perhaps it will happen, if I get far enough along, but it will never be a kernel feature - it would be an entire
5.
▲
by
noone_youknow
5mo ago
Thank you! A project like this is all about compounding small wins for sure, just building one thing on top of the previous thing until (hopefully) one day it’s a complete thing :D I’m glad you found some inspiration and really appreciate y
6.
▲
by
noone_youknow
5mo ago
I agree that for it to be generally useful, it’ll need to be easy to port existing software to. But I don’t think I’ll need a translation layer at the syscall level (unless I want to expose a Linux-compatible ABI as you suggest, which is to
7.
▲
by
noone_youknow
5mo ago
Haha that quote felt pretty much obligatory :D Non-POSIX is definitely keeping things fun, letting me explore different ideas without having to fit into an existing interface design :)
8.
▲
by
noone_youknow
5mo ago
Thanks! I haven't thought much about long term to be honest, right now my immediate goal is to get enough USB HID to be able to make it interactive, with the medium term goal of porting enough software for it being self-hosting.
9.
▲
by
noone_youknow
5mo ago
> We live in an age of AI overinvestment. I would reserve judgement until they prove they actually have something. Haha yes, that's a very fair comment!
10.
▲
by
noone_youknow
5mo ago
There's ideas in here from various other kernels - some of the capability stuff is inspired by (but simpler than) seL4, and the message passing IPC and how I'll avoid priority inversion is based on ideas from QNX. Generally as a l
11.
▲
by
noone_youknow
5mo ago
That's a good way to look at it, and on reflection I feel the same way. It's certainly useful _to me_ and has helped me really nail down concepts I thought I already understood, but it turns out I didn't. I just hope that, in
12.
▲
by
noone_youknow
5mo ago
Ahem, well, that's embarrassing! :D
13.
▲
Show HN: Anos – a hand-written ~100KiB microkernel for x86-64 and RISC-V
(github.com)
115 points
by
noone_youknow
6mo ago
|
32 comments
14.
▲
Bring receipts from your Claude Code sessions
(github.com)
4 points
by
noone_youknow
7mo ago
|
1 comments
15.
▲
by
noone_youknow
11mo ago
It is hard, and things are messy in some areas. But in my experience it’s less hard than writing a lot of the existing documentation would’ve been (because good datasheets and documentation are more available now) and actually less messy (w
16.
▲
by
noone_youknow
11mo ago
This is really great work! Always impressed to see hobby OS projects that get this far, well done. That said, I’m once again reminded that we sorely need some updated resources for aspiring OS developers in 2025. Targeting 32-bit x86 and le
17.
▲
by
noone_youknow
1y ago
Well put! This succinctly sums up the crux of my argument in my other comments.
18.
▲
by
noone_youknow
1y ago
Even taking only x86_64 as an example, going from real to long modes is primarily of concern to those writing firmware these days - a modern operating system will take over from UEFI or a bootloader (itself usually a UEFI executable). The d
19.
▲
by
noone_youknow
1y ago
While I agree this might be a fun resource and useful example code for various aspects of legacy x86 interfacing, I would urge anyone who hopes to actually get into OS development to ignore this (and in fact every other tutorial I’ve ever s
20.
▲
by
noone_youknow
1y ago
Sorry for the confusion, I was referring to the putchar not being implemented in OPs code, I got yours working right away (nice work btw). What you mention about VGA being common on x86 was what got me curious, since it’s not a thing on ris
21.
▲
by
noone_youknow
1y ago
Thanks! I see that you’re using the SBI routines, which is what I was expecting here but couldn’t find - the reference to “output text to VGA” in the post made me curious. I did see the putchar stub in the user.zig but, lacking understandin
22.
▲
by
noone_youknow
1y ago
Nice work! Looks like most of the basics are covered, and meanwhile in my current kernel the RISC-V entrypoint is >700 lines (of C) just to get to the arch-independent entrypoint! I was just looking around for your input/output co
23.
▲
by
noone_youknow
1y ago
Same here. I got a Bambu X1C and have been very happy with it.
24.
▲
by
noone_youknow
1y ago
Thank you! At this early stage, the filesystem exists only to prove the disk drivers and the IPC interfaces connecting them. I chose FAT32 for this since there has to be a FAT partition anyway for UEFI. The concept of the VFS may stick arou
25.
▲
by
noone_youknow
1y ago
> It's a bit disappointing that every time somebody decides to write their own kernel, the first thing they do is implement some subset of the POSIX spec. Well, not quite _every_ time. For example, I’m deliberately not doing POSIX w
26.
▲
by
noone_youknow
1y ago
It’s a very noticeable step down from cursor in terms of AI integration IMO, but also a huge step up in almost everything else. For a while I was running both cursor and RubyMine in tandem and switching between as needed, but lately I’ve be
27.
▲
by
noone_youknow
1y ago
Our wonderful government “news” agency trying to legitimise this while also playing lip-service to balanced reporting: https://www.bbc.co.uk/news/live/cwy05zznyplt?post=asset%3A3e...
28.
▲
by
noone_youknow
1y ago
Nice article! Always good to see easy-to-follow explainers on these kinds of concepts! One minor nit, for the “odd corner case that likely never exists in real code” of taken branches to the next instruction, I can think of at least one exa
29.
▲
by
noone_youknow
1y ago
This fits my experience. I’m definitely getting considerably better results with 4 than previous Claudes. I’d essentially dropped sonnet from my rotation before 4 became available, but now it’s a go-to for this sort of thing.
30.
▲
by
noone_youknow
1y ago
I agree with this. Just the need to keep track of stack, flags and ad-hoc register allocations is something I’ve found they really struggle with. I think this may be why it does so much better at porting from one architecture to another - b
More ›