For the rsync -aivz root@... command to work, PermitRootLogin in /etc/ssh/sshd_config needs to be set to yes (not a recommended change!), followed by service sshd restart.
I installed it on my Raspberry Pi 4, but installing 10 packages with pkg install takes hours. The package extraction is very slow. Arch Linux ARM on the same SD card is orders of magnitude faster. Is there anything I can do to speed it up?
I don’t know the exact way to “fix” this, or if it’s actually possible, but this is most likely due to write caching. Basically on Linux what is considered written (so packages in this) might not actually be written yet, while on FreeBSD the pkg install (the package extraction) will block until everything is actually written to disk.
To verify this is the problem you can use sync after the package install on Linux and see how long it takes to complete. Then you compare the same thing.
That’s not going to be a valid comparison because running sync once after the entire process terminates is going to differ drastically from syncing after each write or each file, especially when interspersed with non-I/O activity during which time writes can complete in the background.
Does the audio device work with 64-bit FreeBSD yet? The original driver passed a pointer to the device and then read it back to find the state associated with the response[1] and, since this was a 4-byte response, didn’t work with a 64-bit kernel. This is the one thing keeping me from using FreeBSD on the Pi 3 I use for musicpd and spotifyd. Raspbian is awful: it drops off from the network, spotifyd isn’t in packages and so I need to install it separately, and systemd managed to make my system unbootable after an upgrade because it failed to mount something in fstab and refused to drop into single user mode.
[1] Aside: This is a terrible idea. The vast majority of BSODs in the early 2000s were caused by transient errors from devices that the drivers then interpreted as pointers (or used in pointer-arithmetic expressions) and dereferenced. Always assume data read from a device might be invalid!
For the
rsync -aivz root@...command to work,PermitRootLoginin/etc/ssh/sshd_configneeds to be set toyes(not a recommended change!), followed byservice sshd restart.I installed it on my Raspberry Pi 4, but installing 10 packages with
pkg installtakes hours. The package extraction is very slow. Arch Linux ARM on the same SD card is orders of magnitude faster. Is there anything I can do to speed it up?I don’t know the exact way to “fix” this, or if it’s actually possible, but this is most likely due to write caching. Basically on Linux what is considered written (so packages in this) might not actually be written yet, while on FreeBSD the
pkg install(the package extraction) will block until everything is actually written to disk.To verify this is the problem you can use
syncafter the package install on Linux and see how long it takes to complete. Then you compare the same thing.That’s not going to be a valid comparison because running sync once after the entire process terminates is going to differ drastically from syncing after each write or each file, especially when interspersed with non-I/O activity during which time writes can complete in the background.
True that. The goal here is not benchmarking though, but looking at the potential cause where this might give an indication.
I’ve found the old rpi models (particularly, the rpi2) to be more reliable. Netbsd runs well on these older models.
Does the audio device work with 64-bit FreeBSD yet? The original driver passed a pointer to the device and then read it back to find the state associated with the response[1] and, since this was a 4-byte response, didn’t work with a 64-bit kernel. This is the one thing keeping me from using FreeBSD on the Pi 3 I use for musicpd and spotifyd. Raspbian is awful: it drops off from the network, spotifyd isn’t in packages and so I need to install it separately, and systemd managed to make my system unbootable after an upgrade because it failed to mount something in fstab and refused to drop into single user mode.
[1] Aside: This is a terrible idea. The vast majority of BSODs in the early 2000s were caused by transient errors from devices that the drivers then interpreted as pointers (or used in pointer-arithmetic expressions) and dereferenced. Always assume data read from a device might be invalid!