Beware of ent (entgo.io)

If you’re using Go, you’ve likely heard of ent. Some Ex-Facebook employee maintaining and developing an open source version of the public version of Meta’s entity framework for Go.

Well there’s a catch.
Migrations.

They sweet talk you in their documentation to use Atlas. Ariga’s Atlas, not the MongoDB one.
But Atlas is a proprietary cloud offering.
There might be a free tier, but who cares?
You have to give other parties access to your schema, if you want to containerize your binary or even if you’re not distributing your schema with your binary. Not just your schema, also your database.

To me that is a breach of trust.

That is “open source” software being used as bait for a lock-in cloud offering.

2 machines with bridge devices and same mac problem

You’re using systemd, maybe you have cockpit installed and are creating a bridge on each host because you need them for libvirt virtual machines.

One machine is your old workstation and you copied the filesystem to the new machine.

But when you create a bridge you local machine suddenly receives the same IP your old machine has received.
Why?
You search around, “How do I set a new MAC address on a bridge?”
But none of the answers work.

Then you remember, “Hey, systemd uses machine-id for each machine”.
And indeed it does.

  1. You have to rm -f /etc/machine-id and dbus-uuidgen --ensure=/etc/machine-id
  2. Reboot the system
  3. Recrete the bridge
  4. -id

How to run gitea securely with snapcraft’s gitea snap on CentOS/Rocky/Alma etc

Install gitea snap

Add user

systemctl edit snap.gitea.web.service

In app.ini

add firewall forward rule

cannot install the best update candidate for package gdal36-libs-3.6.4-5PGDG.rhel9.x86_64

WTF do I have to do to get this bug fixed?

There are a bunch of search results, in the end leading to this dead end, bureaucracy bullshit ticket:
https://trac.osgeo.org/postgis/ticket/5664#ticket
pramsey says, “Please report build issues to the builder, as they won’t get fixed here.”

Typical bureaucratic bullshit.

Yes, crb is enabled.
Yes, epel is installed.

Why is this shit not getting fixed?

mm_answer_keyallowed: publickey authentication test: ED25519 key is not allowed

Debian 12.
After a long time I’ve installed Debian 12 in a VM again.
I used ssh-copy-id to copy the key files to the VM.
When I tried logging in, I still had to supply my password.
What was going on?

Well, I’ll spare you the mindfuck and give you the solution.

It wasn’t the encoding, it weren’t the permissions, it was…
My .ssh/id_ed25519 and .pub were dated older, from 2021, than a newer key I generated for github, id_ed25519_github.
So, I don’t know why all of a sudden this is happeneing, ssh-copy-id decides to take the most newly generated key in the .ssh directory, which is the github one and ignore all other keys.

In order to fix this

because ssh-copy-id since, who knows when, takes only 1 ed25519 key and it’s always the latest one.

I usually always did the copy/pasting by hand, until I stumbled on some smarty-pants blog-post which suggested ssh-copy-id. I’m going to fall back to doing it manually again.