PC Engines $150 APU2 (RIP) shipped with 4GB ECC RAM and AMD Embedded CPU. Since it was a headless device used mostly for 1GbE networking, the RAM was throttled and relatively impervious to Rowhammer.
QNAP has a $600 1U short-depth (11") 4x3.5 2xM.2 2x10GbE 2x2.5GbE 4-32GB DDR4 SODIMM Arm NAS that would benefit from OSS community attention. Based on a Marvell/Armada CN9130 SoC which supports ECC, has mainline Linux support, and public-but-non-upstream code for uboot [2]. With local serial console and a bit of effort, the QNAP OS can be replaced by Arm Debian/Devuan with ZFS. Rare combo of low power, small size, fast network, ECC memory and upstream-friendly Linux. QNAP also sell a 10GbE router based on the same SoC.
That shit contains an ARC core. Never heard of ARC? That's okay, most people haven't. It's an obscure niche architecture used for almost nothing except for ... drum roll ... the Intel Management Engine (up until 2019). Gee I wonder why that's in there.
Don't touch Marvell shit with a ten foot pole, it's blobs all the way down. They're just good at hiding it.
Marvell patches have been going to upstream u-boot for a subset of CN-9130 functionality. Some were rejected as unwanted SoC-unique features, but that code is still public and could be consolidated into a public git repo for evaluation. Support for core features was merged, e.g. this thread from 2020 to 2023, https://lore.kernel.org/u-boot/ddd355c2-344e-4fbd-ace9-29d10...
> the notorious will-never-be-open-source highly-radioactive "snps blob" .. ARC core
Thanks for highlighting snps+eula. While we all want blob-free hardware like the expensive Talos OpenPOWER, all modern CPUs from Intel (ME) and AMD (PSP, MS Pluton) have management cores and firmware blobs (Intel FSP, AMD Agesa). AMD has a public roadmap for open firmware with OpenSIL, but PSP code is not public. One mitigation is to keep the device offline.
> Marvell.. good at hiding it
While this obfuscation is undesirable, many Arm vendors don't even bother with a fig leaf of upstream support. Would you recommend any Arm SoCs that have ongoing upstream Linux and u-boot coverage/fixes? Ideally, the SoC would also have OSS code for TrustZone (TF-A) and support for ECC memory. RockChip RK-3588 looks promising, https://www.collabora.com/news-and-blog/blog/2024/02/21/almo...
While we all want blob-free hardware like the Talos Power9
... which is 100% blobless. Or the Cavium MIPS64 chips (100% blobless). Or if you want Arm64, the Rockchip RK3399 (100% blobless). You have plenty of choices.
One mitigation is to keep the device offline.
Here's an even better mitigation: don't buy junk like this chip.
Stop blobwashing junk hardware like this with deceptive misrepresentations.
I looked into running OpenBSD on ER3-Lite and was told that network routing performance was poor without a binary blob that ships in Ubiquiti router firmware. Cavium is owned by Marvell.
> if you want Arm64, the Rockchip RK3399 (100% blobless). You have plenty of choices.
The challenge is finding existing products that people can buy at retail. We're having this conversation in an HN thread about ECC. The only off-the-shelf Arm NAS (4xSATA, 2xM.2) that I've found with ECC + Debian is the QNAP above.
I will look for an RK3399 SBC that supports ECC memory, 4xSATA and at least one NVME slot, which could be installed into a 1U NAS chassis.
> Stop blobwashing junk hardware like this with deceptive misrepresentations.
ECC is a high priority requirement for an Arm NAS. Would be delighted to find a blobless Arm SBC with ECC support and enough I/O channels for use in a NAS. Otherise, ECC trumps blobs for an offline NAS use case in a 1U chassis, which can be physically secured in a rack against physical tampering.
> A leaker has claimed that Apple is working on a version of macOS exclusive for the M2 iPad Pro ... the exclusivity to M2 iPad Pro could be a marketing push. If the feature is only available on that iPad, more people would buy it.
Based on the M4 announcement, vMacOS could be exclusive to the 1TB/2TB iPad Pro with 16GB RAM that would be helpful for VMs.
You can block 17.0.0.0 at the router, opening up only the notification servers. CDNs are a bit harder, but can be done with dnsmasq allow/deny of wildcard domains. Apple has documentation on network traffic from their devices, https://support.apple.com/en-us/101555
iPad Pro 4:3 264ppi screen = unmatched vertical real estate for SSH CLI and text editing, especially with vertical split screen window management.
Years ago there were 4:3 Thinkpads. Then OEMs moved to 16:9 aspect ratios for video content, some claiming that the economics were no longer viable for 4:3 displays. Yet Apple continues to ship millions of 4:3 screens for iPads.
I’ll have to play more with it for the other things. I haven’t invested much time in troubleshooting, since it seemed like that’s the way iPads just are now. Hopefully that’s not actually true.
When I looked at the top battery consumers in the past there wasn’t anything that stood out. I think home screen was at the top. It wasn’t one or two apps killing it with background activity.
Since the biggest battery consumption associated with home screen is the display, and users are only briefly on the home screen, before using it to navigate elsewhere, home screen should be near the bottom (1%) of power consumption.
speaking of which, whatever happened to qualcomm's bizarre assertion that ARM was pulling a sneak move in all its new licensing deals to outlaw third-party IP entirely and force ARM-IP-only?
there was one quiet "we haven't got anything like that in the contract we're signing with ARM" from someone else, and then radio silence. And you'd really think that would be major news, because it's massively impactful on pretty much everyone, since one of the major use-cases of ARM is as a base SOC to bolt your custom proprietary accelerators onto...
seemed like obvious bullshit at the time from a company trying to "publicly renegotiate" a licensing agreement they probably broke...
I presume the sequence of events was: some developer at Apple thought it would be a great idea to port hypervisor support to iPad and their manager approves it. It gets all the way into the OS, then an exec gets wind of it and orders its removal because it allows users to subvert the App Store and Apple Rent. I doubt it’s ever coming back.
This is everything wrong with the iPad Pro in a nutshell. Fantastic hardware ruined by greed.
EU and US regulators are slowly eroding that service monopoly.
> Fantastic hardware
Hopefully Apple leadership stops shackling their hardware under the ho-hum service bus.
It's been rumored for years that a touch-optimized version of macOS has been in development for use in iOS VMs. With the launch of M4 1TB 16GB iPad Pros for $2K (the price of two MacBook Airs), Apple can sell developers the freedom to carry one device instead of two, without loss of revenue, https://news.ycombinator.com/item?id=40287922
I bet that touch-optimized macOS will never see the light of day, or if it does it will be insanely crippled. Too much of an existential threat to Apple’s stock price.
Apple is in the midst of a cold war with regulators now. Every new feature will be scrutinized to check that it offers no threat to their golden goose if regulators force them to open it up. Allowing one type of VM means that regulators could force them to allow any type of VM.
Apple currently has 5 major build trains: macOS, iOS, watchOS, tvOS (which also runs HomePod), and visionOS. Huge amounts of the code are already the same between them: they literally just build the same stuff with different build settings… except for the UI. The UI has actually unique stuff in each train.
This has become more true over time… teams are likely sick of not having certain dependencies on certain trains, so they’re becoming more identical at the foundation/framework level every release.
Saying they’ll make a macOS with a touch UI is like saying Honda is finally going to make a motorcycle with four wheels and a full car frame. The UI is the differentiating factor in the OS’s. Everything else has already converged or is rapidly doing so.
If the goal is to support macOS apps on iOS then there’s a dilemma: how do you suddenly make apps that are designed from the ground up for a mouse, good for touch? The answer is you don’t: you just make the rest of the system identical (make the same APIs available everywhere) and ask developers to make the UI parts different.
I could almost believe that they’d make a macOS VM available for use with a keyboard and mouse within iOS. But to me it’d make more sense to do a sort of reverse version of how iOS apps are supported on macOS… where macOS apps are run natively on the iPad, but rendered with the iPad’s window management (modulo whatever multitasking features they still need to implement to make this seamless) and strictly require a keyboard and mouse to be in this mode. There’s just no reason to make a VM if you’re doing this: you can just run the binary directly. The kernel is the same, the required frameworks are the same. No VM is needed.
VMs are needed by professional developers who want to run CLI tools and services (e.g. web server, database) without the security restrictions of iOS, while retaining the OS integrity of the iPad Pro device.
Even if a macOS VM had only a CLI terminal and a few core apps made by Apple, using a Swift UI framework that was compatible with a touch interface, it would be a huge step forward for iPad owners who are currently limited to slow and power-expensive emulation (iSH, ashell). Apple could create a new app store or paid upgrade license entitlement for iOS-compatible macOS apps, so that users can pay ISVs for an app version with iOS touch input.
What you’re talking about sounds great but it’s not “a touch optimized version of macOS”. You’re describing a CLI environment in a sandbox.
Apple will never ever take macOS and change its UI to be optimized for touch. Or at least if they do, it’s time to sell the stock. They already have a touch UI, and it’s called iOS. They’re converging the two operating systems by making the underlying frameworks the same… the UI is literally the only thing they shouldn’t converge.
> Microsoft/HP/Dell/Lenovo Arm laptops with M3-competitive performance are launching soon, with mainline Linux support.
I have been seeking someone who’ll be willing to put money on such a claim. I’ll bet the other way. Perchance you’re the person I seek, if you truly believe this?
perf >= M3 while power consumption <= M3, while booted Linux and, say 50%: streaming a video on youtube.com over wifi at min brightness, 50% compiling some C project in a loop, minimum brightness from and to internal SSD.
At Qualcomm SoC launch, OSS Linux can't possibly compete with the deep pockets of optimized-shenanigan Windows "drivers" or vertically integrated macOS on Apple Silicon.
But the incumbent landscape of Arm laptops for Linux is so desolate, that it can only be improved by the arrival of multiple Arm devices from Tier 1 PC OEMs based on a single SoC family, with skeletal support in mainline Linux. In time, as with Asahi reverse engineering of Apple firmware interfaces, we can have mainline Linux support and multiple Linux distros on enterprise Arm laptops.
One risk for MS/Asus/HP/Dell/Lenovo devices based on Qualcomm Nuvia/Oryon/EliteX is that Qualcomm + Arm licensing fees could push device pricing into "premium" territory. The affordable Apple Macbook Air, including used M1 devices, will provide price and performance competition. If enterprises buy Nuvia laptops in volume, then Linux will have a used Arm laptop market in 2-3 years.
So.. your test case might be feasible after a year or two of Linux development and optimization. Until then, WSL2 on Windows 11 could be a fallback. For iPad Pro users desperate for portable Linux/BSD VM development with long battery life, Qualcomm-based Arm laptops bring much needed competition to Apple Silicon. If Nuvia devices can run multiple OSS operating systems, it's already a win for users, making possible the Apple-impossible. Ongoing performance improvements will be a bonus.
Since the hardware already exists and has been benchmarked privately, this is less of a bet and more of an information asymmetry. So let's assume you would win :) Next question is why - is it a limitation of the SoC, power regulators, motherboard design, OS integration, Arm licensing, Apple patents, ..?
QNAP has a $600 1U short-depth (11") 4x3.5 2xM.2 2x10GbE 2x2.5GbE 4-32GB DDR4 SODIMM Arm NAS that would benefit from OSS community attention. Based on a Marvell/Armada CN9130 SoC which supports ECC, has mainline Linux support, and public-but-non-upstream code for uboot [2]. With local serial console and a bit of effort, the QNAP OS can be replaced by Arm Debian/Devuan with ZFS. Rare combo of low power, small size, fast network, ECC memory and upstream-friendly Linux. QNAP also sell a 10GbE router based on the same SoC.
Ryzen Pro (OEM) can support ECC [3].
[1] https://www.qnap.com/en-us/product/ts-435xeu
[2] https://solidrun.atlassian.net/wiki/spaces/developer/pages/3...
[3] https://www.tomshardware.com/pc-components/cpus/amd-confirms...
reply