Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

1 Follower

About Foxlet

  • Title

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This might fit better on ChannelSuperFun, but acquiring a full-size water slide ($180,000) and other waterpark equipment off AliExpress... because economies of scale allow for that apparently. https://www.aliexpress.com/item/33022449706.html
  2. Ironically, with an LGA115x cooler (like the Intel Stock cooler). The die guard should protect against chipping the APU.
  3. Yep, I wonder if hardware accelerated encoding + XSHM wasn't enabled.
  4. If we limit ourselves to just running the kernel (XNU) and a simple userland, that's already possible to a degree with qemu-system-arm64. A RasPi with KVM support could speed up performance reasonably enough to be usable, and this is more likely the route you might see come up once Big Sur is publicly available. Doing the same on bare metal is slightly more difficult, since it depends on Apple's policies going forward. If they continue to publish source code releases on https://opensource.apple.com/, and these include the ARM64 targets and Platform Experts that Big Sir will add, th
  5. PCIe itself is pretty flexible, you could send messages over a serial line if one was up to the task. The problem is that Android itself doesn't really support mainline Mesa, it has its own version of the 3D libraries which may not necessarily support desktop GPUs. The best bet would be to run an ARM version of desktop Linux with mainline libraries, but that's going into custom ROM territory and probably outside LTT's scope. Also, the drivers your linked are for 32-bit legacy ARM devices, which won't work on 64-bit smartphones (most of them nowadays).
  6. I'm mostly fond of XNU and the Unix heritage of the system. It delivers the capabilities of power-user-friendly BSD with the integration of Cocoa in the UI. It's also the only other system with mainstream support for graphics applications (something that Linux still lacks currently). The other side is the challenge of running the OS on exotic hardware. I have a mixture of real Macs and Hackintoshes on AMD architectures, being able to use the OS across systems is great in most situations.
  7. MSRs haven't been an issue since XCPM debuted in the Mavericks kernel.
  8. Compatibility with macOS isn't down to generic brands, but more so the particular on-board hardware that exists in a motherboard. Networking, sound, and on-board I/O are all under consideration when picking a model. Outside of that, UEFI compatibility also matters, badly written firmwares will break the boot process from Clover -> XNU either due to memory fragmentation (KASLR fail) or driver issues.
  9. One could also build a custom ROM to allow any selection of applications on the system.
  10. You don't need any of that reasoning. Codesigning is verified when boot.efi is loaded, and again when boot.efi passes control to XNU. The boot device is irrelevant as long as it can pass the two conditions. UEFI will still be able to access all the other block devices attached to the system.
  11. It wouldn't be usable under Windows, as the feature needed for GPU acceleration (iommu passthrough) just doesn't work without KVM support. There's some experimental accelerator support for CPUs, so at best you'll have a slow experience.
  12. I have a mid-2009 MacBook Pro (on a Core2Duo), XNU can still work on Penryn+ processors to a degree, but I didn't involve any of dosdude's patchers (for various safety reasons).
  13. macOS-Simple-KVM now has support for macOS Catalina, by the way. Instructions to set it up are on the same page. https://github.com/foxlet/macOS-Simple-KVM/tree/catalina
  14. You don't need a dongle for Ethernet, plenty of boards use a chipset for which drivers exist natively.
  15. Assuming Android blobs can be found for graphics, yes, it would be a very good contender (although the touch-oriented interface might hinder it in that regard).