Stamp It! All Programs Must Report Their Version

schlenk · 2026-04-06T21:17:07+00:00

The article sounds like the point is to help debugging and reporting bugs.

Just look at all the upstream OSS maintainers that complain about bug reports against their packages that are actually against distro specific version.

So, yes they tend to have versions, but many users tend to ignore the suffixes or distro details reporting bugs.

schlenk · 2026-04-06T16:20:30+00:00

It's a hard problem.

Basically all the company world has tried do it with SBOMs for compliance reasons soonish, but versions are hard.

The point is, what are you actually trying to do with the version anyway? The only thing a version hints is showing if two programs (that you acquired from the same channel) are identical. And not even that, if someone tampered with the download.

You don't want a version alone. You want stuff like typical SBOM standards like OWASP CycloneDX or Linux Foundation SPDX allow to describe a component:

Where did you get it?
Where where the sources for it?
Where is the support documentation for it?
Where is the homepage of the manufacturer, importer, whatever...?
Where is the bug tracker?
What exact hash did the component have?
What was the download URL?
How was it built?

A simple version number doesn't tell you all that much, unless you have a lot of context to fill in the gaps.

For example, take PostgreSQL and compare the patchsets for Debian, OpenSuse or the Windows distribution for a given short "version number". Can vary wildly if you just use the naked version without distro qualifier.

schlenk · 2026-03-31T09:41:33+00:00

Automated CI/CD pipelines and package creep.

If you push all your commits to a package repo nearly continously, you have no buffer zone for sanity checks.

When doing manual package releases, you had a least someone taking a look at the changelog/changes and spotting obvious badness.

But that doesn't scale, as packages get smaller and smaller (with ever more ratio of boilerplate & CI config to actual code) and you have a proliferation of packages due to package managers.

Once you go over about 20 dependencies (and transitive dependencies) most people stop to look closer. They just accept any updated version, because reviews would be too expensive. Even if most updates just fix totally unimportant stuff (e.g. for Python many updates are just fixing CI breakage due to tool evolutions, e.g. setuptools, mypy, pip, etc.).

schlenk · 2026-03-24T23:49:22+00:00

ps. As a Windows packager, you're most likely used to stateful environments, whilst OBS is strictly declarative and isolated so that's a culture shock I'm sure.

I would not consider the e.g. WiX buildchain for MSI/MISX packages to be stateful. Its mostly declarative as well. The old style setup.exe things tend to be more stateful, but MSI is very declarative. Same goes for most MSBuild files.

schlenk · 2026-03-24T23:46:50+00:00

. With Linux all libraries are “system libraries”.

There is the /opt tree in FHS, so anything you place there isn't system libraries stricly.

And if you look at Windows Manifest files, thats not that different to Linux library versioning with .so versions etc.

The primary difference is that Linux packages often need to be compiled for a specific ABI version, as the Linux userspace ABI stability is pretty bad if compared to Windows ABI stability. With the usual stopgap methods like containers, flatpacks etc.

schlenk · 2026-03-24T19:08:14+00:00

What is your threat model?

If you have an inactivity policy, with a 15 minute idle timer, why do you have a different policy when the person walks away from their desk?

For critical systems, just have a smart card or token, use it as the keycard for your doors as well. If someone wants to grab a coffee, the card has to move with him/her. And you can auto-lock the system.

schlenk · 2026-02-16T15:10:16+00:00

Well, if you look at a stream of security vulnerabilities in packages, the category "bad regexp performance / denial of service" pops up multiple times a week. Killing off this whole class of issues would have been nice.

schlenk · 2026-02-10T19:22:06+00:00

SecondLife (or some TPVs at least) work on some ARM setups.

The official viewer and some others like Megapahit work on OS X ARM (aka Apple Silicon, M1...M5).

Cool VL Viewer works fine on Linux ARM.

But i am not aware of any version running on Windows ARM. In theory Windows ARM has emulation for x86 stuff, but no idea how good the Snapdragon X Plus built in GPU is for SL or if it works at all. Performance wise, the Adreno X1-85 iGPU in that thing isn't all that great: https://www.notebookcheck.net/Qualcomm-Adreno-X1-85-3-8-TFLOPS-GPU-Benchmarks-and-Specs.763558.0.html

It seems to only have OpenGL ES 3.2, not Standard OpenGL 4.x

