flakes

Most of the parent comments in this thread did not seem to understand the article. So here’s the tl;dr

Postgres release is delayed due to the quality bar getting raised. New features are getting more eyeballs, and therefore leading to more rollbacks. Pre-existing releases are getting bug reports and backported fixes at much higher rate. Bug fixing might be taking away time from feature development, but does harden the codebase. LLM usage seems to have been a net positive.

During an internship I worked on optical transport network equipment. Most customers were either submarine or long-haul across land. I was told that many clients would design redundantly, mainly due to people digging up the cables, chopping them in half with a shovel, and being disappointed when there was not much copper to steal.

Quebec gets weird with their french rules. Parents are not allowed to send their kids to English speaking schools if both of the parents did their own schooling in French.

I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.

I interviewed with Microsoft at the end of 2016 as a new grad and was given the same marble question over the phone. I then made it to the on site interview where I failed horribly haha.

IMO a release workflow would be better with something like this:

1) Upload all files in a staging state. Can be done asynchronously via multiple build hosts. Files in this state are referenced via their cryptographic checksums (e.g. SHA, Blake, etc)

2) Make visible with a single call by providing a manifest with checksums for all source dists/wheels contained in the release. All artifacts are made visible atomically and the release is immutable.

That allows authors to prepare uploads over however many days they need to coordinate hardware, but doesn’t allow for users to discover a release in a partial state.

What exactly isn’t a language feature? Or do you have issues with semantics?

    var _ Foo = (*Bar)(nil)

The statement asserts that Bar struct pointers are assignable to a Foo interface.

I do agree it’s not as clean looking as the Java implements keyword, but it’s already a fairly terse pattern and IMO the inconvenience does not justify introducing new language syntax.

How is a package level interface check a “language hack”? They are straight forward and provide a user the same compile time guarantees as the Java implements keyword.

> Isn’t this a symptom of structural/duck typing where interfaces are not declared

Yes, essentially duck typing. See https://github.com/golang/go/blob/65504872cbca64d77f45828409...

The logic uses a type assertion to safely verify if the value backing the provided io.Reader interface also implements the io.ReaderFrom interface. If it matches, then it will use the more efficient implementation

    if rf, ok := dst.(ReaderFrom); ok {
        return rf.ReadFrom(src)
    }

> In Java for all its faults this wouldn’t happen because you’d be forced to implement all the interfaces.

I don't think I would go that far. In Java, many libraries make heavy use of the `instanceof` keyword, which is more or less the same as Go type assertions.

sendfile(2) and io.ReaderFrom both return the number of bytes transmitted. The issue is that users are unaware of (or forget about) the optional interface upgrades and fail to define all the methods required for interface upgrades on their wrapper structs. You can definitely make a counting reader with a minimal performance loss, but the proper solution is less obvious than it ideally should be.

We did do a lot of work sealing the exterior of the home, as well as removal of bird feeders near the house itself. The poison likely wasn’t a silver bullet, but I recall it (along with removing any access to easy food) having the most dramatic impact overall.

One is not really better, you want both. Certificate revocation lists are loaded out of band and depending on the client can be poorly enforced.

Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it?

When the cert expires, it can be removed from the CRL, so shorter lived certs will allow CRLs to be smaller and faster to transfer.

When we had mice in our house years ago, we tried for a few weeks setting poison bait in the garage to get rid of them. We could tell the mice were eating the bait, but there was still no end to the mice.

We then had a thought... what if the mice were also eating the dog food in the garage? The container lid for the dog food was not very strong (weak and flexible enough that a mouse could possibly squeeze in and out), and coincidentally, that dog food was also high in Vitamin K.

Once we got better sealed containers to store the dog food, it only took a few days before we started seeing delirious, sick mice running around aimlessly in plain day light. Shortly after that, we stopped seeing them entirely.

It's possible the dog food was not reversing the poison. Maybe with the dog food locked up they started eating more bait, or maybe it simply took longer than we expected for the poison kick in. But regardless, we definitely learned a valuable lesson about keeping the pet food well sealed!

These models are getting crazy good at examining things like core dumps and disassembly. I've been using an agent to write compiler logic, and its amazing the kind results you can get by having the agent examine the raw binary outputs. I would not be surprised to see agents excel at identifying and labeling patterns for decompilation.

One of the classic examples is highway traffic. You want to prevent traffic jams, so you increase the number of lanes. However, now that there are more lanes, people see less “cost” in driving, leading to even more people driving (e.g. to go on more day trips or as alternative to public transport). This can cause the traffic jams to become even worse.

So, increased efficiency can sometimes not lead to reduced latency, which goes against our natural thinking.

Thanks for the correction. I did mean given the same tooling version/parameters, but (as you and others pointed out) preserving and recreating that state is not at all straightforward.

