This was being done over USB midi, which is already faster than standard DIN midi AFAIK. Trying to change the baud rate of DIN midi on both ends of the communication seems like a lot of work.
Except one of these incidents was a shoot down by Iran. So no, it's not just Russia, but Russia was responsible for two of the three incidents in question.
The example was talking about versions of another package that both of the given packages depend on. Not Python itself. The version numbers were made up.
You also need to consider that formal verification is not the be-all/end-all of correctness.
Formal verification is verifying a mathematical model of the program correct, according to certain mathematical correctness properties. That model may not actually represent the real world, or the correctness properties may not actually be the properties that you want to guarantee. Famously, there was the formally verified Java LinkedList implementation that was buggy due to the formal model not taking into account integer overflow.
There are parts of the Rust language and standard library that have been formally verified. That helps provide confidence that the basic model, of having safety properties upheld by unsafe core functions, to be sound.
But the big advantage of Rust, especially for everyday open source code that the world widely depends on, is that it strikes a good balance between a language that people actually want to use, and which can provide good practical safety guarantees.
Rust is far, far safer than C and C++. Most other memory-safe languages also are, but trade that off for lower performance, while Rust provides a similar level of performance as C and C++. And additionally, it's a language that people actually want to use for writing a lot of the core infrastructure.
As far as I know, I have never use any open source software written in Ada/SPARK. People just don't do it. The only reason they generally do is if they need to for functional safety reasons, in a high-criticality system, and they find it easier to get their software certified by writing it that way.
And even in safety critical systems, most people find using a subset of C, with restrictive rules, static checkers to check those, code review, and extensive testing, done by independent teams and testing on real hardware with requirements based tests that achieve 100% coverage at the MC/DC level is considered to be the gold standard of verification.
Formal verification can not possibly provide some of the safety guarantees that testing on real hardware based on actual system level requirements can provide.
Formal verification is one tool in a toolbox. It is useful for providing certain guarantees. But it's less important than many other factors for the actual improvements in safety that Rust can provide; by actually being used, in critical software that is exposed to potential network based exploitation, a memory-safe language like Rust makes a much better foundation than C or C++, and more people will actually use it in such a context than Ada/SPARK.
The article talks about compiling formalized C code to Rust. While interesting from a tinkering perspective, I fail to see any significant utility in safety, security, readability, popularity and ease of language. Can you please educate me as to what I am missing
They have a library that allows you to write and verify formalized C code more easily. And they have actually written parsers for some common file formats in this, which have been used in some major projects; and that's good, because efficient parsers for complex file formats is one of the places where you really want to use C for its efficiency, but it's also really easy to make a mistake that leads to exploitable memory safety vulnerabilities.
Now that Rust is becoming more popular, it would be nice to be able to re-use these formally verified parsers in Rust, where your entire language is memory safe. The formally verified parsers can still be helpful, because the formal verification can ensure that you also won't crash (in safe Rust, you can still crash, you just won't be subject to arbitrary memory corruption).
But just using the C libraries from Rust is unsatisfactory, now you need to go through an unsafe interface which introduces a potential place to introduce new bugs. And there are existing C to Rust translators, but they generate unsafe Rust.
So this demonstrates a way to translate from C to safe Rust, though with constraints on the existing C code. It's both useful in that it means that you can translate some of these already formally verified libraries to safe Rust, and this research could be used as part of later work for a more general tool, that could potentially translate more C code to safe Rust while falling back to unsafe in cases that it can't reason about.
Anyhow, not all academic work like this ends up being used practically in the real world, but some of it can be, or some of it can be put into practice by other tools later on. Rust came about that way; much of its reason for existence is trying to put decades of academic research into a practical, real-world usable language, since there was lots of academic work that had never really been used in industry as much as it should be.
the translated code may (quietly) not behave correctly.
The whole point of them show that example is that they say they catch this case, and bring it to the attention of the programmer:
If the original C program further relies on x, our translation will error out, and will ask the
programmer to fix their source code. This is another area where we adopt a “semi-active” approach
to verification, and declare that some patterns are poor enough, even for C, that they ought to be
touched up before the translation takes place.
Thanks for clarifying. The issue is what code would be rejected for auto-translation, not the correctness of an "accepted" translation (as my comment may have implied).
The point of noting that the example translation quietly does the wrong thing, is that that is the reason that it would have to be ("unconditionally") rejected.
While the paper does suggest that their example translation would be rejected:
> If the original C program further relies on x, our translation will error out
note that precisely determining whether or not the program "further relies on x" statically (at compile/translation-time) is, in general, a "Halting Problem". (I.e. Cannot be reliably done with finite compute resources.) So they would presumably have to be conservative and reject any cases were they cannot prove that the program does not "further rely on x". So it's notable that they choose to use a (provisional) translation that has to be rejected in a significant set of false positive cases.
And at least on initial consideration, it seems to me that an alternative translation could have, for example, used RefCell<>s or whatever and avoided the possibility of "quietly doing the wrong thing". (And thus, depending on your/their requirements, avoid the need for unconditional rejection.) Now, one might be an a situation where they'd want to avoid the run-time overhead and/or potential unreliability of RefCell<>s, but even then it seems to me that their translation choice does not technically avoid either of those things. Their solution allocates on the heap which has at least some theoretical run-time overhead, and could theoretically fail/panic.
Now I'm not concluding here that their choice is not the right one for their undertaking. I'm just suggesting that choosing a (provisional) translation that has to be rejected with significant false positives (because it might quietly do the wrong thing) is at least initially notable. And that there are other solutions out there that demonstrate translation of C to a (high-performance, deterministic) memory-safe language/dialect that don't have the same limitations.
The ECU has fairly standardized interfaces, mostly CAN or just simple switching circuits on or off. You can just get a replacement ECU. These replacement ECUs generally don't do things like using the O2 sensor to adjust the fueling, so they can burn dirtier than the original ECU.
CAN is just the physical and framing layer. The data that goes over it is a whole different matter, and it's proprietary to every vendor, incompatible and generally undocumented.
For a lot of cars you can't even swap the exact same ECU between vehicles (due to bullshit like the VIN being written into it for no reason, and often no official way to change that other than "buy a new module" - so you have to hack around with reverse engineering & EEPROM programmers), let alone mix and match completely different parts.
There is good reason for this: theft protection. A long known crime model is the "chop shop" where they tow away a car, then cut it up for parts. Because the VIN is in the ECU a chop shop has less incentive to exist since there is less money in it.
It does of course make legitimate repairs harder, and probably there should be a process to write a new VIN in - but it should only be available to someone who can verify the ECU wasn't stolen (which isn't free).
EEPROM programmers and various other ways of rewriting this VIN (turnkey tools using undocumented diagnostic commands giving you unauthenticated read/write access to memory) means it's just one insignificant expense for the chop shop (as it's amortized over all their cars) vs a multi-thousand-dollar investment in money for a legitimate vehicle owner or part-time mechanic.
That's true, but it's usually pretty simple to reverse engineer, and that's been done for a lot of cars. CAN message are generally sent out at fixed time intervals, and correspond to some physical or control value, with a simple linear mapping between some physical unit and the value in the message. You collect some CAN data, change something like pressing the accelerator, see what changes, record results.
Just search for "aftermarket ECU", you'll find lots of them; generally for high-performance cars that gearheads want to soup up further, but the same basic principle applies to most ECUs.
Kyle Rittenhouse and Daniel Perry are both walking free after unambiguously murdering people in broad daylight.
You're right, I do find it less likely that the murderer of a CEO would get the same kind of treatment as murderers of civil rights protesters, but there are examples in recent history of people walking free despite unambiguously murdering people in broad daylight for political reasons.
I find that these efforts to make something that is almost but not quite JSON to be counterproductive.
It means that something you can't tell if it's JSON or another format. You'll have some tools that can work with it, while other tools will choke because they expect valid JSON. Oh, someone just switched the quoting style so now your jq based automation is all broken.
And now you have to figure out which of these not-quite-JSON formats this is. Is it HuJSON/JWCC? Is it JSON5? Does my editor have a mode that supports this particular variant, or am I always going to be fighting with it?
And finally, having used HuJSON for Tailscale config: the issue isn't just things like comments and trailing commas, or quoting styles. JSON is just a kind of heavyweight and cumbersome syntax for writing config files. I find that I prefer writing a script to auto-generate my Tailscale config, because editing it by hand is cumbersome.
There are a number of other possible config file formats, with varying levels of JSON data model compatibility. YAML has its issues, but we've all learned to live with them by now. TOML isn't bad, though good luck remembering the array of tables syntax. KDL is pretty nice; it has a slightly different data model than JSON, but it's actually one that is somewhat better suited for config files.
I'd rather use any of these for config files than something that is almost, but not quite, JSON.
> In an interview with NBC, Thompson’s widow, Paulette told the network that “there had been some threats” against her husband.
> “Basically, I don’t know, a lack of coverage? I don’t know details,” she said. “I just know that he said there were some people that had been threatening him.”
These words are reminiscent of the terms "delay, deny, defend", the title of a book about how the insurance company tries to avoid paying out on claims: https://en.wikipedia.org/wiki/Delay,_Deny,_Defend
So, one of the leading theories is that the shooter was motivated by some kind of case involving a denied claim. Obviously, there's not enough evidence yet to be sure of that, but that same frustration over insurers' failure to pay for necessary, life-saving treatments is part of why there's so much sympathy for the shooter and so little sympathy for the CEO who was shot.
Of course, there are also other competing theories out there; it's possible that the whole bullet casings thing is just a ruse to distract people. But anger about how health insurance companies rack in record profits by denying life-saving healthcare to people has become a large part of this story.
UHC also has the highest claim denial rate in the healthcare industry, and they're notorious for stiffing doctors on payments as well. If there was ever a health insurer who'd stoke the kind of grudge that drives people to violence, it's UHC, because they're the worst among the worst.
