steeleduncan

> The fact that working on Linux code will now require corporate backing to pay for the AI will also aid in taking Linux away from the free software community

This isn't remotely true, it is fictional ragebait

OpenGL is a low(ish) level hardware interface, that is almost certainly implemented in legacy unsafe code, so it will be fertile ground for CVEs. Presumably this is a security fix gone wrong

> Nix is very awkward (and slow) to use for fine-grained caching, which is price of entry for a decent build system.

This is sadly true, I've tried setting up a bazel-esque C++ build system in Nix, and the requirement for 1 derivation per .o file makes it very inefficient

> It also comes (practically) shackled to nixpkgs

This isn't true, and I think it is a shame that it seems true. Nixpkgs is both awful, and completely optional. It would be great if there were more resources on how to use Nix without Nixpkgs, or as is commonly requested, a smaller, cleaner and better engineered alternative

The FAQ seems clear on this

> Where is my code actually hosted?

> On bare-metal servers that we operate in Scaleway's Paris datacenters

    const MAX: u32 = 100;  // Compile-time constant
    let x: u32 = 10;       // Cannot be changed

If x cannot be changed, how does it differ (meaningfully) from a compile time constant in a safe language, ie in a case of no raw pointers

The missing line on that graph is November 2019 when Github Actions were introduced. It would also show the point where things went wrong for uptime

There are no need for permissions if the link per discussion is obscure and you use HTTPS. In that case the link is the password

In princple JJ has non-Git backends, but the only backend they state as being production ready is the Git backend. JJ without the Git interop is more a concept than a reality right now.

I love JJ, and the mental model of source control it presents, and I will continue to use it. However, still needing to "drop down" to Git every now and again to get something done makes it feel very much like a convenient wrapper on top of Git rather than a new SCM.

If Git adds commands to support the JJ workflow, it would be hard to justify having JJ installed any more.

I think it is a typo, and should be std::println()

I think there is a strong argument that Gerrit is the current evolution of the patches workflow, many prefer it, and there are a lot of good blog posts explaining why.

I don't know what the justification for emailing patches around is though, that seems needlessly painful in the face of alternatives

Tiny CC doesn't have its own runtime, it uses whatever you specify (falling back to system standard), same as GCC or Clang. For low runtime footprint you are probably better off with one of those two compilers as they generate smaller, more optimised code.

What has changed at GitHub to cause this?

Not right now, it is far too early days. I'm currently working through bugs, and missing stdlib, to get a simple backpropagation network efficient. Once I'm happy with that I'd like to move onto more complex models.