thayne

My ISP is only a few years old, but they don't support IPv6 at all. And when I complain about it to support, their response is basically "we don't see the point".

That's actually one indication of how quality has gone down. When I was a kid, I remember a lot of big ticket items would have "lifetime" warranties or 20 year warranties, but these days it's hard to find anything with a warranty of more than a couple years, unless you buy separate "supplementary" warranty, which is really more of insurance than a warranty.

It isn't a perfect analogy, but I think the weights of a model are closer to a compiled executable than source code.

> I don't recall their being a huge backlash to elasticsearch ELv2.

That's not the way I remember it...

> HashiCorp has the same business model

And Hashicorp's software is no longer open source, after they changed the license.

How about a joint effort by multiple governments, done fully in the open, with all results, including training data and methodology fully open source?

> Open source doesn't mean "anyone can use the source code commercially".

Yes it does. It might have requirements that you release the code for any changes you make to it or link with it. But no OSI (or FSF) approved license prohibits you from using it commercially.

Even before Let's Encrypt was a thing, that is how most DV (Domain Validated) certs were issued. It was just a more manual, more expensive process to do it. GP's point is since the system depends completely on trusing the DNS chain anyway, why not have the registrar [sic. it should actually probably be the registry] act as the CA as well and cut out the middleman, and the need to verify the domain from multiple paths to prevent MitM.

In Physics, if a theory doesn't describe reality, the theory is incomplete. Of course all theories are ultimately incomplete, the goal is to find theories that match reality better than the ones before.

CRLs were a great (ok, maybe just ok) design in the early days when the internet was small and the number of CAs and revoked certificates was small. But it was never going to be scalable. And it has the really big problem of needing to distribute these lists of revocations. OCSP has a different set of tradeoffs.

I would really love to know a reliable way to determine if a product is a reliable before buying.

The newest version of python that PyPy supports is 3.12. CPython is on 3.15.

And from what I understand there are limitations with using libraries that use the CPython API to interface with native code.

I think you are interpreting 2 as offering some large amount of money as a prize for discovering a solution. But I think it was meant more as funding a team of mathematicians to work on the problem.

> We do not seek academic credit for the discoveries produced by our internal models.

Sure. But that isn't what they really cared about anyway. They care about notoriety among the general population, and especially among people who decide to pay for their products.

I don't think there is anything in quantum computing that is specific yo the many worlds interpretation.

> or automate the process of listening for and reacting to vulns

1. This is also very hard to do correctly.

2. What automated steps would you take without any patches available to apply?

3. Potentially makes you more vulnerable to supply chain attacks

Postgresql uses pages too. The records aren't kept in any kind of order, but the indexes are. So uuidv7 is still useful for postgresql because it means inserts are less likely to be spread across many pages in the primary index.

It seems like it would make more sense for ty to be integrated with ruff than uv.

> refusing br content-encoding at the edge seems like the fastest mitigation.

That's pretty difficult if you make outbound requests, and don't already have a TLS interception proxy set up.

Unfortunately, AFAICT, there is no way to do this for node's fetch. I suspect there are other client libraries that don't have a way to disable it.

In my experience the phrase "it couldn't have been designed better to [negative thing]" is typically used, in a sarcastic, and usually exaggerated way, to mean "they did such a bad job, that they couldn't have done [negative thing] better, even if they had been intentionally trying to do [negative thing] (which they weren't)."

But even with those massive improvements, it's still slower than 1.1.1.

It also depends on exactly which version of OpenSSL. We ran similar tests with multiple versions of openssl. Openssl 3.0, which was the version in the official packages of our LTS distro was unacceptably slow. With 3.4, it was still worse than 1.1.1 but the regression was an acceptable level.

It also definitely depends on your hardware, and how you use it. The main source of the performance regression is more lock contention, so it is more noticeable if you have more threads running on more cores.

That isn't really relevant for the tool starting the container. The biggest problem with go here is that it can't natively perform the operations necessary to set up a container, due to the nature of the runtime, so it has to resort to complicated workarounds like a shim in c, and starting spawning from /proc/self/exe instead of forking/cloning.

I understand that's probably how the law works, but it is kind of nonsensical to me that it passively allowing visitors from a country would pull you into their jurisdiction. Requiring you to be responsible for blocking any users to your service from U ensures seems analogous to an author of a book that is illegal/censored in U being required to make sure that no one from U buys the book and takes it back to their country.

Well, they might be able to go against the domain registrars and possibly cloud providers that also operate in the french market. But those companies probably have a bigger expensive legal team, while quadnine is just a little non-profit.

It isn't just governments. Cases like this are started by companies.

Most of them don't seem that weird to me. Except the use of go. It definitely seems strange to pick a language that can't natively call clone, one of the most important syscalls for using namespaces and implementing containers.

That's actually a design decision made to work around the limitation of having to run as root. Since the container had to be started as a privileged user, if you want non-privileged users to be able to start contianers you either need a setuid binary or a client/server interface like docker has. There are pros and cons to each of those options.

Now it's possible to create containers without elevated privileges (assuming user namespaces are allowed), but that wasn't possible until long after docker had established the client/server model.

I assume you mean podman?

The first two are just kind of the nature of containers on linux, and applies to any container technology.

Podman does allow you to run it as a non-root user (with some limitations), that was in fact one of the biggest motivations for making podman. This wasn't possible at all in the early days of docker, it wasn't until linux introduced user namespaces, where the root user inside the namespace mapped to a non-root user id outside the namespace that non-root conatiners were possible.

And podman, unfortunately IMO, is also written in go.