But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
If you want to know what flying first-class 50 years ago was like (and you live in southern California, and you have money to burn) you can try the Panam Experience (https://panamexperience.com/). It's a replica of a Panam 747, together with a "crew" in period-correct costumes, that tries to recreate the entire experience of flying in the 1950s. (Bearing in mind that the plane is a replica, located on a soundstage.)
That sounds a bit weird, the 747 didn't enter commercial service until 1970.
A 1950s flight experience would have been on something with piston engines and propellors, like a DC-6 or a Super Constellation. Noisy, turbulent, and not particularly safe by modern standards.
I flew in piston airliners long ago. They fly low and slow, and barf bags are supplied for a reason (low altitude means lots of turbulence).
Today's airliners fly high where the air is smooth, they've gotten very good at avoiding turbulent weather, and there are automated damping systems. The barf bags are still there, but I've never seen anyone use one.
The cool thing about piston airliners, though, is the the engine start.
I have flown in turboprops, which start just like a jet engine. Yes I bet the startup of a big Pratt & Whitney Twin Wasp or Wright Cyclone, belching smoke and fire would have been something to see.
Today's high bypass jet engines also qualify as a turboprop.
The sound of a Merlin V12 coughing into life is just pure joy. My dad had the best job in the world flying P-51s (powered by Merlins). I hired a P-51 to do a flyby at his funeral. I only had to pay for the gas.
Ah, I responded to "tries to recreate the entire experience of flying in the 1950s" and not the "50 years ago" yes in the 1970s it could certainly have been a 747.
A proof is not like a program. The goal of a program is to "do the thing", thus you can make the argument that it doesn't matter what the code looks like as long as its works right. But the goal of a proof isn't to "do the thing" (where "the thing" is just to print Yes or No), it's to communicate. An unintelligible proof is really just a first draft.
That article (slash advertisement for Speechpad) spends a lot of words not explaining why human captioning is preferable in general to automated captioning. If I, a human, make a mistake in captioning my videos, am I any better off than if I'd used whisper and it messed up?
The page lists some of the requirements, e.g. accuracy, completeness, equivalence in access, etc. The point of their pitch is that you can't simply tell your SWEs to slap automated captions on something, check a box, and call it a day. You'd need to actually confirm you're meeting the requirements, which is something that a human who is trained in this compliance activity would do. (and something that unaware SWEs often miss)
A common compliance mistake (for any type of compliance, not just ADA) is:
* someone tells an SWE to implement [compliance measure]
* they implement poor quality [compliance measure] that doesn't actually meet the compliance requirement, close jira ticket
* they don't realize they didn't meet the compliance requirement because they don't use or need [compliance measure] and they are a SWE without any expertise with the law or the understanding of reason for the need for that requirement
I think the algorithm recommended Chris to me because of his topology videos, and from there I watched all his "old computing devices" stuff. Something about the Boston accent, the dry humor, and the occasional audio jump-cut make his stuff quite funny.
> And, the US providers seem to all be racing to make that capability inaccessible to anyone who isn't at a Fortune 500 and able to use their "cyber" versions.
Because it's valuable. I'd be surprised if the big providers didn't go even further with this idea. Need your agent to write some C++? Gotta upgrade to the "system developer" package (a $100/mo add-on to your subscription). SQL? You'll need the DBA package. Working with hardware/firmware (or anything that might be construed as reverse engineering or hardware hacking)? You'll need a verified computer engineering account for that.
And, everyone will go to Chinese/open models. Which, I guess, is why the US providers are angling for regulatory capture to lock in their monopoly for a few years and guarantee US decline in tech to the status of an "also ran".
Wand blender don't make things hot enough to cook, so OP is indeed using raw eggs in their ice cream. Which is probably fine, it just means their ice cream isn't using a cooked custard base.
> Some markdown flavors for example use \(\), which is probably the worst of them to use.
Some markdown flavors say they use `\(\)` but they also use `\` as the escape character, so in practice you have to use `\\(\\)` which is definitely the worst.
> UB was coined only in the first C standard, in 1989. Prior to that there was no "If you do this, anything can happen".
I.e., the context is, before UB existed as a concept, how would these things be categorized. And I was trying to offer the correction that, before UB existed, it wasn't "all behavior is defined" but rather many behaviors depend on your particular local environment. While that may technically be implementation defined, the current standard requires that implementation defined be documented, and UB-like edge cases were most definitely not documented anywhere consistently in the old days!
No, that's actually UB. The important bit here is "compiler defined" -- UB means the compiler is allowed to assume it never happens while compiling.
Consider, for example, an implementation defined function f() -- which can also diverge/crash horribly, etc.
If I write
if p {
print("p is true")
} else {
g()
}
if p {
f()
}
Then either we:
- print p is true and execute f
- do nothing
This is true regardless of if f immediately crashes the computer, nasal demons, whatever -- that's implementation defined.
UB means f may never happen.
And that means the compiler may optimize this to just:
g()
Notice the difference here -- the print never happens!, and g always happens.
You can see why this is concerning when you write code like
if dry_run {
print("would run rm -rf /")
} else {
run("rm -rf /")
}
if dry_run {
// oops: some_debug_string is NULL and will segfault!
print(some_debug_string);
}
I see what you're going for, but I don't see how your example is UB. If `p` is a pointer, and, after your `if (p)` check, `p` is dereferenced unconditionally, then yes, your check for `p == NULL` could be removed, and the code under the `if` would be removed as well. But the example you've constructed is not UB.
If doesn't matter what 'p' is in their example. The point is: if 'f' is undefined behavior (rather than just impl-defined), then the optimizer concludes that the "if p { f() }" can never happen... which means that we're allowed to assume that 'if p { ... } else { ... }' (in the first part of the example) will always take the else branch. The compiler will optimize accordingly and just always call g() unconditionally.
reply