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.
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?
Great question. In practice, 'native to FreeBSD' means a few things for grsh:
System Integration: I’m prioritizing first-class support for FreeBSD-specific tools and environments (like Jails and the Ports system). While many shells treat BSD as an afterthought, I want grsh to feel like it was built specifically for the FreeBSD base system.
Technical Implementation: Currently, I’m leveraging specific behaviors of the FreeBSD terminal driver and signal handling. While the Rust codebase is portable in theory, I’m not 'watering down' the features to guarantee Linux compatibility yet. I want to exploit FreeBSD’s strengths first.
License & Philosophy: The project is under the BSD-3-Clause license, which aligns with the ecosystem's preference for permissive licensing.
Can it work on Linux/other BSDs? Yes, it can be compiled on Linux, but you might find that certain job control nuances or terminal optimizations are currently 'tuned' for the FreeBSD kernel. I’d rather have it work perfectly on one OS than 'okay-ish' on all of them.
> - 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.
> You write on your site; I write on mine. That’s a response. I don’t use comments on Wilcox’s site to respond publicly to his pieces, but somehow it’s unfair that he can’t use comments on my site to respond to mine? What kind of sense is that even supposed to make?
How is it hypocritical to hold the view that some places are intended to be open forums for comments from anyone, and others are not?
Also, by not hosting my own comments, all public commentary on my writing is thus out of my control. I don't get to block comments I don't like here, or on Mastodon, or Twitter/X, or Bluesky. I think that's actually for the better.
DF is a blog and was conceived that way. HN is a discussion site. The two forms (blogging and internet discussions) are different. They serve different purposes and require different management styles.
The discussions here do seem to be tamped down in some ways, and as a user, that takes something away from the experience.
Relatedly: in general, I think "hypocritical" is not a big gotcha that ends discussions. Different things serve different purposes.
The site's source code is already updated, but unfortunately the website itself is refreshed per Rustup release, so we might have to wait for a bit longer...
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.
