sfx2000

And for those who live on the command line - byobu is like screen and tmux on steroids - and it's in the ubuntu repos... If one wants to have a fun demo... byobu rocks...

How old of a chromebox - is it still supported by ChromeOS? (FWIW - there are more than a few ChromeBoxes and ChromeBooks that are end of support, so it's a legit question) More recent versions of ChromeOS have linux app support via Crostini - much easier that Crouton or Gallium that break security of the platform by going into dev mode.

hard to read - that's a good point in general with ANSI in general - part of the problem for me is that I have challenges in color vision, so some distros and/or terminals default to items I honestly have trouble with.

Sorry to hear that - this is a forum for discussion on Linux, and specifically Armbian. Plenty of Windows forums out there, and if you're looking at Android - XDA is a good place to start.

Hmm... actually yes - is the role of Armbian to teach users about Linux? Probably not, IMHO, they're better served by the Pi Folks - Raspbian is good training wheels for folks dipping their toes into Linux The average Armbian user is not a paying customer - there are no Service Level Agreements dictating that any bug of a defined severity level must be fixed within a specific timeframe. So yes - just ignore it for the most part, step in if is sounds fairly interesting - sounds a bit mean spirited perhaps, but generally folks will step in to help out, and if it's really a bug that is directly traceable back to Armbian code - then if it pops up enough, fix it directly, or delegate it to someone who is maintaining it (better to delegate, as that person knows the code likely better). So if someone has problematic hardware - "my whoflungpI Zero2W with the built in XYZ WiFi adapter doesn't work" - well, it might be crap hardware, and in the sub-$50USD field of hacker boards and TV boxes, there's a fair amount of crap - can't fix bad hardware, and there, someone will tell them, use something that does work.

Quick glance at the numbers, I'd say yes... 20:30:48: 1008MHz 0.35 12% 2% 8% 0% 1% 0% -203885°C 0/4 obviously not true - but one could test it out and run the clocks up, lol... To paraphrase - what's cooler than being cool - ice cold...

true, true... and that was one the market barriers to entry. the ar150 is easily available on the various sales portals (amazon/alibaba/etc), and relatively affordable - they typically run in the $20-25 USD range, which for a board of that price, is actually a lot of bang for the buck - ar150 is essentially the QC-Atheros AP-121 platform at a firmware level. OpenWRT direct support is very good - and the ath9k driver makes it even more so...

The power issue is due to the USB PHY, not the radio. AR9271, which is a great chip, also has it's own CPU, running it's own closed source firmware from EEPROM, this run on a Tensilica Xtesna 2.1 microcontroller... Don't forget - the AllWinner SOC also has a hidden core for power management, and it runs it's own firmware - the AR100 - some folks have reverse engineered the blob there, but I've not seen a working example yet...

I have to put my program manager hat on - the numbers don't work with potential volume, so I'm putting the project idea on the shelf for now. That being said - there are a number of boards that are suitable and similar in concept - and they available now. these boards are hacker friendly, accessable, and supported. GL-iNet AR150 - This is a QCA9331 MIPS24Kc @ 400MHz, 64MB DDR2, 16MB SPI-NOR GL-iNet AR300M - QCA9531 MIPS24Kc @ 650MHz, 128MB RAM, 128MB SPI-NAND and 16MB SPI-NOR, there's a couple of variants there - one with no NAND, the 16M, and the lite, which is single ethernet. AR150 is fully supported on OpenWRT ar71xx, and is very affordable, and a cool hacker board due to the open nature of the CPU and more importantly, the ath9k radio, along with a robust uboot implementation.

Opi Zero is the XR819 - which has some odd connection to the ST micro cw1200 chip - licensed maybe, or reverse engineered - anyways, a bit problematic https://linux-sunxi.org/Wifi#Allwinner

Broadcom BCM43438 Wi-Fi 802.11n (2.4GHz only) + Bluetooth 4.1 (Dual Mode) combo chip

Always hard to mask HW w/SW, but that's always been true - and sometimes it's upstream at a chip level errata. Don't sell the community here short - there are plenty of active contributors here that have specific skills, and some do this kind of work in their day jobs - but it is a valid point that it's unpaid, volunteer time, and resources are never enough. The fact that Armbian is on the radar as a serious distro is a good sign of the quality of the community.

for that price, one could spin up a couple of Linode or Digital Ocean hosts...

That's what I thought - the 8040 is an expensive chip, without a doubt, and in an odd space - too big to be small, and too small to be big - Marvell recently has gone in a new direction, selling off the WLAN stuff to NXP, and focusing on core segments. The RK is probably the right choice... As a side note - The Cavium ThunderX and ThunderX2 is also an interesting story - X2 is the old Broadcom Vulcan hardware on custom ARM cores (Broadcom, like Apple and Qualcomm, was an ISA/Arch licensee), ThunderX was Cavium's own effort with ARM IP cores... I had access to a ThunderX machine that was sitting idle in a data center for some time, and used it as a builder for a distro my old startup/science project was doing. Having 48 ARMv8a cores with a server class IO/MEM made builds a snap

Remind me - which version of that board (the NanoPi Neo 2) My NanoPi Neo 2 is v1.1, so it does have the voltage regulator... but I had to sfx@nano2:~$ cpufreq-info -c1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 120 MHz - 1.30 GHz available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 120 MHz and 1.30 GHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 120 MHz:97.01%, 240 MHz:0.19%, 480 MHz:0.06%, 648 MHz:0.02%, 816 MHz:0.07%, 960 MHz:0.06%, 1.01 GHz:0.00%, 1.06 GHz:0.00%, 1.10 GHz:0.00%, 1.15 GHz:0.00%, 1.20 GHz:0.00%, 1.22 GHz:0.00%, 1.25 GHz:0.00%, 1.30 GHz:2.57% (1571539) If I recall - boards that run at 1.1 only, there was a decision to limit to 816 to cover all H5's... looking at /etc/default/cpufrequtils... # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=120000 #MIN_SPEED=120000 #MAX_SPEED=1296000 MAX_SPEED=1296000 GOVERNOR=schedutil But @guidol - you know this already, as I made that tweak based on your posts