| ▲ | grigio 2 days ago |
| Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux |
|
| ▲ | pjmlp 4 hours ago | parent | next [-] |
| 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. |
|
| ▲ | KetoManx64 2 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | fg137 2 hours ago | parent | next [-] | | Only M1 and M2 (and Pro versions). | |
| ▲ | grigio 2 days ago | parent | prev [-] | | does suspend and other hw fully works on it? however it is an old gen computer | | |
|
|
| ▲ | ux266478 5 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | jjtheblunt 5 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | officeplant 4 hours ago | parent [-] | | A lot of us would prefer MS/Apple to never be within touching range of our hardware. | | |
| ▲ | dhosek 4 hours ago | parent | next [-] | | 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. | | |
| ▲ | bigyabai 3 hours ago | parent [-] | | 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. | | |
| ▲ | nomel 3 hours ago | parent [-] | | > it just feels like a poorly-supported Linux distro. That's because it's Unix, not Linux. | | |
| ▲ | bigyabai 2 hours ago | parent [-] | | 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... | | |
| ▲ | duskwuff 2 hours ago | parent | next [-] | | 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. | | |
| ▲ | wtallis an hour ago | parent [-] | | 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. |
| |
| ▲ | spockz 2 hours ago | parent | prev [-] | | 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. |
|
|
|
| |
| ▲ | happyopossum 3 hours ago | parent | prev [-] | | Then maybe a "lot of" you should not be buying Apple hardware? | | |
|
|
|
| ▲ | WorldPeas 2 days ago | parent | prev [-] |
| what about the ones from CIX like the orangepi or their framework mainboard? (though I agree, I miss UEFI for all its faults) |
| |
| ▲ | eqvinox 4 hours ago | parent | next [-] | | 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.) | |
| ▲ | officeplant 4 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | kjs3 39 minutes ago | parent [-] | | 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'? |
| |
| ▲ | grigio 2 days ago | parent | prev [-] | | i hope, but i dubt that will be mass produced.. so no economy of scale |
|
