gargravarr

MacOS has some very strange ideas on removing permissions. When you allow kexts in modern OS releases, the signature gets added to an SQLite database in /var/db (you have to consult this database to get the signatures if you want to whitelist kexts in an MDM). Now kexts are quite invasive, hence Apple's caution on allowing them in the first place.

What happens if you want to revoke a kext? Delete the entry from the SQLite DB? Nah. Guess what, SIP prevents any and all deletions from that DB. You have to disable SIP to revoke a kext's permissions. And because the signature is not a hash, but instead a two-part vendor/product, it's entirely possible for a malicious version of an existing kext to be released that is then permitted by the signature.

As an admin with security focus, this to me seems completely backwards. I get that Apple don't want to make the permitting operation to be too difficult in the first place, because these are end-users we're talking about, but the lengths they go to in order to prevent the permissions being revoked is downright strange.

64GB will cost you $800 now. When you need it, it may cost half that, or less. And Apple was notorious for underspec'ing the maximum amount of RAM a machine could take - it was common for a machine to take double the Apple official maximum because the DIMM densities increased with time. Since the integration of the memory controller into the CPU this is less of an issue, but the soldered RAM means you're limited to the amount that Apple is prepared to give you, which until this model has been far less than the CPU actually supports - the 15" i9 could be spec'd to 32GB, but the CPU could address 64GB.

Apple's attitude to upgrading is to replace the entire machine. It's both expensive and absurd. I bought a 2008 MBP back in uni in 2010. I later upgraded the RAM and disk when I could afford to, and when I had reached the limits of what it had. That machine served me well for 5 years. There's nothing else on the market today I'd trust to be a daily use machine for 5 years straight.

Even the XPS 13s are more serviceable than their rival MBP 13"s. The RAM may be soldered on both but the XPS uses a standard NVMe SSD. It's saved me a few times already.

Not just the risk of data loss, but the inconvenience of restoring the machine is much higher. This means the only solution to restoring a modern Mac notebook is to replace the entire logic board - everything else may be functional except the storage, which is a consumable by most considerations, but now the entire board must be swapped. And if it's out of warranty, which let's face it, it's extremely likely to be, then you are completely and utterly stuck. You either have an enormous bill from Apple or an authorised repair shop (and Apple is notoriously cagey about allowing third parties access to their replacement parts) or you have to hunt down a machine for spares to do the swap yourself, and now with Apple's invasive security measures requiring communication with Apple's diagnostic tools to perform certain swaps, storage failure can render the machine entirely useless for months, if not permanently. Whereas if the disk was replaceable, just order one from the most convenient store, swap it in, restore from Time Machine.

The Function Key MBPs have a problem with their flash storage where they may randomly and unpredictably die, taking all the data with them. The fix is a firmware update, which also takes all the data with it. Fantastic, Apple, we bought six of those machines, and because the users are actively, y'know, using the damned things, it's not really convenient to tell them they'll be without their machine for a week while the service centre gets around to it, and then multiple hours of restoring their Time Machine backups. On the plus side, the SSDs in those machines are not soldered. Yes, they're proprietary, but it's something - if those machines suffer failure, I could grab an SSD on eBay and get them running again. It's almost worth the risk.

Xbox One X.

Now with 40% more confusion.

Mostly bandwidth, reliability and interference robustness. The Wii U certainly proves it's possible, although that's streaming 1280x720. Displays at much higher resolutions require considerably higher bandwidth and are much more expensive as a result. Plus, if your screen is in one place, the source is likely to be there too, so why not just make it more reliable with a cable.

I wasn't aware of this kernel flag (nor am I surprised it exists), seems like it would be useful to the article's author. However, by default it's left enabled, which allows the kernel to automatically set up the environment based on what it can glean from the hardware. So my comment was in regards to the machine without intervention.

Linux provides /dev/random and /dev/urandom to all applications as well as relevant API calls, but the quality of those is always in doubt (especially with urandom, which recycles the entropy pool when it gets too low). CPU hardware PRNGs are supposed to be much higher quality, when they work. So it's all about depending on the CPU to actually do what it's advertising - the CPUID flag advertises a high-quality hardware RNG, but then the firmware bug completely nurfs it.

My understanding is that implementing a PRNG in software results in a very small entropy pool. At the OS level, it can collect entropy from a vast number of sources, including things that an application won't have access to, which is why the OS exposes the RNG to applications. It also means maintaining such a PRNG in your software. Basically, it's the same old dependency argument again - there is nothing inherently wrong with using the tools the environment provides for you rather than building your own, but it does mean that the tools have to work properly. This is especially critical for cryptographically-secure PRNGs - those are things you really do not want to be maintaining yourself if you can access a high-quality source of random data, but again, if the PRNG doesn't work, you're in deep trouble (see for example Yubico's broken PRNG chips on the Yubikey 4). Hardware PRNGs on the CPU itself were supposed to dramatically improve the state of random data provisioning, but when bugs like this hit, it shows the weakness of depending on the stack beneath.

By which time the next release comes out.

You can't win with Apple now.

Disk images don't work with Macs any more. Apple has forced us onto 'workflow-based' installations which are supposed to ensure firmware for all subsystems are installed as well, by running the OS installer every time. However, this is pretty time-consuming.

You really don't have 'complete control' of Macs any more. Apple do what they like with your hardware.

Well now, that's interesting. I include LibreOffice v5 with my standard install of Mojave. I ran a fresh install earlier this week just to test the upgrade, which worked. Only then did I try opening the applications. And LibreOffice v5 opened without a fuss. I read this article and tried downloading v6. Sure enough, I hit this exact issue. That's seriously inconsistent Apple. Thanks for the unnecessary grief.

No question that this idea would be pure hell on a cramped plane in cattle-class. There's even mention in the article that, yes, the plane can manage the flight, but even with a full fuel load they can't spare the weight of more passengers and cargo. It seems completely disconnected from the real world, which, okay, it's mostly science at this stage and looking at severe jet lag from such a long flight. The implication is that it's nowhere near ready for the masses and is a curiosity at best.

The most I've managed on a plane is a 12-hour flight from London to Hong Kong, and that's enough. Nobody will be able to afford beds on such a flight except the ultra-rich, and that's assuming you can sleep on planes at all (I can't). In an era where fossil fuel emissions are dangerously damaging the planet, this is also a strange time to unveil such a concept as we need to fly less. On the other hand, versus a a stopover flight, if you're flying this distance, doing it in one go is much more fuel-efficient as the plane spends far longer in the upper atmosphere reducing drag, and only burns take-off fuel once. But this isn't something that needs to be offered to the masses if there genuinely is a market for it.

Even if a 20-hour-long flight was completely harmless to both physical health and the environment, I cannot think of anything I would rather do less than sit in a tin can at 40,000 feet for that duration.

Agreed, I do and don't want to know what on earth Google was doing with /var that led to this situation in the first place...