Skinney

This is required in order to implement value classes in Java (project valhala).

MNT just started offering the QCS6490 for their laptops.

https://mnt.re/media/reform_md/2026-06-30-june-update.html

vibe has improved _a lot_ during the past few months, fyi.

The new Mistral Medium 3.5 is also a big improvement over devstral-2

"Unified" means that it's shared between CPU and GPU, I believe.

But yes, it tends to be soldered on.

Cheaper tokens means the company's margins increase, which would be valuable for investors to hear

I'm not doing anything huge, but my local radicle node is connected to ten other nodes at present, one of which is my own hetzner-hosted seed. Even if half of these go down, I still have full access to all the repos I follow.

Wouldn't people discover HardenedBSD via google and then find the link to the code via the website?

I've personally never discovered projects through Github.

Radicle is local-first, so you can create issues and patches (pull requests) even when offline. It will sync when you're back online.

Also, my understanding is that ATProto is relatively centralized in practice, wheras in radicle every node is sort of equal.

The load will be spread across the network, but I guess the main benefit is that everything continues working even though HardenedBSDs official seed is down.

Every user has their own node, and everyone's node talks to several seed nodes. Even if the official HardenedBSD seed is down, there's still going to be another node to sync with.

You work for money.

I work for money because I need food on the table and a place to sleep. It doesn't motivate me much more than that. In fact, I wouldn't even call it motivation. It's a requirement to live.

There have also been studies that have found that money stops making people happier or more motivated once their yearly salary exceeds a certain amount (the equivalent of 700.000NOK here in Norway).

Some people are primarily motivated by making as much money as possible, sure, but most people I've worked with have found someplace else to work once their current job stops being interesting.

Having a register machine doesn't seem very useful...

Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.

Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).

If it works anything like what we've got in Norway, they take a rough percentage, and once every year when the taxes are filed, the IRS equivalent charges or repays the missing amount.

Litestream is already backing up your changes, so synchronous=normal seems reasonable.

What sort of IDE plugin are you thinking of? As long as you have a git plugin it should work just fine (if you're thinking of something similar to github/gitlab plugins then I don't think there are any, but I'm not sure what those buy you).

It's possible to setup CI: https://app.radicle.xyz/nodes/ash.radicle.garden/rad%3AzwTxy...

It's "just" git, but you push to a special remote which will synchronize your repo on a p2p network.

There's also a CLI for issues and pr's, which also get's stored in your git repo.

Anyone using radicle for a project with external contributors?

I've tried it with some of my projects and it seems promising, but I wonder what it'd be like to use it on one of my more successful projects.

If I’m deploying a new version of my app, the typical managed solution will spawn a new server instance with that new version, and once a health check has succeeded a couple of times it will reroute trafic to this new instance and kill the old one.

Previously this would be problematic, as the new instance might miss changes made by the old server. Is this fixed by these new changes?

Git repos (it's too difficult)

Sourcehut

Startpage uses Google's index.

If they have enough users/make enough money, they'll make their own. Ecosia and Qwant (both european search engines) are working together to make their own index.

In any case, even if a european is a proxy for an american service, you need to prove that there is a market for an european equivalent for change to happen.

Keep user information in one database, keep user _data_ in another.

It all depends on your app, really. For some apps the above won't make sense, but maybe it would make sense to keep one db per org, or something like that.

Good article.

I currently use Litestream (https://litestream.io/) for efficient SQLite backups to S3, and I'm happy with that.

For me, the main point to consider wrt SQLite is if you need high availability or not. And how easy it is to setup litestream and persistent storage.

Not necessarily. You can just commit your changes...

Saves me from doing that extra commit, then.

[...] it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch.

That's also a thing I like about jj. Nothing prevents me from committing changes. Even merge conflicts are commited, so I know I can always come back to it later.

I find I think less about when to commit my work in jj. In Git I find that I like to commit to avoid loosing work, in addition to commiting when I feel "done" with part of a change.

It's a small thing, really, but it feels quite big (for me).

Sure.

I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit.

In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back.

In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change.

Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes.

To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.

I find JJ to be what you get when you take a step back, evaluate everything that works in Git and try to find a design that accomplishes all those things with the fewest amount of concepts possible. Like a Git 2.0, if you will.

You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps.

Couple that with colocated repos, meaning I can use JJ while everyone keeps on using Git, there wasn't really anything holding me back.

I'm using it for everything now. The beauty of JJ is that everyone else on my team can keep on using git if they want, even if I'm using JJ on the same repo.

Pretty much love all the Simply Solo games from Button Shy Games.

Go's compiler is written in Go, and is known to compile very quickly. I'm not sure I understand why Roc needs to be even faster than that?

The syntax came from Elm, which got it’s syntax from Haskell (where Nix also got it from) which got its syntax from ML.

It’s a syntax that’s several decades old at this point.

It’s different, but not harder. If you learned ML first, you’d found Algol/C-like syntax equally strange.

https://gren-lang.org

I've gotten feedback that the landing page should have code examples. Will probably add that when preparing the next release (due in December).

Part of the reason is that it's been a commercial database until recently. I also think it hasn't helped that it's closely associated with Clojure (for natural reasons), which might make Java developers turn away from it.

It's a shame, though. Datomic is a marvel.

Problem with Node is that the snapshot functionality has several severe limitations.

Copy pasted from NodeJS docs:

---

Currently the support for run-time snapshot is experimental in that:

1. User-land modules are not yet supported in the snapshot, so only one single file can be snapshotted. Users can bundle their applications into a single script with their bundler of choice before building a snapshot, however.

2. Only a subset of the built-in modules work in the snapshot, though the Node.js core test suite checks that a few fairly complex applications can be snapshotted. Support for more modules are being added. If any crashes or buggy behaviors occur when building a snapshot, please file a report in the Node.js issue tracker and link to it in the tracking issue for user-land snapshots.

---

(1) is fine as you can use a bundler to work around it. (2) can't, as far as I know, be worked around.