Thats true. And regardless of compressed vs regular tar, I think the OCI format working with opaque archives is extremely limiting. I hope the industry will eventually redesign to use content addressable storage per file and have metadata to describe the layer/disk layout instead. That would allow per file deduplication, and we can use tar for just bulk transfer over the wire, rather than using tar for the data at rest.

Recompressing should be guaranteed deterministic. It’s the packing/unpacking of tar archives to/from directories on disk that leads to the non-determinism (such as timestamps and ownership metadata). If the tar is left intact, both zstd and gzip should produce byte for byte identical outputs given the same compression parameters.

When a child process finishes (that is not actively being waited on) it is left in a "defunct" or "zombie" state and will stick around in the process table until the parent process waits on them to fetch exit code. When you kill a parent process with active children, these subprocesses will become orphaned and re-parented to the OS pid 1 (or another "sub-reaper" process depending on your setup).

The OS will typically not kill orphaned/re-parented processes for you. It will simply wait/reap them so they are not left as zombies once they complete. If your parent process spawns something like a daemon server that needs an explicit signal to be stopped (e.g. SIGINT/SIGTERM), these processes will continue to run in the background until they are manually killed or they crash.

> "this test failure is preexisting so I'm going to ignore it"

Critical finding! You spotted the smoking gun!

I would say that this is limited to a targeted Go version and architecture. For example, the filter checks for the goroutine pointer on `r28` which is correct for arm64 but not universally true.

Any changes to the struct layouts, stack, or heap layouts would also cause failures in these lookups. E.g., in Go 1.17, many functions now use direct register mappings for arguments rather than always placing arguments in the stack.

Would need to thoroughly vet compatability with each new Go version before using something like this in production.

You’ll probably want to look to the PEPs. Havent dug into this topic myself but looks related https://peps.python.org/pep-0744/

I'd say a lot of users are going to borrow patterns from Go, where you'd typically check the error first.

    resource, err := newResource()
    if err != nil {
        return err
    }
    defer resource.Close()

IMO this pattern makes more sense, as calling exit behavior in most cases won't make sense unless you have acquired the resource in the first place.

free may accept a NULL pointer, but it also doesn't need to be called with one either.

Thats interesting. If you’re on Chrome I’d try out Firefox just to see. I haven’t had any issues for a long time.

I find it better to bubblewrap against a full sandbox directory. Using docker, you can export an image to a single tarball archive, flattening all layers. I use a compatible base image for my kernel/distro, and unpack the image archive into a directory.

With the unpack directory, you can now limit the host paths you expose, avoiding leaking in details from your host machine into the sandbox.

bwrap --ro-bind image/ / --bind src/ /src ...

Any tools you need in the container are installed in the image you unpack.

Some more tips: Use --unshare-all if you can. Make sure to add --proc and --dev options for a functional container. If you just need network, use both --unshare-all and --share-net together, keeping everything else separate. Make sure to drop any privileges with --cap-drop ALL

Maybe it's a mix of me using the site less, or questions I previously answered not being as relevant anymore, however as it stands, it's just not fun to visit the site any more.

I have about ~750 answers and 24K rep after almost 12 years of being a member. The site was a great way to spend some free cycles and help people. My favorite bounty answer lead to me finding a bug in the Java compiler! I even got recruited into my current role from the old Stack Overflow Jobs board.

With AI, not only did the quality and frequency of posts go down, but the activity on my existing posts are basically zero now. I used to have a few notifications a week with either comments on my past answers/questions or a few upvotes (for those fun little serotonin boosts). Looking at my past stats.. in 2023 I had ~170 notifications, in 2024 that dropped to ~100, and in 2025 it went down to ~50 (with only 5 notifications since September).

I don't feel engaged with the community, and even finding new questions to answer is a struggle now with (the unanswerable) "open-ended questions" being mixed into the normal questions feed.

> Maybe once every four years on leap day or something.

Advantage: You no longer need to fix that leap day bug on your website.

I do the same, but I skip rsync for git.

    git clone $uri dotfiles; export HOME=$(pwd)/dotfiles 

These days, my laptop acts as a dumb SSH gateway for Linux VMs. No configuration or setup, aside from VS code connecting to VMs. Any server that I would want to load my dotfiles onto will almost always have git installed.

Rant (not directed at any comment here): If it's a production server without git, then please do not run scripts like this. Do not create junk directories on (or ideally any modifications to) secure machines. It inevitably causes new and uninteresting puzzles for your colleagues. Create documented workflows for incident responses or inspection.

Auto has really made c++ unapproachable to me. It's hard enough to reason about anything templated, and now I frequently see code where every method returns auto. How is any one supposed to do a code review without loading the patch into their IDE?

A selfie at that resolution would be some sort of super-resolution microscopy.