I think people started doing that after one of the Intel SSE examples did it and everyone just copied it.
But on any modern CPU there should be essentially no penalty for doing that now. Testing the full register is basically free as long as you aren't doing a partial write followed by a full read (write AH then read AX), and I don't think there's any case where this could stall on anything newer than a Core 2 era processor. But just replacing that with a "jnc" or whatever you're exactly trying to test for would be less instructions at least. I'd love to see benchmarks though if someone has dug deeper into this than I have.
I tried GLM-4.7 running locally on a beefy GPU server, in about 3 minutes it got to 25846 cycles, but then struggled in circles for about 90 minutes without making any meaningful progress, making the same mistakes repeatedly and misdiagnosing the cause most of the time. It seems to understand what needs to happen to reach the goal, but keeps failing on the implementation side. It seemed to understand that to beat the target an entirely new approach would be required (it kept leaning towards a wavefront design), but wasn't seeing the solution due to the very limited ISA.
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.
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.
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.
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.
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.
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.
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.
Just a suggestion: "If you are familiar with Core Data or Realm, Dflat occupies the same space as these two". I'm not familiar with either of these, even a brief description of what this is would be super helpful.
You can try yourself by going to one of the IOS Safe Browsing test pages on your phone, and when the warning pops up click "Show Details". It'll either say Google or Tencent on the warning message, which should let you know which one got chosen for you.
But on any modern CPU there should be essentially no penalty for doing that now. Testing the full register is basically free as long as you aren't doing a partial write followed by a full read (write AH then read AX), and I don't think there's any case where this could stall on anything newer than a Core 2 era processor. But just replacing that with a "jnc" or whatever you're exactly trying to test for would be less instructions at least. I'd love to see benchmarks though if someone has dug deeper into this than I have.