Conceivably you could also fix this by having all verifiets special case this one certificate in their verification software to substitute the correct hash?
Obviously that's a huge pain but in theory it would work?
> Note, however, that roaming between APs is a feature of the 802.11 standard;
In theory yes, but man do a lot of devices have terrible roaming heuristics.
"I can still see beacons so id better stay here even though i havent received a packet in the last minute. Wouldnt want to pay the time cost of associating with that other BSS that has 5X the signal"
The intention was that software would be released as source code "tarballs" and contain a configure script, written in the lowest common denominator scripting language to configure that source code to compile on the users system. Additionally by distributing the configure script itself instead of configure.ac, users tend to need fewer dependencies that they don't already have.
It's _less_ applicable now that most users get pre-built binaries from package managers and it just feel pretty antiquated overall. But yeah the intention is that configure is platform agnostic and prepares your source code tree to build on the current platform. Whereas autoconf/autoreconf is intended as a tool for the developer to make writing "configure" a lot easier.
> autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's running on).
The configure script is not generated according to the platform it is running on. The whole reason tbe configure script is such a monstrosity is because its supposed to be portable, its written in the lowest common denominator of shell. You are supposed to distribute it. Its also fine to check in if you want end users building directly from VC rather than from tarballs. Just dont modify it by hand.
Its difficult to match the origibal macro, but dead easy to match into the shell script.
If youre just trying to get something to build as a user, its actually quite easy to read the configure script and see why its failing. The accompanied config.log is also quite detailed.
Autotools are not the best, but i always prefer building autotools packages over cmake. Worst case i can modify the configure script directly.
The web browser vendors have too much money. They have no incentive to keep the platform small. Google in particular, the cost to implement Blink is essentially meaningless to them, but it is beyond affordability for almost anyone else.
It really seems like the only reason I need this device is that most of my devices are not truly under my control.
The fact that my phone does not have these features baked in and comes with apps that violate my privacy and serve me ads without regard for malware those ads may contain is because my phone doesn't truly obdy me first.
The problem is these sorts of things are trivia. They are things that sufficiently smart tooling should handle for us so people can spend time building higher level constructs and less time worrying about individual bits.
A smart compiler should have caught (a + b) / 2 and fixed it to be correct, there's no way the overflow situation is what the programmer wanted.