alexrp (u/alexrp) - Readit News

alexrp commented on Milk-V Titan: A $329 8-Core 64-bit RISC-V mini-ITX board with PCIe Gen4x16 cnx-software.com/2026/01/... · Posted by u/fork-bomber

IshKebab · 24 days ago

I don't think you'll be able to get away from custom distros even with RVA23. It solves the problem of binary compatibility - everything compiled for RVA23 should be pretty portable at the instruction level (won't help with the usual glibc nonsense of course).

But RVA23 doesn't help with the hardware layer - it's going to be exactly the same as ARM SBCs where there's no hardware discovery mechanism and everything has to be hard-coded in the Linux device tree. You still need a custom distro for Raspberry Pi for example.

I believe there has been some progress in getting RISC-V ACPI support, and there's at least the intent of making mconfigptr do something useful - for a while there was a "unified discovery" task group, but it seems like there just wasn't enough manpower behind it and it disbanded.

https://github.com/riscvarchive/configuration-structure/blob...

https://riscv.atlassian.net/browse/RVG-50

alexrp · 24 days ago

> You still need a custom distro for Raspberry Pi for example.

Are you sure that's still the case? I just checked the Raspberry Pi Imager and I see several "stock" distro options that aren't Raspbian.

Regardless, I take your point that we're reliant on vendors actually doing the upstreaming work for device trees (and drivers). But so far the recognizable players in the RISC-V space do all(?) seem to be doing that, so for now I remain hopeful that we can avoid the Arm mess.

alexrp commented on Milk-V Titan: A $329 8-Core 64-bit RISC-V mini-ITX board with PCIe Gen4x16 cnx-software.com/2026/01/... · Posted by u/fork-bomber

irusensei · 24 days ago

I feel this is becoming a bit of a tech urban legend such as ZFS requires ECC.

As far as I understand the RVA23 requirement is an ubuntu thing only and only for current non LTS and future releases. Current LTS doesn't have such requirements and neither other distributions such as Fedora and Debian that support riscv64.

So no, you are not stuck running custom vendor distros because of this but more because the other weird device drivers and boot systems that have no mainline support.

alexrp · 24 days ago

I'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available.

It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.

alexrp commented on Milk-V Titan: A $329 8-Core 64-bit RISC-V mini-ITX board with PCIe Gen4x16 cnx-software.com/2026/01/... · Posted by u/fork-bomber

alexrp · 24 days ago

Most people would be better off waiting for the multiple RVA23 boards that are supposed to come out this year, at least if they don't want to be stuck running custom vendor distros. "RVA23 except V" at this price point and at this point in time is a pretty bad value proposition.

It's honestly a bit hard to understand why they bothered with this one. No hate for the Milk-V folks; I have 4 Jupiters sitting next to me running in Zig's CI. But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).

alexrp commented on Zig quits GitHub, says Microsoft's AI obsession has ruined the service theregister.com/2025/12/0... · Posted by u/Brajeshwar

tacker2000 · 2 months ago

To be fair this has more to do with Github Actions than Github, which from the beginning was never really going to rival any professional solution.

The people at Zig should use proper CI tools and not something that a big service provider is offering as an afterthought.

alexrp · 2 months ago

Our CI workflow literally just invokes a plain old shell script (which is runnable outside CI). We really don't need an overcomplicated professional CI/CD solution.

One of the nice things about switching to Forgejo Actions is that the runner is lightweight, fast, and reliable - none of which I can say for the GitHub Actions runner. But even then, it's still more bloated than we'd ideally like; we don't need all the complexity of the YAML workflow syntax and Node.js-based actions. It'd also be cool for the CI system to integrate with https://codeberg.org/mlugg/robust-jobserver which the Zig compiler and build system will soon start speaking.

So if anything, we're likely to just roll our own runner in the future and making it talk to the Forgejo Actions endpoints.

alexrp commented on Zig quits GitHub, says Microsoft's AI obsession has ruined the service theregister.com/2025/12/0... · Posted by u/Brajeshwar

aperture147 · 2 months ago

I don't get it, why did they allow GitHub bot to modify and merge pull request automatically? Yeah I agree that MS is ruining everything with AI, but this problem is avoidable, if they turn off the bot's auto merge feature, or turn it off completely. The reason they move to a lesser known Git provider sounds more like a marketing stunt.

alexrp · 2 months ago

> The reason they move to a lesser known Git provider sounds more like a marketing stunt.

