How well do we understand the tokenization for Claude? I'd posit that the exact human-representation of this markup is likely irrelevant if it's all being converted into a single token.
Code length will itself become a problem. The instruction cache is limited in size and often quite small. Bloating instruction counts with lots of duplicated code will eventually have a negative effect on performance.
Ultimately, there's too many factors to predetermine which approach is faster. Write clean code, and let a profiler guide optimizations when needed.
Exactly. Memory access is a major factor in runtime, often more important than instruction counts. And in the vast, vast majority of cases it doesn't matter. I trust the compiler to make reasonable choices, something would have to be deployed at a very large scale before the programmer time of considering such things became cheaper than the hardware savings from doing it. And the vast majority of code simply doesn't execute often enough to matter one way or the other.
Save your brainpower for the right algorithms and for the inner loops the profiler identifies (I did not expect to learn that the slowest piece of code was referring to SQL fields by name!) Ignore the rest.
Additionally, so long as we can be sure the human's output is not actively adversarial, we can xor it into the entropy pool. Entropy can only increase this way.
I'm reminded of a diagram from the pitch doc for the original Diablo [0] that made its rounds across the web recently. The dungeon/town split was particularly sharp back then, but the broad design has stuck with modern ARPG design, either in the form of safe zones around town or explicit town zones.
A lot of this seems to be due to modern multiplayer design, with shared town instances and (usually) private dungeon/outside instances.
It might have been filled with mineral oil, those external enclosures often setup that way so that the enclosure is less extreme to manufacture. Not sure if that would work for camera lenses though unless those were also filled.
As someone who was on the product team for a 6000msw video camera, it's probably not filled with mineral oil. I doubt anyone makes subsea camera bodies/optics completely from scratch, and off-the-shelf units are not designed for pressure. In ours we used Sony camera internals, the enclosure was atmospheric, filled with dry nitrogen to reduce condensation, and the sapphire lens was designed to resist 12500psi and reduce distortion from the air-->sapphire-->seawater interface.
Hmm ok that would have explained why the SD card wasn't damaged if it were because when the vessel is filled with mineral oil it wouldn't have imploded like the main body of the craft.
Here; the title focusing on the price is implying that the cheap SD card survived ocean floor environment alone. A surprising amount of stress for its price.
Instead, a pressure-proof deep sea camera module was found at the wreckage site. It’s less interesting that an expensive thing rated for ocean depths was intact at ocean depths.
Its like “missing child found after 4 days in Alaska temperatures!”
gasp! How did they survive!
“The child was on holiday in their grandparents’ holiday log cabin, with their grandparents, a log fire, food, water..”
Oh. Clickbait. Hiding the boring bit to make the story appear more of a tease.
I noticed a pattern a few months ago in my phone's newsbait feed of headlines in the format "[Large familiar company] to close 500 stores on [date]" — and then below the fold "because it's [Independence Day, Rosh Hashanah, etc]" or "because they are moving to summer hours" or whatever.
> Here; the title focusing on the price is implying that the cheap SD card survived ocean floor environment alone. A surprising amount of stress for its price.
I certainly did not read that implication into the title, so it's entirely possible that the author didn't mean it.
The manufacturer didn’t even know encryption was enabled, because as long as the camera was working, it would just provide all files over USB without any encryption.
It was basically enabled by accident, and the only thing it prevented was recovery of files directly from the SD card when the camera was damaged.
I think it depends. Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents. Of course that means metadata may be in plain text or may be separately encrypted - again possibly folder by folder instead of all metadata at once. Exact details would vary with different file system encryption schemes.
Whereas if you image the disk and encrypt the image properly, that gives you all the great confidentially guarantees but no random access.
> Encrypted filesystems typically encrypt contents of each file separately - that way you don't need to read / write the whole disk to read it write any individual file contents.
Ah, that's not true of "full disk encryption". It usually encrypts the disk blocks.
File-based encryption is stronger; you can use different protection classes on different files, you can use authenticated encryption, etc. iOS does it this way and I assume other systems have caught up, but don't know any in particular.
Most FDE systems are not authenticated so you would only lose one block (16 bytes for AES). Can this be bad? Yeah, but it's not that bad for data recovery.
Most unauthenticated encryption modes only mess up a few bits of a block, sometimes the following block too. A few only flip the exact bit in the plaintext.
Citation needed. It might be slightly easier, but most cases where you can get part of the camera, you can get the whole camera. This isn't a little point-and-click with a handy spring-loaded slot either.
Yeah but the Camera's owner is much more likely to notice "my camera is missing" than "the SD card is blank for some reason... the SD card must have failed"
EDIT: The linked PDF has a photo, the camera literally opens up to access the SD card.
The camera's (former) owner may very well notice, but that will have little effect. It's much more common that cameras (security, photography, phones) get stolen with cards inside, rather than someone extracting the card and leaving the camera.
Worth mentioning that I would immediately know if a different SD card was in my camera the moment I turned it on or ejected the card. If somebody knew to buy the same exact model and storage size that would be truly impressive.
Industrial espionage is far far more often done by hard work then being clever. Checking the SD cards you use and buying matching ones before executing a swap isn't noteworthy.
If you look through my case of SD cards I have all sorts of sizes and makes/models. I also have a procedure for dumping and formatting, and someone who is handling this most likely would as well. The moment the storage on screen looks funny or I see the card I don’t recognize, I’ll notice.
I’m not saying it’s impossible or I’m somehow immune to being tricked, but you would be surprised how easy it is to leave evidence of tampering through the simple act of trying to take an SD card, whether you swap it out or not. And people like me who handle them regularly would likely notice it in a split second. Maybe we won’t even catch the perpetrator, but it would not be written off as “oh interesting I guess it didn’t record,” if for no other reason then I would go straight into CYA mode and start looking for any hint that I didn’t make a mistake.
At that point if you have a basic security SoP in place and adhere to it you can start auditing.
Anywho again nothing is airtight and a determined individual could of course get past me. But you would be surprised how many hurdles they have to get over, and it certainly wouldn’t go unnoticed and be brushed off as a read/write quirk, that’s really all I’m saying
If you read the article, the SD card was placed there by the camera manufacturer and then the device was sealed so it would withstand pressure, and then sold to divers. Blame the camera manufacturer's engineers.
Seems like the SD card of all things performed just fine, so it hardly seems like the weak point.
They are surprisingly resilient! There was a blog post a couple of years ago by someone who found a digital camera in the sea which must have been in the water for months. The author could look at the photos to see if they can find the original owner of the camera.
> Getting on the public suffix list is easier said than done [1].
Can you elaborate on this? I didn't see anything in either link that would indicate unreasonable challenges. The PSL naturally has a a series of validation requirements, but I haven't heard of any undue shenanigans.
Is it great that such vital infrastructure is held together by a ragtag band of unpaid volunteers? No; but that's hardly unique in this space.
My 2c is that it is worthwhile to train on AI generated content that has obtained some level of human approval or interest, as a form of extended RLHF loop.
Ok, but how do you denote that approval? What if you partially approve of that content? ("Overall this is correct, but this little nugget is hallucinated.")
It apparently doesn't matter unless you somehow consider the entire Internet to be correct. They didn't only feed LLMs correct info. It all just got shoveled in and here we are.
It reminds me of the early days of Typescript rollout, which similarly focused on a smooth on-boarding path for existing large projects.
More restrictive requirements (ie `noImplicitAny`) could be turned on one at a time before eventually flipping the `strict` switch to opt in to all the checks.
The way the question was framed, it was ambiguous whether "draw again" only applied to B, or whether A would draw again as well. I'm assuming the 'infinity' answer applies only to the former case?
> IEEE754 is not great for pure maths, however, it is fine for real life.
Partially. It can be fine for pretty much any real-life use case. But many naive implementations of formulae involve some gnarly intermediates despite having fairly mundane inputs and outputs.
