I wonder how this improves performance on older Intel macs with a Metal-compatible GPUs, or if it's really a M-series only improvement.

It says in passing As the Metal backend is only supported on Apple Silicon devices, GPU and CPU share the same memory in the part talking about the differences between the Direct3D and Metal render pipelines.

Not sure why though, because Metal 3 is still supported on a bunch of Intel Macs...

It may be an error on the part of the writer.

Maybe the M-series unified memory architecture is required?

If anyone has read the Iain M. Banks novel Excession, this feels somewhat similar to the funnier parts of it where a bunch of AI's embedded in spacegoing vessels have chat discussions back and forth, with a fair bit of shade thrown.

github repo (MIT license): https://github.com/ttscoff/apex

Has anyone calculated or measured the input lag of ADB vs other protocols such as PS/2 or USB? This is unfortunately hard to search because most references on the web to ADB are for the Android Debug Bridge.

From the numbers given, it seems like ~2ms to send a packet (my math may be off), which is quite good when compared with other contemporary/modern protocols (see: https://danluu.com/input-lag/ for examples)

Can I file a claim if I'm related to folks who shared their (and by extension, my) DNA with this company?

This will basically be everyone in the world. Could be the largest class action ever?

Oprah spruiked 23andMe.

Can people sue Oprah?

Since when is spruiking a liability?

Spruik

Promote or publicise.

A new word to me, and not one I’ll use.

It seems like a word that's read and not spoken.

You can be held liable if fraud was committed and you were aware of it.

I may actually try my hand in conciliation court against them on this one. I received a test kits back around 2015 from a family member, but was disgusted at the idea that there was no possible way they 1) wouldn't go under and sell my data 2) be breached. I feel like these sort of outcomes for these types of services are very obvious as highly likely to anyone who works in proximity to tech, and especially startups.

Anyway, I never submitted the test. But I know for a fact that family has. It's really annoying to that others can make these sort of linked decisions for you - especially as we are now acutely aware that this type of data can, will and I'm sure is being used in ways that basically nobody would consent to.

If you want even more minimal, Gerrit is structured as a Java app with no external dependencies like databases, and stores all it's configuration and runtime information on the filesystem, mostly as data structures in the git repos.

Shared filesystems is all you need to scale/replicate it, and it also makes the backup process quite simple.

I might be one of the few that is intrigued by this being that it’s Java but this looks really neat. Does it do git repositories like gitea, GitHub, etc, or is it more of a project management site for the repositories? They describe it as “code review”, so I wasn’t sure.

I’m a little put off on the google connection but it seems like it could run rather independently.

It necessarily hosts a git server (using jgit), but the primary interface is as a code review tool.

even browsing the git repos it hosts uses an embedded version of another tool (gitiles).

https://gerrithub.io/ is a public instance

It's hyper-focused on code review and CI integration, which it does really well.

It's not focused on all the other stuff that people think of in code forges (hosting the README in a pretty way, arbitrary page hosting, wiki, bug tracking, etc.) but can be integrated with 3rd party implementations of those fairly trivially.

> I’m a little put off on the google connection but it seems like it could run rather independently.

Yeah, its actually a really healthy open-source project, google contributes usually around 40% of the code, but you have other companies like GerritForge(disclaimer, I work here), Nvidia, SAP, Qualcomm, Wikimedia foundation, all contributing heavily to it.

The deployment may be simple, but at the same time, the Gerrit code review workflow is terrible.

Coming from Github myself, I cannot imagine going back to it after using Gerrit for even just a few days.

The workflow in Gerrit really makes a lot of sense, unfortunately its the workflow in GitHub that has screwed up everyone's idea of what code review should look like[1], even by one of GitHub's co-founder own's admission.

[1] https://medium.com/@danielesassoli/how-github-taught-the-wor...

I personally find the rebase and stacking commit focused method of integration that Gerrit uses to be easier and cleaner than PR's in GitHub.

Having done CI integrations with both, Gerrit's APIs send pre- and post-merge events through the same channel, instead of needing multiple separate listeners like GitHub.

The Jonsbo N3 case which is 8x 3.5" drives has a smaller footprint than this, which might be better for most folks. Needs a SFX PSU though, which is kind of annoying.

If you get an enterprise grade ITX board that has a 16x PCIe slot which can be bifurcated into 4 M.2 form factor PCIx4 connections, it really opens up options for storage:

* A 6x SATA card in M.2 form factor from Asmedia or others will let you fill all the drive slots even if the logic board only has 2/4/6 ports on it.

* The other ports can be used for conventional M.2 nVME drives.

That's what I built! It's a great case, the only components I didn't already have lying around were the motherboard and PSU.

It's very well made, not as tight on space as I expected either.

The only issue is as you noted, you have to be really careful with your motherboard choice if you want to use all 8 bays for a storage array.

Another gotchas was making sure to get a CPU with integrated graphics, otherwise you will have to waste your pcie slot on a graphics card and have no space for the extra SATA ports.

