kevinday

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?

https://bugzilla.mozilla.org/show_bug.cgi?id=1910322

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.

https://www.noaa.gov/heritage/stories/cryptogram-in-silk-dre...

This is a slightly better and more detailed version of this story.

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.

Buypass as

Yes, but you can’t use it if you enable 6ghz according to the 6E specification.

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.

More info here since this is surprising to many: https://www.extremenetworks.com/resources/blogs/wireless-sec...

https://allthetropes.org/wiki/Category:Banned_On_TV_Tropes

Bash really isn't a standard outside of most Linux distributions, you're going to find the same issue anywhere that isn't Linux.

OpenBSD uses pdksh, Busybox/NetBSD/Minix use ash, there are some linux distros that use zsh, OpenSolaris is ksh, etc.

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.

This was from 6 months ago. Not that it's right that happened in the first place, but they apologized and fixed it.

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.

If this source is to be believed, it's either going to Google or Tencent, but never both:

https://twitter.com/eromang/status/1183422784082530304/photo...

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.

https://testsafebrowsing.appspot.com

I just tried it, and it says Google for me in the US.

It's working now - nothing changed as far as I know on my end, but if it happens again I'll do that.

I'm getting the same on Chrome/Mac. Requesting /mock/ just 301's me back to /mock/

https://pastebin.com/vmgSU6nj

That may be true for some UNIXes, but not for all UNIXes. For example on FreeBSD, create a process that will stick around for a bit:

  # cat >sleepy.c
  #include <unistd.h>
  int main(void) {
    sleep(999);
    return 0;
  }
  # cc -o sleepy sleepy.c
  # ./sleepy &

  # cp /bin/date sleepy
  cp: sleepy: Text file busy

  # install /bin/date sleepy
  # ./sleepy

  # touch a
  # stat -f %i a
  686974
  # cp /etc/motd a
  # stat -f %i a
  686974

  # stat -f %i a
  686974
  # install /etc/motd a
  # stat -f %i a
  687076

  46785 install  CALL  unlink(0x7fffffffed52)
  46785 install  NAMI  "a"
  46785 install  RET   unlink 0

  46785 install  CALL  openat(AT_FDCWD,0x7fffffffed52,0x602<O_RDWR|O_CREAT|O_TRUNC>,0600<S_IRUSR|S_IWUSR>)
  46785 install  NAMI  "a"
  46785 install  RET   openat 4

Previously: https://news.ycombinator.com/item?id=16412541

It sounds like they distributed a tool that goes through your Chrome saved passwords database and if the installer thinks you're a pirate, it sends credentials from that database back to the author. The author is now saying they used credentials they learned from this to break into a private website to learn more about how their DRM was being bypassed.

This seems so incredibly illegal, I can't believe they admitted that this is what they're doing.

Facebook has a nearly unused feature where if you send it a text message, it posts it for you. When mobile phones that didn't have a web browser/facebook app were more common, this was how you did mobile status updates.

https://www.facebook.com/help/125384024209252?helpref=faq_co...

Forum post with a little more information: https://forum.transmissionbt.com/viewtopic.php?f=4&t=17834

There are 6 bugs that were announced.

#1 Weak default key in config_auth()

If you're only doing local timekeeping, and not using authentication (you'd know if you were) this doesn't apply. Basically the automatically generated key used for authentication (if you didn't specify one) was only 31 bits long and easily guessable.

#2 non-cryptographic random number generator with weak seed used by ntp-keygen to generate symmetric keys

Same as the above. If you're not using keyed sessions with remote hosts, this doesn't apply to you. Even if you are, the worst you're losing here is that someone could potentially mess with your clock.

#3 Buffer overflow in crypto_recv()

If you are using crypto (i.e. your ntp.conf file contains a line starting with "crypto pw"), you are potentially remotely exploitable to remote code execution. You probably do not have that configuration line set unless you know you put it there.

#4 Buffer overflow in ctl_putdata()

From the sound of the post on ntp.org, this is the scary one. "A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process." This makes it sound like everyone is exploitable. However, Redhat says "the ctl_putdata() flaw, by default, can only be exploited via local attackers". This makes me believe if you have your ntp.conf locked down using the 'restrict' lines you might not be vulnerable.

#5 Buffer overflow in configure()

This is the same as #4, ntp.org's advisory is vague enough that it sounds like everyone is vulnerable. Redhat is saying "the configure() flaw requires additional authentication to exploit." I do not know what this means.

#6 receive(): missing return on error

From their description, it's technically possible (but they haven't done it) to get ntpd into a weird state that is unlikely to be exploitable.

TL;DR: You're possibly vulnerable to #4 and #5 on a stock configuration. Redhat says no, ntp.org's advisory is vague enough that I'm not sure.

You can see it sort-of in use at the start of this AT&T commercial:

https://www.youtube.com/watch?v=IEp6ca9Ppks

The lack of unlocking really surprised me. We bought one for testing that some of our mobile software would run on it, so we got the no-contract version. Even if you pay full retail price, it's still locked to AT&T. That's just blatant foot-shooting. If someone's going to pay you full price, it shouldn't be locked.

(And yes we tried getting Amazon to give us the unlock code. They said their contract with AT&T didn't allow it.)

Hard drives store things with varying forms of ECC. Each sector has an ECC field, allowing it to detect many errors and automatically correct some.

This isn't a replacement for something better, it just allows simple bit errors to be corrected automatically by the drive. The problem is that it's not really obvious when it's happening, and you only notice when it can't fix something. Drives eventually throw a SMART error when it's had to do too many corrections though.

If you're looking at this and not seeing any difference between the "before" and "after" versions, it's because HTTPS Everywhere is redirecting all github urls to their SSL version, so http://jessepollak.github.io/card/ redirects to https://jessepollak.github.io/card/ then can't load any of it's javascript dependencies due to the http/https mismatch.

Bonus points for the form still working right through all of that.

I've had really good experiences with Amadi Systems as a Supermicro reseller. http://amadisystems.com/

I've stopped buying Dell/HP entirely now, because the price of Supermicro's stuff is so much better and you don't get into warranty arguments like you do with HP about running non-approved OSes.