[1] Actually, the defect was that creating a root account was a unprivileged action, so anybody could create a root account on your machine with a password of their choice. The most obvious presentation is that you could login to root by pressing enter twice with the empty password; the first time creating root with the empty password and the second time logging you in.
Their lawyers already did that and got it ruled that Tesla’s statements are unbelievable lies and thus Tesla is not liable for deceiving customers or the public.
On page 16, the judge states that the defendants, Tesla, argued: “Defendants also assert that several Safety Statements are corporate puffery. For example,
statements that safety is “paramount” (FAC ¶ 325), Tesla cars are “absurdly safe” (id.), autopilot is “superhuman” (FAC ¶ 337), and “we want to get to as close to perfection as possible”
(FAC ¶ 363). Mot. at 19.”
That does not work. They just infect you and do not demand a ransom for a few months as they encrypt all your data going to the backup. Now your backups are also encrypted going back multiple months and you have to discard months of work.
I agree, I'll try adding some. We use the tool on a benchmarking platform so we run this thing hundreads of times daily and did dozens of tests against pretty much every other load generator (that I know of). Numbers are also always tied to the hardware where you run it and typically benchmarks provided by the maintainer himself are always biased and won't match what you get though.
I personally never care about benchmarks presented, it's much better to use and see for myself so didn't think much about having a table with values there but I can understand how it may help.
I did and I still didn't see any numbers. Just a bunch of AI generated text about why it's supposedly fast. It even says it records numbers multiple times, so why aren't there any presented?
There are plenty of ways for language to be better now that we know far more about arithmetic than when number words were created.
"One Five Five Two Three One" is 6 words, 6 syllables long where as "One Hundred and Thirty Two Thousand" is 6 words, 9 syllables long and conveys less information. Even shortening it to "One Hundred Thirty Two Thousand" is still 5 words, 8 syllables long and conveys less information.
You can also easily convey high order digits first by using a unambiguous "and/add" construction: "Thousand Two Three One Add One Five Five". You have now conveyed the three high order digits in 5 words, 5 syllables. You also convey the full number in 9 words, 9 syllables in contrast to "One Hundred Thirty Two Thousand One Hundred Fifty Five" which is 9 words, 14 syllables.
You could go even further and express things in pseudo-scientific notation which would be even more general and close to as efficient. "Zero E Three (10^3) Two Three One" which is 6 words, 6 syllables, but no longer requires unique separator words like "Thousand", "Million", "Billion", etc. This shows even greater efficiency if you are conveying "One Hundred Thirty Thousand" which would be something more like "Zero E Four (10^4) Three One" since the scientific notation digit position description is highly uniform.
This distinction might seem somewhat arbitrary since this just seems like it is changing the order for the sake of things. However, the advantage of little-endian description is that it is non-contextual. When you say the number "One" it literally always means the one's place "One". If you wish to speak of a different positional "One" you would prefix it with the position e.g. "Zero E Three (10^3) One". In contrast, in the normal way of speaking numbers "One" could mean any positional one. Are you saying "One Hundred", "One Thousand", "One Hundred Million"? You need to wait for subsequent words to know what "One" is being said. Transcription must fundamentally buffer a significant fraction of the word stream to disambiguate.
It also results in the hilariously duplicative "One Hundred Thirty Two Thousand One Hundred Fifty Five" which has positional signifiers for basically every word. "One Hundred Thir-tyThousand One Hundred Fif-ty Five”. Fully 8 of the 14 syllables are used for positional disambiguation to reduce necessary lookahead. "And/Add" constructions get you that for a fraction of the word and syllable count. They allow arbitrary chunking since you can separate digit streams on any boundary. It also reinforces the fact that numbers are just composites of their components which may help with numeracy.
Little endian is actually just better in every respect, expect for compatibility and familiarity, if we use our modern robust knowledge of arithmetic to formulate the grammar rules.
You should actually not use format-swapping operations.
You should actually use format-swapping loads/stores (i.e deserialization/serialization).
This is because your computer can not compute on values of non-native endianness. As such, the value is logically converted back and forth on every operation. Of course, a competent optimizer can elide these conversions, but such actions fundamentally lack machine sympathy.
The better model is viewing the endianness as a serialization format and converting at the boundaries of your compute engine. This ensures you only need to care about endianness when serializing and deserializing wire formats and that you have no accidental mixing of formats in your internals; everything has been parsed to native before any computation occurs.
Essentially, non-native endianness should only exist in memory and preferably only memory filled in by the outside world before being parsed.
I have frequently proposed a objective legal standard for false advertising that handles that: "Technically, your honor". If somebody says that in court, they lose.
The words they used, as commonly understood by the target audience, were intentionally crafted to be interpreted differently than what they were going to say they meant in court. They spent time, effort, and money, ran focus groups, and carefully selected and curated their words to be incorrectly interpreted by the target audience to reach knowingly false conclusions.
The correct standard should be that they spent time, effort, and money, ran focus groups, and carefully selected and curated their words to be correctly interpreted by the target audience to reach true conclusions. Their statements should only be accidentally incorrect in proportion to the time and effort spent crafting and distributing them.
"Technically, your honor", should be treated as the ethical abomination it is.
I know there's some tort caselaw in Australia towards both parties actual understanding of the contract vs written word. We went over a few of these cases in high school commerce. Its been further enshrined by the ACCC, which tends to take the view that the verbal understanding provided at the point of sale can often supercede terms and conditions.
When did we enter the twilight zone where bug trackers are consistently empty? The limiting factor of bug reduction is remediation, not discovery. Even developer smoke testing usually surfaces bugs at a rate far faster than they can be fixed let alone actual QA.
To be fair, the limiting factor in remediation is usually finding a reproducible test case which a vulnerability is by necessity. But, I would still bet most systems have plenty of bugs in their bug trackers which are accompanied by a reproducible test case which are still bottlenecked on remediation resources.
This is of course orthogonal to the fact that patching systems that are insecure by design into security has so far been a colossal failure.
Bugs are not the same as (real) high severity bugs.
If you find a bug in a web browser, that's no big deal. I've encountered bugs in web browsers all the time.
You figure out how to make a web page that when viewed deletes all the files on the user's hard drive? That's a little different and not something that people discover very often.
Sure, you'll still probably have a long queue of ReDoS bugs, but the only people who think those are security issues are people who enjoy the ego boost if having a cve in their name.
Eh, with browsers you can tell the user to go to hell if they don't like a secure but broken experience. The problem in most software is that you commit to bad ideas and then have to upset people who have higher status than the software dev that would tell them to go to hell.
But, have you any code that has been vetted and verified to see if this approach works? This whole Agentic code quality claim is an assertion, but where is the literal proof?
It’s agents all the way down - until you have liability. At some point, it’s going to be someone’s neck on the line, and saying “the agents know” isn’t going to satisfy customers (or in a worst case, courts).
> It's not like humans aren't already deflecting liability
They attempt to, sure, but it rarely works. Now, with AI, maybe it might, but that's sort of a worse outcome for the specific human involved - "If you're just an intermediary between the AI and me, WTF do I need you for?"
> or moving it to insurance agencies.
They aren't "moving" it to insurance companies, they are amortising the cost of the liability at a small extra cost.
Just today I had an agent add a fourth "special case" to a codebase, and I went back and DRY'd three of them.
Now I used the agent to do a lot of the grunt work in that refactor, but it was still a design decision initiated by me. The chatbot, left unattended, would not have seen that needed to be done. (And when, during my refactor, it tried to fold in the fourth case I had to stop it.)
(And for a lot of code, that's ok - my static site generator is an unholy mess at this point, and I don't much care. But for paid work...)
The chance of a defect fix introducing a new defect tends to grow linearly with the size of the codebase, since defects are usually caused by the interaction between code and there's now more code to interact with.
If you plot this out, you'll notice that it eventually reaches > 100% and the total number of defects will eventually grow exponentially, as each bugfix eventually introduces more bugs than it fixes. Which is what I've actually observed in 25 years in the software industry. The speed at which new bugs are introduced faster than bugfixes varies by organization and the skill of your software architects - good engineers know how to keep coupling down and limit the space of existing code that a new fix could possibly break. I've seen some startups where they reach this asymptote before bringing the product to market though (needless to say, they failed), and it's pretty common for computer games to become steaming piles of shit close to launch, and I've even seen some Google systems killed and rewritten because it became impossible to make forward progress on them. I call this technical bankruptcy, the end result of technical debt.
Except they don't converge. You see that if you use agents to evolve a codebase. We also saw exactly that in the failed Anthropic experiment to create a C compiler.
The fact that KiCad still has a ton of highly upvoted missing features and the fact that FreeCAD still hasn't solved the topological renumbering problem are existence proofs to the contrary.
It probably is introducing more bugs because I think some people dont understand how bugs work.
Very, very rarely is a bug a mistake. As in, something unintentional that you just fix and boom, done.
No no. Most bugs are intentional, and the bug part is some unintended side effects that is a necessary, but unforseen, consequence of the main effect. So, you can't just "fix" the bug without changing behavior, changing your API, changing garauntees, whatever.
And that's how you get the 1 month 1-liner. Writing the one line is easy. But you have to spend a month debating if you should do it, and what will happen if you do.
Oh geez. Legal did not give them the go ahead to make the unqualified statement: “We are not aware of any successful spyware attacks” they had to explicitly qualify it with “mercenary”.
There are more weasel words "we are not aware" - means they actually don't know if such attack was successful, "successful" - what is the definition of success? Maybe attackers got access, but didn't find anything interesting?
I think you are, the words make perfect sense. They know of a lot of attack attempts, and so far they have no reason to believe any were successful. Success can mean a lot of different things, why list it all out (were able to extract data, install malicious software, encrypt files with ransomware, delete any data, etc).
They have a legal department carefully directing what they say. In a court of law, their lawyers will successfully argue that they are beholden to only the precise letter of their statement. Are you arguing that their lawyers are incompetent and imprecise in their wording? If so, what evidence do you have that their lawyers are incompetent?
In light of the correct legal interpretation of their words, being only the specific letters, we can see that your interpretation is incorrect.
> They know of a lot of attack attempts
No, their statement says nothing about attack attempts.
> so far they have no reason to believe any were successful
No, their statement says nothing about their belief, only their explicit knowledge. Their statement says nothing about their investigation practices or whether they even attempted to investigate and learn about attacks. Their statement says nothing about non-mercenary attacks.
Their statement is technically correct as long as any successful attacks they know about are not explicitly known to be committed by mercenarys.
> No, their statement says nothing about attack attempts.
That's a good point. The best way not to know about any successful attacks is not to know about any of them. I also can definitively state that I'm not aware of any successful attacks, but for obvious reasons this is a basically meaningless statement. Without more data, it's not clear how meaningful the statement they gave is, and while it probably is more meaningful than mine, it doesn't make sense to jump from what they said to "there have definitively been no successful attacks" based on it.
I'm just going to ignore your entire first paragraph that tries to use hostility to overcome a clear willful misunderstanding, or strong evidence of a recent stroke.
> No, their statement says nothing about attack attempts.
Exactly, they're keeping the statement brief and correct. They have sent multiple batches of notifications to users on previous attacks.
The statement is clear, covers their primary use case for the product, and I'm sure is legally sound. You're grasping at straws trying to think up ways they can be lying to you. I would be very surprised if you ever have used their lockdown mode with any actual cause.
I am glad that you agree that their legal department’s explicit and intentional exclusion of known successful non-mercenary attacks is precise and legally sound.
It is advisable to not grasp at straws to think up ways that highly paid lawyers are not saying exactly the words they have approved. That is literally their job and they are good at it.
If they meant something more expansive they can do so. It is not the public’s job to do it for them while letting them retreat to the legally binding interpretation at their pleasure.
They can be perfectly aware of nation-state hacks. These are exactly the weasel qualifiers used by the NSA when they were claiming not to be watching the communications of US citizens. "No intercepts were made under program X" specifically sidesteps all the shady stuff under program Y.
They have very good reason to believe that - shareholders and public perception. Apple maintains image of their phone being secure and that is far from the truth. As long as general public don't know their phones have holes like Swiss cheese, the shareholders will be happy.
>"successful" - what is the definition of success?
At risk of stating the obvious, isn't success "hacked it and no one ever found out (at the time)"? By definition, Apple could probably only be aware of unsuccessful attacks. Though that's not guaranteed either, considering all the myriad failure modes that there must be.
Automatic turret-mounted anti-air shotguns. Blow up 100 $ drones for the cost of a 0.50 $ shotgun shell.
I bet you could do aiming and firing in less than 0.1 seconds with nearly 100% accuracy in the 50 meter range which would enable ~10 destroyed drones per unit if the drones are going 150 km/h.
Shotgun pellets are also basically entirely safe when shot into the air as they have low falling velocity enabling usage when shooting over populated areas.
> Blow up 100 $ drones for the cost of a 0.50 $ shotgun shell.
Then two drones approach from opposite sides at 200 MPH. Your emplacement costs more than $200 and can only fire in one direction at a time.
Or, as we've seen in Ukraine, once your disposable low-cost drones have precisely identified a high-value, high-effectiveness static emplacement, you send in a cruise missile to clear it out, and then the drones continue sweeping forward.
Drones that can move that fast have extremely little cargo capacity for explosive charges and it's not fast enough to simply use the kinetic energy of the drone for much.
> Then two drones approach from opposite sides at 200 MPH.
A drone that can go 300 km/h is way more than 100 $, you are in the thousands of dollar range at that point. Turret wins if it blows up one.
Also, it could probably blow up more than one since at 300 km/h you would get 0.5 seconds to respond and I was arguing 0.1 seconds per target anywhere in a full 360. 0.25 seconds for anywhere on a full 360 would be enough for 2 and that is within human capability.
> you send in a cruise missile to clear it out
Cool, you sent in a hundred thousand dollar cruise missile to blow up a thousand dollar turret. Turret wins. Also you can put wheels on the turret, so it might not even be there.
Now you are probably going to argue about a drone that goes 1000 km/h at which point what you have is a cruise missile which costs tens to hundreds of thousands of dollars. At that point the entire argument about drones being too cheap to cost-effectively stop is moot.
Or you might argue that the drones just go high. 50 m is a ludicrously low flight ceiling. But then your drone can not explode on contact. You could use a drone that drops explosives, but that still requires flying over the target. High flying drones are easier to detect, and you could counter that with flying shotgun drones or turret mounted machine guns which have ranges in the hundreds to thousands of meters and would still only cost a few dollars of ammo per kill.
My main point is that bullets can easily disable a cheap drone and are much cheaper than a cheap drone. You just need a cost-effective way of deploying mass bullets against mass drones. Logical answers are ground deployments around targets or drones with bullets that cost-effectively shoot down drones without bullets.
You will then likely get into a arms race of fighter drones to protect your bomber drones. And scale up your drones until they are not easily bullet-destroyable. But then your drone costs have likely increased to the point where anti-air cannons shooting 100 $ explosive shells are cost-effective. And so on and so forth.
> Cool, you sent in a hundred thousand dollar cruise missile to blow up a thousand dollar turret. Turret wins.
Nope. The calculus is not about individual components, but about overall cost of the entire system and all of its associated support. What was the material, labor, and opportunity cost to install the turret? What was it protecting (which is now presumably destroyed by drones, or captured by the enemy)? You're also still assuming that you're facing off against guerillas fighting an asymmetrical war on a shoestring budget, but that's not the case. Whatever force you're fighting can be trivially bankrolled by a peer power who is happy to bankroll them to make you bleed to death. China will be happy to build plenty of cruise missiles, and plenty more drones.
The argument is literally that it is problematic to send 100 k$ interceptors to stop 1 k$ drones and then you turn about and argue you can end 100 k$ cruise missiles to stop 1 k$ turrets. Your argument is inconsistent with the entire premise.
You have presented no evidence as to the overall cost of this mystical unstoppable drone swarm. In contrast, we do know that shotguns, machine guns, and bullets are cheap, mass-produced, and mass-deployed by the tens of millions.
The key unknown of my proposal is the bulk cost and production of a small automated turret or fighter drone that can economically and flexibly deploy cheap bullet interceptors to asymmetrically defeat expensive drones. However, the operational requirements for such devices are simple and within the range of existing technology.
There is no clear evidence that cheap explosive drone swarms are magically cheaper than cheap fighter drone swarms or cheap ground drone swarms. It could easily go either way and without a rigorous actual analysis you and I are both unqualified to determine what is actually dominant.
Which only protect a small area, so drones just need to target less obvious things. Meanwhile your guns shoot birds and once in a while - an occasional bystander. Attackers are always advantaged since you have to protect _everything_ and they only need to target what's left unprotected. Some drones just drop grenades, I somehow don't see your shotgun hitting either the drone (too high) or a grenade (too fast and small).
We have these things called wheels. Or you could mount it on a drone.
> Meanwhile your guns shoot birds and once in a while - an occasional bystander
We are discussing protecting military bases or military assets.
> Some drones just drop grenades
That requires flying above the target. See counter-point 1.
Please put in the minimal effort needed to follow through at least a few steps of argument and counter-argument in your head. I assure you I am not putting in as little effort into my arguments as you did.
How many shotguns? How do they reload? What happens when they run out of ammo?
Can they be hacked, or duped into firing at friendly aircraft?
How will they deal with the enemy adapting their drones to have camoflage?
There's no way automatic turret mounted shotguns are the solution to this problem.
It simply isn't economical to produce, install and maintain all of these things, and now you've sunk a massive amount of resources into this infrastructure when the enemy doesn't even really have to launch a real attack.
What's their supply chain for being restocked with ammo? Is that supply chain susceptible to drone attacks along any part? Then you still lose eventually.
Now picture an American military base. They're pretty big, right?
Now imagine how many of these shotgun towers you need to secure the paremeter based on the firing range of these weapons, then imagine how many you shotgun towers you need to defend the interior of the base from drones that don't attack from the side but instead come in from the middle because they can fly.
How much ammunition can each of these shotgun towers hold? What happens when it runs out? Does a human have to go over there and refill it? What kind of equipment do they use to do that? How much time does this take and how much fuel does it consume? What is the opportunity cost of this?
Now that's just one military installation. How many does the US have? Are you going to put these shotgun towers outside the homes of high ranking military officers? The roads that they take to go to work?
What's stopping someone from doing this kind of drone attack on the highway to the military installation timed with the morning or evening commute? What's the counter to that?
Automated shotguns are not an economically viable defense to the threats that I described in my previous post.
> Automatic turret-mounted anti-air shotguns. Blow up 100 $ drones for the cost of a 0.50 $ shotgun shell.
Yeah, doable. I went to a clay pigeon range last week (company outing). These are targets that move quite fast. They don't spring out from the same spot and some roll over the ground. I had never handled a gun before. I am 50, with the attendant poor eyesight and lack of twitch reflexes.
And yet, I still nailed 20/25 moving targets. A turret with a shotgun is going to hit much more than that.
https://security.it.miami.edu/stay-safe/sec-articles/macosx-...
[1] Actually, the defect was that creating a root account was a unprivileged action, so anybody could create a root account on your machine with a password of their choice. The most obvious presentation is that you could login to root by pressing enter twice with the empty password; the first time creating root with the empty password and the second time logging you in.
reply