wezm

Yes hopefully it improves over time (or RISC-V catches up). I'm not sure the fan really needs to go as hard as it does, but I haven't found any way to control it.

I do my pitch. I say, “Look, I’m not a very good hardware engineer, but I’m a great user of AI.” I was one of the top users of [AI coding tool] Cursor last year. I did 43,000 agent runs and generated 25 billion tokens. We open my machine. Chris and I go line by line through the code. I don’t know the language that the code was written in because it was written in AI, so Chris actually explained the code to me.

They don't even know what the language is? Wow.

What does the "focus on the FreeBSD ecosystem" and "feels native to FreeBSD" mean in practice? I.e. are there FreeBSD specific features being utilised that prevent it working on Linux, or other BSDs?

- What's the package manager like, and how does it compare to say, pacman (especially in terms of update speeds and dependency handling)?

It's apk, so well known through Alpine Linux already. Dependency handling is elegant: https://chimera-linux.org/docs/apk/world

- What's it like working with dinit as opposed to systemd? Any annoyances, any compatibility issues with packages that expect systemd?

It's unremarkable in a good way. It works and I've not encountered any issues as a user. I've not run into any compatibility issues, most systemd units are usually easily translated. I kinda miss having a centralised journal. I think that's something q66 wants to address at some point.

- Similarly, what's it like working with the FreeBSD userland, as opposed to GNU? Any script breakages due to differences in the switches? Because virtually every other distro ships with GNU coreutils, I would expect a decent chunk of popular scripts to fail on Chimera, if they weren't writen with BSD in mind. This is currently my biggest concern with Chimera. I also wonder if I can replace the BSD utils with the Rust uutils and without breaking things...

Aside from the diff issue it's a non-issue. The Mac OS X userland is/was derived from them too, so there's already a lot of compatibility work been done. Most scripts that are intended to be run by a broad audience already stick to POSIX features.

Did DF ever allow comments on its own website?

Not that I'm aware. There's some discussion about it in this post from 2010:

https://daringfireball.net/2010/06/whats_fair

Might be worth giving these posts a read when thinking about a lightweight Rust:

- https://without.boats/blog/notes-on-a-smaller-rust/ - https://without.boats/blog/revisiting-a-smaller-rust/

It's also niche, but https://gleam.run/ might be a candidate alternate language, depending on your use-case.

I haven't tried it in OpenBSD but this article claims that it's mapped to Super+LShift+F23: https://www.tomshardware.com/software/windows/windows-copilo...

Thanks for the pointer to the aarch64 build of rustup. Are there plans to update this bit of the website to point at that version in the future? https://files.wezm.net/forums/Screenshot%202024-07-16%20at%2...

NVIDIA started publishing more of their driver as open-source in 2022, which while not hardware documentation probably helps a lot.

You may be wondering why Red Hat is bothering with this effort then? I assume it’s so that the code can be added to Linux directly as opposed to being out of tree.

https://developer.nvidia.com/blog/nvidia-releases-open-sourc...

Ahh whoops. Will fix in the morning, thanks.

Edit: fixed now (might take a few mins for the cache to expire).

It kinda does if https://www.typescriptlang.org/play#example/discriminate-typ... is what you're referring to but it appears to be missing one of the major benefits: an error/warning if you haven't handled all variants.

Edit: lots of replies showing how TypeScript can be made to do exhaustiveness checking. It's neat and all but it's a lot of gymnastics compared to languages that just have this built in, which again is part of the appeal of Gleam for me.

the Gleam aspect of this is inessential, TypeScript is quite good

TypeScript can be quite productive but I find its type system lacking. Specifically the use of structural typing/lack of nominal typing and lack of sum types. I find these extremely useful when writing reliable software, which is why Gleam appeals to me.

Oops, thanks for heads up, I had it set to private. Should be fixed now.

I think it would be good to include some examples in the README to show off what it can do. Also how to invoke it: can it find SQL embedded in other source file or does it need to be pointed at .sql files.

Nice. Looks a bit fancier than my version from a few years ago https://git.sr.ht/~wezm/lobsters

In addition to what reocha said, ClangBuiltLinux is the project you're probably thinking of. They track issues building with clang and provide CI: https://clangbuiltlinux.github.io/

Yes that’s a GNOME thing. It doesn’t take much to fill up 8Gb these days. I had a few different things running on other workspaces when I took that screenshot: Firefox with a bunch of tabs, CLion (usually good for ~2Gb), Obsidian, some other stuff.

It's a lot more than my little personal server usually uses in a month though.

Nitter seems broken at the moment. My original tweet https://twitter.com/wezm/status/1430670384362184704

It runs really well. There's nothing at all that makes it obvious it's running an entirely different architecture.

https://github.com/ironrobin/archiso-x13s/wiki/Feature-Suppo...

I build docker images locally that my server then uses.

https://swaywm.org/

Fair enough. Good luck with it!

Is your primary differentiator to existing Rust CLI HTTP clients like https://github.com/ducaale/xh that it does not have any dependencies?

I can easily see myself upgrading the CPU or the screen on an annual basis, or packing in more RAM.

This is the bit I'm most sceptical about. Time will tell if these sorts of upgrades are actually made available.

Have you tried working through the book[1]? Rust tends to be much harder to learn though experiments/doing than other languages. It can be beneficial to work through the book, even if that's not normally the way you go about learning.

[1] https://doc.rust-lang.org/stable/book/

We used Rust to replace font handling that was implemented in C in Prince¹ (which is mostly written in Mercury). This was then extended to include all font shaping and released as Allsorts². We integrate the Mercury code with Rust via FFI/Rust’s C interop.

¹ https://www.princexml.com/

² https://github.com/yeslogic/allsorts

That's an interesting perspective. In particular, "I don’t think it’s hard to vote with our wallets at all. We just can’t expect to get what Apple built", aligns well with my experience switching to Linux. I included this part in the post:

Something I learnt from my move to Linux though, was to embrace the platform's conventions as opposed to trying to reproduce the system you're moving from as much as possible.

Which is kind of along the same lines. I think my experience so far was that it felt like giving up too much to go the more/completely open option at the moment. With projects like postmarketOS though, I feel there is some progress being made on this. I will continue to keep an eye on it.

/e/ might be a good solution, preinstalled on a Fairphone 3.

I looked into /e/ but don't have a phone to try it on. Fairphone isn't available in Australia.

Good to know about the GPD.

I have no idea what people need all that horsepower for in their pocket.

The "modern" web mostly.