sfx2000

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 Qu

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.

what @Igor is getting at - this is a community supported driver - there's no real support from the chipset vendor for Linux. 88XXau has been problematic across the board with all Linux distro's...

Just out of curiousity - what's he using for a screen reader? sfx

1) RPi has fairly good community support for their native Raspian PiOS thingy - now that Canonical is onboard with Pi, not much value add 2) Armbian is just fine without Pi Foundation endorsements, and a distinct lack of interest from them to support Armbian 3) Not so sure, but what I can say is that Armbian is a great community, but not the only one out there 4) Is Pi Foundation willing to fund/support Armbian to port over to Raspberry Pi? I know some folks are concerned about VC3/VC4 and ThreadX, and with Pi4, the eeprom - and this is fair and undocumented...

As mentioned above - interesting - but outside of wrapping PCI-e addresses - this is a security concern

Probably never - as this is a bit of a security concern... There's a reason why there are EL levels in ARM-V8A, and bringing in support for things under the kernel are a bit of a concern. If Mainline picks this up, perhaps, but I suggest that this be kept as a science project - most folks don't need PCI-e support on hobby boards

Realtek lately has been a bit of a pain - lot of chips/variants on 8188, but they're different from a driver level...

IIRC, there was an issue with a the linux headers on one of the more recent Armbian builds - might have been solved...

Pretty early in the morning for US folks - I'm out here in the PDT timezone, which if I recall is 6AM - I'd be ok moving this a couple of hours to 4PM GMT/8AM PDT, which works well for me, as I have teams in the UK/DE that I deal with on the job stuff. That is of course, if you really need/want me present for the meeting.

Sorry - bit busy with the jobby-job... Off the job - some concerns around support for older boards - keeping images over the the legacy... Bit surprised today... seems like AW-H5 has fallen off the supporte path. sfx@192.168.15.23's password: _ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Armbian 20.08.3 Bionic with Linux 5.8.11-sunxi64 No end-user supp

Yes...

Kind of like the stability testing we did for H5 and memory timing... openssl speed -multi 4 Puts a fair load on to the CPU...