One last thought. Since you mentioned heat, I found a comparison between your i7-3520M and the RK3588 at gadgetversus.com. If the TDP numbers are accurate, then the TDP is 35W vs 12W. Which means your lap or whatever body part you put your laptop on should definitely be less toasty. Also, other benchmark numbers at the end matches my conclusion - a little slower in single threaded performance, more performance with multithreaded workloads.

@zapper The Phenom II X6 1100T was released around 2010-2011, and that was the top of the line for the Phenom II series. The Piledriver series was released around 2012-2013. So assuming that the passmark scores are a reasonable estimate of performance, the 8-core RK3588 performs roughly the same as 2010-2013 desktop CPUs.

As for the current gen laptop CPUs, I've only looked at AMD laptop CPU scores on passmark, but maybe that will give you a little more helpful info.

These two are the oldest AMD CPUs based on the first generation Zen architecture that I could find.

  2200U | 2 cores / 4 threads | 3700 / 1679 | TDP 12–25 W | released: 2017-2018
  2300U | 4 cores / 4 threads | 5532 / 1746 | TDP 12–25 W | released: 2018
 
These are the lowest two models. So the 8-core RK3588 has roughly comparable performance to AMD's lowest end laptop CPUs from around 2018, 6 years ago.

You also mentioned the Intel N100. I was curious about it, and looked it up on passmark:

  N100 | 4 cores / 4 threads | 5557 / 1959 | TDP 6 W | released: 2023

The N100 TDP is only 6 watts, which means very low heat. That's still performs better than the RK3588, based on passmark's scores.

So hopefully, that gives you an idea on how the RK3588 roughly compares to a few laptop CPUs.

One more quick test result: I just discovered that in UEFI boot, I can change the keyword "linuxefi" to "linux". I ran a quick test on the mini PC (UEFI boot only), and all 4 memtest files run successfully with the "linux" keyword.

Since the legacy boot only lets me change the file path, there aren't any new tests to run.

So to summarize the current problem, in legacy boot, the current default "Memory Test" menu option will hang the PC.

Here are my test notes.

- The sha256 file is correct for the iso file.
- When I mount the iso to the file system, I see these 4 files in the /live directory:

    memtest86+ia32.bin memtest86+ia32.efi memtest86+x64.bin memtest86+x64.efi

- Legacy boot only test notes and results:

  - The default path for the Memory Test menu option is:

      /live/memtest86+x64.bin

  - /live/memtest86+x64.bin  -> The PC hangs.
  - /live/memtest86+x64.efi  -> Memtest works.
  - /live/memtest86+ia32.bin -> The PC hangs.
  - /live/memtest86+ia32.efi -> Memtest works.

- UEFI boot only test notes and results:

  - The default path for the Memory Test menu option is:

      /live/memtest86+x64.efi

  - /live/memtest86+x64.bin  -> Memtest works.
  - /live/memtest86+x64.efi  -> Memtest works.
  - /live/memtest86+ia32.bin -> The PC hangs.
  - /live/memtest86+ia32.efi -> The PC hangs.

- I tested on 3 difference PCs:

  - A 2010 PC, so it's legacy boot only.
  - A 2019 PC, which has both boot options.
  - A 2022 mini PC, which is UEFI boot only.

  The results are confirmed on multiple PCs.

I'm not experienced with legacy vs UEFI booting. But it seems strange to me that in legacy boot mode, both .bin files failed to run, but the .efi files worked. Also, in UEFI boot mode, both x64 files worked and both ia32 files failed to run, which also seems strange to me. Is this the expected results?

I don't know who fixed what, but the packages that got moved to local/obsolete appears normal again. Thanks to whoever it was.

Looks like /jessie/main/binary-amd64/Packages is supposed to say that apache2 version is "2.4.10-10+deb8u12". It's actually /jessie-security/main/binary-amd64/Packages that says apache2 version is "2.4.10-10+deb8u14". Something must have happened in jessie-security a month ago, but has been fixed within the past week.

All of my original problems have been resolved. I think the repackaging of policykit-1 fixed it. Please pass a thank-you to Centurion_Dan for updating policykit-1.

Oh I didn't know there were instructions for mirroring the Devuan repositories. I used the apt-mirror script, which had previously worked for mirroring Ubuntu 10.04 repositories, and has also been working for Devuan Jessie.

Yes, I'm using devuan jessie. I have only the MATE desktop installed, no XFCE or any other desktop.

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 1.0 (jessie)
Release:	1.0
Codename:	jessie

Based on what I've seen in the code, I don't think hardware matters. But in case it somehow does, it's a PC that I built a while back:

CPU: Athlon II X4 620e
Motherboard: Jetway NC84E-LF
RAM: 4 GB

I have no explanation why caja doesn't crash for you. From what I've seen in the code so far, caja must crash when in list view, if the split pane has been opened and closed, and you launch the File Management Preferences dialog.

- When you launch the File Management Preferences dialog, the code initializes the GUI in the "List Columns" tab.
- The act of initializing this GUI causes settings to be saved to "org.mate.caja.list-view". You can view these settings using dconf-editor.
- Whenever the settings for "org.mate.caja.list-view" are changed, each tab in the main pane or the split pane is called back, so the tab can add or remove columns or change the order to match the new settings.

- Caja creates a list view memory object for each tab that you open.
- When you close each tab, caja properly deletes the list view memory object from memory.
- But when you close the split pane, caja does NOT delete the list view memory object - it remains in memory!
- So when the "org.mate.caja.list-view" settings are changed, the list view memory object representing the closed split pane is still called back! Some of its data contents are now NULL, and when the code tries to use this NULL data, caja crashes.

If I can figure out why the split pane's list view memory object isn't properly deleted from memory when the split pane is closed, I think that will fix the crash, and possibly fix a memory leak as well.

Nope, it's not a trick question. I didn't want to waste my time debugging a problem that ended up being a configuration or compiler option.

I've done the same thing at work when I write my own compiling scripts on my local PC - I check what the build scripts do on our build server and make sure my local build scripts use the same config or compiler defined options. This ensures my local builds that I debug with are the same as the ones the customers get.

For example, if my local build had a TIMEOUT variable of 30 sec, but the customer build had a TIMEOUT of 1 sec, my local build will never see the customer's problem. That's what I'm trying to avoid and why I wanted to know how devuan builds the packages.

Yeah, I got the source code using this command. I can see that the command downloaded the original caja.1.8.2 source and some debian patches, which the command automatically applied.

Nope, not yet. That's coming up next once I ensure that my compiled caja has the same settings as the installed caja.

The steps to reproduce the crash:
- Open any caja file manager window.
- Press F3 to open a split pane.
- Press F3 to close the split pane.
- Go to the menu: Edit > Preferences.
- Crash.

This problem doesn't occur in Nautilus 2.30.1 (on Ubuntu 10.04).