We had technical problems that GitHub had no interest in solving, and lots of small frustrations with the platform built up over years.

Jumping from one enshittified profit-driven platform to another profit-driven platform would just mean we'd set ourselves up for another enshittification -> migration cycle later down the line.

No stunt here.

alexrp commented on LLVM-MOS – Clang LLVM fork targeting the 6502 llvm-mos.org/wiki/Welcome... · Posted by u/jdmoreira

Sharlin · 2 months ago

Pretty sure that the prospects of successfully pitching the LLVM upstream to include a 6502 (or any 8/16-bit arch) backend are only slightly better than a snowball’s chances in hell.

alexrp · 2 months ago

Worth noting that LLVM has AVR and MSP430 backends, so there's no particular resistance to 8-bit/16-bit targets.

alexrp commented on Migrating the main Zig repository from GitHub to Codeberg ziglang.org/news/migratin... · Posted by u/todsacerdoti

emrah · 2 months ago

Codeberg repo took only an eternity to load. So much for “snappy”.

alexrp · 2 months ago

Hug of death followed by a DDoS. At the time of me writing this, it loads instantly again.

alexrp commented on Migrating the main Zig repository from GitHub to Codeberg ziglang.org/news/migratin... · Posted by u/todsacerdoti

networked · 2 months ago

> We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.

That's great. I hope it works out, and you have CI for NetBSD, OpenBSD, and illumos, too.

Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.

It's a shame GitHub doesn't have native CI even for FreeBSD on x86-64. I can see the economic case against it, of course. That said, the third-party Cross-Platform GitHub Action (https://github.com/cross-platform-actions/action) has made Free/Net/OpenBSD CI practical for me. I have used it in many projects. The developer is currently working on OmniOS support in https://github.com/cross-platform-actions/omnios-builder.

alexrp · 2 months ago

> Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.

In fact, we do already have cross-compilation support for NetBSD (and FreeBSD). But we currently only "test" NetBSD by building the language behavior tests and standard library tests for it on Linux, i.e. we don't actually run them, nor do we build the compiler itself for NetBSD. Native CI machines will allow us to fill that gap.

As it happens, Go's cross-compilation support does indeed make our lives easier for provisioning CI machines since we can build the Forgejo Runner for all of them from one machine: https://codeberg.org/ziglang/runner/releases/tag/v12.0.0

alexrp commented on Migrating the main Zig repository from GitHub to Codeberg ziglang.org/news/migratin... · Posted by u/todsacerdoti

wg0 · 2 months ago

If voiced and channeled properly, I see very little chance of Microsoft and Github wouldn't prioritize fixes for a critical open source project.

Yes issues have been filed but more could be done back channel.

Personally - I think GitHub is a cultural artifact now. Of the entire planet. Hackers and curious minds from Japan to Alaska and everything in-between flock to GitHub.

alexrp · 2 months ago

As I pointed out in a different comment, even IBM have to maintain a GitHub Actions runner fork with s390x support because upstream just cannot even be bothered to accept the relevant patches: https://github.com/uweigand/runner

If IBM cannot get Microsoft to work with them on something so small but impactful, there's no chance we can.

> Personally - I think GitHub is a cultural artifact now. Of the entire planet. Hackers and curious minds from Japan to Alaska and everything in-between flock to GitHub.

And it's in the hands of a for-profit company pushing LLM nonsense. That should be alarming! Let's instead encourage people to use platforms managed by non-profits.

alexrp commented on Migrating the main Zig repository from GitHub to Codeberg ziglang.org/news/migratin... · Posted by u/todsacerdoti

PunchyHamster · 2 months ago

The arguments seem... really weak ? They just linked to some random obscure bug and an obscure OS not being supported in containers (and I'd imagine solution being "just bring your own runner").

I have... questions about Zig leadership

alexrp · 2 months ago

> obscure OS not being supported

Believe it or not, there are platforms outside of the big 3.

The GitHub Actions runner does not work on FreeBSD, NetBSD, OpenBSD, and illumos, all of which are operating systems we either have existing support for, or intend to start supporting properly soon. (We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.)

And that's ignoring CPU architectures; the upstream GitHub Actions runner only supports x86 and aarch64. We had to maintain a fork that adds support for all the other architectures we care about such as riscv, loongarch, s390x, etc. We will also likely be adding mips64 and powerpc64 to the mix in the future.

Even IBM have to maintain an s390x fork because Microsoft can't even be bothered to accept PRs that add more platforms: https://github.com/uweigand/runner