Veserv

You are agreeing with them.

They called it 'int' instead of 'int32_t' because it was meant to be the natural word size. It was supposed to float as the natural word size increased and allow code that worked on one word size to transparently work on the new word size.

Not floating to 64-bits on amd64 means their rationale for not giving it a fixed size was wrong. That is a simple width-doubling to another power of 2, the easiest possible case to expect to work transparently, on a compatible instruction set and they still chose to not float the size.

You can not just transparently change the word size and expect it to work, so you should just fix the size or use a fixed size. The notion of only having floating sizes as primitives was a mistake.

I do not understand why people continue parroting this performance nonsense.

Memory copying is on the order of 100 gigabytes per second. You can do 80 full payload copys and still out-pace a dog-slow 10 gigabit per second connection. If your bottleneck is memory copying you are either doing something very wrong and doing way too many copys or congratulations you have implemented one of the fastest network stacks.

Supervisor calls are also very fast, on the order of 100 ns up to maybe 1 us with all the Spectre mitigations. Even if you did something as stupid as one supervisor call per packet, you would still be getting on the order of 10 Gbps at the long end there and 100 Gbps at the short end. Which, again, means congratulations are in order because you have implemented one of the fastest network stacks. If you do batching and add just 10 us (us, not ms) of latency then that entire cost is so small as to be irrelevant. You are going to bottleneck on your memory copying first.

Network stacks are so slow almost entirely due to poor protocol design and poor protocol implementation. Usually both.

Oh indeed, if we just redefine words in the fine print then we can commit fraud with impunity.

Please enlighten me how that blurb supports the common reading of the claim: Your data, … secure. Note that and is a additive conjunction, so the components can be safely examined separately.

A regular person would assume that means your data is secure against tampering and disclosure. If you then say: “lol, jk we do not do anything related to securing your data” in the fine print then in a reasonable society you should be required to remove that more prominent false large print.

You can always go back and reword your large print to be more accurate without making deceptive claims to your benefit. Weird how the deception is always beneficial.

Oh, so when they advertise “Your Data, Forever and Secure”[1] in big bold letters on their homepage with total disregard for the truth of that statement they are just committing fraud. Got it.

[1] https://radicle.dev/

Oh, Microsoft can just figure out how to make unhackable systems, they just choose not to. They spend all of those billions of dollars per year on security and spent all of those decades on failed attempts as a prank.

You really think that if they could have they would not have, even just for bragging rights? Or are we going with that it is some kind of task demanding enormous expenditure even though the organizations that have made secure systems are infinitesimally small in comparison?

Microsoft has spent orders of magnitude more money and time than the organizations that have succeeded and the result of their efforts is Windows. That says everything you need to know about their capabilitys.

Multiple literal trillion dollars organizations have spent literal decades failing at it. You are really underselling the capability gap.

> The problem isn’t that we lack the capability to make secure computers.

Depends on the "we". "We" have the capability to make secure computers like how "we" have the capability to make EUV lithography machines. There exists a relatively small number of people and organizations in the world who can do so. Microsoft does not have that capability. Google does not have that capability. Linux does not have that capability. Amazon does not have that capability. Apple does not have that capability. Cisco does not have that capability. IBM does not have that capability. etc. All of those organizations have tried for literal decades, thumped their chests about how they have awesome security year after year, and yet have totally and utterly failed despite their best efforts.

Acquiring the capability to do so is difficult and challenging and requires years to invent if you start right this very second and know what you need to do, which these organizations emphatically do not. We need security at scale and fast. The only way forward is to scale up working solutions rather than letting the bozos who put us in this spot fail at scale with yet another promise that this time for sure they will solve the problem they have repeatedly failed at for decades.

Ah yes, the parable of the bear. There are a million people stuck in a valley and two bears. You do not need to outrun the bears, you just need to outrun at least two other people. But it turns out one of those bears is male and the other is female. So next year there are more bears, but you still just need to outrun a few people. Then one day, there are 1 million bears and they eat you all. Very inspiring story.

Software security has just been a fun time of ignoring the exponentially growing number of bears for the last few decades so you can continue to use systems unfit for the threat landscape because they are cheap.

