Realistically, I would grieve the loss of my children, who would never be born if I didn't line things up just right to cause them to happen again. I'd spend more time with my parents, who are getting along in the years, and I'd make the most of my time with them while they're healthy and happy.
There are a few specifics where I'd try to get some loved ones out of trouble before some critical tipping point that would later cause a bunch of heartache and stress.
There are general things about money and politics I'd probably do differently, knowing about how stocks have performed and what not, but that's not super interesting to me, because I'm mostly content in my personal life (including my career) and wouldn't want to upset that balance by doing anything too different from what brought me here.
I've been a general skeptic of exactly how much the power and performance to power stats are attributable to the ARM instruction set or architecture versus the fact that Apple just locks up TSMC's latest and greatest node for a year before everyone else. AMD's CPUs are still x86_64 but achieve similar performance per watt as the Apple silicon on the same node and similar TDPs.
So if it turns out that TSMC has the secret sauce, then maybe we don't need to move laptops over to ARM at all.
How do they even still have energy to send and receive signals? That's one heck of a durable power source.
It's literally decaying plutonium-238. And because it decays, it's putting out less power than when it started. They've shut down certain operations to conserve power, and obviously prioritize things like communication back to earth.
I made an alt on each of the big instances, because I wasn't sure which one I wanted to use long term. Then I just kinda stuck with them, each following slightly different topics, and therefore having different opportunities to participate in discussions.
Yes, but I don't think the CHIPS Act was aimed at the not-so-cutting-edge processes and getting those reshored onto US soil. The US already has a bunch, and the strategic value of those supply chains are less critical to national interests.
Fi has two different, incompatible options for how to sync your messages to a computer or other device that isn't your primary phone with your SIM (or e-SIM): the so-called "option 1" is RCS compatible, but treats your phone as the canonical device that has the primary copy of all messages, voicemails, etc. "Option 2" is device agnostic, where all messages and voicemails live on the cloud, and your phone (and all other devices) merely syncs with that primary copy in the cloud.
If your phone breaks or dies or is lost/stolen, Option 2 keeps chugging along with all your logged in devices, but the dead phone is the single point of failure for Option 1.
Ideally there would be a device agnostic way to access RCS through your account, but every implementation seems to require a specific SIM.
What chips were we making in China? Unless you're counting Taiwan as China, but I'd point out that we're still making the top of the line chips in Taiwan.
So I gotta ask: what's your plan for addressing your stress levels and your lack of sleep? A prescription from your doctor doesn't squarely address those issues, and they should probably be addressed.
Our data centers and backbone internet/Tier 1 internet providers are basically the best in the world. The US Department of Energy maintains a network with 46 Tbit/s connections between its labs.
They've got beacon location data, yes, but Apple is the only one that gives up that information without first conforming that the query is coming from someone who sees that BSSID. As OP notes:
In this respect, Apple's Wi-Fi database also differs fundamentally from other Wi-Fi databases, such as the one operated by Google.
If you click through to the paper, it describes 2 approaches for using BSSIDs to identify location:
Client submits a query listing each BSSID and its signal strength, and the server calculates position and returns where it believes the query is coming from.
Client submits a query listing each BSSID it's interested in, and the server responds with the location of each BSSID so that the client can calculate its own position.
See the problem there? Approach 2 gives more raw information away, by outsourcing the positioning calculation to untrusted clients.
And the paper outlines how Apple goes even further than that:
Apple’s Wi-Fi geolocation API [4] works in the latter manner, but with an added twist: In addition to the geolocations of the BSSIDs the client submits, Apple’s API opportunistically returns the geolocations of up to several hundred more BSSIDs nearby the one requested. These unrequested BSSID geolocations are presumably then cached by the client, which no longer needs to request the locations of the nearby BSSIDs it may soon encounter, e.g., as the user walks down a city street.
It goes on later:
Apple’s WPS API is free and places few restrictions on its use. It requires neither an API key, authentication, nor an Apple device; our measurement software is written in Go and runs on Linux. Moreover, Apple appears to make no attempt to filter physically impossible queries. The BSSIDs submitted to the WPS need not be physically proximate to each other nor to the device submitting the query; Apple’s WPS will respond with geolocations for BSSIDs on two different continents in the same request to a querier on a third.
That's the discussion here. Apple keeps a large database, like many other big tech/mapping firms, but does nothing to keep that database hard for strangers to scrape in bulk.
In contrast, Google uses the first approach and keeps the information a bit more restricted by performing the location calculation at the server:
Han et al. reverse-engineered Google’s WPS’s method of operation [17]. Google’s WPS functions differently than Skyhook’s and Apple’s insofar as Google’s service attempts to geolocate the device submitting the query, providing it with only the device’s computed position given a list of BSSIDs from the client.
So it's possible to run this type of service with this type of database, without sharing BSSID locations with anyone else who asks.