@sgage I apologize if this sounded insulting to you - this was absolutely not my intention. I am aware that Devuan had (and has) good reasons to run and maintain its own infrastructure. The term "actual work" was directed towards work for systemd removal/init diversity and was meant in contrast to the infrastructure work. Yet, I never questioned that any of these was time-consuming. On the contrary, I rather wanted to express that I wished we could save some effort on the latter and direct it to the former category.

That's really great news and I highly appreciate the efforts and the collaboration that seems to enable running Debian with (at least) sysvinit again - though I have to admit that I didn't try this yet.

Assuming it becomes feasible to use Debian without systemd, I don't think it makes sense to use Devuan just for the mentioned political or "trust" reasons - at least not for me. Actually, by using Devuan you have to trust Debian as well as Devuan is pulling most binary packages from Debian - doesn't it?

If things really turn out for the better in Debian, wouldn't it become more practical to reduce Devuan to "just" a pure Debian-blend with alternative inits preconfigured and systemd-depdendent packages blacklisted?

Please don't get me wrong. I love Devuan and this community. Yet, I wonder if all the effort spent in running and maintaining an own infrastructure could not be better put into the actual work needed for init diversity? With this being said, I have to admit that the wounds from the community split will certainly not heal overnight. But as an end-user who wants to run Debian without systemd, I hope we are getting back on track.

I also highly recommend using partition labels over UUIDs. You can find a detailed example how they can be used in my generic aarch64 tutorial here:

https://www.kulesz.me/post/140-debian-d … 4-install/

The keyboard issue might be related to this (I think the u-boot shipped by Debian is still affected?):

https://lists.denx.de/pipermail/u-boot/ … 00162.html

Well, tbh I have the pinebook pro because it was the first kinda-powerful and kinda-freedom-friendly arm64 laptop that was available. Opinions about it vary, and personally I prefer old Thinkpads over it (especially due to their much better input devices - keyboard, trackpoint). Yet, the PBP is a really interesting device with a pretty decent screen and long battery life.

I am pretty sure bullseye will have quite a good ootb experience on it, however, I really dislike that the regular installer does not support installing to f2fs filesystems so I will probably continue doing installs in the fashion described in the article. However, having a stable (packaged) kernel and packaged bootloader will be definitely an improvement over the current situation.

Hi,

afaik this is a cubietruck-specific issue. Try the following in u-boot:

setenv bootargs console=tty1 fb=false
saveenv 
boot

Btw.: Welcome to the forums!

I assume it should also work from the backports repo. However, I don't see much sense in using the backport kernel as it (afaik) does not get regular security updates and 5.9 is EOL in upstream already. However, the packages in Debian unstable (5.10 currently or very likely also 5.9 in backports) do *not* work as the kernel is compiled with said configuration parameter that prevents the display from working.

Regarding the blobs: Okay, this was new to me. I always thought Debian included the upstream kernel from kernel,org without deblobbing it. However, it seems like Debian indeed deblobs it. Therefore, it would be proabably better to use the sources from the kernel package in Debian instead of pulling the kernel directly off kernel.org.

Well, not all software is optimized for multiprocessing loads. I used an x86 cpu with cores but very slow per-core performance (AMD Opteron) and processing larger TEX documents on it was no fun at all. So in the end it really depends on what you use your box for. In general, I think the MNT Reform should be up to most everyday tasks and its batteries should last much longer than on a X200.

Apart from blobs, my main concern with the Pinebook Pro is the keyboard and (especially) touchpad when compared to the Lenovo machines that shine here. This tought me that the general ergonomics should be taken into account very seriously. I really hope the MNT Reform can get much closer here than the Pinebook Pro did. But please don't get me wrong - the Pinebook Pro isn't worse than many "consumer" laptops here, I am just used the Thinkpad experience and that's what I miss there.

Regarding RISC-V: Yes, the port is not officially supported but most packages seem to build fine. I tried to find information on whether or not risc-v support is planned for Debian bullseye but was unable to find any info on that. So I guess the actual problem with risc-v in production on Debian is simply getting packages and timely security updates...

Hi,

I have both a pinebook pro as well as several core2duo Lenovo Thinkpads (such as X200) and also considered getting an MNT Reform. Overall, I think that the MNT Reform is a great project and I hope they will be able to reuse most stuff (such as the case) for a future model with a different PCB. In particular, I am hoping for RISC-V using one of the SiFive cores that are already almost available for Mini-ITX desktops:

https://www.crowdsupply.com/sifive/hifive-unmatched

When considering ARM64, both the rk3399 and NXP's LS1088A might be an option. The LS1088A is used in this box which I find interesting as well:

https://www.crowdsupply.com/traverse-technologies/ten64

However, the rk3399 has the issue that it needs a blob for DDR4 training, but this afaik applies to the current MNT Reform as well. Future Rockchip SoCs might be interesting as well, but if you consider that the pinebook pro still does not run an official version of Debian or Devuan shows that new SoCs really need some time for being supported well enough without tons of unofficial patches.

When comparing performance, I found geekbench.com to be an interesting option as it supports multiple architectures. So, if you want to compare the a typical Core2Duo P8600 with the RK3399 the data looks roughly like this:

P8600: 250 (single), 500 (multi)
RK3399: 250 (single), 700 (multi)
iMX8MQ: (unfortunately not benchmarked)

So YES, the rk3399 is almost as fast as an P8600. BTW: The fastest libre x86 option from the core2duo generation is a quadcore CPU in a T400 or T500 (requires some modding):

Q9000: 300 (single), 1000 (mutli)

However, if you consider running a "me cleaned" X230 with an i7 CPU as a viable option as well you will notice that the X230 is still waaay faster (not talking about quadcore i7 in a W530):

i7-3620M: 650 (single), 1500 (multi)

Overall, I am pretty optimistic that we will see some very interesting new options in 2021 and 2022 both based on ARM64 and RISC-V. Regarding PPC64LE (POWER9, POWER10), I am not that optimistic, at least for mobile.

Hi, I appreciate your effort but I doubt that building hardcoded kernels is the proper way to go. The "universal" Debian/Devuan kernel supports at least some of the mentioned boards quite well. Newer boards might run better with newer kernels from unstable.

I mean, if you want to provide such kernels you should build a repository where you package, test and update these kernels as well. Since this is probably too much effort, it might be better to simply use the packaged and SoC-optimized kernels from Armbian as they receive updates regularly.

Meanwhile, I worked around this issue. It seems that the cryptroot-unlock script does not work on newer kernels (5.7+) from dropbear-initramfs when there is an external display available but not connected.