It's a terminal. It was a terminal before they pivoted to AI (I don't blame them, with their funding rounds I don't see them having particularly free reins) Before this, it was all about collaborative (CRDT) features. I have no idea why you'd want a terminal that is also an agent harness, but I appreciate them making it open source none the less.
> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
The user can't even enter their passcode, how do you expect them to perform code execution?
> but if you do specs and tests it's actually the opposite, you can go beyond technical debt and regenerate your code as you like.
Having to write all the specs and tests just right so you can regenerate the code until you get the desired output just sounds like an expensive version of the infinite monkey theorem, but with LLMs instead of monkeys.
Ah cool, thanks, didn't know this existed. I just get a dummy message when playing audio, so I'll play around with some speech dispatcher[1] solutions later!
> Oh, and mozilla's off-line translate for private translation of web pages... that's another neat AI thing they added that I've found super helpful.
Yes, it's awesome! And one of my favorite additions to Firefox in many years, it's stuff like that they should focus on if they want AI, imo.
I don't understand how they expect offline LLM models to work in a meaningful capacity for users.. Isn't there a single multilingual person working at Mozilla?
All of the small LLM models break down as soon as you try to do something that isn't written in English, because - surprise - they're just too small.
There would need to be a hardware breakthrough, or they would have to somehow solve the heavy cost of switching the models between pages.
Instead of useful AI stuff that is a clear improvement to accessibility, they're insistent on ham-fisting LLM solutions that no one have even asked for.
Off the top of my head, they could instead:
1. Integrate something like whisper to add automatic captions to videos or transcribe audio
2. Integrate one of the many really great text to speech models to read articles or text out loud
What I don't see mentioned here or in the article:
PostNord Denmark has been operating with massive losses for a while now, in part because they were required by law to be able to deliver everywhere in Denmark, when there were very little demand for it. The money just isn't there, which is why the law has been changed.
The cost of sending a letter was also just going up and up. In 2025, it cost $4.55 _per letter_.
> CUE was a fork of the Go compiler (Marcel was on the Go team at the time and wanted to reuse much of the infra within the codebase)
Ah, that makes sense, I guess. I also get the feeling that the language itself is still under very active development, so until 1.0 is released I don't think it matters too much what it's implemented in.
> Also, so much of the k8s ecosystem is in Go that it was a natural choice.
That might turn out to be a costly decision, imho. I wanted to use CUE to manage a repository of schema definitions, and from these I wanted to generate other formats, such as JSON schemas, with constraints hopefully taken from the high-level CUE.
I figured I'd try and hack something together, but it was a complete non-starter since I don't work within the Go ecosystem.
Projects like the cue language live and breathe from an active community with related tooling, so the decision still really boggles my mind.
I'll stay optimistic and hope that once it reaches 1.0, someone will write an implementation that is easily embedded for my use-cases. I won't hold my breath though, since the scope is getting quite big.
I've been trying to apply CUE to my work, but the tooling just isn't there for much of what I need yet. It also seems really short-sighted that it is implemented in Go which is notoriously bad for embedding.
The AI hardware race is still going strong, but with so many rapid changes to the fundamental architectures, it doesn't make sense to bet everything on specialized hardware just yet.. It's happening, but it's expensive and slow.
There's just not enough capacity to build memory fast enough right now. Everyone needs the biggest and fastest modules they can get, since it directly impacts the performance of the models.
That's when you go a level deeper and have every template use another template (e.g. a Helm subchart or Helm library) only to realize scoping and templating is completely fucked in Helm.
I've wanted to make something like this myself, so thanks and good job!
How does this work? Does it rely on GPT to extract the data or does it actually generate a bunch of selectors? If it's the former, then the results aren't reliable since it can just hallucinate whole results or even just parts.
Just put them on a train during work hours! We have really good coverage here but there's congestion and frequent random dropouts, and a lot of apps just don't plan for that at all.
"Permissions" seem too specific a term to use as a general term. It's something I'd use to describe the specific rights a role may have in role-based access control, and not authorization as a whole. I'll stick to authn/authz for abbreviations, auth for both or if it's not specific, and if it's for documentation or cross-department communication I'll just write the whole word.
CloudNativePG also implements support for volume snapshots: https://cloudnative-pg.io/docs/1.29/backup#backup-methods