aljarry

I did try seaweedfs ~half a year ago and I had issues with setting up users through terraform module (if I recall correctly, users endpoint were not correctly responding on delete), and lack of S3 expiry rules (you needed to use seaweedfs configuration or API for that). Other than that, I was pretty happy with it.

Schemas, etc. look a lot like JSON-LD. You would need to pin the schema only if you're worried someone might modify one. But it gives you a lot of options out of the box, while still being valid JSON.

That's a good point. Though I'd still expect more effort from the developer to convince people that they will actively maintain the project after the first 3 months.

There are 3 new commits, and the only actually fixes are: Go update and revert to earlier version of console.

But there are a bunch of changes to docs, CI workflows and issue templates. Which is what is the easy part of managing a fork, and I've seen a bunch of forks that ended up only updating readme-s, CI, etc.

I'll have more faith in the fork when the maintainers do actual fixes.

This does seem like a person getting hooked on idle games, or mobile/online games with artificially limited progress (that you can pay to lift). It's a type of delayed gratification that makes you anxious to get next one.

Not everyone gets hooked on those, but I do. I've played a bunch of those long-winded idle games, and it looks like a slight addiction. I would get impatient that it takes so long to progress, and it would add anxiety to e.g. run this during breaks at work, or just before going to sleep. "Just one more click".

And to be perfectly honest, it seems like the artificial limits of Anthropic (5 hour session limits) dig into similar mechanism. I do less non-programming hobbies since I've got myself a subscription.

>the failure mode is invisible

Only if you are missing tests for what counts for you. And that's true for both dev-written code, and for vibed code.

One option is to do multi-stage rollout of your database schema and code, over some time windows. I recall a blog post here (I think) lately from some Big Company (tm) that would run one step from the below plan every week:

1. Create new fields in the DB.

2. Make the code fill in the old fields and the new fields.

3. Make the code read from new fields.

4. Stop the code from filling old fields.

5. Remove the old fields.

Personally, I wouldn't use it until I really need it. But a simpler form is good: do the required schema changes (additive) iteratively, 1 iteration earlier than code changes. Do the destructive changes 1 iteration after your code stops using parts of the schema. There's opposite handling of things like "make non-nullable field nullable" and "make nullable field non-nullable", but that's part of the price of smooth operations.

I had a strange problem with Dell P2720DC (27'' 2560x1440) - the whole outer edge of the screen would flicker if I used dark background with a lot of dim colours (like dark mode in IDE, or default Grafana theme). It wouldn't happen all the time, but it would happen on a weekly basis (I most often seen that on Sunday). I've RMA'd it, got another monitor, which also started showing the same problem. I gave it to someone who doesn't use dark mode - no issues.

So, I'm not getting another Dell until I'd be sure this issue won't happen again :)

It does use a ton of energy - with clock on 4k screen my M2 macbook air CPU temperature went up 10°C in 10s and 20°C in 50s.

The first one is usually called "explainability".

NX NPM attack (at least the previous wave which targetted tinycolor) relied on running post-install scripts. Go tooling does not give you ways to run post-install scripts, which is much more reasonable approach.

> Nothing to do with it? You certainly don’t mean that. The software running an LLM is causally involved.

Not in the way that would apply problem of non-computability of Turing machine.

> Perhaps you can explain your point in a different way?

LLM is not a logic program finding perfect solution to a problem, it's a statistical model to find next possible word. The model code does not solve a (let's say) NP problem to find solution to a puzzle, the only thing is doing is finding next best possible word through statistical models built on top of neural networks.

This is why I think Gödel's theorem doesn't apply here, as the LLM does not encode strict and correct logical or mathematical theorem, that would be incomplete.

> Related: would you claim that the physics of neurons has nothing to do with human intelligence? Certainly not.

I agree with you, though I had different angle in mind.

> You might be hinting at something else: perhaps different levels of explanation and/or prediction. These topics are covered extensively by many thinkers. > Such levels of explanation are constructs used by agents to make sense of phenomena. These explanations are not causal; they are interpretative.

Thank you, that's food for thought.

The program - yes, it is a rule-based program. But the reasoning and logic responses are not implemented explicitly as code, they are supported by the network and encoded in the weights of the model.

That's why I see it as not bounded by computability: LLM is not a logic program finding perfect solution to a problem, it's a statistical model to find next possible word.

Yes, exactly. What I meant is: it's not the code itself that encodes this logic or reasoning.