Is Protectli just rebranded Aliexpress stuff?

There are many posts on various internet discussions (Reddit, HN etc) about how Protectli devices are just rebranded aliexpress devices (often the brand Yanling is mentioned, which I can't find on aliexpress anymore).

To test this theory, I recently bought a Protectli V1410 as well as a Wooyi branded fanless Aliexpress firewall device with basically same specs: 4x2.5Gbe ports and similar CPU (N5105 and J6412 are basically the same in terms of performance and released around the same time). 

I measured power draw at the wall using the same method for both devices. I booted Linux from USB and looked at the power draw while idle, with HDMI unplugged and no USB connected except for the USB stick, and only one ethernet cable plugged in, so that the only things connected are these 3 things: 1). Power 2) Ethernet 3) USB stick. So the hardware setup was completely the same, peripherals completely the same, software stack completely identical.

The Aliexpress machine draws 10.5 Watts on idle with stock BIOS. The Protectli device draws 5.5W on idle with stock Protectli BIOS. After extensive fiddling with the BIOS and running powertop auto-tune I was able to get the Aliexpress machine down to 9.9W. I was not able to get it any lower than that. 

Checking ServeTheHome, I found this article: https://www.servethehome.com/fanless-intel-n100-firewall-and-virtualization-appliance-review/4/

Quote:

We purchased units from CWWK and Topton. Both use the CWWK motherboard. In terms of power consumption, both the N100 and N200 consumed around 10.5-12W at idle. That feels high, especially since the 35W TDP-fanned 1L PCs like the HP Elite Mini 600 G9 is under 8W.

Checking their HP 600 G9 article: https://www.servethehome.com/hp-elite-mini-600-g9-review-an-updated-hp-returns-to-project-tinyminimicro-intel/3/

Quote:

In terms of power consumption, idle was generally in the 4-5.5W range. Under load, we could get the system to 60-65W. That is very reasonable and is actually less than the Intel NUC 12 Pro that we reviewed.

This is in line with my own observations. I have multiple HP mini PCs, and in my experience 5.5W is normal when it's running a full desktop environment. When running a minimal server Linux OS with no desktop environment, 4W average power is quite normal. And all this out of the box with no BIOS or powertop tuning.

Interestingly, powertop shows that my HP mini PC is hovering around package state C8 whereas my Protectli is spending about 75% in C3. Which makes it all the more puzzling why the Protectli uses so much less power (around 50% less power) than the equivalent Aliexpress machine.

Overall my impression is that these Aliexpress firewall mini PC devices are cheap, but many if not most of them use significantly more power than a comparable Protectli or HP device. Of course the Protectli is more expensive, so if you are looking to save money, electricity costs would have to be pretty high for it to be worth buying a Protectli device just for the savings on electricity bill. Another positive is that Protectli devices are guaranteed to support Coreboot, whereas with an Aliexpress device - who knows?

My advice when buying an Aliexpress device is to make sure someone has tested the idle power draw of THAT SPECIFIC DEVICE otherwise you should just assume it will consume at least 10W on idle. I have also heard rumors that Aliexpress sellers will sometimes just randomly change components in their device which may significantly affect idle power consumption. Anyway, my point is, don't just assume it will idle around 5W just because it has a low power CPU.

 

Raspberry Pi vs used mini PC for home server

In the past I have always preferred using new hardware instead of used 2nd hand hardware because I don't want to deal with annoying hardware issues with used 2nd hand hardware. Sometimes it's small things like CMOS battery replacement, or having to redo the thermal paste, or replace the CPU fan, or replace the PSU. Those are pretty annoying but easily doable. Sometimes the hardware will just randomly turn off, and you have to spend time trying to fix it, and sometimes you can fix it by just upgrading the BIOS or changing some BIOS settings. For all these reasons I have generally preferred to use new hardware instead of used 2nd hand stuff. Especially in this case as a new Raspberry Pi costs less than an old used mini PC most of the time.

However, recently I tried to set up a new home server, and I have some experiences to share. Below I compare the experience of using a Raspberry Pi vs a used HP mini PC.