Almost all marketing is actively detrimental to the world. Marketing that is intentionally truthful and intentionally avoids over-promising is actually of value to the world. Marketing where in a court of law they would not go: "Technically your honor..." and backpedal on everything they say using tortured interpretations that would make a genie blush.

The problem is that a vanishingly small amount of marketing is that way, and when done is mostly the purview of good hard-working individuals with no "marketing" experience. Almost all marketing is intentionally deceptive and fraudulent where the entire goal is to say something that only a genie would agree is technically correct, while intentionally focus grouping until every single member of the focus group believes you said something other than what your lawyers would say. That is pure, intentional, pre-meditated deception and fraud. That should be advertising fraud.

"Technically your honor" should be a instant loss in the courts. The more time you spend crafting your message, the more accurate it should be required to be. If your focus group does not think you said what your lawyers are going to say, "Go directly to jail. Do not pass Go." If your target demographic does not overwhelmingly think you said what your lawyers are going to say, that had better be a case where all the money you spent on crafting the message and the proportionally expensive preventative measures failed.

Allowing deception and fraud is the harm that suppresses good, hard-working, honest individuals and companys and replaces them with liars and cheats making the whole world poorer.

The label has not lost its meaning. Everybody knows what it means and wants it, just almost everybody “selling it” is claiming it without regard for the truth of their claim for their own financial gain. In polite society that is called lying and fraud.

Really, your lawyer asks you what year you graduated for a legal filing and you would give the wrong year? Not even bother to go check, just fly by the seat of your pants?

> Musk has a bachelor's degree in physics from the University of Pennsylvania.

Clarification, Musk bought a B.A. in physics. In the Paypal S-1 in 2002, [1] Paypal's lawyers claimed that he graduated with a B.S. in Physics and B.S. in Economics in 1995.

Yet the actual degrees subpoenaed from UPenn indicate a B.A. in Physics and B.S. in Economics in 1997, two years later. He could not even remember the year he graduated or the degree he received just 5/7 years after their purported completion. I have yet to meet a single person who actually graduated from college who can not accurately recollect the year of their graduation, have you?

Most likely he did this because he was in the USA on a student visa and dropping out of UPenn in 1995 made him a illegal immigrant which his brother, Kimbal Musk, corroborated in a interview [2].

[1] https://www.sec.gov/Archives/edgar/data/1103415/000091205702...

[2] https://www.reddit.com/r/EnoughMuskSpam/comments/1az29vs/elo...

That is because you do not need to clear the field at the end of a critical section. It contains the contiguous instruction range where it fires so there is no problem with leaving it active forever unless you have another critical section where you want to use it.

No explicit memory barrier is required anywhere as the value is only read in supervisor mode and a privilege switch implicitly issues a LS-LS barrier on all major architectures. Even if you did not want to rely on that, you would only need a single S-LS barrier when you store the control structure the very first time.

Yep. Here is another comment of mine where I breakdown one of the most famous examples:

https://news.ycombinator.com/item?id=46176059

And another comment where I discuss another example and their legally binding declaration to not sue over accidental contamination:

https://news.ycombinator.com/item?id=45725426

That just sounds like bad tracing implementations. A good tracing implementation should be able to drive gigabytes per second of trace logs to memory. If you are generating it slow enough to allow actual offload then you should be in the 1—10% range even if you are saturating your offload.

You should, of course, upper bound this overhead by switching to a full time travel debugging solution, thus tracing everything, when you get to the 10-30% range.

The only way you get to “majority” is if your trace implementation is slower than time travel debugging and provides less information, but then why choose something worse in every dimension.

Since lawyers just love engaging in language lawyering when things get to court and always use to most uncharitable interpretation of words, we have no choice but to interpret their words in the most uncharitable and technically correct fashion. In that context, let us examine their lawyer-drafted statement.

> LG smart TVs do not continuously record or transmit users’ conversations.

"or" is ambiguous in the English language. A lawyer can rightly argue that they mean exclusive or and thus they are being technically truthful as long as they both continuously record and transmit users' conversations. They can resolve this ambiguity by stating each element as a independent sentence.

"continuously" means without end. A lawyer can rightly argue that as long as the recording can end in a single instance, then they are being technically truthful.

> Speech-to-text processing begins only if a user activates a voice interaction through a supported wake-word feature or by pressing the voice (or AI) button on the remote control.

