This is where iphones are a risk actually. Android webapps on old phones with their original OS installed have a better chance of working compared to old iphones with their original iOS version. This is both due to Apple's continued stubborness in keeping Safari releases tied to iOS releases (eg. "to get the banana you need the gorilla holding the banana and the entire rainforest the gorilla lives in...") and the dominance of Chromium browsers in webapp testing.
On old Android phones it's easier to install newer browsers without having to update the OS.
Edit: your comment is also not valid on occasion. I've recently witnessed some banking mobile webapps being broken for long periods of time and one bank that decided to remove the agreement approval function from their webapp, forcing you to download the app in order to approve updated agreements.
The SE didn't sell well. They want people who not only buy the phone but also buy content through the App Store and through the media services like Apple TV/music.
There's no free lunch. I don't know where you're getting this "Pareto improvements" thing from because it's a much more constrained codegen framework than LLVM's backend. It supports a much smaller subset, and real world code built by LLVM will use a lot of features like vectors even at -O0 for things like intrinsics. There's a maintenance cost to having a completely separate path for -O0.
You can complain all you want on here but it's not going to change the fact that most readers including myself just glaze over them. Because as you say most are just bullshit.
So keep doing it if you don't actually care. If you do, maybe try to think of a different way to communicate it that sets you apart.
I generally like it when resumes do this, and so do most people I know. I'd be interested to see surveys, I don't think it's anywhere close to universal. That said, I'm typically focused on very measurable domains (e.g. making code faster.)
I've read so many resumes over the last few years that I'm just completely overwhelmed by the practice. In fact I now judge resumes unfavorably if they use it more than very sparely.
The best resumes I read (and the strongest candidates) were ones which were very confident in their skills and experience. They showed a bit of personality (as much as you can).
The heck would you know? LBT studied physics and did a masters in nuclear engineering at MIT, he then started but left a PhD in that subject at MIT. He's not some clueless management scrub.
Even in this letter he says he's going to be reviewing major chip designs before tape out. JFC...
That doesn't make sense. If a pilot wanted to deliberately cut off the engine there's no reason they couldn't do at that time. The time difference between the switches being one second shows it was more likely to be deliberate, not less. An accidental hit would result in both happening at the same time, not with a time delay.
The two switches changed in sequence, but within the same second and at max speed. Dont think a human can have such a timing. If you look at the timing it looks more and more like electronical or software triggers.
Another possibility is a foreign object like a personal item sliding back during acceleration.
I looked at both pilots background, and unless a story of medical depression on the part of the captain emerges, I dont see the pilot suicide as plausible.
I agree the evidence points to the Captain, but the report did not provide the full text of the pilots interaction. The timestamps shows they were cut, one after the other, but within the same second as max vspeed. Doubt humans can have that precision.
>> The switches are not software controlled.
That is what unethical people, like Captain Steeeve - Who changed his "accident clear cause" story four times since the accident - keep saying.
But on the 787, fuel switches are part of the electronic cockpit interface and toggling one sends a command via AIMS to the Engine Interface Unit, then over AFDX to the FADEC. The FADEC actuates the spar and engine fuel shutoff valves who are both electrically controlled with no mechanical linkage.
The switch itself doesn’t cut fuel, it initiates a command interpreted and executed by software. Additionally, software logic can override or block the command based on conditions like fire, overspeed, or sensor faults so
its software-controlled end-to-end.
A faulty sensor could trigger even if so far evidence points to the Captain.
"Full authority digital engine controls have no form of manual override available, placing full authority over the operating parameters of the engine in the hands of the computer.
- If a total FADEC failure occurs, the engine fails.
- Upon total FADEC failure, pilots have no manual controls for engine restart, throttle, or other functions."