1. The mini PC was noisier than expected. I fixed this by replacing the CPU fan.
2. The mini PC was not storing date/time on power loss. I fixed this by replacing the CMOS battery.
3. The mini PC sometimes randomly rebooted for no reason. I fixed this issue by upgrading the BIOS and changing a whole bunch of BIOS settings including disabling wake on LAN.
1. EDIT: It happened again today, which means what I did (changing BIOS settings) did not in fact solve the issue. I am now changing the power supply and seeing if that fixes it.
4. The Raspberry Pi SD card corrupted the file system on power loss. This turns out to be a common problem with the Raspberry Pi and there is no solution to it except "use a UPS". This happened so many times that I swore to never use SD cards with Pi ever again (unless it's a use case where I can use a read only file system).
5. The Raspberry Pi is very picky about what USB SATA adapters it will boot from. Careful research and testing is required to find one that works with the Pi, supports UASP, TRIM etc.
6. The Raspberry Pi has a very limited USB power budget of 900mA. And this is shared across all USB ports. This means, if you are using the Pi to power a USB SSD, that may use up something like half of the power budget by itself, leaving not much left for other USB devices (mouse, keyboard, etc). This is a motivation for using an externally powered USB SATA adapter.
1. Unfortunately, many externally powered USB SATA adapters will backfeed power to the Pi.
2. Unfortunately, it is not possible to use a USB power blocker to prevent the backfeed, because the Pi will not boot from SSD if the SSD is connected via a power blocker.
3. I found an externally powered USB SATA adapter on Amazon where the reviewers said it doesn't backfeed power to the Pi. Unfortunately, trying to boot from this USB SATA adapter fails. The initial boot works but as soon as the boot finishes it fails (screen goes blank, the adapter LED starts blinking).
7. The Raspberry Pi has a problem where sometimes, plugging in a USB device OR unplugging a USB device will cause all USB devices to disconnect. If you are running the Pi from a USB SSD, this means your Pi will crash. This made me afraid of plugging in / unplugging USB devices as I could never be sure when it would crash the Pi.
8. I use a USB power blocker to prevent power backfeed from my powered USB hub. I connect the USB hub to all my machines (PC, laptop, mini PC) through the power blocker, and all my USB devices (mouse, keyboard, speaker etc) work perfectly. Except it doesn't work properly with the Raspberry Pi. The USB keyboards work, but the USB mice (I have multiple) do not work. On all my other computers (PC, laptop, mini PC), they work fine, they only don't work properly on the Pi.
9. A lot of software just doesn't support ARM. Going off the beaten path just a little bit will have you running into pain. For example NixOS has publicly said they won't be supporting RPi5 , they said even supporting the Pi 4 was a mistake. On x86, everything is supported and just werks (TM), you can run whatever software you want on your home server. 
10. Running a desktop environment on the Pi is extremely slow even with the light DE on the Raspberry Pi OS. On the mini PC, running a full fat KDE Plasma felt snappy and responsive. I can use the mini PC as a desktop whenever I want, I can browse the internet and even play games on it. Whenever I want to use the mini PC as a server, I can just unplug the HDMI and USB, and it goes down to 5.5W, and this is while running a full desktop environment. The Raspberry Pi idles around 5W because the USB SSD draws like 2-3W of power by itself.

Overall, although the mini PC is more expensive than the Pi, for the extra money you get a 100x better user experience - it just werks (TM). The Raspberry Pi has tons of software compatibility issues because most software just doesn't support ARM, as well as tons of hardware issues (SD card corruption, USB instability, etc) that you don't have to worry about on any normal PC, laptop, or mini PC. Furthermore, the mini PC can be used as a desktop and when it's used as a server the power draw is similar to the Pi.

In conclusion, I would say that a used mini PC is in almost all cases a better choice for home server than the Raspberry Pi.

EDIT: Here is the relevant quote from samueldr regarding NixOS stance on Raspberry Pi:

"NixOS" proper won't see support for the Raspberry Pi 5.

Just like all other ARM platforms, NixOS support depends on the platform's support in upstream mainline projects.

We will not repeat the mistake we did with the Raspberry Pi 4 and adding bespoke support for a proprietary ecosystem. It is too much work to support for the resources available to NixOS.

Note that this reply applies to any $BOARD, and not limited to ARM things.

So the roadmap to "NixOS booting trivially on Raspberry Pi 5" is:

• upstream support in U-Boot
• upstream support in Linux  

Then we can add its U-Boot build to the token pre-baked firmware partition (assuming we still ship it by then) and it should work [just as well as mainline supports it].

And here is a quote from ElvishJerricco regarding NixOS and Raspberry Pi:

The sd image works for the pi4 because we have a working boot loader (u-boot) for that device and because a ton of volunteer work has gotten the pi4 to work pretty well in the mainline kernel. The pi5 doesn't have either of these things. We could package the pi5 kernel, but nixpkgs generally has a policy of not including new vendor kernels anymore because of the maintenance nonsense they entail. We could use the pi4 kernel since that should work too, but given the posture against vendor kernels, it's best if we don't introduce new uses of the ones we already have. Even if we had a working kernel, there isn't a working boot loader. There's some patches for u-boot we could use, but they're not complete enough. There was an EDK2 port we could use, but that was abandoned very quickly by the person who wrote it and it doesn't work on later revisions of the board.

Raspberry Pi has been sorta hostile to distros in this way. They don't care about us, so they don't do anything to support our efforts to use a standard, maintainable boot chain. Nixpkgs maintainers have been fed up with vendors like RPi for years for stuff like this, so the official position by the relevant teams is: Keep these things out of the nixpkgs repo and let someone else maintain it if they want. The result has been predictable; because maintaining support for these boards is such a pain in the ass until mainline u-boot and Linux have good support for it (and even then it's still a bespoke boot chain in the image), there have been multiple efforts since the pi5 was released to produce working images, and as far as I know they've all been abandoned because no one can be bothered to maintain this nonsense.

I didn't even mention the pain that comes from Device Trees on most ARM boards, or how RPi, makes that even more painful with their abuse of DT overlays.

These boards suck if you don't want to run Raspbian. Buy a low power x86 mini PC instead. They're usually better anyway.

A couple of thoughts on using LLMs

Recently I started using Claude Opus 4.6 and burned through over $10 after just a couple of queries. In one of my queries, I asked Opus to generate me a wireguard config for NixOS, and saw that it generated this:

    networking.wireguard.interfaces.wg0 = ...

This immediately rang alarm bells because I've previously read the official NixOS Wiki page on wireguard, and I knew that there are at least 4 ways to configure wireguard in NixOS:

• NetworkManager
• wg-quick
• networking.wireguard
• systemd.network

Which one to use? Well, claude just picked networking.wireguard with no explanation. But according to the official NixOS wiki, systemd.network is recommended, while networking.wireguard is said to have "issues with routing". So at least in this instance Opus seems to have not followed best practices as documented in the official NixOS wiki. This was disappointing as Opus 4.6 is, at the time of this writing, considered the best model for code gen, and is also super expensive (cost me over $10 for a couple of queries), and I had some good experiences using it, so I had high expectations for it. After seeing this result, I realized that Opus is just the same as the other LLMs after all and that my trust had been misplaced.

In another query, I asked Opus to help me build a system, and it wrote the whole system in python, without any type hints, and of course no tests. I get that maybe it's trying to conserve tokens, but writing a python app with no type hints feels like something that should be illegal.

That inspired me to finally write this blog post. I feel like I've finally had enough experiences with LLMs to write down a couple of my thoughts on using LLMs:

1. LLMs can be very useful for debugging and troubleshooting software and hardware problems. LLMs are very fast at reading code. An LLM can sometimes find a bug near instantly by itself, saving you potentially hours of debugging time. 
2. LLM output is always and in all cases unreliable. I have found no use case where LLM output is reliable and trustworthy 100% of the time. My absolute rule is that all LLM output must be inspected and checked (e.g. tested) before it's trusted. For example, if I have an app, I would never accept code changes from a LLM without inspecting all of the code to make sure it looks okay first, and then testing it to make sure it works.

Bottom line, I think it's best to think of LLMs as an unreliable ideas generator. They generate ideas, some of which are good, and some of which are bad. When the human has run out of ideas, LLMs can provide additional ideas to try and test. In situations where ideas can be quickly tested at little cost, LLMs are awesome. In situations where doing the wrong thing can have irreversible consequences, one should naturally be more cautious about trusting LLM output. 

Additionally, I think there are a couple of tendencies to be wary of when using LLMs:

1. The tendency to treat LLM output as authoritative. This is seen when two people are having a debate, and one side pulls out an LLM, and asks it the question, and treats the LLM answer as authoritative. I must admit that it also irked me when people used to do the same thing by only looking at the first result on Google, or treating wikipedia as authoritative, etc.
2. The tendency of LLMs to act as a "confirmation bias" amplifier. This is when a human has an idea, and asks the LLM about it, and the LLM basically goes "yes, your idea is very valid", and the human goes from treating the idea as "possible" to being almost certain. Example: You think you might have some medical problem, you ask the LLM if it's possible, the LLM says yes it's possible, then you become quite certain that you have it. This is related to point 1.