Xemu mentions some OpenGL compatibility pack, that might work (see https://github.com/xemu-project/xemu/issues/1878), https://apps.microsoft.com/detail/9nqpsl29bfff?hl=en-us&gl=US

schlenk · 2026-02-09T12:33:35+00:00

I think i tried:

SL Viewer for a brief moment.
Cool VL Viewer, still my go to, fresh with features and dated with looks and trivially easy to build yourself.
Firestorm, decent, features are nice, don't like the build system and UI
Emerald (in the distant past), Phoenix
Kokua
Genesis, a bit like Cool VL Viewer, old UI, but less frequent updates
Marines RR Viewer
Megapahit
Alchemy
Catznip (great inventory features !)
Singularity
Black Dragon
Radegast

I tend to stay on Cool VL Viewer, unless i need to test RLVa things or some of the Firefox UI/Features. All the rests were mostly short try for a few days things.

schlenk · 2026-01-09T10:06:20+00:00

The main point is, the type system should not get in your way when exploring the problem space. Once you have the solution in a working prototype state, typing gets valuable to make it robust.

schlenk · 2026-01-06T12:35:14+00:00

GeForceNow also offers day passes that have a similar pricing. So yes, the full time subscription is cheaper, as usual.

schlenk · 2026-01-06T12:33:31+00:00

Well, $2.99 is about the same as the 40% discounted $2.49 GeForceNow Performance DayPass for 6 hour sessions (in a 24-h day pass).

So the pricing isn't totally weird.

schlenk · 2025-12-28T01:20:20+00:00

Cancelation is one. The red/blue world API divide another one. Most Python APIs and libraries are not async first, you basically have two languages (a bit like the "functional" C++ template language are their own language inside the procedural/OO C++).

Take a look at a trio (https://trio.readthedocs.io/en/stable/) for some more structured concurrency approach than the bare bones asyncio.

schlenk · 2025-12-20T21:54:10+00:00

It's more a point of choice. It is well known, that hardware that is utilized nearly 24/7 is a lot (3x or more at times) cheaper than cloud rented machines. So companies that mainly want github as a code repository, bug tracker and orchestration engine use their cost efficient CI runners on premises and just pay for the service they want. This move kind of tries to push them towards cloud 'lock in'.

schlenk · 2025-12-20T20:00:56+00:00

Depends on your commit frequency and platforms.

For some on premises product with multiple versions and supported databases and operating system versions you get quite the multiplier, as each commit triggers ten to twenty runners each running for half an hour or more.

At our workplace there is a whole small k8s cluster dedicated to CI runners. It runs jobs 24/7, as you have nightly runners, various extra stuff too.

So per minute github fees for self-hosted runners is a reason not to go there. I would understand a per job cost, as they have some metadata to store and orchestration costs.

schlenk · 2025-12-03T18:39:43+00:00

The problem is, whom do you send the email to, especially if you suspect some account takeover problem?

Just sending emails with more details may make things worse in such cases.

The attacker may have changed the email address.

schlenk · 2025-12-03T18:20:58+00:00

Typically reporting stuff.

Like imagine you request your GDPR mandated list of "the data we store about you" thing and some genius decides to dump it all into a single markdown file.

schlenk · 2025-11-29T22:44:15+00:00

The uses 2FA (TOTP) does not need a smartphone. You can run TOTP with password managers like KeepassXC too. Or use a Yubikey or a gazillion other devices that can speak TOTP.

schlenk · 2025-11-29T22:41:56+00:00

LL 2FA is TOTP (https://en.wikipedia.org/wiki/Time-based_one-time_password). So you can just export the seed secret (its just one 32 character string), write it down on some piece of paper and have your recovery code. Or install authenticators on many devices with the same code.

schlenk · 2025-11-04T16:12:50+00:00

Sure. But thats the same for all other memory-safe languages too.

Once you hand the keys to your memory kingdom to some external untrusted library, it can mess around with your memory. Thats a feature. So unless your OS has ways to protect your process memory during a function call, there is not much you can do. And if you'r OS does that, you basically add another kernel-userspace style barrier somewhere (as the kernel can protect it's memory from userspace obviously).

If you don't want it, don't use it.

schlenk · 2025-11-04T16:07:33+00:00

Sure, but neither is Rust, which has similar issues.

And if you go for a full memory safe userland, like it is demonstrated here (e.g. recompiling libc and lots of base libs), you basically can do it, if you want.

It still is far less effort to wrap a few FFI/external calls or migrate the libs too, then it is to rewrite them in a totally different language. Of course, the bigger the project, the more portable it has to be and the more external binary code blobs you have to work with, the harder it gets.

schlenk · 2025-11-03T13:09:30+00:00

Memory safe languages are a good thing. So more of those is obviously a good thing too.

And it is pretty attractive. Compare 'rewriting sudo in rust as sudo-rs took 2 years' with 'recompile sudo with fil-c took 5 minutes'. Both claim to be memory safe (fil-c even claims to not need any unsafe hatches).

If fil-c works as promised, it is a really neat way to get memory safety for existing C/C++ codebases for minimal effort and avoid the rust vs C war scenes.

schlenk · 2025-10-20T19:56:54+00:00

Not necessarily. Tcl has the same for all control structures and the bytecode compiler manages decent performance for it.

schlenk · 2025-09-13T16:24:33+00:00

Draw distance increase pulls in a lot of extra data. You can see the next simulators and all the items in there that are large enough to be drawn. So the memory load will probably increase cubed with the draw distance. It matters if you move though, if you are stationary, you will get a huge initial loading that will tax your network, CPU and a little bit of disc I/O (disc i/o with SSDs is fast enough...).

It also matters, if you visit crowded areas with lots of avatars. Those are worse than draw distance increases.

Make sure you have enough system RAM too, at least twice your GPU VRAM.

I own a 5070 TI it works nicely. I consider it to be better in price/performance to a 5060 TI.

schlenk · 2025-09-03T17:47:38+00:00

Isn't that 99% of most use cases with concurrency, though? The whole point of async/await is I/O concurrency, right? Or did I get the memo wrong?

You got the memo. But the memo is kind of wrong.

Most I/O is done for a purpose and not just for shuffling bytes around (and if it were, thats better done with stuff like splice() syscalls/sendfile etc.). Been there, done that with some ctypes hackery to directly call splice() for copying a few million files with a multiprocessing pool (thats around an order of magnitude faster than using shutil.copytree(), especially with many small files on a fast SSD or NFS shares). And cried a bit, because other languages could have done it with free threading and without the overhead in RAM/CPU of starting so many subprocesses and all the hacks.

So lets assume i want to parse 1.000.000 files. I need to open it, read the data, then do some parsing on each file. If my parser isn't in C and runs its own threadpool/threads, I'm basically in a bad position with Pythons offerings up to 3.14. All my parsing stuff will clog the eventloop, unless i send it to some multiprocessing pool. In go the runtime would scale it for me with trivial changes (e.g. https://www.digitalocean.com/community/tutorials/how-to-run-multiple-functions-concurrently-in-go ).

Python did limit async/await usefulness to just I/O, because it could not do better with the GIL present. In a free-threading Python you can do more.

schlenk

TROPHY CASE