mxey

The problem is that it is actually not just Python, branched with “normal if statements”: https://docs.pyinfra.com/en/3.x/deploy-process.html#checking...

That’s the opposite of clean-room. The whole point of clean-room design is that you have your software written by people who have not looked into the competing, existing implementation, to prevent any claim of plagiarism.

“Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.”

PostgreSQL shares other caches between processes so they probably could have a global plan cache if they wanted. I wonder why they don’t though.

One possible reason is that the planner configuration can be different per connection, so the plans might not transfer

This is very good to know because it means this exclusion constraint workaround is a better approach over using a SQL hash function and a btree if you want to enforce uniqueness on values too long for a btree index.

No, that’s why I said deploy. All it does is run kubectl apply and kubectl rollout status.

Only those are directly tied to the data in CUE. there’s not much advantage to running other commands with it. You can run arbitrary processes with cue cmd though.

“ss” also has filters, no need for grep

ss -o state established '( dport = :ssh or sport = :ssh )'

There will be no certificates longer than 45 days by any CA in browsers in a few years.

Not sure if that’s what you mean but we have apps where all you need to deploy them to Kubernetes is run “cue cmd deploy”.

> The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support.

cue cmd is nice but it’s not the reason to use CUE. The data parts are. I would still use if I had to use “cue export” to get the data out of it with a bit of shell.

Without those headers, you can as a fallback compare the Origin header to the Host header.

See https://words.filippo.io/csrf/

I had the same thought about the idea that Safari is “behind”. My hypothesis is that features only “exist” to people if they are implemented in Chrome. If a feature exists in WebKit but not in Chrome, nobody talks about it.

iPhones tend to have dramatically better JavaScript performance so you might wanna also test on an average Android phone.

I can’t wait for websites to tell me I need to install Chrome on my phone.

Safari adds support for new web features in point releases throughout the year.

you know you CAN make small websites with the existing standards already

Quilt was AFAIK used before Git, so you’re not wrong. But now that it’s there, it has some advantages.

I’m not arguing against replacing Quilt, but it should be more than just Git. I haven’t done Debian packaging in a long time but apparently there are some Git-based tools now?

So there’s no way to have commit messages on changes to patches? There’s also https://dep-team.pages.debian.net/deps/dep3/

People keep saying “just use Git commits” without understanding the advantages of the Quilt approach. There are tools to keep patches as Git commits that solve this, but “just Git commits” do not.

How do you track changes to the patches themselves?

> For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience.

The golang/go repo itself has various checked-in generated repo

> On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it).

https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processin...

What do you mean that there is no standard decoder? For what, UTF-8?

I agree on the composability. Accepting Unicode code points is more generic. I guess it depends on your environment. If every caller will combine it with a UTF-8 decoder, you might want to include it.

> Unfortunately, in software, manufacturing costs are too cheap to meter, so we're fine with using bench-top prototypes in production, because we're not the ones paying the costs for the waste anyway, our users are.

I’m not sure what you’re trying to say - UTF-8 is the standard text encoding by a mile. It’s not a prototype.

If this makes the library harder to use because most people will have UTF-8 strings, I’m not sure that’s a win.

There is an overhead per container launched so it would probably not be worth it.

I recently wrote some Go code for running containers and chose to use the docker CLI instead of an API client. The CLI is more well known and better documented, and this is what replacements like Podman support. When there’s a problem, it’s easier to reproduce it by running the same CLI command. It also meant I wouldn’t need a whole lot of dependencies, and we needed the docker CLI anyway.

Obviously you shouldn’t try to parse human-readable output.

JFTR, of course it has a library for it https://pkg.go.dev/os/exec

> You can also argue that sd_journal (the C API) exists for this exact reason, rather than shelling out to journalctl.

Quoting from https://systemd.io/JOURNAL_FILE_FORMAT/

> If you need access to the raw journal data in serialized stream form without C API our recommendation is to make use of the Journal Export Format, which you can get via journalctl -o export or via systemd-journal-gatewayd.

Certainly sounds like running journalctl, or using the gateway, is a supported option.

Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.

Linus didn’t name Linux, someone else named it after him.

> For users that require new features or reliable resolution of reported bugs, we recommend using pgx which is under active development.