sfx2000

Armada 38x is fairly decent with CESA in specific use cases - and it's worth the effort perhaps to get it up and running (armbian, if I recall, doesn't enable it by default) MV3720 is a different chip - and there, it's better to skip the CESA units, and go with software on the cores, IMHO...

Atheros 9331 can do this all day long on 100-Base-T... 400MHz MIPS32 [SUM] 0.00-10.00 sec 102 MBytes 85.5 Mbits/sec sender [SUM] 0.00-10.00 sec 101 MBytes 84.4 Mbits/sec receiver 64MB RAM/16MB SPI-NOR - running OpenWRT If you need a bit more horsepower to route traffic - MV3720 on Gigabit can do wire speed there... Alternate for 1GB - QCA IPQ-40xx - I've got a IPQ-4019 board running QSDK (based on an older OpenWRT with QCA special sauce), and it can route actually better than the MV3720 - and that's a QuadCore Cortex-A7... Key thing here - AR9331/MV3720/IPQ4019 - these are all communications focused devices, not application processors/boards...

Shortcut perhaps... but this does override systemd assigning things there... Add the following line to /boot/armbianEnv.txt extraargs=net.ifnames=0 and then reboot... sfx

Indeed - and they both get along, and want to do a threesome.... It's so very wrong and right on many levels, LOL, and rarely ends well That being said - Microsoft is a very different company that it was under Gates/Ballmer with Windows/Office at all costs... WSL on Win10 for example, as well at the beast that is Azure... Embrace/Extend/Overcome? Who knows... sfx

Nice to see VS Code in the repo's - it's my goto editor these days on Mac/Win/Linux.. On lower end ARM's - it's a bit slow and memory intense, but it does run... The RPI folks recently added it to their debian based distro in the last couple of weeks...

ZFS support is nice to have - one can use EXT4 for the boot volume, and ZFS for attached drives as a storage pool... That being said, ZFS can, and often does, use more memory...

u-boot and device tree optimizing works wonders here - need to declare the interfaces before the kernel boots, otherwise it's going to grab the first one ready...

"best" is subjective - yes zsh is nice, and now the default shell even on MacOS BigSur. I'm a bit old-school - bash is good enough for me, I know it's quirks, and zsh (or others) is always an option post first-boot. On my other efforts - I'm still dealing with busybox (and that is ash.c)...

Screen/Tmux - pretty nifty, and it's in the repo's so one can play with it, and define as the default shell if one prefers...

I'd suggest putting this in armbian-config to enable (along with the options for tmux, etc) and leave bash as default... Also look at byobu - this is an ubuntu sanctioned environment, and pretty handy - it's my go-to for working on the shell... https://www.byobu.org/

Just curious as to why proposing to change the default shell from bash to zsh? u-boot updates - agree/concur where applicable. Desktop vs Master/Mainline merge - depends on 3D support (I'd recommend not by default), and blob-space - this seems to be the bigger topic...

Tesla's own fault... 1) 8GB eMMC is going to have a fair amount of writes if logging direct to disk - and each write there is two writes, one to erase a block, and one to rewrite the entire block. 2) Reminds me of a handset vendor about 7 years ago, where they would write a time value every second to eMMC - after about 9 months, the device would die... sfx

Gah - systemd strikes again... This is upstream stuff - not just Armbian...

Light up a single bus - if you're looking for device detect - otherwise don't do this, and let the kernel sort it once booted with device tree... What problem are you trying to solve?

Sounds like a good reason to revisit that code and make it work across platforms.