It is often used an expression of thanks or appreciation, but I associate that more with an elder speaking to someone younger.

Most of the time, it is an genuine expression of true empathy, but it's not uncommon to be used as a passive aggressive expression of false empathy. It's that childish connotation that give it the extra bite when used passive aggressively.

And that plausible deniability, where the phrase is used in a genuine context often enough that sometimes you can't tell that someone is throwing shade, is very much a reflection of southern culture.

Source: Grew up in Georgia and North Carolina, with some family in Alabama.

I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway.

Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.

Graphics and physics performance in 2026 across all kinds of hardware is wildly impressive.

    void* malloc(size_t size) {
        void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        return (ptr == MAP_FAILED) ? NULL : ptr;
    }

    void free(void *ptr) { /* YOLO */ }

- They "no longer use Github" but their Github account was only created on March 1st.

- Their blog domain was registered on March 1st according to whois.

- They have sixteen (!!) blog posts dated March 10th.

- This is the kind of project you could vibe code: "read the ffmpeg manual and convert all of its flags into a TUI." No shade on the value of the project, just that it's a good one for LLMs.

The original AGit blog post is no longer available, but it is archived: https://web.archive.org/web/20260114065059/https://git-repo....

From there, I found a dedicated Git subcommand for this workflow: https://github.com/alibaba/git-repo-go

I really like what I've read about AGit as a slightly improved version of the Gerrit workflow. In particular, I like that you can just use a self-defined session ID rather than relying on a commit hook to generate a Gerrit ChangeId. I would love to see Gerrit support this session token in place of ChangeIds.

The claim that malware "makes a ton of money" for Apple definitely needs a citation. I certainly don't believe it.

Obviously, Apple understands that the reputational damage from malware is more costly than any cut they might get from the miniscule sales of it. Apple might be evil (for some definition of "evil"), but they're not dumb.

Occam's Razor and Halon's Razor are aligned here. Apple would prefer this app not exist, but somehow it slipped through the review.

I thought it was, and posted this same comment on the other telnet article. But I was informed that it is back! And I was able to confirm it myself.

I don't have a telnet client on my Mac, but I was able to confirm with nc.

    nc towel.blinkenlights.nl 23

Amutability is a huge security feature, with tons of real world applications for good.

The fact that mega corps can abuse consumers is a separate issue. We should solve that with regulation. Don't forsake all the good that this tech can do just because Asus or Google want to infringe on your software freedoms. Frankly, these mega corps are going to infringe on your rights regardlessly, whether or not Amutable exists as a business.

Don't throw the baby out with the bath water.

By that logic, we should just turn off the internet. Too much potential for evil there.

More seriously, the argument being presented seems to just be "attestation tech has been used for evil in the past, therefore all attestation tech is bad," which is obviously an unsound argument. A sound argument would have to show that attestation tech is _inherently_ bad, and I've already provided examples that I think effectively counter that. I can provide more if needed.

I get that we want to prevent attestation tech from being used for evil, but that's a regulatory problem, not a technical one. You make this point by framing the evil parties as "corporate and government interests."

Don't get me wrong, I am fully against anything that limits the freedoms of the person that owns the device. I just don't see how any of this is a valid argument that Amutable's mission is bad/immoral/invalid.

Or maybe another argument that's perhaps more aligned with the FOSS ideology: if I want e2e attestation of the software stack on my own devices, isn't this a good thing for me?

The integrity of a system being verified/verifiable doesn't imply that the owner of the system doesn't get to control it.

This sort of e2e attestation seems really useful for enterprise or public infrastructure. Like, it'd be great to know that the ATMs or transit systems in my city had this level of system integrity.

You argument correctly points out that attestation tech can be used to restrict software freedom, but it also assumes that this company is actively pursuing those use cases. I don't think that is a given.

At the end of the day, as long as the owner of the hardware gets to control the keys, this seems like fantastic tech.

As you said, most installers need to place binaries in privileged locations anyway.

The reason Prolog doesn't support trailing commas is exactly the same reason JSON doesn't support trailing commas: the language is designed to be parsed by an operator precedence parser, and the comma is an infix operator.

The fact that Prolog is a purely operator precedence syntax, with a dynamic operator table, allows you to build DSLs embedded in Prolog. CLP(FD) uses this to create the #= operator.

I think this is a common failure mode in filesystems. For example, in ZFS, if you store your metadata on a separate device and that device is destroyed, the whole pool is useless.

It's all whether or not you trust the entity supplying the installer, be it your package manager or a third party.

At least with shell scripts, you have the opportunity to read it first if you want to.