AlotOfReading

Sure, not going to disagree that processes affect outcomes. As someone who lives with standards-following-practices every day though, I always have to caution people that following the process is often a vastly different thing than improving the outcome. For example, (most) certified compilers are great from a process perspective, and awful if your goal is less buggy software.

My opinion is that all the process in the world won't help if the people doing it don't care about the outcomes.

26262 is a process standard (a voluntary one at that), not a software standard. It barely even talks about software outside a couple specialized sections. You can also think of the CA program as a process standard that comes with active enforcement.

I've enjoyed embedding declarative syntax inside imperative languages, like LINQ and prolog as a dsl. The imperative code can express temporality much easier, and the declarative code allows you to throw that away when you don't want it.

Why would you need a fast insecure key at all though? Just use a real key. Key generation for an ECC curve should be lightning fast.

Sure, but it feels like you're doing something helpful. It's like self-help books, or new years resolutions. The emotional fulfillment of feeling like you've done something is vastly more popular and marketable than doing the actual work.

The market is more complicated than that, unfortunately. Some properties can sustain high ratings on their other strengths (e.g. location, decor, view, heritage) regardless of the host rules and the clientele that's interested in them. There's also a problem with the rental market getting very thin for some locations and property types (e.g. 3+ bedrooms), so ratings effectively stop mattering.

As a personal example, I once stayed at a place that charged a $150 cleaning fee, but also required dishes + taking the trash out and down the street, which wasn't known until we opened the door. And of course there was a threat that failure to do so would incur a fee. Also a bit of ceiling plaster fell on my wife during the night. Still had a fantastic rating because it was a castle and I'd stay there again if someone else paid.

Let he that has never created potential vulns cast the first stone.

The East Bay Park district is the largest regional park system in the US, so I'm not sure it's entirely fair to call them "lazy". There's an ongoing fight over whether they should prioritize improving/maintaining/restoring what they already have or acquiring new land.

You could choose to detect small keys, but my understanding is that implementations entirely eliminate the issue by only searching factors with leading bits set (i.e. large numbers).

Definitely not. Their CPS requires that these keys be generated by an HSM and no HSM would ever generate these, so there's little reason to believe they're following any of their other controls.

The US also has laws imposing restrictions on institutions outside their borders/jurisdiction. FATCA for example.

The one hashing scheme should be technically better.

That said, I suspect you could avoid the coprime partitions and the issues they cause with semi-correlated permutations over block partitions and avoid hash collisions in the process.

This is a general point rather than an argument supporting the GP comment, but it can be shockingly hard to know what the correct response to particular situations is, or predict how a system will respond. For example, one system I know had difficulty differentiating people laying on the road from unmapped speedbumps (particularly at night), but was very good at recognizing them standing up. Someone spent a lot of time testing with dummies until perception improved. Another had no idea how to handle people in fursuits and halloween costumes, because it was incorrectly applying animal behavioral models to pedestrians.

Waymo has been winter driving in Tahoe since 2016 or so. Hard to find icier conditions with bigger hills.

Why are SLAs the bar for performance? Every additional second of execution time accumulates in the annual cloud bill, and using too much memory means I need a bigger box.

For example, the C++ replacement for a Java program bottlenecking my CI takes 1/3rd as long (with less variance) and runs on a smaller instance.

As someone who lives in a country with wolves and other apex canids (to the point where we have legal hunting seasons for them), I really don't understand the supposed "consequences" here. Canid populations just aren't an issue. There are no children living in fear (rather, we have to keep kids from trying to approach the cute animals...), nor are the occasional depredation events more than a minor annoyance. If a wolf or big cat in particular eats your lifestock, you file a form with the government for market-value compensation and complain about the hassle at the bar.

I'm not sure we read the same story. By the time of the inciting incident, the technocrat cyborgs (Titans) have been enslaved by the machine leader, which has no humans in charge of it.

I'm pointing out that Japanese companies can do that because they're organized and managed like Japanese companies. Tesla is not, and in fact lacks pretty much all the organizing characteristics and long term planning that enables keiretsu to function.

A.k.a the circular economy, or HP's modern business model. One of the difficulties has always been that if your materials are truly fungible commodities, why would anyone pay your premium instead of buying from a dozen other suppliers. HP makes it work with technical moats, but that doesn't apply here.

What about Tesla's management style would you call Japanese?

This exact same problem exists on mountains, which is why there are no permanent settlements above 5,100m. The Apollo pressure mentioned above (1/3rd atm) is roughly equivalent to an elevation of 8,500m, well into the "death zone" for a normal atmospheric mix.

The primary mechanism for redress of constitutional right violations under current law are monetary damages under FTCA, especially now that universal injunctions are dead. There's no actual counterbalance.

I wouldn't use this as a guide.

The beeswax I get from a local apiarist looks nothing like that under a blacklight, and in fact is quite (pale) orange. Carnuba wax mixtures fluoresce yellow. My box of paraffin fluoresces blue brightly enough to be visible in full sunlight, much brighter than the image. Rosin fluoresces bright, radioactive orange in case you're wondering.

The Mongolian version, aaruul, comes in a whole range of textures from reasonably chewable to a hardness that dissolves in your mouth over the course of an hour or so. It makes for great travel food.

I don't know why nepali version is dried so much, but it becomes impossible to rehydrate and hence, unusable.

That's trivially untrue. Nothing about turing machines or lambda calculus requires temporal unsafety. Even this example wouldn't exist if the compiler rejected covariant lifetimes. You already know this of course, so I'm not going to keep beating that dead horse.

The obvious follow-up is to find a minimal set of rules that allow us to express what we want without permitting temporal unsafety. The borrow checker is one set of fairly minimal rules that works pretty damn well. Alternatively you could define away the unsafety by giving it semantics, like fil-C does.

I'm only talking about modern C++, not C++98. C++'s footguns include smart pointers. For example, is the following code safe?

    std::unique_ptr<int> p(foo());
    std::print("{}\n", *p);

The answer depends on how foo() is implemented. You can't reason about it locally, and strictly speaking it's not possible to determine at compile time. Now, I should be declaring this gsl::not_null<std::unique_ptr<int>> to comply with the core guidelines, but I think we can agree that optional support libraries aren't relevant to this discussion.

It's not enough for memory safety issues to be "rare". To meet your obligations under the standard and have defined behavior (i.e. rust's basic guarantee), memory safety issues can't exist at all.

And yet applications written in modern C++ are constantly discovering new memory safety issues. Sean Baxter wrote a whole manifesto talking about the shortcomings of the existing C++ model [0].

[0] https://safecpp.org/draft.html

If it were transmit only, you could put it behind a data diode and buggy report code wouldn't matter. Even better, validating the code is a lot easier if it doesn't accept attacker input.