"processing begins" makes no indication as to when it ends. A lawyer can rightly argue that as long as you use a wake-word a single time or press the voice button on the remote control a single time, they can begin processing and never stop. They can resolve this ambiguity by stating that they only process audio during a session and that session has a strict maximum duration.

Also, it makes no statement as to audio processing, only speech-to-text processing. A lawyer can rightly argue that as long as they do not convert the speech to text and just directly transmit the audio they are being truthful. They can resolve this ambiguity by removing the narrowly defined "speech-to-text" and changing it to "audio". Weird their lawyers made this so specific.

> Audio used for wake-word detection is processed locally on the TV and, if no wake word is detected, audio is not converted to text, stored, or transmitted.

Narrowly defined to be only "Audio used for wake-word detection". A lawyer can rightly argue that if they make a second copy of the audio that does not go to wake-word detection, then they can convert it to text, store, and transmit it. They can resolve this ambiguity by removing the narrowly defined "Audio used for wake-word detection" to just state that they do not convert to text, store, or transmit any audio outside of a session. Weird their lawyers made this so specific.

> Voice-recognition results and related technical logs may be generated as part of processing a voice command. These records are associated with specific voice interactions and do not indicate continuous recording of conversations occurring outside an active voice recognition session.

"These records ... do not indicate continuous recording" is not a denial that they are continuously recording. It merely states that it does not indicate continuous recording. A lawyer can rightly argue that as long as they have at least one record that is not associated with a continuous recording, then they are being truthful. No need to remove ambiguity here as it would be covered by the above fixes.

> Speech-recognition results may be used to support voice-related features but are not uploaded later when the TV is offline or when connectivity is restored.

"but are not uploaded later when the TV is offline or when connectivity is restored". Again, "or". Only mentions later, no statement about "now". Their lawyers can rightly argue that as long as they upload them immediately they are being truthful.

"uploaded later when the TV is offline" is illogical nonsense, how is it uploading when it is offline? Their lawyers can rightly argue that as long as they upload later when the TV is online and the TV never lost connectivity, then they are being truthful.

They can remove the ambiguity by stating that they never upload the speech-recognition results or only retain them until the voice-related feature has completed the task. Weird how their lawyers made this so specific.

> ACR uses audio fingerprinting technology using the TV’s internal audio processor (not a speaker) to identify content and does not collect screenshots, screen recordings, video recordings, voice recordings, or other audio recordings from the TV.

Again, "or". "uses" does not mean exclusively uses. "collect" only means ACR does not collect it. This does not indicate that screenshots, screen recordings, video recordings, voice recordings, or other audio recordings are not collected by other processes. It does not indicate that they do not use the resources collected by those other processes. They can remove the ambiguity by stating that ACR does not "use" these data sources and exclusively uses audio fingerprinting technology. Weird how their lawyers made this so specific.

Truly so odd how their lawyers make such precise, minute, and nuanced distinctions for their benefit, but leave everything else so ambiguous they can rightfully argue a tortured interpretation is technically truthful. If they were lawyers on behalf of the consumers, they would never accept such ambiguous language. Must be accidental.

This is why you should not use low-resolution summarys as exhaustive and authoritative.

"Bullshit jobs are jobs which even the person doing the job can’t really justify the existence of, but they have to pretend that there’s some reason for it to exist. That’s the bullshit element."[1]

He talks about it a lot and the book is 368 pages. Of course you will get some variations on the general theme with some embellishments to get it to hit home. But the key aspect, which he mentions repeatedly, is the part about "even the person doing it thinks it is worthless".

[1] https://www.vox.com/2018/5/8/17308744/bullshit-jobs-book-dav...

I do not see how you are disagreeing with his definition. What do you think his definition is?

You seem to be using the definition: “A job that people think is worthless”.

The actual definition he uses is: “A job where the person doing it thinks it is worthless”.

The commonly cited fatality statistics do not discuss fault, so, absent more precise information, a apples to apples comparison should not conditionalize on fault.

Why? Well let us try to imagine a world where Waymo has the statistically average fatal crash rate, yet is never at fault. In this world, every fatal crash occurs at the Waymos. You just have a bunch of crazy drivers roving the streets causing fatal crashes against (or involving) unsuspecting, not-at-fault victim Waymos.

