I’ve been running Linux for 14 months now and loving it.
My laptop is a HP Victus gaming pc, which is bulky and heavy, but Its powerfull.
I find myself laying on the couch more and developing from there half the time or doing laptop stuff more and more from the couch.
Lugging it to work and back is also not great.
In October I can buy a new laptop through work and write off half the price against tax, honestly I want everything a mac book offers.
Good solid build quality, not plastic. No GPU needed, just light weight, long battery life, shouldn’t heat up too much, good trackpad etc.
But fuck apple and their walled garden, so I want something Linux.
ARM is perfect for this, but does Linux play nice with it? What are my options?
Or do I just go with x86 and compromise
You must log in or register to comment.
I use a MacBook M1 Air with Asahi Linux (using Fedora + Nix home-manager) for programming and web stuff and it works decently aside from a few missing features, although I hate the soldered storage and RAM. I might get a Framework or MNT laptop when it dies.
Grass is always greener. Have a framework and want to get an M1 or 2. Nothing wrong with framework just want to try arm.
ARM is perfect for this, but does Linux play nice with it?
to paraphrase the saying, “Millions of Raspberry Pi can’t be wrong”
With ARM Macbooks, you need to look into what models are specifically supported by Asahi Linux. It doesn’t seem to work on the newest models, at least not right away. This means either the CPU not being supported at all, or possibly missing drivers for some of the hardware.
The main question, where are the Snapdragon Laptops and is Linux support there?
ARM support highly depends on the device tree and drivers, as poorly it is often not standardised it seems.
An m2 Macbook would be the easy option, but soldered storage is horrible. Mac minis etc need a stupid adapter but then you can use NVMEs.
Ironically the best arm laptop for linux is a macbook. https://asahilinux.org/
Just to mention, a used or refurb M1 or M2. I don’t believe anything newer is supported, so save some cash IMO.
My pinebook Pro has been rocking it with fedora as its primary OS. The most issues it seems to have is with the wifi drivers after release updates. I’ve had good experiences with Debian/Armbian on SBCs too.
My only advice on getting an ARM device to run Linux is to check the wireless used in your desired device has good existing support. It’s a bit of a pain having to dig around for a no-fail dongle just to update drivers for the internal hardware.
The biggest issue I’ve had with my Pinebook Pro is getting any external display to work. I have bought multiple dongles and none of them are working. In fact, there are multiple smaller issues all different depending on the OS installed. I settled on Manjaro but wifi stops working after coming back from suspend, and it needs to be rebooted. The speakers are weak too.
And there’s software compatibility. Most of the software have ARM packages in multiple versions, but sometimes it doesn’t exists or can’t work. Like wine.
It’s not very polished and it requires knowing tech and Linux a good deal. It’s functional enough and could be useful for development, but I wouldn’t recommend it as an everyday laptop.
I tried to have it nearby and use it from time to time but I just end up getting back to my x86 laptop.
Manjaro had such a strong start on the pbps, but maaaaaan did it feel like it just went to trash towards the end. That’s why I switched to fedora on mine.
About the display out, I actually found that there was something about the port (iirc) where the display out only worked in one way. You could plug in a usbc cable, not get video out, unplug and flip it, plug it in, and you’ve got video out. Of course many distros broke it altogether somewhere during the kernel v5.xx.
I will say that during the times I ran Manjaro or Arch on it, I was pleasantly surprised how many things from the AUR I could get to build/run on just by asking yay to try!
I agree though, support and the device are not polished enough to immediately recommend for daily driving. But I also saw last night that there’s more distros advertising images for it. I may have to grab an SD and give them a whirl, see if things have improved. Regardless, it was a poc that definitely showed ARM could be a viable alternative to x64 in laptops
Is the wifi chip soldered? If not, you might be able to replace it with m.2/PCIe…
It is. Iirc when the m.2/pcie board for the pbp was released a lot of people did use for alternate wifi chips. I opted for a 2260 SSD. I may revisit the laptop and see if it’s hammered out now though
Lenovo x13s Gen1, as a light/mobile server with ubuntu/arch arm: nice
for media production (like music), not useful…
Gentoo supports ARM quite well (obviously), but I’m not sure what new hardware is out there that has an open enough firmware (or that can be flashed with coreboot) that will allow a Linux install.
I am a linux beginner: Why obviously?
Gentoo compiles everything. Like, even the command is like “compile world”. It’s not as straight edge as LinuxFromScratch and AFAIK they’ve started having precompiled packages sometime in the last few years but the core approach is that you configure compilation flags system-wide and recompile whatever needs recompilation every update
Yes, the source code gets compiled directly on the machine (or indirectly FOR the machine).
This, of course, assumes one can actually boot a kernel not developed specifically for the machine.
Some modern boot loaders / managers are locked (Asus does this a lot), so you’re stuck with whatever they put on the machine.
They’re locking down kernels now?
“They” probably are, I don’t know who “they” is but it’s definitely not Asus (at least not their upper-end stuff). Source: bought an Asus “gaming” laptop last year and installed Linux with no issues.
Edit: clarification on gaming laptop manufacturer (specified that it was Asus which I initially neglected to do in above comment)
I think the biggest question will be peripherals. Having a laptop where there are no drivers for its WiFi or similar can be tough. Otherwise I’ve been happy with my arch arm servers
Sometimes there might be no docker image for base image of your project. But you should be able to build it yourself
my pinebook pro has been bricked for at least 3 years now. still dead.
same w mine on the 3rd day i received it; i updated using cli and it no longer booted.
it won’t boot from SD? Or was it a bad spi flash?
it does nothing. might as well not be plugged in. at this point I don’t remember what killed it. maybe trying to transition to another os.
I get that, one of my pis is in that boat. I’ve been putting off making a boot disk for the distro and chrooting in to reinstall the system.
on the bright side, barring physical damage or an spi issue, you should be able to get it booting again. If it might’ve been an install issue, you could force SD boot, reinitialize the emmc, and reinstall. Those things were really good about not being able to fully brick easily.
I wish I could recommend Arch Linux Arm, but it’s really poorly maintained. Literally zero packages available for update for months on end. And no hope of improvement in sight.
My experience is mostly with Raspberry Pis. (I’m typing this on a Raspberry Pi in fact.) I still have a couple of Pis on Arch. And the one I’m on right now is running Raspian. I have plans to migrate them all to Gentoo some day, but I want to build a build server first and I’m currently deep in another project. I’ll get to it eventually.
Raspian is boring and maybe a little simplified and restricted. But it’s fine.
How’s software in arm devices? Could you generally compute and web browser? Documents, notes, basic apps?
Yeah, the ARM situation is pretty impressive now-a-days.
Again, I mostly know about Raspberry Pis (RPi 4’s specifically) and those are mostly pretty low-power/low-CPU-speed kind of devices. And so there are some limitations with regard to just how much “oomph” the Raspberry Pi has. Not because it’s an ARM device rather than an AMD64 device so much as because it’s really cheap (which is both a feature and a bug) and low-power. For example, last time I tried using Chromium, I found it nearly unusable for how slow it ran, but Firefox works great. (Though I do turn off things like smooth scrolling animations and such just to lower how much CPU it uses. It’s still “regular Firefox”, though. Not some “minimal” fork like Fennec or anything.) But again, that’s mostly because the Raspberry Pi is low power, not because it’s ARM. But the Raspberry Pi also has good 3d graphics support, so Luanti runs surprisingly well and very playably. I’m also kindof a terminal-or-die kind of guy, so not using heavy GUI apps isn’t much of a problem for me.
But as to the issues that are specific to the fact it’s ARM rather than AMD64, there are very few now-a-days. Binaries, for instance aren’t portable between ARM and AMD64, of course. Very few application just straight up don’t even run on ARM. (Cura is the only one that comes to mind, and it’s been a long time since I tried it, so that might have changed by now. Cura’s kindof a terrible piece of software, though. Good slicer, but the way they just don’t have any interest in making it cleanly/easily runnable on various systems makes it a huge pain to the point that some Linux distros (Gentoo, for instance) have given up supporting it even on AMD64.) I’ve never tried to run Wine on a Raspberry Pi, but it looks like there are options for doing so, and running x86 and AMD64 applications on it. But basically every feature of your browser (including streaming video and WebGL and stuff) works as expected (again, depending on how powerful your ARM device is). Aside from problems with Arch Linux Arm, whatever distro you settle on will have great support for the apps you’re used to using on AMD64. And you’ll have your choice of DE/WM the same as you do on AMD64. Etc.
Oh, I guess one more caveat I’ll mention. Some of the Raspberry Pi’s RPi-specific hardware tends to change a lot over time. The drivers update and there are new ways of doing things that don’t work quite the way they used to. The main places I’ve seen that happen are in the audio drivers (after one update, the audio didn’t work and I had to go down a bit of a rabbit hole to get that working again), the graphics drivers (a few years ago, they released FOSS graphics drivers for the RPi and that changed some of the options available and such, and the main symptom I’ve seen of that is that documentation may be out-of-date and apply only to the old way the graphics drivers work, so it’s definitely worth making sure you know roughly when changes have taken place and that you’re looking at documentation that applies to the latest), some of the miscellaneous boot parameters (on Raspberry Pis, there’s a
/boot/firmware/config.txtfile that has a bunch of boot-level kernel options), and GPIO pin access.Which leads me to something else I didn’t think of until just now. The bootloader, driver options, kernel options, and the installation process tend to work differently for ARM devices. With AMD64, you kindof expect UEFI (possibly with legacy BIOS support) to be the norm. With ARM that’s rarely if ever the case. I don’t know that secure boot is likely to be available for very may ARM devices. Disk encryption isn’t something I’ve gone to the trouble to figure out how you’d do. You don’t use Grub, you use U-Boot, or in cases like the Raspberry Pi, the bootloader is kindof hidden away from you except that as you install it and configure it, the kernel/config/driver files go in the right place on the SD card to make sure the bootloader can find them. And the installation process tends to be “stick an SD card into another computer, DD this disk image onto it, and stick it into the target ARM device”. Depending which distro you’re using, from there it might take you into an interactive installer kind of thing (like with Raspian) or it may be more low-level (like with Arch.) And if you follow the default installation instructions for your distro, you most likely end up with a little less control over things like the partition layout, whether you’re using LVM or BTRFS, etc. If you wanted root- or home-partition encryption, my guess is you might have to take an existing installation disk image, dissect it, and build a custom disk image with certain partitions encrypted out of the result before DD’ing it to the SD card. (Ok, I took a break here to check and see if there are guides on how to do full disk encryption on a Raspberry Pi and there are.)
(Side note. You may have to decide when installing a distro on an ARM machine whether you want the 32-bit ARM distro or the 64-bit ARM distro. If you want to run on an older ARM device that doesn’t support 64-bit ARM, you’ll have to go with the 32-bit ARM distro. If you want to run x86 Windows apps on Wine, it’s definitely recommended to use the 32-bit ARM distro. Otherwise, 64-bit is the way to go.)
Ok. Jeez. This ended up being a long post. That’s about all I can think to say at the moment.
I run a Pi400 every now and then… It’s not setting any speed records, and starts to lag out after 10 tabs, but it runs all day on an external phone battery. There’s the odd app that nobody bothered porting to ARM, but I have more trouble with Arm Windows than Arm Linux.
I had a pinebook 1080p, same exact experience. Fine, not fantastic, good battery life. It keeled over and died after a year though.
