mxey

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.

> especially if readers don't read to the bottom.

That note at the bottom was only added after the article was posted.

> We’ve discussed doing brownouts where we fail everything for an hour with clear error messages as to what is happening.

That sounds like the best option. People are used to the idea that a service might be down, so if that happens, they’ll look at what the error is.

The article has a new note at the bottom:

> In case the sarcasm isn’t clear, it’s better to leave the warts.

So existing binaries will keep working?

glibc, which has had ABI compatibility for decades?

Go does deprecate stuff. It just never removes it.

> If you develop a useful library and give it away for free then all power to you if you want to rearrange the furniture every 6 months.

That would make it no longer a useful library

Actually this is the reason why Win32 is the stable ABI for Linux.

https://blog.hiler.eu/win32-the-only-stable-abi/

> Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be.

In this case it was 2 functions with 1 line of code each. https://github.com/urllib3/urllib3/pull/3732/files

It is wild to realize that this is the same author as https://entropicthoughts.com/you-want-technology-with-warts

It’s like 5 lines of code https://github.com/urllib3/urllib3/pull/3732/files

Haven’t seen this mentioned yet, but this means you can do media queries in inline styles, right?

I’ve run Kubernetes since 2018 and I can count on one hand the times there were major issues with an upgrade. Have sensible change management and read the release notes for breaking changes. The amount of breaking changes has also gone way down in recent years.