None of this means that you have to be on a specific platform. GitHub as default/mandatory is a single point of failure for the entire tech industry.

For an example of another language that avoids being entirely coupled into Github, Go has it's real code hosting and CI interaction on a Gerrit instance, with some sync back and forth to GitHub for a few items.

The CI pain and operational blindness mentioned in the Zig post is entirely real.

Yeah but marketing matters for Zig because it's still struggling to get significant mindshare.

Zig needs to behave more mainstream rather than less and technical gripes about the source hosting platform should not matter more than marketing.

Maybe, but isn't it too soon to be mainstream anyway? Until the language and standard libraries hit 1.0, it seems like Zig is for early adopters. Having too many of the wrong kind of users is just going to be frustrating for everyone.

Well maybe we are seeing this the wrong way. Maybe that's exactly the mindshare they want.

People who get angry when they see bad code, so much to call the developers lackeys and monkeys.

And an organization whose code base doesn't have to be on a mainstream server to attract exactly those who agree with this choice.

Marketing and visibility retention will likely be better when people think - hey its the PL that is NOT on github.

See also part 3: https://blog.cr.yp.to/20251123-dodging.html

and 4: https://blog.cr.yp.to/20251123-scope.html

Helm is truly a fractal of design pain. Even the description as a "package manager" is a verifiable lie - it's a config management tool at best.

Any tool that encourages templating on top of YAML, in a way that prevents the use of tools like yamllint on them, is a bad tool. Ansible learned this lesson much earlier and changed syntax of playbooks so that their YAML passes lint.

Additionally, K8s core developers don't like it and keep inventing things like Kustomize and similar that have better designs.

Imho, anyone who thought putting 'templating language' and 'significant whitespace' together is a good idea deserves to be in the Hague

Seriously. I’ve lost at least 100 hours of my life debugging whitespace in templated yaml. I shudder to think about the total engineering time wasted since yaml’s invention.

You blame YAML but I blame helm. I can build a dict in Python and dump it as YAML. I've painlessly templated many k8s resources like this. Why can't we build helm charts in a DSL or more sensible syntax and then dump k8s manifests as YAML? Using Go templating to build YAML is idiocy and the root of the issue here.

There's lots of advice on StackOverflow against building your own JSON strings instead of using a library. But helm wants us to build our own YAML with Go templating. Make it make sense.

I 100% agree. It’s not so much the yaml as it is the templating. I originally wanted to say “since the invention of yaml/jinja” in the parent comment because that’s what I’ve gotten most of my gray hairs from (saltstack templating). Go templates are not jinja but fundamentally the same thing - they have no syntax awareness and effectively are just string formatters.

I took out the part about templating because I thought it made my comment too wordy, but ended up oversimplifying.

This is more or less the approach Apple's "pkl" takes.

You define your data in the "pkl language", then it outputs it as yaml, json, xml, apple property list, or other formats.

You feed in something like:

    apiVersion = "apps/v1"
    kind = "Deployment"
    metadata {
     name = "my-deployment"
     labels {
      ["app.kubernetes.io/name"] = "my-deployment"
      ["app.kubernetes.io/instance"] = "prod"
     }
    }
    spec {
     replicas = 3
     template {
      containers {
       new {
        name = "nginx"
       }
       new {
        name = "backend"
       }
      }
     }
    }

And then you `pkl eval myfile.pkl -f yaml` and get back:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-deployment
      labels:
        app.kubernetes.io/name: my-deployment
        app.kubernetes.io/instance: prod
    spec:
      replicas: 3
      template:
        containers:
        - name: nginx
        - name: backend

The language supports templating (structurally, not textually), reuse/inheritance, typed properties with validation, and a bunch of other fun stuff.

They also have built in package management, and have a generated package that provides resources for simplifying/validating most kubernetes objects and generating manifests.

There's even a relatively easy path to converting existing YAML/JSON into pkl. Or the option to read an external YAML file and include it/pull values from it/etc (as data, not as text) within your pkl so you don't need to rebuild everything from the ground up day 1.

Aaaaand there's bindings for a bunch of languages so you can read pkl directly as the config for your app if you want rather than doing a round trip through YAML.

Aaaaand there's a full LSP available. Or a vscode extension. Or a neovim extension. Or an intellij extension.

The documentation leaves a bit to be desired, and the user base seems to be fairly small so examples are not the easiest to come by... but as far as I've used it so far it's a pretty huge improvement over helm.

Yaml wouldn't be so bad if they made the templates and editors indent-aware.

Which is a thing with some Python IDEs, but it's maddening to work on anything that can't do this.

    autocmd FileType yaml setlocal et ts=2 ai sw=2 nu sts=0

I'm sure Emacs and others have something similar

we use cue straight to k8s resources. it made life way better.

but we don't have tons of infra so no idea how it would run for big thousands-of-employees corps.