SQLite benchmarks are deeply flawed. Somebody has proven that it can sustain 4M queries per second on bare metal, 1.5M qps on a cloud VM, and it happened over 7 years ago. Therefore I do not believe any number from SurrealDB.
The repo is open source, so why not raise a PR to https://github.com/surrealdb/crud-bench and point out any misconfigurations you find? It's good that they've made it open source, so can easily point out if there are any misconfiguration.
The name is so misleading... The first thing I see when hearing "sequence" is the "arithmetic sequence", like 1,2,3,4. Therefore "restartable sequence" is like 1,2,3,4, 1,2,3,4, 1,2,3,4... Closer to SQL's "CREATE SEQUENCE" than "restartable sequence of assembly instructions". I could not comprehend how this can help with lock free data exchange. I've done my homework now.
says it all. It's a really bad joke or an excellent trolling.
The entire world have used:
%Y for the year.
%m for the month.
%d for the day.
%H for the hour.
%M for the minute.
%S for the second.
for over 50 years, but Golang forces me to remember "06" for a year, "15" for an hour and "05" for second. and "MST", the Mountain View time, that particular time zone moniker, in a center of the universe, as a placeholder for a real time zone. Yes, the Mountain View, not UTC ("Z"ulu time) like a sane person would do (although nobody sane would implement that format).
I am heavily reliant on the Office suite, and aware of many business that also are. I tried to switch to LibreOffice numerous times, with no success. For example, a simple thing - the CSV import wizard is so inefficient and buggy in LibreOffice that I spent literally hours to make it work. I then proposed concrete improvements for the LibreOffice team, but they got downplayed and dismissed. "Everything's normal, just got used to it". The productivity with LibreOffice is ruined at the very moment you have to do anything but typing a text or spreadsheet cell content. Paying the MS subscription returns in a few hours saved by it compared to LibreOffice and clones.
Americans love wars. They must fight wars either literally or figuratively. How are you not seeing this? When I'm sipping my coffee looking at mountains and contemplating chirping birds, they must fight, make billions and destroy the planet along the way.
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
> Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
Oversimplified and not accurate. Some manufacturers had flawed implementations, others did not. Also, that was a long time ago. There are advantages to hardware encryption. It preserves performance and mitigates other vectors like cold-boot attacks without having to encrypt RAM, which also comes with a performance penalty. By the way, both software and hardware-based encryption can be combined. Cryptsetup on Linux actually offers this, and before you ask, the keys are split. If one is compromised, the other remains secure.
I don’t think manufacturers with deliberately undocumented, nigh-impossible-to-inspect crypto get to claim their bugs are shallow and thus that the absence of evidence for bugs implies the absence of bugs.
Less emotionally but mostly equivalently, the expense and non-cryptographic skill requirements of breaking mass-storage crypto are quite high while the rewards are comparable to those from breaking much softer targets, so the absence of results since that one paper only changes my mind very slightly. Besides, we know plenty of examples of what these kinds of opaque, serious-business, pay-to-play environments produce: cellular crypto is an uninterrupted series of disasters, so is Wi-Fi, and the things that we do know about storage devices don’t point to an outstanding culture of cryptographic competence there either. Once you’ve done enough to slap an “OPAL” label on it (which says nothing about the internals), there’s just no competitive pressure to improve.
There is a right way to do all this, and it’s essentially what NICs do: allow the host to offload symmetric crypto to the device, but keep the results of said crypto accessible at any moment. And it’s not like there are even that many modes used in full-disk encryption, let alone ciphers.
It’s a way of saying that I consider the demand for post-2020 evidence to be cherry picking when there’s evidence from 2018 and little objective (cultural or economic) reason for things to have improved since then. A competent modern businessman will not pay for a competent worker in a very specific narrow field until there are consequences to not doing so (creating such consequences is the purpose of every compliance regime, for instance).
It’s also a way of saying that the entire approach taken by hardware disk encryption (unspecified crypto done inside the device in an unverifiable manner) has, with the benefit of hindsight, proven fundamentally flawed despite its reasonable appearance (in every system which had used it, not just storage), and I wish there was a way to pressure (consumer) storage vendors into going in a different direction. It is simply never a wise choice to trust people’s opaque crypto, however competent they are.
we're not talking about the hdd/ssd here, those are not really encryption but data packing and compression algorithms, they added encryption because it's a single instruction for extra talking points.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
None of OVH, GCP, AWS, Azure wanted so much data about me, and I run my services in all of them successfully. Not in Hetzner.
Sorry Hetzner, you're too data-hungry. Nothing you say justifies that.
reply