If that is the world, then are these crazy drivers only crashing into Waymos? Probably not, these crazy drivers would almost certainly be crashing into a statistically average distribution of unsuspecting, not-at-fault victims.

So this imagined world is consistent with the overwhelming majority of human drivers engaging in 0 fatal accidents at fault with a small, crazy roving subset being at fault for all fatal accidents. So, in that world, a Waymo that is only ask good as the statically average driver would actually be infinitely worse than the overwhelming majority of human drivers. If you only replaced the 10th percentile driver (90% of drivers are better), you would actually be increasing the fatality rate. Only by displacing that crazy subset would you actually be decreasing the fatality rate.

Are we in that world? The Waymo numbers on fatal accident involvement with no fault actually kind of point in that direction (though the mileage numbers are still too low to make a strong conclusion). Seemingly massive crash and injury reduction due to massive reduction of at-fault crashes, but the fatality reduction does not seem proportional. Another possibility is that the Waymo driving distribution is biased toward being in situation that result in more no-fault fatal crashes.

But, that is all just conjecture and thought experiments. Unless we have better data, we unfortunately should be restricting ourselves to apples to apples comparisons which, in this case, do not conditionalize on fault.

Though, to nitpick on the original post, I think that the 2 fatal crashes in 170 million miles (~85 million miles per fatal crash which is similar to the USA human average of ~83 million miles per fatality), is probably not the correct analysis. The average fatal crash is probably 2 vehicles and 1 fatality. So, the 85 million miles per fatal crash versus 83 million miles per fatality is probably fine in the crash vs fatality direction. But I am pretty certain you would actually need to double the 170 million to account for the "statistically average mileage of the other cars".

Otherwise, if we have exactly two cars in the world each with 100 million miles and they engage in one fatal crash with one fatality, then we would conclude that car 1 has 1 fatality per 100 million miles and car 2 also has 1 fatality per 100 million miles. Naively averaging them, we could conclude that the overall fatality rate is 1 per 100 million miles. Therefore, over the 200 million miles the two of them drove, there were 2 fatalitys. Obviously incorrect, so we almost certainly need to weight them by their relative proportion when aggregating them.

You are correct, I missed the adjective on my second use. As my points were exclusively about fatal crashes and I never mentioned the injury or crash rate at any point and previously used 5,500 years exclusively in relation to fatal crashes, it should be obvious that I intended to mean that and my point still stands with that correction.

Sir this is a Wendy's, I mean a discussion about autonomous vehicles. The benchmark for the autonomous vehicles in the USA is in comparison to humans in the USA. That means autonomous vehicles need to go ~5,500 person-years worth of driving between crashes to equal the mean driver. The mean US driver is a very high bar to reach for technology, that is why Waymo has just maybe barely reached that bar after nearly two decades and billions of dollars.

The fatality rate is 1.19 per 100 million vehicle miles [1], ~83 million miles per fatality. The mean driver averages ~15,000 miles per year. So, the mean driver encounters a fatal crash after ~5,500 years of driving. If you started driving when the Great Pyramid was built, you would still have another 1,000 years before you would expect to die in a fatal crash.

The mean driver in the context of the USA driving environment is shockingly safe. Being safer than even the mean human driver in the USA is hard and takes a shocking amount of data to verify. Anybody downplaying it as "lol humans are so unsafe" to argue the problem feels easy to solve or can be solved by the end of the year with a little bit of elbow grease is utterly clueless.

[1] https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...

A public, well documented safety defect for multiple years with clear, incontrovertible evidence:

https://bsky.app/profile/realdanodowd.bsky.social/post/3lz6h...

https://www.jalopnik.com/1983251/tesla-train-tracks-investig...

https://www.jalopnik.com/1971193/tesla-full-self-driving-mig...

https://www.nbcnews.com/tech/elon-musk/tesla-full-self-drivi...

They still have not been able to solve the challenging problem of stopping when there are bright, flashing red lights and loud horns after over a decade of furious work and years of public reports.

But Tesla Robotaxi will totally be ready to serve half the US population by 8 months in the past. Railroad crossings are just the hardest nut to crack unlike simpler problems like full autonomy.

