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?
> - 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.
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.
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.
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.
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.
