Hacker News Reader

Comment by grigio | Hacker News Reader

Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux

Most computers have been like that, FOSS got lucky that IBM failed to secure the PC for themselves, thus the PC clones.

When folks say Intel and AMD are done, and we should all be on ARM, or RISC-V, beware of what to wish for.

Yes there are device trees now, however someone has to keep them up to date, and that is only part of what makes a motherboard.

Yeah the mainstream alternatives to x86 are all super locked down

I have said it for a while, Microsoft's business strategy was probably the best thing that ever happened to Free/Open software. They were ones pushing for more open systems so that they could sell DOS and Windows to other vendors. yes, it left the door open for others but they also figured they could push their software far harder than others could.

I agree with the ARM/RISCV stance that we should be cautious with what we ask. I have seen some RiscV providers in China are starting to push for a BIOS compatible boot system which is great to see, but there is no guarantee that it will be adopted or it will last for long.

This is also not guaranteed to be adopted widely, but the RISC-V Server Platform Specification was recently standardized with mandatory UEFI and ACPI support: https://github.com/riscv-non-isa/riscv-server-platform/relea... I'd rather have OpenFirmware like enterprise POWER, but anything is better than static device trees.

Other than this situation, what other landmines are there? I have an M1 with Asahi Arch Linux that I've been using as my primary laptop for the last 8 months, its my favorite laptop by far out of the 5ish I have.

does suspend and other hw fully works on it? however it is an old gen computer

The M1 is still perfectly fine.

Only M1 and M2 (and Pro versions).

Pretty much all ARM platforms are. Even ARM devices designed from the ground up to be Linux devices are full of issues, like the MNT Pocket Reform's lack of HW suspend. The tight interop between vendor and implementation is a huge anti-pattern for software freedom, and the standardization initiatives like ARM SR are nowhere to be seen. It's probably the most problematic part of ARM being the future of personal computing, yet another impending manifestation of enshittification.

what about the ones from CIX like the orangepi or their framework mainboard? (though I agree, I miss UEFI for all its faults)

i hope, but i dubt that will be mass produced.. so no economy of scale

Those are currently suffering from high power draw because they have to keep the cores awake for memory speeds. Lackluster performance as well, but thats the problem with the majority of the ARM ecosystem ever since apple started crafting SoCs.

I must have missed something...what does Apple creating M-series have to do with Allwinner, Qualcom, Mediatek, AWS, and the rest of the ARM ecosystem having 'lackluster performance'?

They showed what ARM could pull off, and no one has caught up since at least on a single core performance level.

Ah...it's "they haven't matched Apple" (not even Graviton?), not "Apple impeded them in some way". Fair, but that was not clear.

You do actually get UEFI on a few of these, though personally I've always fared better with U-Boot. (Sooner or later, I always run into something that is a simple edit in the device tree or uEnv, but UEFI doesn't expose.)

i run linux on both in arch and fedora versions with zero problems, by using the hypervisor framework of macos and wsl2 (wrapper for hyperv). do you need a more direct than hypervisor access to some hardware?

A lot of us would prefer MS/Apple to never be within touching range of our hardware.

On the other hand, your “us” is not very big compared to your “not us.” I like Linux as a server OS (and would pick it over Windows or MacOS for that any day of the week that ends in y), but as a desktop OS it’s just more work than I care to exert (in fact, Windows also exceeds my tolerance for fiddliness in a desktop OS). My general preference is for “you don’t have to” over “you can” as much as possible which is the exact opposite of the Linux desktop experience.

macOS and Windows are both such a chore for development, though. WSL was the closest I got to an "it just works" dev environment, but it exposes just how bad native toolchains like Cygwin and git bash are. macOS is hardly any better, and once you manage to install all of the GNU utilities it just feels like a poorly-supported Linux distro. It's a bunch of wasted effort to imitate a fraction of Linux's power.

So what are we supposed to use? ReactOS? SerenityOS? The entire mainstream is a "you have to..." OS, I fear the day when I have to abandon GNOME for a desktop that treats developers like chopped liver. Your general preference is fine, but I'm surprised that it aligns with the OEMs that want to put advertisements all over your desktop.

> it just feels like a poorly-supported Linux distro.

That's because it's Unix, not Linux.

macOS, as shipped, is only Unix-like. Even when configured to pass UNIX certification, it doesn't qualify without the temporary waivers:

  if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin, set the setuid bit on all of these binaries, add /usr/local/bin to your PATH before /usr/bin and /usr/sbin, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers. [1]

Maybe your installation of macOS is technically Unix, but mine sure as hell ain't. Desktop "Unix" in 2026 is little more than lipstick on a pig anyhow.

[1] https://www.osnews.com/story/141633/apples-macos-unix-certif...

As an aside:

> ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ...

This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local.

It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.

Oh, that makes more sense. I'm still not sure why you couldn't give the binaries setuid in their default locations, given that compliance testing also requires SIP to be disabled - but, in any case, at least they aren't setuid by default.

Anyways, "real UNIX systems must implement UUCP" is still extremely silly.

Disabling SIP still leaves the root filesystem as read-only and signature-checked (this is referred to as SSV, 'signed system volume'). There is a separate command to disable SSV, but it breaks the ability to install OS updates and is rarely used. /usr/local is one of the paths that's redirected to the read-write data volume.

I get most of this, but spotlight doesn’t need to be disabled altogether. That is a requirement for the verification, not the actually running as unix.

> it doesn't qualify without the temporary waiver

The nature of temporary waivers makes this untrue per the post you cited - The Open Group only grants them for 12 months, and the post is over a year old.

IMO, the only significant call-out is APFS case insensitivity by default, which makes the default volume a non-conforming filesystem. However, UNIX certification does not forbid you from mounting non-conforming filesystems (such as FAT32). Instead, this means the majority of software which makes certain assumptions about being used with UNIX conforming filesystems in addition to running on a UNIX conforming operating system are at risk of breaking.

Let's just say I have my doubts the author would have written a similar post if the final HP-UX release had "lied" about their certification by shipping with root login disabled by default and ulimit -c defaulting to zero.

I don’t use Windows so I don’t have advertisements on my desktop. I have had very little friction with using MacOS for development.

Then maybe a "lot of" you should not be buying Apple hardware?

Or Apple could just fix these issues.

what issues are you referencing?

Reply on news.ycombinator.com