Just like learning calculus. The hardest problem is learning how to add. Once you get that it is just a few months to calculus.

Only if you think penetrating holes in a paper vest and then patching those holes constitutes “improving”. If that worked Windows and Linux would be impenetrable fortresses with all the holes that keep getting punched in them.

Cyberdemolitions expertise is about as relevant to cybersecurity as gun making is to bulletproof vest making. Necessary for validation, but not very related to the fundamental engineering and technology.

That makes as much sense as saying that better gun technology results in body armor that can stop it. It might incentivize that, but in no way "results" in that; the fundamental technologys underpinning advancements in offense versus defense are fairly different.

What is the "same one"? Define item in "I" formally.

Are we talking about Values? Then inigyou is correct.

Memory locations? Then it is trivially true, but that does not prevent me from writing 0 into every memory location.

Value + Memory location? Then it does not work for arrays since we are modifying the memory locations by moving the values between them.

The abstract notion of manipulable things in a indexable order? You need to show how that correlates to reality in a way where you can not put in a hole even larger than this one you are trying to close.

To loop back, this very discussion shows how non-trivial it really is and how much thought actually needs to be put into handling even "trivial" problems. Almost everybody who talks about how we can replace these complex implementations with simpler, understandable specifications has little to no experience with the difficulties of actually creating correct specifications. Anybody who would bring up sorting as "trivial" either has no idea what they are talking about or is so far ahead that they have weird ideas as to what constitutes as "trivial". In both cases, their opinion is highly divorced from practical reality.

That is not to say that it is not worthwhile or even that the specifications are "more complex". It is quite possible the specification is still simpler despite the difficulty, but it is also likely the complex implementation was already totally incomprehensible and a simplified specification is also incomprehensible, it is now just formally incomprehensible.

You are correct.

However, that specification is not trivial. Almost nobody correctly articulates property 1 when first encountering the problem if they do not already know the answer or are already aware it is a trick question (and even then most software developers still fail).

Furthermore, that also sidesteps the problem of formally specifying what a permutation is. Unless you have a grab bag of already proven powerful theorems, the author is most likely also going to make a error doing that as well even if we start at a proof abstraction level comparable to normal programming.

Reality is that trivial problems admit trivially wrong specifications exceedingly easily. There is little reason to assume that much more complicated problems that are hard to even articulate will magically support obviously correct specifications that are simpler and more understandable than the code.

Huh? Sorting does not have a trivial specification. In fact, it is usually used as the first example of how easy it is to make specification errors because it seems trivial, but is actually not.

You are objectively wrong. The math is straightforward to show that you can operate on a ciphertext securely in some cryptosystems.

Consider two integers M1 and M2.

Consider RSA with private key (E), public key (D), and public modulus (N).

Encrypt(M, E, N) = mod(pow(M, E), N).

Decrypt(C, D, N) = mod(pow(C, D), N).

mod(Encrypt(M1, E, N) * Encrypt(M2, E, N), N) = mod(Encrypt(M1 * M2, E, N), N).

So, for all RSA encryption, multiplying the ciphertexts results in a ciphertext that is the multiple of the plaintexts. However, unless you can break RSA, you can not determine what numbers you multiplied or what the final multiplied number is.

This is not a fully homomorphic system as it only allows multiplication, but it is a existence proof that you can do operations on ciphertext that apply to the plaintext without being able to recover the plaintext unless you can break the encryption directly.

Shadow memory mappings are only needed when you do not have hardware virtualization or when doing nested virtualization.

From the page: "it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization"

That is not to say that it is not a serious vulnerability though.

You can prove a program is correct and terminates for all inputs and, absent a hardware or other assumption vulnerability that breaks the abstract machine assumptions, there would be no inputs that "break" anything. In fact, almost any human-designed program that is correct and terminates would not just be provable, but "easy" to prove algorithmically (in the theoretical sense, in a practical sense existing techniques are insufficient to prove complex programs).

Even ignoring isolation guarantees that could generically prevent unbounded escalation for arbitrary programs, you can just reject anything that is not "easy" to prove. Humans are really dumb, so anything that is not directly proven or easy to prove automatically is almost certainly not correct, so you can just err on the safe side and just reject them if you care about global correctness.