weinzierl
Joined 16 years ago
Joined 16 years ago
What I wish existed is smarter handling of megamorphic call sites. In practice most dyn sites only ever see a handful of concrete types, so tracking which types actually get coerced to dyn Trait in reachable code could prune a lot of the vtable fan-out. Probably not easy, but does not have to be perfect. It's also OK to acknowledge that this sometimes fails and handle that gracefully in visuslization.
And a view that overlays coverage data, so you can see which paths are actually exercised. Could be especially useful with panics, so you can see which panic paths tests actually hit.
Works for whom? For the customer, "works" means the features work. Security is a vague, nebulous thought at the back of their minds.
The provider provides features. Lack of security has no impact on them, not in the short term and not in the long term. The short term we can't change easily, because people are people. The long term we could: regulation can turn negligent security into a lasting cost.
As much I'm against more regulation in general, I'm afraid as long as we don't do that, companies will always prioritize more features faster over security.
Thank you very much!
I'd be interested in the latest version of the dynaham.w program, if anyone has that.
noreply@[HN username]web.com
falls-dann-sonst
would be more correct, since "wenn" is temporal, like the English "when".
Many Germans often use these wrongly in everyday speech, but mathematicians like Friedrich L. Bauer probably wouldn't.
When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.
It's not that it can't be done.
It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
I, for my part, as much as I dig a little 70s and 80s retro stuff, would never ever want to go back.
But the work doesn't go away, it moves. Someone still has to judge the 100 results, pick one and integrate it with everything else. That part doesn't partition, and it's where Brooks put most of the schedule anyway: in the same chapter his rule of thumb gives a sixth to coding and half to testing.
For me it was a bit sad to see the mad and creative UX world of the homecomputer era being bulldozed over with the minimalist uniform results of the scientific usability research.
Little did I know that a mere quarter century later we are back were we once started and everyone as clueless as we were in the 90s goes overboard everywhere as if there was no tomorrow.
Yeah, and it sadly makes me miss the nicely ordered and easily usable world - I'm gettin' old I guess.
Interests:
* Rust
* Robots
* Machine Learning
* Cybersecurity