Yeah, I had an issue where Claude was convinced that a sqlite database was corrupt and kept wanting to delete it. It wasn't corrupt, the code using it was just failing to parse the data it was retrieving from it correctly.
I kept telling it to debug the problem, and that I had confirmed that database file was not the problem. It kept trying to rm the file after it noticed the code would recreate it (although with no data, just an empty db). I thought we got past this debate until I wasn't paying enough attention and it added an "rm db.sqlite" line into the Makefile and ran it, since I gave it permission to run "make" and didn't even consider it would edit the Makefile to get around my instructions.
Sounds like the problem was that the session was too long, they tend to get extremely dumb, extremely fast. Once you noticed that it was trying to debug if the database was corrupted or not, you should probably have began in a new session, setting a stronger initial prompt about that the database isn't corrupted, so the agent wouldn't consider it at all during the session. I find I get much better results, if I do this iteratively all the time. If anything is wrong, don't add another message with a correct, undo and restart the session with a better prompt so the issue is altogether avoided.
I just saw a YouTube video on a similar topic, with the host noticing that jalapeno poppers seemed to be the same no matter what restaurant he went to, and then it dives into the struggles of NOT using Sysco as your distributor if you want to have local goods. https://www.youtube.com/watch?v=rXXQTzQXRFc
In the article you mentioned the Indy having a T1 interface. I only remembered having ISDN as an option on them, with the use case being that ISDN was pretty easily orderable for people working from home or branch offices and needing to get online with it. T1s were still exotic, expensive and not available in a lot of places. Do you have a T1 card for an Indy? I'd love to see that! Do you know what the intention of that was?
for more background. The short story is that when doing CNAME based validation, they were supposed to put an underscore at the start of the random string for you to add to your DNS records. They still generated sufficiently random strings but didn't include a _ before it which is in violation of the RFC. The rationale is that some sites might do something like give you control of yourusername.example.com and they don't want to make it possible for random users to register the random string and be able to manipulate it. If you don't allow users to generate anything that causes a hostname to appear with a leading underscore, they can't pass the domain validation.
Also, while a DNS name can have an underscore a host name, even in DNS, cannot have this character. So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.
So even if you are completely oblivious to this work, and don't care about security at all, your "Give everybody a hostname" code should already avoid underscore characters as desired because otherwise stuff breaks.
Several current systems use DNS names (but not hostnames) which feature underscores but it's pretty unlikely that you've got (for example) a service where users can pick their own TCP/IP service name and port and issued appropriate records for it in DNS. If you have done this weird thing you probably want to use the existing mechanism (in DNS of course, the CAA record) to tell most CAs that they should not issue for your names even if they think they've received permission. You can then cut a suitable deal with a for-profit CA to do whatever crazy extra checks you want (e.g. Meta's CA has to contact actual people in the appropriate security team at Meta, so that "mistakes" which give somebody a certificate for facebook.com never happen without some pretty drastic real world errors).
So if you have a user named "haha_funny" you already aren't allowed to give them the hostname "haha_funny.somesite.example" - and on some system it will just silently not work because it's invalid.
Not long ago I actually did come across a site that had an underscore in its domain name, and it worked both for me and apparently Google, because it indexed and showed a (relevant) page from that site. I only remembered it was on a *.tripod.com subdomain, and can't find that exact site now since I don't remember what I was searching for (it was a highly obscure and technical topic), but there do appear to be others there with underscores, e.g.:
My browser is configured to auto-upgrade such links and I get a full screen interstitial when the upgrade fails (as of course it did for these)
This is now at a place where I'd recommend such configuration more broadly, it's not suitable for everybody, but many could benefit from just knowing all links are secured.
Please renew your Buypass ACME (Go SSL) certificates issued before December 22 12:00, 2023.
We have identified an issue within our systems so that these certificates do not comply with certificate issuance requirements. We have corrected the issue, but all still active Buypass ACME (Go SSL) certificates issued before December 22 12:00, 2023 must be revoked.
Renew your affected certificates and install them immediately to ensure that your services continue to be available.
If you need support for the renewal, please comment here on the ACME Community where our staff and Community members will be able to assist.
We apologize for any inconvenience this may cause.
WPA3-only is mandatory if you want to use 6GHz frequencies though. At least for the gear we use, that means if you want 6GHz you either must only have devices that support WPA3 or you have to use a separate SSID for 6GHz clients to use. Fallback to WPA2 isn’t permitted.
I appreciate the sentiment, but new devices being sold that still don’t support WPA3 means the adoption of 6GHz is going to be a very slow process.
> I appreciate the sentiment, but new devices being sold that still don’t support WPA3 means the adoption of 6GHz is going to be a very slow process.
No, it just means the adoption of WPA3 is going to happen at the same speed of 6 Ghz. The point is that every device that supports 6Ghz has to support WPA3.It's not like you could do 6Ghz on your Raspberry Pi but lack of WPA3 blocks you from it.
There’s a nuance that I didn’t explain well. WPA2 and 6GHz clients can’t exist together on the same SSID. According to the specification, if you enable 6GHz, the whole network becomes exclusively WPA3. If you enable WPA2, that SSID can’t speak 6GHz. Having new non-WPA3 devices being sold is going to really slow down the adoption of 6GHz, because they can’t coexist. You can’t band steer 6GHz clients to a preferred 6GHz compatible WPA3 only network, it’s up to the user to pick the right SSID.
This is a draconian reading of the standard which I think no reasonable person would agree with.
If this is about 12.12.2, then it refers exclusively to the 6GHz STA, and not "to the entire network", which on Wi-Fi is a very loosely defined concept (same BSS? same ESS? already the standard forces different channels to use different BSSIDs).
Nothing prevents the 6 GHz AP's SSID from "coincidentally" being the same as the 2.5/5GHz AP. In fact, this is exactly how a/n works now: even though initially it was common for 5GHz STAs to operate on a different SSID, no one bothers to check, and nowadays I can barely find a consumer/business AP that _by default_ still keeps separate SSIDs for both 2.5 and 5.
While I can find APs that today by default give different SSIDs to 2.5/5 and 6 (oh, the irony), I have not found any that would prevent me from setting the same SSID to all; and some APs I have already set the same SSID to 2.5/5/6 by default. These all have the Wi-Fi logo.
> You can’t band steer 6GHz clients to a preferred 6GHz compatible WPA3 only network, it’s up to the user to pick the right SSID.
You have never been able to truly band steer clients since this is at the client's discretion. Even if you give everything the same SSID, the client may choose to prefer the 2.4GHz band instead -- this is also one of the reasons it was common to give both of them a different SSID early on, so that users could force 5GHz.
When commercial routers "band steer" they simply prevent the client from associating to to the lower bands (by e.g. hackishly not responding to probes at that band), thereby leaving the client with only one choice: the band you want.
Dumb spec? There are fundamental limits in this world. Some things are simply mutually exclusive. A dump spec IMO would be a spec that does not acknowledge this.
A spec which uses a new frequency and still makes it impossible to co-exist with existing previous versions of the spec on other, different frequencies is fundamentally dumb.
It would be like if USB-C required any device with USB C to not support any other USB types or specs. Seriously, what the hell!
And no, there is no practical reason for them to be mutually exclusive.
The single-threaded nature of WPA2 AES-CCMP-128 is the reason (in addition to not wanting to embed known weak security protocols). The higher speeds and later standardization of Wi-Fi 6E (as compared to Wi-Fi 6) made this, in my opinion, a reasonable trade-off.
For Wi-Fi to survive, it must bring improvements in security protocols /and/ user experience (speed, coverage, and ease of setup). While I agree that security configuration should ideally not be tied to the physical characteristics of the link, security tends to lag, and the driver is user experience. So, if we want to have a high baseline of security, we have to tie it to the driver, the craving for a better user experience (higher speed and better spectrum utilization).
Good standards make trade-offs in the right places (both in time and space). Dumb standards miss the goal. I cannot say that this is a dumb standard when it is evident that trade-offs have to be made. Using WPA2 would have impacted cost of equipment, performance and security negatively.
So instead, it won’t roll out widely for a decade plus due to active incompatibility, therefore rendering its improvements pointless for all but a tiny number of early adopters?
As I said, dumb.
Next version will likely include degrees of backward compatibility or workarounds, would be my guess. Since you can’t even iteratively roll it out!
That or routers will have parallel radios and 2x SSIDs, which would confuse everyone and add even more to the costs.
That's the sort of thing that gets put into specs, is completely ignored by everybody except the handful of companies that pushed to get it into the spec in the first place, and eventually generates enough market pressure than even they start to ignore it.
I can understand a desire to kill WPA2 (and I can make some guesses about some maybe less noble motives)... but the WiFi standards can't effectively mandate things the market won't accept. Little trademarked "certified" logos and whatnot end up losing out to "it actually works". Generating pain in the process.
The problem is that if you enable 6GHz on an existing 2.4/5 GHz SSID, you immediately kick off all WPA2 devices. So you have to create a unique SSID for 6GHz devices to use, which is kinda confusing to end users.
HTTP requires that the length of the content be sent before the content, so that pipelined connections know where the data ends and the next headers start. If you're sending a file directly off disk you know the size before you've even looked at the data so there's no delay. If you're running everything through gzip, you have to wait to compress the entire file before you know the output length, so the critical "time to first byte" metric could get much worse. There are similar issues with dynamic content (CGI scripts, PHP, etc) where both the server and browser would end up buffering large amounts of content before compressing/decompressing them, which also affected perceptual speed. If the connection bandwidth was high enough, skipping all of this and just sending the uncompressed file would appear faster to the user, despite transferring more.
This was later improved with things like chunked encoding and caching the compressed output on the server side, but they came later and weren't always supported or desirable.
I kept telling it to debug the problem, and that I had confirmed that database file was not the problem. It kept trying to rm the file after it noticed the code would recreate it (although with no data, just an empty db). I thought we got past this debate until I wasn't paying enough attention and it added an "rm db.sqlite" line into the Makefile and ran it, since I gave it permission to run "make" and didn't even consider it would edit the Makefile to get around my instructions.