Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C (github.com)

by hpscript 43 comments 102 points
Read article View on HN

43 comments

[−] m132 42d ago
The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them can run [1]. The bootloader is also a stub [2]. Not a single exception vector table, but plenty of LLM-style comments explaining every single line.

Others (well, two people really) have also noted the lack of a linker script, start-up code, and that the project doesn't even build.

82 points at the time of writing, which is 4 hours from the post's submission. Already on the main page. The only previous activity of the author? Two other vibe-coded projects of similar quality and a few comments with broken list formatting, suggesting that they were never even reviewed by a human prior to posting.

Does anybody read past the headline these days? Had my hopes higher for this site.

[0] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...

[1] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...

[2] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...

[−] bschwindHN 42d ago
HN these days is filled with people saying basically "Show HN: I had an LLM shit out something I wanted, I didn't read it, but you should!".

And then a bunch of green new accounts commenting on how it's cool and they learned something. It's just a never ending attack on our attention.

[−] mbernstein 42d ago
HN used to provide a really high signal to noise ratio for me, but it's degrading pretty quickly. There are new accounts below saying "hey I just learned what RTOS means, thanks!"

I reflexively reload HN many times per day, but I'm wondering if I need a walled garden with some sort of curation of individuals - which sucks - to get the signal level I want.

[−] onetimeusename 41d ago
This probably isn't just an HN problem (GH's model is broken now). It's so cheap to make software that the previous process of releasing something new associated with a person is probably outdated. AI knows what sounds impressive too. So now we're drowning in software releases and attributing software to a person is meaningless.
[−] Retr0id 42d ago
I wish HN upvote data was public, I feel like I could build some kind of improved algorithm that reduces the vote weight of people who upvote slop.
[−] the_biot 41d ago
This site is very much drowning in all the slop. It's over half of posts now I think, not just the "Show HN" posts. Those are 100% slop, as are all the non-show-hn new project announcements.

All the moderators have done is drop Show HN posts by newish accounts. It fixed nothing. I have to hope they have some ambitious plan along the lines of what you suggest.

[−] sornaensis 41d ago
As a rule people do not read the linked content, they come to discuss the headline.

The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.

[−] m132 41d ago
Honestly, maybe this is the problem.

A web-of-trust-like implementation of votes and flags, as suggested below, might be a solution, but I feel like it's an overkill. I've recently flagged a different clickbait submission, about Android Developer Verification, whose title suggested a significant update but that merely linked to the same old generic page about the anti-feature that was posted here months prior. Around 100 points too, before a mod stepped in, changed the title, and took it down.

Maybe the upvote button is just too easy to reach? I have a feeling that hiding it behind CSS :visited could make a massive difference.

[−] Retr0id 42d ago
Don't forget the 71 stars on github, and counting!
[−] m132 42d ago
Oh wow, was 60 just a while ago. Guess the dead Internet theory is no longer just a theory.
[−] hpscript 42d ago
Hi HN,

I’ve been working on a tiny RTOS as a personal project to better understand how operating systems and schedulers work internally.

This project includes: - Basic task scheduler - Context switching - Simple memory management - Runs on (your target hardware or environment)

Motivation: I wanted to learn OS internals by building everything from scratch rather than relying on existing frameworks.

Challenges: - Implementing context switching correctly - Designing a minimal but usable scheduler - Keeping the codebase simple and readable

I’d really appreciate feedback, especially on: - Architecture design - Scheduler implementation - Code structure

GitHub: https://github.com/cmc-labo/tinyos-rtos

[−] bahmboo 42d ago
Impressive! Very complete on first glance. You might want to soften or qualify the RTOS statement so people focus on its compactness and low latency. As you are already seeing in the comments the RTOS aspect has a lot of opinions depending on what one is trying to accomplish.
[−] peteforde 42d ago
Very cool! Thanks for sharing.

I would appreciate an honest comparison with FreeRTOS. Building something like this is an excellent learning exercise for the coder, but someone who has to balance the risks, learning curve and feature set has to justify the adventure in a different way.

One thing that would be interesting to hear more about would be your own recounting of the places where you made opinionated decisions about how things should work.

[−] maximusdrex 42d ago
Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code. You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.
[−] m132 42d ago

> Runs on (your target hardware or environment)

Nice try, OpenClaw

[−] Retr0id 42d ago
Did you never even try compiling it?
[−] nofunsir 42d ago
What ever happened to μC/OS?

Seemed both well documented and well suited to have taken over for the current MCU explosion. I almost never see anyone talk about it.

Looks like it open-sourced in 2020.

https://github.com/weston-embedded

[−] jockm 42d ago
Question: Do you mean real time, meaning there is some kind of expectation of task switching time, nothing can stop other threads from executing, etc; or do you really mean embedded?
[−] tvst 42d ago
I thought this was about UC Berkeley's TinyOS: https://github.com/tinyos/tinyos-main

This was a big deal in some academic circles in the early 2000s

[−] nurettin 42d ago
There is already a TinyOS in the sensor networks space. I've used it with MicaZ motes over a decade ago.

https://github.com/tp-freeforall/prod

[−] throwawaypath 42d ago
Interesting this kernel implements kernel message queues, which are almost never used out in the wild. Are there any examples of popular software projects that use POSIX/SysV message queues?
[−] onetimeusename 42d ago
How much of this was by AI?
[−] synergy20 42d ago
this reminds me of: https://github.com/tinyos/tinyos-main more than one decade ago
[−] Yokohiii 42d ago
I have no practical insight on RTOS in general, if anyone bothers to give me a hint, please. From all what I've looked into, RTOS does mean to create software systems that are almost perfectly predictable and safe to execute. Predictable latency, runtime and memory usage, plus maybe side channels to do the unpredictable stuff in between. It's actual rocket science, as no systemic mistakes are allowed. The confusion is that this project doesn't mention any of it. Is it just hijacking of a fancy acronym, are there two worlds side by side or am I completely misled?
[−] jaylew1997 42d ago
Thanks for sharing