mkroman

>Has it become a trend to pick up some proprietary software and vibecode a replacement for it and then slap a FOSS license on it?

Very much, yes. It started niche, and then notable sloppified projects made the normie news (Artcraft, sloppified Adobe software stack) and Sony's "you will own nothing" stance made people target the PS5 and popular titles that are now popular decompilation and emulation projects.

After that made the rounds, it seems everyone has gone full tilt on remaking existing products, but worse (there are some that are decent, but this does not look like one of them)

It's cool and interesting, but I can't help but feel we're about the enter an entirely new era of anti-consumer lobbying leading to new legislation that will be an absolute bloodbath for these projects, all while making individual consumer rights even worse.

I disagree.. Feels very sloppy to me:

- Time is UTC rather than local by default.

- Units are imperial rather than metric (i.e. not basing it on users locale)

- The concept of init time is not initially clear at all, so it's confusing when you click the calendar icon to see the weather forecast for a future date only to see it isn't an option, you have to use the slider.

- When changing the sidebar to the "detailed" view, most of the hovering element is cut off by the container so you can't actually read it.

And it took longer to write this comment than it did to find these issues. It's fine since it's clearly marked as experimental, but I disagree that it's "really easy to use" :p

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.

How? The article states:

> 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.

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.

shudders.. `| nindent 12`..

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.