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

It seems to have updated to SDL3 - https://github.com/love2d/love/blob/main/CMakeLists.txt#L178

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.

It uses the same trick as Go [1]. The grammar has semicolons, but the tokeniser silently inserts them for ease of use. I think quite a few languages do it now

[1] https://go.dev/doc/effective_go#semicolons

I'm not totally sure what it is, but I believe there is something for running Rust code on the GPU easily

I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok

- There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal

- OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories

- The runtime functions are not compatible at all, but most projects wouldn't touch those

- CoreFoundation and the other C APIs are not there at all, so you'll need replacements

- It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do

Discord if you don't mind something proprietary, Mattermost or Rocketchat if you do, Zulip if you want something slightly different . . . and no doubt many other alternatives

Slack is easy to replace with something cheaper and better on a product or technical level. The network effects are strong of course, but they won't sustain it forever

Use tmux. Ssh in and start a tmux session. If the connection breaks you can ssh back in and reconnect to the tmux session later.

GNU Screen is another alternative

It is odd, I would have thought $0 is the more obvious number there. It seems you can refund via a shell command though, so the money is not trapped

Gemini/ChatGPT help (a lot) when getting going. They make up for the poor documentation

package.lock is JSON only, Nix is for the entire system, similar to a Dockerfile

Nix specifies dependencies declaritively, and more precisely, than Docker (does by default), so the resulting environment is reproducibly the same. It caches really well and doubles as a package manager.

Despite the initial learning curve, I now personally prefer Nix's declarative style to a Dockerfile

I do the same with Nix as it works for macOS builds as well

It has the massive benefit of solving the lock-in problem. Your workflow is generally very short so it is easy to move to an alternative CI if (for example) Github were to jack up their prices for self hosted runners...

That said, when using it in this way I personally love Github actions

I believe Rob Pike also doesn't use syntax highlighting [1]

[1] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

None of this actually matters. If you want to keep your data private, host it on your own hardware. Countries, company policies, etc are all essentially irrelevant

Sorry if I missed this in the docs, but how robust is the persistence? ie is it the disk that comes with a standard AWS VM? or is it a share backed by e.g. Ceph with multiple redundant copies?

The other conclusion to draw is "Git is a fantastic choice of database for starting your package manager, almost all popular package managers began that way."

It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.

I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.