What part do you disagree with? It sounds like you don’t disagree with either the title of the article or its contents.
> In talking to engineering management across tech industry heavy-weights, it's apparent that software engineering is starting to split people into two nebulous groups:
> The first group will use A.I. to remove drudgery, move faster, and spend more time on the parts of the job that actually matter i.e. framing problems, making tradeoffs, spotting risks, creating clarity, and producing original insight.
My guess is that significantly fewer people use drugs than would have used drugs if they were not banned.
> "The Crime Survey for England and Wales (CSEW) estimated that 8.7% of people aged 16 to 59 years (around 2.9 million people) reported using any drug in the last 12 months for the year ending (YE) March 2025; there was no statistically significant change compared with YE March 2024"
Are there some significant changes to policy during that time period? I don’t see how this factoid is related to whatever argument you are trying to make.
Yeah, murder is illegal too, but still the number of murders is non-zero. Maybe we should just legalize it?
Sarcasm aside, if the goal is to reduce consumption, criminalization does work. Repression, though, does come with its own can of worm (an euphemism, yes). It's up to the citizenry and its representatives to decide if the trade-off is worth it.
At the cost of how many people's lives that get jailed for doing drugs/smoking and not hurting anyone?
Telling people what they cannot do in the privacy of their own homes is a massive invasion of pri... Ohh, well England is par for the course when it comes to that at this point.
How many people's lives have been ruined due to them getting caught with drugs? Your "net positive" just focuses on using force to make people not have self agency to what they do to their bodies.
You know what would really solve crime and drug abuse issues? If we just gave people lobotomies at the age of 16. They will all be nice and complacent and due what they're told by the state.
IMO—package manager outside the container. You just want the packages inside the container; the manager can sit outside and install packages into the container.
For the package management, it depends on the package manager, but most have some mechanism for installing into a root other than the currently running system.
Even without explicit support in the pacakage manager, you could also roll your own solution by running the package manager in a chroot environment, which would then need to be seeded with the package manager's own dependencies, of course (and use user-mode qemu to run pre- and post-installation scripts within the chroot in the case of cross-architecture builds).
Whether this yields a minimal container when pointed at a repository intended to be used to deploy a full OS is another question, but using a package manager to build a root filesystem offline isn't hard to pull off.
As for how to do this in the context of building an OCI container, tools like Buildah[1] exist to support container workflows beyond the conventional Dockerfile approach, providing straightforward command line tools to create containers, work with layers, mount and unmount container filesystems, etc.
There have got to be a million ways to do this by now. Some of the more principled approaches are tools like Nix (https://xeiaso.net/talks/2024/nix-docker-build/) and Bazel (https://github.com/bazel-contrib/rules_oci). But if you want to use an existing package manager like apt, you can pick it apart. Apt calls dpkg, and dpkg extracts files and runs post-install scripts. Only the post-install script needs to run inside the container.
I may be a little out of touch here, because the last time I did this, we used a wholly custom package manager.
Docker recommends using multi-stage builds e.g. Stage one image has the package manager, stage two image omits it completely, leaving only the installed software.
Recently I’ve been noticing that Nix software has been falling behind. So “the software you need is almost certainly there” is less true these days. Recently = April 2026.
That's been an issue for years from my impression of the state of NixOS. There are other problems too, like a lot of open source packages doing straight binary downloads instead of actually building the software.
Are you referring to how the nixpkgs-unstable branch hasn't been updated in the past five days? Or do you have some specific software in mind? (not arguing, just curious)
It’s a variety of different software that just isn’t updated very often.
I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.
“Your own server in a colo” means going to the colo to swap RAM or an SSD when something goes wrong. You rent a server and the benefit is the rentor has spare parts on hand and staff to swap parts out.
My experience with Equinix varies wildly by facility and somewhat by which tech gets the ticket. Chicago has been good, Seattle tolerable, Dublin is dumber than rocks. We flew somebody up there rather than take chances for a big project.
NFS in practice is too different from S3 to make this work.
I’ve been at a couple companies where somebody tried putting an S3 interface in front of an NFS cluster. In practice, the semantics of S3 and NFS are different enough that I’ve had to then deal with software failures. Software designed to work with S3 is designed to work with S3 semantics and S3 performance. Hook it up to an S3 API on what is otherwise an NFS server and you can get problems.
“You can get replication with RAID” is technically true, but it’s just not good enough in most NFS systems. S3 style replication keeps files available in spite of multiple node failures.
The problems I’m talking about arise because when you use an S3-compatible API on your NFS system, it’s often true that you’re rolling the dice with three different vendors—you have the storage appliance vendor, you have the vendor for the software talking to S3, and you have Amazon who wrote the S3 client libraries. It’s kind of a nightmare of compatibility problems in my experience. Amazon changes how the S3 client library works, the change wasn’t tested against the storage vendor’s implementation, and boom, things stop working. But your first call is to the application vendor, and they are completely unfamiliar with your storage appliance. :-(
> but it’s just not good enough in most NFS systems.
NFS is just an interface. At the end of the day it's on top of an FS. It's entirely possible and sometimes done in practice to replicate the underlying store served by NFS. As you would expect there are several means of doing this from the simple to the truly "high-availability."
> […] why would they sell bitcoin to continue funding their mining operations […]
There are usually some fixed costs involved and you need cash flow. Without cash flow, your business can shut down pretty damn fast. With cash flow, your business can stay around longer, maybe long enough for the economics to shift.
This sort of thing happens with oil. There are oil producers which sell at a loss. There was even a brief moment when the price of an oil barrel went negative, which meant that if you gave somebody a barrel of oil, you had to pay them for the privilege of taking that oil off your hands. Oil producers did not all shut down when that happened.
I am a little doubtful of the $19k figure anyway.
> It would actually make more sense to sell all their bitcoin, flood the market with coins to do the price, wait for large miners to collapse and then restart mining at hopefully lower prices.
This kind of market manipulation is not so straightforward.
No, the price of a contract for future delivery to a specific location went negative just before the delivery date, at a time when there was almost no unoccupied oil storage nor transport capacity at said location.
In that circumstance you might sell your right to some oil for almost nothing rather than deal with the consequences of accepting it. You might even pay someone to take it off your hands.
Options is “right but not obligation”. Physically settled futures are an obligation at maturity.
(Both instruments are not that popular in my country, so my daily language is to put both of them as synonym, while they are different animals in some details)
Your guess would be wrong. If you’re trading physically settled commodity futures, and don’t close before the settlement date, you are now the owner of a large quantity of your commodity of choice.
How did she not get to buy oil while the reddit guy got it delivered?
And down in your reddit thread someone says:
>
This is fake but this has happened before years(decades?) ago, hence why brokers added to t&c that they will close out unrolled contracts on your behalf so retards playing oil futes and cfds don't end up having barrels of oil shipped to their nearest port
<
Trying to buy a single barrel of oil <> getting assigned on a futures contract. An assigned long isn't getting a physical barrel either, they're transferring into a pipeline/storage facility/truck.
You're right that your broker will do all they can to avoid you shooting both you and them in the foot. But your agreement with your broker does not control your relationship with the counterparty to your futures contract. If the broker doesn't (or can't) close your position in time you('re both) on the hook.
> Disclaimer: I wrote this on a basic text editor which has spell and grammar check, presumably powered by some sort of AI/LLM tech. The ramblings, and run-on sentences, are all mine.
I think I want this at the bottom of the article, “Words are my own; spell checking and grammar tools probably had AI.”
Fair enough. I've read a bit too much LLM written non-tech posts these year that I'm a bit fatigued. I figured people would just want to know this upfront. Moved it to the bottom now.
reply