Codeberg Terms of Use[^0] makes it clear that it's only for "projects covered by a licence for free and open source software, free and open source hardware, or free cultural works", and "You must not share projects that mostly consist of code written by "generative AI"-tools". They also only provide private repos where the FOSS system need it for their infra or what not, and not just for any purpose.

These are totally fine for Codeberg to do, and it's wonderful for FOSS!!

However it is not a viable place for many projects that are on GitHub/GitLab now and would want to migrate, say: any commercial project, that would need "permission-free" private repos, or when the teams want to decided themselves how much generative AI their developers should use, not their Git-hosting provider...

So yeah, different ballpark.

[0]: https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse...

[0]: https://en.wikipedia.org/wiki/Dymaxion_map

And it's just funny for what details the brain is unable to suspend disbelief...

- earthquakes: these can arrive indeed before you even feel them (a few seconds before); they filter it to areas where it's expected to be felt, there are discussions around how sensitive to make it (how wide area it should cover)

- extremely heavy rain: this was new recently, and very useful, when locally it all went cats & dogs, more than maybe I've ever seen. See an example here: https://fosstodon.org/@imrehg/117058657161401667

- military drills: the yearly "if there's an invasion drill", they had sent reminder a week before, and then at the start/end; example here: https://fosstodon.org/@imrehg/117030180601973598

- Chinese rocket launches that will fly over the island (not sure what could one do about it, and never seen anything, so maybe this is more borderline)

Interestingly (for me), the headers seems to change over time. Started with "Presidential Alert", there were "Government Alert" then, now "Emergency Alert" and just "Alert". I'm not sure if there area list of these or it evolved over time...

I do wonder what would have happened if some months later they do actually find a contract, maybe slid between a filing cabinet and a wall... Absence of evidence and evidence of absence, aye?

Also enjoy Stallman's title, President and Chief GNUisance, which he definitely tried very hard to live up to, with that reply. (And I won't fault him for that. :)

The second I didn't say it's any of llama.cpp's "fault", but it is _related_ to llama.cpp since it's being shipped in another system, aye?

Can't stick to the old hash either, because older version have different bugs. E.g. on older versions the same Qwen3.6 model reliably fails to call specific tools due to template issues, while just having the newer llama.cpp version has that fixed. So different versions - different bugs, rather than no bugs.

Why the beating you are trying to gimme, mate? :)

As much as I can tell, the ROCm version of llama.cpp would be a bit faster on prompt processing, but about the same on the token generation as Vulkan. Real life benchmarks don't seem to give any "ROCm or nothing" sort of vibes. And the difference between the performance of different models are way bigger than the difference between the llama.cpp versions (and versus different runtimes like the llama.cpp/GGUF and the MLX runtimes on Mac for the same models)...

I've tinkered enough with the serving, that I'd rather do something with them with, say 10% slower speed, than spending hours on seting things up again... YMMV

Two examples:

- https://github.com/ggml-org/llama.cpp/pull/25863 Someone's few lines change broke the native (ROCm) support for the AMD GPU inside Framework (and other integrated systems), and any rollback or proper fix is pending for almost a month. Fortunately there's workaround (switching to Vulkan rather than ROCm devices), but both the way the bug was introduced and the way it is not fixed just doesn't give much confidencen

- LM Studio is using llama.cpp internally for GGUF, they ship their own build with their closed source system as "runtimes". Their ROCm runtime does not enable the the AMD GPU inside the Framework, even thought the llama.cpp version would support it. So their runtime keeps telling me that there's no supported AMD GPU -- again, the solution is to use the GPU with the Vulkan devices. Not fixed since Jan at least https://github.com/lmstudio-ai/lmstudio-bug-tracker/issues/1...

I guess overall it's the worst runtime I've seen so far, except for all the other runtimes out there... I'm a fan, though in some cases I don't have enough knowledge, or I don't have access to fix things, and that feels like a bummer...

The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too).

But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)

Also, haven't realised that it was off for almost a month (the email is from 13th July, so I guess few others have realised it either way, if it just makes its way to HN).

If it was a truly world representation, this might be different. But if things like health are sacrificed (ie. no WHO access either), I don't think they really deserve the benefit of the doubt.

[0]: https://en.wikipedia.org/wiki/Taiwan_and_the_United_Nations

As others mention it - it seems to shows the Watts used as well :) (and network, and GPU, and disks,....)

[0]: https://github.com/aristocratos/btop

This is a blast from the past. Centaur was doing VIA Technology's CPUs, and I was at VIA (in Taiwan) while this author was in Centaur (in the US). I was on the embedded side, but I remember some distinct collaborations with the US team, so there's a non-zero chance to have crossed path.

I've done a couple of checks, and it seems very marginally better on some local benchmarks I'm running, but it's not super scientific evaluation.

I still use the MTP version as it _feels_ slightly better quality, and because the unsloth quantizations I can get have more variety to fit into the various systems at hand... but that's not for the MTP aspect, unfortunately.

In the article they did have ~2x performance on the 27B (which might be something to retry, though on my Framework that would bring it from 5 -> 10 token/s so still "excrutiating" speed, probably).

YMMV for sure.