mrpippy

The article says this one was on a pylon (with a spare engine on display on the ground below). Being owned by NASA is important, also being on a military base (the home of USAF test flight!) where it could be removed and easily wheeled into a large-enough hangar without anyone noticing for 5+ months.

Getting any of those planes outside of their museums would be logistically difficult, and of course it would immediately be noticed. And even if you can rent a hangar big enough, and secure it, then you're stuck at BFI/IAD/Wright-Patterson trying to do this impossible task.

Or (common in the US) handing your card to a restaurant waiter who walks off with it to do the charge

It works, but gives you zero help with dark mode or HiDPI (both are possible, it's just entirely on the developer)

This. The X1 Elite laptops came out 2+ years ago, but you still need to use a special Ubuntu remix to get everything* working, and support is very dependent on which laptop you bought. You could say it’s not Qualcomm’s job to make audio or the camera work on every Lenovo/Dell/HP, but someone needs to do it…

*: I’m sure there’s some features that still aren’t working right.

Completely predictable. They’ll likely dodge a lawsuit in this case (since the car that was hit was an unoccupied police car) but it will inevitably happen.

Gerbils! is a demo app for QuickDraw 3D where gerbils are racing on a roller coaster track (or similar…it’s been a few decades). It existed for classic Mac OS too (I remember playing it on a 6100)

> A potential concern is that when jumping between x86 emulation and ARM code, that the ARM code will pay unnecessary overhead due to all its accesses being TSO now. While this is a reasonable concern, the amount of ARM native code executing under emulation approaches 0%.

This may be true when FEX is executing as a usermode whole-process emulator on Linux, but it is not true when FEX is built for Windows(/Wine)'s ARM64EC mode. With ARM64EC a thread could be running a very small amount of emulated code while everything else is native.

I believe Microsoft Office is built as ARM64EC in order to support x86_64 plugins, in this case the entire suite itself (along with all the system DLLs) are native ARM64EC code and the only emulation would be for plugins. Kingdom Come Deliverance 2 has an ARM64EC build where the main game EXE is small and x86_64, but the actual game engine is in an ARM64EC DLL.

I don't know of a good solution for this though, enabling/disabling TSO needs a kernel syscall so is too slow to be doing constantly when entering/leaving emulation. With cases like KCD2 where the game itself is ARM64EC, maybe it could be faster to not use hardware TSO.

That’s possible (never underestimate the bad decision-making of phone makers), but what would they have done instead? Windows Mobile 6 was the only licensable alternative, but it was a known quantity and obviously a generation behind Android and iOS.

AFAIK they still aren't shipping an actual ARM64 version of Steam, making it difficult to actually use those (unsupported) ARM builds of Proton. That article is 5 months old.

Sonoma will be getting its last security update imminently (possibly tomorrow).

Yes, real apps use Mach messaging directly. i.e.: https://source.chromium.org/chromium/chromium/src/+/main:ipc...

The Mach APIs are available to userland applications, if you used a different kernel you’d have to implement them somehow

Especially since the Linux kernel dropping support usually happens years after distributions already have, so it would be quite difficult to run actual software on such hardware anyway. Whereas NetBSD is an entire OS.

Alan Coopersmith works at Oracle, on Solaris. I don't know of any effort to use Wayland on Solaris, so maintaining X really is their only option.

OTOH, RedHat seems happy to let X die.

There were Itanium workstations (https://www.openpa.net/systems/hp_i2000.html, https://www.openpa.net/systems/hp_zx2000.html), but of course these quickly crashed and burned with the rest of Itanium

Not to mention rendering the driver’s display (gauge cluster)

It’s rendering the driver’s display (i.e. the gauge cluster), the driver HUD, the central display, watching a driver-facing camera for fatigue alerting, handling Bluetooth, WiFi, navigation. Calling it an “infotainment” system is underselling a bit

That’s correct, Rosetta for running x86_64 binaries in Linux VMs is not going away. They’re no longer branding this feature as Rosetta, so it doesn’t get lumped in with the Rosetta removal for Mac binaries (although it’s all still kinda confusing)

https://developer.apple.com/documentation/Virtualization/run...

For some reason, the PS4 and PS5 actually cannot play audio CDs

These links show the pinout:

https://hardware.majix.org/computers/sgi/keyboards.shtml https://hardware.majix.org/computers/sgi.pi/keyboard.shtml

And the keyboard(7) man page actually has full details on the protocol (Indigo uses the mini DIN-6): https://github.com/jtsiomb/sgikbd/blob/master/doc/sgi_man7_k...

Also, SGI keyboards never used ADB. Indigo-era SGIs used a mini-DIN keyboard/mouse, but it was proprietary. They were PS/2 starting with the Indigo2 and Indy.

My memory from classic Mac OS is that pushing the keyboard soft-power key brought up a system-modal dialog asking if you wanted to shut down, restart, or cancel, a dialog with exactly the same design as: <http://www.christianboyce.com/page25/files/tipofthedayjulyth...>

That would obviously not be compatible with a server, maybe if soft power was just constantly held down starting from boot that dialog wouldn't show up?

The author discussed this a bit on Mastodon as well:

https://xoxo.zone/@numist/116716469017975106

At this point that would be a 2018 Mac mini, which can only run Sequoia (which will be out-of-support at the same time as Homebrew drops Intel support).

If you want Intel support, MacPorts still runs back to Leopard.

Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.

I would consider HFS+ to be a legacy filesystem at this point, something you shouldn't use without a really good reason (interop with pre-macOS 10.13 machines being the only one I can think of).

Fun fact: HFS dates back to the 80s, and so does the fsck code. https://github.com/apple-oss-distributions/hfs/blob/main/lib... still contains '#if BSD' blocks for the Mac OS X code, and classic Mac code in the '#else'.

And 'dfalib' refers to 'Disk First Aid', the classic Mac fsck application.

Note to the author: did you file an Apple feedback for this? You should put that FB number in your post and the GitHub repo, it will ease the process for any Apple employees who see this and want to get it fixed.

Right, that’s why you get a simpler yes/no dialog for notifications, and a conplex “navigate to this settings pane and click a separate button” flow for a keylogger

Those are still needed for the Rosetta use-cases that are sticking around (old games, Linux binaries)

I feel like that's true for early/mid-90s games where the PC version targeted DOS (+ the varied universe of PC video/sound hardware), and the Mac version could just target the much more uniform Mac platform.

But SimCity 3000 is from 1999, and the PC version was a normal Win9x game. I own (still have the CD) the SimCity 3000 Mac port, and it is not very good. Maxis didn't port it themselves, it was done by Software MacKiev. System requirements were quite high for the time, it was sluggish, often unstable, and the file open/save dialogs reused the Windows-style dialogs which was very awkward.

The soundtrack is great though.