Indeed. If it were just a question of Swiss law, we'd be in excellent shape. The problem is that France and Switzerland are both signatories to the Lugano Convention, while the US is not. As long as the Quad9 Foundation has to have a legal domicile somewhere, there will always be some lever that can be used against it. Switzerland was the best place, but does not offer perfect protection.
Quad9 is not a telecommunications service provider as defined by Swiss law, which is where that application becomes enforced. Details of this (and many other things) can be found on the "Compliance and Applicable Law" section of the website. https://quad9.net/privacy/compliance-and-applicable-law/
It still feels a little strange that that loophole is allowed: everyone who has a Swiss ISP could switch to Quad9 and be strictly better off. But if everyone does that, then the DNS ban is completely ineffectual. Maybe I should let sleeping dogs lie.
I have a feeling the fact that people have to opt in to using Quad9 does a lot to help them in this case vs an ISP where all of their users are using the ISP’s DNS by default. But yeah it does seem like a “letter of the law vs spirit of the law thing”.
That's because the Swiss DNS blocking originated in an anti-unregulated-gambling law. Basically all unregulated gambling websites are blocked. There shouldn't be any other sites on that list.
I'm a little mad because it's the principle of the thing.
In practice the only site I occasionally want to check that's blocked is Polymarket. I don't trade on there myself, but I find it useful to check the odds of certain events.
I don't personally care about betting sites but it's the legal precedent and principle that the government can add anything to such a list and make obligatory.
"First they came for the shady weird-ass online gambling sites...."
Nuclear is to solar in terms of energy generation what hydrogen is to electric for cars: it's proponents keep arguing that the other thing doesn't work and will never work, and that you absolutely, positively need their approach. And then it just works and effectively kills off the other technology within a couple of years. Nuclear is basically already dead, and anyone starting new nuclear projects now will look extremely silly in 20-30 years when they finally come online.
They might not look silly because they will have material from which to make nuclear weapons, which is the principal reason we have nuclear power at all.
That is how you end up with a test suite that now takes 10x as long, unless you occasionally prompt the agent to consolidate and group tests.
There are still a lot of issues with coding that require intervention. Just recently, I had Astra detect a minor bug in an HTTP client that resulted in it deciding that the best approach would be to spend 1800 LOC on implementing its own from scratch. Some other time, Opus 5.5 was trying to tell me that test runs on a small to mid-sized application would take another three weeks until they would be fully finished.
If you need a reason, the modem and the baseband firmware have several unpatched vulnerabilities on that model, which is not something that an Android update can resolve.
Based on the amount of modem CVEs posted in the monthly Android security bulletins, I think it's safe to assume that if you are no longer getting updates then there are unpatched vulnerabilities in them.
Based on the artificial delays Google introduces into the Android patching process, on the general crappiness of mobile firmware and the sleaziness of major mobile chipset vendors, I think it's safe to assume that even if you are supposedly getting updates, there are unpatched zero-day vulnerabilities in them. Usually under ongoing attack, at least by professional phone cracking software vendors and secret services.
>Based on the artificial delays Google introduces into the Android patching process, on the general crappiness of mobile firmware and the sleaziness of major mobile chipset vendors, I think it's safe to assume that even if you are supposedly getting updates, there are unpatched zero-day vulnerabilities in them.
Maybe if you include third party android OEMs like samsung, but google pixels are as up to date as you can get.
Pixels running GrapheneOS sure, but stock Pixels lag months behind patches that exist but not yet shipped. Check any bulletin and it links to git commits to months ago.
>Check any bulletin and it links to git commits to months ago.
Is there any evidence that the git commits weren't in the ROMs from months ago? The monthly ASB corresponds to when the bugs are publicly disclosed, not when they made it into ROMs.
Pixels only ship a tiny subset of the security preview patches early. Samsung ships a subset for their flagship devices too and it's likely larger than Pixels. Samsung lists these patches in their bulletins and you can retroactively figure out which were future Android Security Bulletin patches. Go through the vulnerabilities for September 2026 or October 2026 and search for them in Samsung's bulletin.
The only way to get the full set of security preview patches is through GrapheneOS. It's strange Google doesn't ship more for the Pixel OS but that's the way it is right now. It takes them around 4 weeks to make a release and even longer when including the time for adding changes to it so there's a long delay built into the process. They should fix it but are clearly not prioritizing it without media pressure that's not happening. They do a lot better than other OEMs but that's much different from doing a good job.
Android Security Bulletins don't list the vast majority of firmware, driver, HAL and especially Linux kernel vulnerabilities. Those list a large subset of the High and Critical severity Android Open Source Project (AOSP) vulnerabilities backported to older releases along with a tiny portion of non-AOSP vulnerabilities. AOSP vulnerabilities below High and Critical severity aren't backported so those aren't listed. Non-AOSP vulnerabilities for Pixels are covered in the Pixel Update Bulletins with many of those being vulnerabilities in components used by other devices. Each OEM is supposed to make their own equivalent to the Pixel Update Bulletins, but they aren't required to provide those updates to claim the latest patch level.
It has remotely exploitable vulnerabilities in the firmware, Linux kernel, kernel drivers, userspace drivers and HALs. Those don't require installing anything on your device to exploit. There are publicly available proof of concept exploits for a bunch of these vulnerabilities.
And how many CDs can you buy per month for the price of a Spotify subscription? I am not going to be spending hundreds of Euros per month on physical media, and I also value my time too much to bother with ripping and converting these, just so I can end up with a worse experience for more money, while also producing a bunch of unnecessary plastic rubbish.
I don't understand myself, what you actually gain from constantly buying new music. Either the music is good, or it's not. If it's not it's not a loss to not buy it, and if it is it's not going to stop invoking the emotions you like it for, or intellectually demand you. You can hear the same music for hundred of times and still discover some new aspect, instrument, melody or sound, you haven't noticed yet. (if it is good)
If I would try to chase, constantly, new music, I wouldn't be able to actually listen to anything, and thus wouldn't enjoy anything at all.
(The only thing that makes sense to me, if people want to be like their peers and up to trends, so simply "listen" to new music to be able to talk like they now what's en vogue right now. But then it's hardly about the music itself and more like collecting an evergrowing checklist.)
At least for a family plan ($22/mo), around 2-20 or so depending on the CD. That accumulates pretty quickly, and of course you don't have to worry about limitations like living at the same address.
This may be the main difference between consuming content and listening to music. For some people, more is not always better and the process of building a collection and putting time and energy into it is a big part of the experience.
After ten years of Spotify subscriptions, you own nothing. Put that $12.99 or more per month into discs instead, and you'd have quite a nice music collection that's still yours ten years later.
You dont own those either. If you lose your copy, it's gone forever with no remediation or claim of ownership except at the specific retailer you did your transaction at. The source where it came from is unaffected by your loss, and they can decide at any time to stop selling their discs with or without your involvement. The nostalgic rose tinted pandering behind vinyls and old media conveniently forgets the introduction of digital storage to actually ensure reliable redundancy, and so "buying" physical media is just a smoke and mirrors way of saying the disc is for vain aesthetics while the actual mental relief comes from the secondary process being able to digitize it locally.
Following the same mindset of circumventing the traditional process, I could spend one single month ripping every single song I possibly can from Spotify and have the same claim of ownership over their files that you do with a much larger variety and without all the wasted physical space on assets that are immediately digitized. The only benefit to your method is that you feel like it justifies hoarding.
Presumably people also have some sense of fair exchange when buying the disc to rip vs. ripping from Spotify. If you want to be strictly rational you can of course skip the Spotify part too and just pirate it.
Astra is barely usable even on the $100 plan. And that is if it doesn't just burn through 80% of your weekly quota in a couple of hours by continually expanding the scope of the task you gave it - while not noticing the failing tests that are right in front of it.
Opus is at least actually usable even on the small plan. The main downside is its insane writing style, but 5.5 seems to address that somewhat. Otherwise, you can just use your $20 OpenAI plan to have Luna de-slop Opus' prose, which seems to work fine.
I have a Claude Code hook that calls codex for a code review on commit time (Codex is set to Astra Medium) and it's been pretty good in general. It sometimes hits the 5hr limit but most of the time it provides really good feedback and because it's a completely different model it's mostly complementary to what Fable/Opus do themselves. IMHO it's been $20 well spent.
...but the few times I've tried to use codex for a moderately difficult task it burned through its limit extremely quickly.
reply