aljarry

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.

Github Actions Runner code is pretty easy to read, here's a specific place that define default arguments for popular shells / binaries: https://github.com/actions/runner/blob/main/src/Runner.Worke..., it is exported through a method ScriptHandlerHelpers.GetScriptArgumentsFormat.

In ScriptHandler.cs there's all the code for preparing process environment, arguments, etc. but specifically here's actual code to start the process:

https://github.com/actions/runner/blob/main/src/Runner.Worke...

Overall I was positively surprised at simplicity of this code. It's very procedural, it handles a ton of edge cases, but it seems to be easy to understand and debug.

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.

Good point, I meant the reasoning is not encoded like a logical or mathematical rules. All the neural networks and related parts rely on e.g. matrix multiplication which works by mathematical rules, but the models won't answer your questions based on pre-recorded logical statements, like "apple is red".

That's true with any neural network or ML model. Pick a few points, use the same algorithm with the same hyperparameters and random seed, and you'll end up with the same result. Determinism doesn't mean that the "logic" or "reason" is an effect of the algorithm doing the computations.

But it is only a program computing numbers. The code itself has nothing to do with the reasoning capabilities of the model.

LLMs (our current "AI") doesn't use logical or mathematical rules to reason, so I don't see how Gödel's theorem would have any meaning there. They are not a rule-based program that would have to abide by non-computability - they are non-exact statistical machines. Penrose even mentions that he hasn't studied them, and doesn't exactly know how they work, so I don't think there's much substance here.

Interesting, my 3060 uses 150-170W with 14B model on Ollama, according to nvidia-smi.

From my experience in C#, generics are mostly useful for implementing custom containers.

That's my experience as well in C# - most of other usages of generics are painful to maintain in the long run. I've had most problems with code that joins generics with inheritance.

Ubuntu supports ZFS, so if you can track Ubuntu's kernel, you get ZFS without risking unbootable system.

Thanks! Dagger looks really nice :)

I'm working on a CI system with DSL instead of yaml configs.

The general premise is that most sufficiently advanced yaml configs begin to look like code - e.g. in Github Actions one could look at external Actions and shared workflows as dynamic libraries; workflows as public functions; jobs and steps as internal ones.

We have better languages than yaml-structure-as-a-code, and tools to help us write and test them quicker.

  retry() {
    local n=$1
    shift
    for i in $(seq $n); do
      "$@"
    done
  }

Maybe the license is pretty clear, but interpretations differ. E.g. Minio provides a very aggressive interpretation of AGPL, equating to "if you use it in closed-source commercial product, it's a violation of AGPL": [0], [1], [2]. For me the whole problem with AGPL is that it's so subjective.

[0] https://github.com/minio/minio/issues/13308#issuecomment-929...

[1] https://github.com/minio/minio/issues/12829#issuecomment-889...

[2] https://github.com/minio/minio/discussions/13571#discussionc...

There are libraries for writing Architecture tests for .Net and java (that I know of) for enforcing architecture design. You can enforce reference rules for classes and namespaces, like: classes from the domain namespace cannot reference the API or DB namespaces.

I haven't used them in a real project though.

The article states that "Other event sources like SNS use so-called Event Source Mapping", but (at least to my knowledge) SNS directly triggers the Lambda. SQS and few other "stream and queue-based services" use Event Source Mapping.

SNS = topics, push. SQS = queues, poll.

Is Htmx a good case for UI for a local application? I want to build a server app which I could host openly behind some auth, but at the same time I'd want to be able to run it in local mode, as a simple UI for local tests.

I understand there are some security challenges, as in "local" mode it can only communicate over HTTP with local app, or probably without CORS, etc. XSS might be a real issue here.

It's broken in an adversarial situation: given the hash of evidence-file A, it's possible to construct a file B that gives the same hash.

No, that's a second preimage attack. MD5 is safe against preimage & second preimage attacks.

What MD5 is not safe against, is a collision attack: you can create two messages/files with different content, that end up having the same hash.

I've played Noita (https://noitagame.com/) for quite a bit, and lately it clicked to me, that the core mechanics of the player and environment come from Liero. Though Noita is a single player rouge-lite, it has wands instead of guns, but environment is destructible, and explosions work the same.

It's much deeper, both in mechanics and in lore, it has actual levels with progressions, but I was curious why did I enjoy that game so much. Turns out, I spent a ton of time playing its predecessors with my friends :)

TIL :) thanks, I misunderstood that part.