Thanks for the detailed writeup. Seems like the machine still needs some more polish in the audio department.
Having a lot of low-level options via ALSA sound interesting to me, actually. As someone who produces music on Linux, I prefer to give ALSA a good kicking until it works, rather than dealing with Pulseaudio’s latency issues.
Is it possible to record the internal stereo mix directly, ie. can you select it as a recording source without resorting to jackd trickery?
To be honest, “you have to use ALSA instead of pulse to get audio to play reliable” is not a pinebook-specific problem; both my thinkpads are the same way.
And I have the opposite experience with both my thinkpads. Audio ‘just works’ with pulseaudio, including multisource concurrent playback, auto-switching from internal mic/speaker to external headset on plug in, bluetooth headsets, etc. None of that works out of the box with alsa on those systems.
Agreed, wasn’t trying to suggest otherwise. That said, “reliable” maybe isn’t the right word. Pulseaudio works fine for just listening to music or watching video, and is usually much less of a hassle to set up. When latency matters however (music production, emulation), ALSA performs much better in my experience.
Pulseaudio works fine for just listening to music or watching video
This has not been my experience. Of course every machine is different, but I used to have it cutting out constantly until I removed it entirely. Frequently plugging in my headset would reset the volume so that one ear was muted and the other wasn’t. Ever since uninstalling pulse, on my machines ALSA has been 100% reliable.
On my old black plastic MacBook (3,2) running Arch back in the day, PulseAudio was what made Linux audio start to be nice. ALSA worked, but in an https://xkcd.com/963/ sort of way.
Charts like that having been making the rounds for ages and always feel they’re a bit disingenuous because most people don’t have half that stuff installed, and use even less of the stuff they do have installed.
For most people, it’s just PulseAudio → ALSA → Sound card. Some of the abstractions/libraries on top of that – such as SDL, gstreamer, etc. – add useful features like the ability to decode mp3 files and whatnot. In other words, it’s a lot less messy than that chart makes it seem.
(I do have plenty of gripes with the ALSA C API, which is … not very good, but that’s a different matter)
Indeed, these charts conflate the audio system with multimedia libraries (and in case of the first one, even multimedia applications like VLC). That said, I very much agree that the state of audio on Linux is not great. Sadly everybody seems to be betting their horses on Pulseaudio, which to me seems more like an attempt to cover up the mess rather than cleaning it up.
VLC is included because of one of the cursed parts in the chart - VLC can be used as a playback backend by phonon, which is an audio playback API that is mostly used by KDE software.
(I do have plenty of gripes with the ALSA C API, which is … not very good, but that’s a different matter)
Out of curiosity, do you have any references for what a good low-level audio API looks like? It’s something I’ve been wondering about for a while, since audio on Linux is so perennially bad, but while I’m decently familiar with the physics of audio I don’t know much about the low-level details. It seems like it should just be “bytes with the proper format go into buffer at a fixed rate”, which is something that GPU and network drivers have been solving forever…
Thanks. Judging from this output, it is not possible to record the internal mix out of the box. That’s somewhat disappointing. It’s not surprising considering this has been the norm for off-the-shelf laptops for several years now, but I would have expected an open hardware like the Pinebook Pro to fare better.
Just to satisfy my curiosity, why do you want to record the internal mix on the built in sound card? This is surely handy in some situations (when you want to record all your screen for example) but… personally for serious music stuff I’ve always used USB sound cards. Playback is probably okay on most decent laptops these days, but recording is something entirely different even on a super high end machine. So if I’d buy a Pinebook Pro I would expect an awfully noisy sound card even for playback (even if I wouldn’t really care).
There’s another clue: the issue with the speakers described in the article feels like a noise coming from a bad sound card or amplifier. Broken speakers don’t produce noise like that.
Compile rustc using all 6 cores at once – you’ll use up all your memory far before anything useful gets done.
You might want to look into zram/zswap, which basically allows you to fit more into memory by compressing data, at the cost of a little extra CPU usage. I don’t know how easy it is to set up on the default OS (I’m using NixOS on my Pinebook Pro, so it’s just a case of setting zramSwap.enable = true for me). Anecdotally, it makes a big difference: The cost of compressing data is not really noticeable, but the extra swap space is.
You also mention that you fitted an M.2 SSD. Assuming a reasonably speedy drive, a decent sized swap file will help with large compiles.
I’m planning to put NixOS on my PineBook Pro when it shows up. Would love to see a post on your config + experience deploying NixOS on Pine64. My initial research suggests I’ll be compiling a lot of stuff.
My initial research suggests I’ll be compiling a lot of stuff.
Mostly just the kernel I think, as there are still a few bits missing from the mainline kernel (looks like the device tree is making its way in, but has just missed 5.7 (?)). I also had to package the firmware blobs for the wifi/bt chip, but I’ll need to double check if that’s still necessary. As long as you choose a fairly recent channel (20.03 or unstable), most other packages are sufficiently up to date, so you can just get them from the main binary cache. Generally speaking, most things are working well; graphics acceleration just works, accelerated video playback with mpv just works.
I will try to write a proper review of my experiences at some point.
What is the touchpad? i2c-hid generic multitouch, I hope? What’s touchpad related in dmesg? What does libinput list-devices say about it?
I didn’t like sway at first. I’ve used keyboard-heavy WM’s in the past and always eventually gave up on them
Check out Wayfire — it’s based on the same library as sway (wlroots) but is much more flexible. Tiling is an optional plugin, by default it’s a normal stacking desktop — with wobbly windows :) which are also a plugin of course.
Run Firefox half-decently
Which graphics backend are you using in Firefox? Software, legacy GL or WebRender? (about:support to check, MOZ_WEBRENDER=1 to try WR, about:configlayers.acceleration.force-enable to try GL) Also, I hope you’re running native (MOZ_ENABLE_WAYLAND=1) not xwayland?
What is the touchpad? i2c-hid generic multitouch, I hope? What’s touchpad related in dmesg? What does libinput list-devices say about it?
[ 3.339108] hid-generic 0003:258A:001E.0001: input,hidraw0: USB HID v1.10 Keyboard [HAILUCK CO.,LTD USB KEYBOARD] on usb-fe3a0000.usb-1/input0
[ 3.361825] input: HAILUCK CO.,LTD USB KEYBOARD Mouse as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input1
[ 3.363213] input: HAILUCK CO.,LTD USB KEYBOARD Touchpad as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input2
[ 3.364559] input: HAILUCK CO.,LTD USB KEYBOARD System Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input3
[ 3.429245] input: HAILUCK CO.,LTD USB KEYBOARD Consumer Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input4
[ 3.430852] input: HAILUCK CO.,LTD USB KEYBOARD Wireless Radio Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input5
[ 3.432646] hid-generic 0003:258A:001E.0002: input,hiddev96,hidraw1: USB HID v1.10 Mouse [HAILUCK CO.,LTD USB KEYBOARD] on usb-fe3a0000.usb-1/input1
So it looks like I was wrong about the keyboard not being USB, in fact. Looks like there’s a USB HID controller with inputs for several devices (some of which don’t exist). Thank you for the tip on libinput list-devices; that’s a great tool! Here’s what it has to say about the touchpad:
[ 3.048761] usb 2-1.2: new high-speed USB device number 3 using ehci-platform
[ 3.149294] usb 2-1.2: New USB device found, idVendor=0c45, idProduct=6321, bcdDevice= 0.00
[ 3.150050] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 3.150697] usb 2-1.2: Product: USB Camera
[ 3.151063] usb 2-1.2: Manufacturer: Sonix Technology Co., Ltd.
It’s then followed by a USB disconnect message for that device, so I expect you just have to do something specific to turn it on.
Which graphics backend are you using in Firefox? Software, legacy GL or WebRender? (about:support to check, MOZ_WEBRENDER=1 to try WR, about:config layers.acceleration.force-enable to try GL)
Whatever the default is on Firefox 68.8.0esr. In about:config it does say HW_COMPOSITING: blocked by env: Acceleration blocked by platform so I expect it’s either software, or legacy GL with some features turned off. Attempting to force acceleration in about:configlayers.acceleration.force-enable results in the same message for that section. If it’s worth anything, since I’m not ACTUALLY sure what I’m looking for, AzureCanvasBackend is set to skia.
Also, I hope you’re running native (MOZ_ENABLE_WAYLAND=1) not xwayland?
Annoyingly, when I use firefox MOZ_ENABLE_WAYLAND=1 I get this:
dbus[6672]: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file ../../../dbus/dbus-message.c line 1366.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Redirecting call to abort() to mozalloc_abort
I’d stumbled across that before, then forgotten about it. So I was using xwayland. Apparently it’s this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551664 Easy workaround is to run Firefox with MOZ_ENABLE_WAYLAND=1 firefox --no-remote . Now that I’m doing that performance seems… about the same really, but I’ll keep playing with it.
huh, I think some of the dev blog posts mentioned outdoing the proprietary driver in some places already? Maybe the GPU hardware is just weak.
That’s quite possible! Experience has just taught me to assume that if you have anemic GPU performance on Linux, the driver is the first bottleneck. I haven’t done any actual graphics benchmarks on it, mainly due to the annoyance with having to find/write interesting programs that don’t assume a newer version of OpenGL is available.
Can I have permission to reproduce this conversation as an appendix to the original article?
(If you want to have a real shit time, try to use a USB-C video camera (like an Intel Realsense, for example) next to a sensitive GPS receiver or long-range wifi. Not with the PBP, just with anything.)
What would happen? I don’t own a sensitive GPS receiver or long-range wifi :)
Unless you had very good quality USB hardware, they would get totally swamped by the radio interference radiating from the USB cable/connector. You know, the way that it’s theoretically not supposed to do to be able to pass US FCC regulations. I do wonder how long before it causes a problem for an airplane; it can certainly cause problems for a drone navigating by GPS.
When you plug a USB thing into the side of a laptop, the thing is perhaps 10cm away from the PCU and main memory, a drone overhead might be 10m up, and an airplane 10km up.
This means that the CPU and main memory (full of circuits only a few atoms wide) suffer interference that’s about 10000 times as strong as the drone and 10000000000 times a strong as the airplane, and they suffer that permanently. The airplane and drone move, the CPU is fixed, and the USB device must’ve been tested with at least a half-dozen current-day laptops.
CPUs really are amazing. They execute another instruction each time a photon moves 2cm, and contain electric conductors that are only tens of atoms wide. That’s a lot of sensitive parts and even very brief disturbances can last long enough to throw an instruction off the tracks. Testing that USB doesn’t bother such devices isn’t bad testing. Could be better I suppose, but it’s not bad.
I was referring to items in the aircraft or mounted on the aircraft, sorry that wasn’t clear.
Also the problem isn’t interference in the CPU, the problem is the antennas for the communication or GPS system.
Citation: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html . Also I’ve tried to fly a drone with a small computer and USB3 camera attached to it. USB2 camera? Fine. Other sensors that transfer their data over ethernet? Fine, even with gigabit ethernet and unshielded cables. USB3 camera? Drone’s GPS gets swamped with noise and it gets lost, even with expensive “shielded” cables. Can happen with wifi as well; you can find lots of people complaining about it if you search.
“My only real protest is that it often doesn’t suspend correctly; if you close the lid on it it’ll either hang and require a reboot, or sit there forever still on and sucking power. My XPS 15 used to do the same quite routinely, so I’m honestly not sure whether this is a hardware/driver problem or a Linux problem.”
I’m surprised nobody glommed onto this one. For a laptop, this seems like a big deal. I recall it being an issue on Linux over a decade ago but am surprised to hear that it hasn’t been fixed yet.
I recently started looking at a Raspberry Pi 4 hoping to run 9front on top; I wonder if this could run it? Then again, i can get the raspberry pi for much cheaper. 🤔
It’s not that much cheaper; $80 plus SSD, display, power, keyboard, chassis, etc. vs $200. Wouldn’t be the slightest bit surprised if once you added up all that the Pi ended up costing more.
While I somewhat agree, I’m looking at the 4GB desktop kit (sold on buyapi.ca for 169 CAD). It includes keyboard, mouse, SD card and a bunch of cables. I kinda have “the rest”, in one form or another. One of the reasons for my “9front” comment is that I intend to run it as my main driver, if at all possible. One of the things that I’d like to do is to have my main disk space “elsewhere”. I have external drives lying around, and probably could rip out an SSD from a computer around here if I wanted more storage. Moreover, confinement means I don’t move as much with a computer as I used to do, so technically, a desktop is fine.
I wanted to toy around with the fact that in a minimalist case the raspberry pi is extremely portable. Potentially, I could move from one place to another with only the Pi in tow. If I wanted to do stuff “on the run”, it would help to have an external screen, of course, and the “I can do things from everywhere” with my laptop is an affordance I might end up missing, but I also have a few laptops lying around. Old ones. I wonder if I can boot 9front on an old EEEPC I have here. Might try that first.
Potentially, I could move from one place to another with only the Pi in tow.
Theoretically this is possible, but the Pi is impractical to run off battery power in the way you describe. The Pine64-based systems all have onboard LiPoly support, (so the OS can be aware of the charge levels) and not only does the Pi have no such thing, all the external charging circuits I have been able to find either max out at 1A (the Pi3 takes 1.5A; the Pi4 even more) or do not support pass-thru charging. That means you can run the Pi off battery power, but you have to shut down the whole system to either charge the battery or move it over to another power source. This makes the Pi very impractical for portable computing.
Ah, yeah, that’s a bit crappy, although I don’t think 9front supports suspending, so I’d have to shut down to move around anyway, or not move far distances, and make sure to have pass-thru. I think the pinebook might be more expensive than it seems too; it sells for 200 USD, and I’m pretty sure I’d have to pay a nice fee at the border, I’d probably end up paying 300-some CAD. 😑
If you want to go the DIY route for something battery-powered, you can just swap out the Pi with a Pine64 SOC; I had a lot of success doing that here: https://atreus.technomancy.us/markv
Thanks for the detailed writeup. Seems like the machine still needs some more polish in the audio department. Having a lot of low-level options via ALSA sound interesting to me, actually. As someone who produces music on Linux, I prefer to give ALSA a good kicking until it works, rather than dealing with Pulseaudio’s latency issues. Is it possible to record the internal stereo mix directly, ie. can you select it as a recording source without resorting to jackd trickery?
To be honest, “you have to use ALSA instead of pulse to get audio to play reliable” is not a pinebook-specific problem; both my thinkpads are the same way.
And I have the opposite experience with both my thinkpads. Audio ‘just works’ with pulseaudio, including multisource concurrent playback, auto-switching from internal mic/speaker to external headset on plug in, bluetooth headsets, etc. None of that works out of the box with alsa on those systems.
Agreed, wasn’t trying to suggest otherwise. That said, “reliable” maybe isn’t the right word. Pulseaudio works fine for just listening to music or watching video, and is usually much less of a hassle to set up. When latency matters however (music production, emulation), ALSA performs much better in my experience.
This has not been my experience. Of course every machine is different, but I used to have it cutting out constantly until I removed it entirely. Frequently plugging in my headset would reset the volume so that one ear was muted and the other wasn’t. Ever since uninstalling pulse, on my machines ALSA has been 100% reliable.
I haven’t had problems with pa since switching to Arch from Fedora. I think the experience varies a lot based on what distro you use.
On my old black plastic MacBook (3,2) running Arch back in the day, PulseAudio was what made Linux audio start to be nice. ALSA worked, but in an https://xkcd.com/963/ sort of way.
Linux ecosystem in general needs cleanup in audio department
Charts like that having been making the rounds for ages and always feel they’re a bit disingenuous because most people don’t have half that stuff installed, and use even less of the stuff they do have installed.
For most people, it’s just PulseAudio → ALSA → Sound card. Some of the abstractions/libraries on top of that – such as SDL, gstreamer, etc. – add useful features like the ability to decode mp3 files and whatnot. In other words, it’s a lot less messy than that chart makes it seem.
(I do have plenty of gripes with the ALSA C API, which is … not very good, but that’s a different matter)
Indeed, these charts conflate the audio system with multimedia libraries (and in case of the first one, even multimedia applications like VLC). That said, I very much agree that the state of audio on Linux is not great. Sadly everybody seems to be betting their horses on Pulseaudio, which to me seems more like an attempt to cover up the mess rather than cleaning it up.
VLC is included because of one of the cursed parts in the chart - VLC can be used as a playback backend by phonon, which is an audio playback API that is mostly used by KDE software.
Out of curiosity, do you have any references for what a good low-level audio API looks like? It’s something I’ve been wondering about for a while, since audio on Linux is so perennially bad, but while I’m decently familiar with the physics of audio I don’t know much about the low-level details. It seems like it should just be “bytes with the proper format go into buffer at a fixed rate”, which is something that GPU and network drivers have been solving forever…
It’s not perfect, but in contrast to Linux, I’ve never had audio issues under FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=sound&sektion=4
Thanks, I’ll take a look at it!
Coming in late, but sndio is also worth a look(default sound under OpenBSD)
I have no idea, but if you can give me some pointers on how to find out I can try. If it’s worth anything, the full dump from the
alsa-infoscript is here: http://alsa-project.org/db/?f=5363202956bb52364b8f209683f813c662079d84Thanks. Judging from this output, it is not possible to record the internal mix out of the box. That’s somewhat disappointing. It’s not surprising considering this has been the norm for off-the-shelf laptops for several years now, but I would have expected an open hardware like the Pinebook Pro to fare better.
Just to satisfy my curiosity, why do you want to record the internal mix on the built in sound card? This is surely handy in some situations (when you want to record all your screen for example) but… personally for serious music stuff I’ve always used USB sound cards. Playback is probably okay on most decent laptops these days, but recording is something entirely different even on a super high end machine. So if I’d buy a Pinebook Pro I would expect an awfully noisy sound card even for playback (even if I wouldn’t really care).
There’s another clue: the issue with the speakers described in the article feels like a noise coming from a bad sound card or amplifier. Broken speakers don’t produce noise like that.
You might want to look into zram/zswap, which basically allows you to fit more into memory by compressing data, at the cost of a little extra CPU usage. I don’t know how easy it is to set up on the default OS (I’m using NixOS on my Pinebook Pro, so it’s just a case of setting
zramSwap.enable = truefor me). Anecdotally, it makes a big difference: The cost of compressing data is not really noticeable, but the extra swap space is.You also mention that you fitted an M.2 SSD. Assuming a reasonably speedy drive, a decent sized swap file will help with large compiles.
I’m planning to put NixOS on my PineBook Pro when it shows up. Would love to see a post on your config + experience deploying NixOS on Pine64. My initial research suggests I’ll be compiling a lot of stuff.
Mostly just the kernel I think, as there are still a few bits missing from the mainline kernel (looks like the device tree is making its way in, but has just missed 5.7 (?)). I also had to package the firmware blobs for the wifi/bt chip, but I’ll need to double check if that’s still necessary. As long as you choose a fairly recent channel (20.03 or unstable), most other packages are sufficiently up to date, so you can just get them from the main binary cache. Generally speaking, most things are working well; graphics acceleration just works, accelerated video playback with mpv just works.
I will try to write a proper review of my experiences at some point.
What is the touchpad? i2c-hid generic multitouch, I hope? What’s touchpad related in dmesg? What does
libinput list-devicessay about it?Check out Wayfire — it’s based on the same library as sway (wlroots) but is much more flexible. Tiling is an optional plugin, by default it’s a normal stacking desktop — with wobbly windows :) which are also a plugin of course.
Which graphics backend are you using in Firefox? Software, legacy GL
or WebRender? (about:supportto check,MOZ_WEBRENDER=1to try WR,about:configlayers.acceleration.force-enableto try GL) Also, I hope you’re running native (MOZ_ENABLE_WAYLAND=1) not xwayland?(UPD: WebRender doesn’t work on GLES2 yet it seems)
huh, I think some of the dev blog posts mentioned outdoing the proprietary driver in some places already?
Maybe the GPU hardware is just weak.
So it looks like I was wrong about the keyboard not being USB, in fact. Looks like there’s a USB HID controller with inputs for several devices (some of which don’t exist). Thank you for the tip on
libinput list-devices; that’s a great tool! Here’s what it has to say about the touchpad:Also for the webcam, since it was nearby:
It’s then followed by a USB disconnect message for that device, so I expect you just have to do something specific to turn it on.
Whatever the default is on Firefox 68.8.0esr. In
about:configit does sayHW_COMPOSITING: blocked by env: Acceleration blocked by platformso I expect it’s either software, or legacy GL with some features turned off. Attempting to force acceleration inabout:configlayers.acceleration.force-enableresults in the same message for that section. If it’s worth anything, since I’m not ACTUALLY sure what I’m looking for,AzureCanvasBackendis set toskia.Annoyingly, when I use firefox
MOZ_ENABLE_WAYLAND=1I get this:I’d stumbled across that before, then forgotten about it. So I was using xwayland. Apparently it’s this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551664 Easy workaround is to run Firefox with
MOZ_ENABLE_WAYLAND=1 firefox --no-remote. Now that I’m doing that performance seems… about the same really, but I’ll keep playing with it.That’s quite possible! Experience has just taught me to assume that if you have anemic GPU performance on Linux, the driver is the first bottleneck. I haven’t done any actual graphics benchmarks on it, mainly due to the annoyance with having to find/write interesting programs that don’t assume a newer version of OpenGL is available.
Can I have permission to reproduce this conversation as an appendix to the original article?
Huh, wow, USB, but still standard HID multitouch, nice.
That’s what you get for using old “stable” versions: “Firefox 68.8.0esr” — that’s 10 major versions behind Nightly (78.0a1) :P
huh. You did restart Firefox, right?
of course
What would happen? I don’t own a sensitive GPS receiver or long-range wifi :)
Unless you had very good quality USB hardware, they would get totally swamped by the radio interference radiating from the USB cable/connector. You know, the way that it’s theoretically not supposed to do to be able to pass US FCC regulations. I do wonder how long before it causes a problem for an airplane; it can certainly cause problems for a drone navigating by GPS.
When you plug a USB thing into the side of a laptop, the thing is perhaps 10cm away from the PCU and main memory, a drone overhead might be 10m up, and an airplane 10km up.
This means that the CPU and main memory (full of circuits only a few atoms wide) suffer interference that’s about 10000 times as strong as the drone and 10000000000 times a strong as the airplane, and they suffer that permanently. The airplane and drone move, the CPU is fixed, and the USB device must’ve been tested with at least a half-dozen current-day laptops.
CPUs really are amazing. They execute another instruction each time a photon moves 2cm, and contain electric conductors that are only tens of atoms wide. That’s a lot of sensitive parts and even very brief disturbances can last long enough to throw an instruction off the tracks. Testing that USB doesn’t bother such devices isn’t bad testing. Could be better I suppose, but it’s not bad.
I was referring to items in the aircraft or mounted on the aircraft, sorry that wasn’t clear.
Also the problem isn’t interference in the CPU, the problem is the antennas for the communication or GPS system.
Citation: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html . Also I’ve tried to fly a drone with a small computer and USB3 camera attached to it. USB2 camera? Fine. Other sensors that transfer their data over ethernet? Fine, even with gigabit ethernet and unshielded cables. USB3 camera? Drone’s GPS gets swamped with noise and it gets lost, even with expensive “shielded” cables. Can happen with wifi as well; you can find lots of people complaining about it if you search.
At what distance?
“My only real protest is that it often doesn’t suspend correctly; if you close the lid on it it’ll either hang and require a reboot, or sit there forever still on and sucking power. My XPS 15 used to do the same quite routinely, so I’m honestly not sure whether this is a hardware/driver problem or a Linux problem.”
I’m surprised nobody glommed onto this one. For a laptop, this seems like a big deal. I recall it being an issue on Linux over a decade ago but am surprised to hear that it hasn’t been fixed yet.
I recently started looking at a Raspberry Pi 4 hoping to run 9front on top; I wonder if this could run it? Then again, i can get the raspberry pi for much cheaper. 🤔
It’s not that much cheaper; $80 plus SSD, display, power, keyboard, chassis, etc. vs $200. Wouldn’t be the slightest bit surprised if once you added up all that the Pi ended up costing more.
While I somewhat agree, I’m looking at the 4GB desktop kit (sold on buyapi.ca for 169 CAD). It includes keyboard, mouse, SD card and a bunch of cables. I kinda have “the rest”, in one form or another. One of the reasons for my “9front” comment is that I intend to run it as my main driver, if at all possible. One of the things that I’d like to do is to have my main disk space “elsewhere”. I have external drives lying around, and probably could rip out an SSD from a computer around here if I wanted more storage. Moreover, confinement means I don’t move as much with a computer as I used to do, so technically, a desktop is fine.
I wanted to toy around with the fact that in a minimalist case the raspberry pi is extremely portable. Potentially, I could move from one place to another with only the Pi in tow. If I wanted to do stuff “on the run”, it would help to have an external screen, of course, and the “I can do things from everywhere” with my laptop is an affordance I might end up missing, but I also have a few laptops lying around. Old ones. I wonder if I can boot 9front on an old EEEPC I have here. Might try that first.
Theoretically this is possible, but the Pi is impractical to run off battery power in the way you describe. The Pine64-based systems all have onboard LiPoly support, (so the OS can be aware of the charge levels) and not only does the Pi have no such thing, all the external charging circuits I have been able to find either max out at 1A (the Pi3 takes 1.5A; the Pi4 even more) or do not support pass-thru charging. That means you can run the Pi off battery power, but you have to shut down the whole system to either charge the battery or move it over to another power source. This makes the Pi very impractical for portable computing.
Ah, yeah, that’s a bit crappy, although I don’t think 9front supports suspending, so I’d have to shut down to move around anyway, or not move far distances, and make sure to have pass-thru. I think the pinebook might be more expensive than it seems too; it sells for 200 USD, and I’m pretty sure I’d have to pay a nice fee at the border, I’d probably end up paying 300-some CAD. 😑
If you want to go the DIY route for something battery-powered, you can just swap out the Pi with a Pine64 SOC; I had a lot of success doing that here: https://atreus.technomancy.us/markv
Thanks for the writeup! I’m still waiting on mine to ship so at least reading other people’s experience gives me something to do.
Great, and very detailed, review!