Search results

Back to the topic: I think the problem is not so much the language but the ecosystem. For Bcachefs in Linux, which will be rewritten in Rust, you'll need a specific version and apparently this needs to have both Clang & GCC installed. It must be a bootstrapping and maintenance nightmare...

They should migrate to the one based on LLVM like FreeBSD did. That CoC is based on the Contributor Covenant created by the same person who penned the Post-Meritocracy Manifesto. I have a deep distrust of all kinds of anti-meritocracy postures. PDVSA in Venezuela was explicitly meritocratic...

It's the ideal language for LLMs because it's anal about everything.

It has plenty of spaces like LWN. It also had Groklaw in the past when they had the water in the neck. And in the worst case scenario it wouldn't be hard to fix. We geeks should discuss geek stuff and leave lawyer stuff to lawyers.

The Linux Foundation has the Open Invention Network with lots of companies pledged not to sue for patents. They must have the same protection wrt licenses that only apply to original code anyway. It's not like Linus suddenly allowed vibe-coding in the kernel. Google also provides legal...

Technical lists are not the best place for philosophical & ethical discussions that by their very nature are endless, and this is considered a feature and not a bug. There's no single outcome that will satisfy everyone and I think that Linus' verdict is the right one because it will benefit the...

Colin Percival & Linus Torvalds disagree. They have found bugs that were decades old and pieced together exploits in novel ways. There's a huge asymmetric disadvantage for defensive security right now. It's irresponsible not to use LLMs to level the playing field.

LLMs are really good at: - Discussing ideas. - Generating skeleton code. - Creating unit tests. - Documentation. - Review. - Finding bugs. It's like having a second opinion, even a third. It's up to you if you want to also delegate the fun. We can throw the tedious parts to clankers. LLM...

I meant the FreeBSD code & license.

The source code is open and the license too. They could've done that already.

Please someone forward this to FreeBSD developers: https://claude.com/contact-sales/claude-for-oss

I guess they're fixing lots of stuff found with LLMs. You can help with testing. In RC6 they fixed a coredump that I reported in `efi -v`.

wget2 for simultaneous download. Accepts the same options as wget.

This can very well work. Only on Linux it seems not recommended to use a zvol for swap: https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html#using-a-zvol-for-a-swap-device-on-linux But needs careful investigation. On Linux I thought that zram was better than zswap and...

No. I tried experimenting with geom_uzip(4) and swap-backed md(4) but couldn't get much further.

This is very easy to fix now. Boot an installer image and go to the shell: To check the pools that ZFS detects: zpool import Optionally check any leftover labels: zdb -l /dev/$partition This is the command that fixes it all: zpool labelclear -f /dev/$partition

Just to report that I succesfully installed FreeBSD 16.0-CURRENT, NetBSD 11.0 & OpenBSD 7.9 on one drive, and DragonflyBSD 6.5.0 on the other. The RTL8125BG works on all of them.

The dirty comes from git and means changes that are not commited. Seems like someone or the build script just applied the patch against the git revision for 15.1 and then compiles, without doing a git commit. It's harmless but feels... dirty...

I'm happy that I could finally install OpenIndiana on the G3 Plus. Dual-booting with FreeBSD. Next step: NetBSD & OpenBSD in the same drive as FreeBSD.

Because of capitalism!1!