ris

It's weird to me that TALA is considered the "special sauce" layout engine, because I've only ever had it produce extremely weird layouts for me.

I always tend to end up using ELK.

I much prefer d2 https://d2lang.com/

Only downside is AFAIK no in-browser renderer.

I would much much prefer the cited "awful" syntax over the proposed loop syntax any day. Don't make me run a little virtual machine in my head to figure out what the end result of a block of code is going to be.

Let's take this thing to Canada.

I think it's about more than just having ABI stability - the rust ecosystem is built around applications being able to demand exact micro-versions of every dependency and that falls apart when you want multiple non-cooperative applications sharing the same crate binary.

This is cool, but still

(...HN formatting fail, imagine shell output showing the nixpkgs bash binary is 1.1M, the brush binary is 6.9M...)

with no prospect of further amortizing that size through shared libraries. Without shared libraries the only chance I see for rust being used to replace base system tools is with multi-call binaries a la busybox.

Please see yesterday's https://simonwillison.net/2025/Apr/29/chatgpt-is-not-bad-for... instead of propagating the hand-wringing.

Distributions tend to use shell-script-wrapped compilers that can inject additional flags desired by the distribution, and in all likelihood distributions will just add flags that force the old behaviour if there are problems.

Yeah sure if you want to get zero guarantees about any of the versions of anything you're getting.

Worst part of GitHub Actions? Its encouragement of the total misuse of containers as what have essentially become installer scripts - complete with all the flakiness you'd imagine.

Go look at your workflows and see how much of the runtime is spent running installers upon installers for various languages, package managers and so on. Containers were not supposed to be like this.

Have you ever donated? What services do you want that shouldn't be available to non-paying users.

Some people are very good at this, e.g. https://app.media.ccc.de/v/35c3-9614-inside_the_amd_microcod...

Still waiting for someone to train an LLM entirely from sources written before a chosen date and be able to discuss concepts with someone apparently lacking any knowledge of the world after that date.

> Restate is open source and you can download it at...

https://github.com/restatedev/restate/blob/main/LICENSE#L1

> Business Source License 1.1

https://spdx.org/licenses/BUSL-1.1.html

> The Business Source License (this document, or the “License”) is not an Open Source license.

Suggest exploring e.g. https://github.com/dbos-inc/dbos-transact-py

Why? It just isn't what draws me to Nix.

I've never even really tried NixOS on the desktop TBH.

I think this is quite a fair commentry (although I quite like the Nix language personally) - as a nixpkgs developer even I don't use NixOS on the desktop. For me it shines on servers and development environments.

No, I'm not going to give you access to WebGL just to show me a map.

Those tricks cover a very small subset of dynamic queries, and if you don't give your developers a proper tool to do dynamic queries in, your code will start growing these funny string-formatting-based query-mangling functions that have god-knows-what escaping problems behind them.

And you end up with no canonical declaration of the schema in your application code, leaving developers to mentally apply potentially tens, hundreds of migrations to build up an idea of what the tables are expected to look like.

This is a fun article, but the whole "dependency resolution problem" is a bit of a wild goose chase anyway, because the underlying data you're basing it all on (what package authors publish as their version constraints) is only slightly better than junk. For a start, python (like most ecosystems) is very limited in its ability to express compatibility constraints - it's not even able to understand the concept of stable branches that receive backports.

Add to that most package authors putting about a second's thought into their version constraints, with other package authors being overzealous and for example thinking it's their duty to protect you from security vulnerabilities through their version constraints, and I frequently doubt the worth of putting all this SAT wizardry into these tools, as fun as it is.

> A nation state can probably buy the building across the street if that's the value of hacking your system.

So make them spend that money.

Or, more likely, convince them to refocus on a cheaper target.

Terraform

I'm not really convinced of the value of such attestations until a second party can reproduce the build themselves on their own hardware.

Putting aside the fact that the mechanisms underpinning Github Actions are a mystery black box, the vast vast vast majority of github workflows are not built in a reproducible way - it's not even something that's encouraged by Github Actions' architecture, which emphasises Actions' container images that are little more than packaged installer scripts that go and download dependencies from random parts of the internet at runtime. An "attestation" makes no guarantee that one of these randomly fetched dependencies hasn't been usurped.

This is not to go into the poor security record of Github Actions' permissions model, which has brought us all a number of "oh shit" moments.

Further to this, don't underestimate how powerful git diff | sed | git apply can be for mass edits of files.

Nothing?

Just Say No to "endpoint security"

This sounds like a message written from a time before NixOS.

How about you stop trying to create package managers for every single language/ecosystem in existence and instead converge on trying to solve the whole problem once and for all with Nix.

Makefiles become a horrific technology the minute dynamic variables and the ensuing escaping games get involved. Massive footgun. Bash is already a fairly bonkers language (think from a junior engineer's perspective) and Makefiles so frequently compound that by an order of magnitude.