DB lookups + extra index are way more expensive then hardware assisted decoding.
If your UUIDv4 is cached, your still suffering from extra storage and index. Not a issue on a million row system but imagine a billion, 10 billion.
And what if its not cached. Great, now your hitting the disk.
Computers do not suffering from lacking CPU performance, especially when you can deploy CPU instruction sets. Hell, you do not even need encryption. How about making a simple bit shift where you include a simple lookup identifier. Black box sure, and not great if leaked but you have other things to worry about if your actual shift pattern is leaked. Use extra byte or two for iding the pattern.
Obfuscating your IDs is easy. No need for full encryption.
Hardware assisted is a red herring here. As you noted the real problem is that random reads have poor data locality, which degrades your database performance in a way that is expensive to resolve.
Why would it be computationally complex? The encryption is implemented in the silicon, it is close to free for all practical purposes. The lookup table would be wildly more expensive in almost all cases due to comparatively poor memory locality.
I think 'local' in this context could also simply mean 'wall', as in wall clock time. When my friend asks me the date and time, I don't have to bother with time zones.
This type of date/time is also very useful to store in a computer.
Having had decades of this in geophysical exploration, the time is now AND (where relevant) it's the current UTC Zulu time AND it's both local times.
Any data collected is logged against a UTC sync for start of recording (and continues with lapsed time AND logging raw GPS times .. which sorts out leap second issues).
Any discussion re: start of next data collection is relative to the local time at the field end, the planes et al are often bound by daylight - so field operation local dawn and sunset are relevant.
Any discussion re: software changes | hardware support is relevant to the local time at the home office end as that'll rest on when the office staff or aircraft mechanics come in or free up.
For ease of communication many such discussions are along the lines of "we'll ring back in four hours and ...". That's a NOW relative epoch.
Additionally I've always wanted institutions to be part of the timeline of technology. Corporations, Nation-states, Universities, Guilds, International Organizations - the ways people innovatively organize make things possible that otherwise wouldn't be.
The higgs boson experiments, for example wouldn't have been possible without the complex international institutions that orchestrated it. Manhattan project, Moon landing, the internet ... the iphone ...
This was originally in the HN submission title, but this comment from the maintainer is mind-boggling:
> GitHub has confirmed that the block.txt file in the repo has been responsible for over 1 petabyte of bandwidth per day — mainly due to automated downloads (likely from Adobe’s Chrome extension). This is way beyond what a single repo is designed to handle and poses a risk of the repository being temporarily disabled as early as June 13.
Adobe appears to be actually responsible for the DDoS.
> i think we might have finally tracked it to the GenAIWebpageBlocklist for Adobe Reader plugin on Chrome
> Adobe has acknowledged the issue and removed the URL reference from their Chrome extension. The updated version is already submitted to the Chrome Web Store and should roll out to users in the coming days
> GitHub has removed the content warning from the repository and will continue to monitor bandwidth usage
It's the AMD 7000 series that is available. Only the AI 300 can be pre-ordered if I understand correctly, and that's the one being referenced by the featured model on that page.
Point is, they need a link saying there is an option available, even if it's not the new new new (which is in pre order).
I just bought an AMD 13", and had the same "wtf, that's silly" thought about the site.
Also, Ubuntu 24.04? Lts works great. Suspend eats some battery, but can't be more than 1% an hour. If I suspend it overnight, it's not the end of the world.
I have it hooked to some Amazon USB4 dock, with wireless dongles for keyboard and mice, and 2 1080p displays. One horizonal, one vertical. Those work as expected, and all scaling between them works and makes sense. It did take a few moments to get it all to align up but once it did it's worked great.
New bios update mangled my battery charge limit behavior in weird ways. Prior to mid month update, it worked great! Sometimes now it works, sometimes it's at 100%. Since the battery can be replaced in no time, I've honestly not fret it much.
The speakers are not great but I found some customized eq settings for an app. (Easy .. something) That made them sound 80% better, immediately).
Battery life, I dunno. I'm one of those people who kills all their batteries by panicking at 56%. If light duty, 6 hours no problem, maybe 8?
I love it. A bit of coin but I'm hoping they stay around so when things break , they can be replaced.
Tired of forced updates and controlled subscribe behaviors. A laptop one can replace broken pieces themselves and an OS that thus far lets you use the damn computer.
I think it's a question of trust and responsibility, and the client should decide where to draw those lines. Depending on the environment and context, it could be totally acceptable to trust the filesystem, but not in other cases.
Yes. It is a "storm in a glass of water", as we say. Probably the client application doesn't assume cosmic bit-flipping events for its own files, which would have equally bad consequences, either. Probably the likeliness for this happening and not being caught and corrected by the storage medium is as low as a hash or UUID collision, which everyone conveniently round down as "impossible".
> We've received feedback from customers that several reboots (as many as 15 have been reported) may be required, but overall feedback is that reboots are an effective troubleshooting step at this stage.
Why would multiple reboots make sense? I can accept three reboots triggering some condition that tries three times before it stops trying, but fifteen?
It sounds like a race condition; you want the CrowdStrike updater to start and pull down the fix before the affected virus definition file is loaded and kills the box.
If you keep rebooting, you eventually may get those to load in the right order.
Anyway, had that confirmed by whoever is in charge of security and whatnot, as we have an internal StackOverflow clone and someone asking the same question was pointed to a PowerPoint presentation of dos and don'ts.
