Tido

Hi Werner, not only that, while thinking about it I realized that the title of my posting is wrong - it is the service description not the naming conventions
 
I agree with you, as a Swiss (non native speaker). Does it explain itself better like this:
armbianmonitor -m provides simple CLI monitoring - automatic new-line feed output armbianmonitor -M provides simple CLI monitoring - automatic refreshing in line output armbianmonitor -n provides simple CLI network monitoring - automatic new-line feed output armbianmonitor -N provides simple CLI network monitoring - automatic refreshing in line output  
By the way, everybody is welcome to chime in !
 

This is a tricky shit that hides behind openness, but in fact tightly controls the main part-the loader. I.e., at any time, it can block or completely control any unwanted person's actions.
 
 
It's funny, you described a whole theory about freedom, and as a result it all came down to advertising and pushing aml shit. 
For your information, aml imposes its BSP shit on everyone, which is stuffed with Trojans and bookmarks to gain full control over those who use their shit. They lie to all users about their hardware and actively cooperate with those you are trying to protect yourself from.
 
In general, everything is as usual, if you remove the beautiful words about freedom, it all came down to the fact that "someone" would spend their time and money and provide the rest with free use of aml shit.
 

Oh, sure enough. I see this now.
I had a look at the strace dumps again, and it looks like this is in fact an upstream bug affecting all apt versions I tested.
I didn't think this was the case at first because Armbian is the only one where the bug inflates the processing time enough to make apt search actually unusable - on my Raspberry Pis running Raspbian and laptop running Debian, searching with compressed indexes only takes a few seconds, even despite the many repeated access operations. I remain perplexed as to why only Armbian seems to take around two orders of magnitude longer to complete the operation (presumably due to a similarly higher number of extraneous read operations).
 
In any case, the solution in the meantime is just to disable compression, either by commenting out the lines in /etc/apt/apt.conf.d/02-armbian-compress-indexes or by removing that file, then clearing and re-fetching the index files in /var/lib/apt/lists/. When operating on uncompressed lists, apt seems to be much better behaved, and I don't tihnk I see any signs of the vast numbers of repeated file accesses that I see when the lists are compressed. As I already mentioned, and contrary to what has been said previously in this thread, switching to gzip will not be effective. Disabling list compression entirely seems to be the only way to dodge this bug at the moment. Fortunately, it does appear to work properly; when operating on uncompressed lists, apt doesn't seem to perform the extraneous reads at all (and you're not just being saved by your disk cache).
 
I still can't quite figure out why this seems to be affecting Armbian so much more severely than any of the other Debian-derived distros I currently run. The bug clearly happens on my other systems, but only makes the search operation take around 10 seconds at most, whereas on Armbian, searches on compressed lists take upwards of 20 minutes, and don't go faster than about 16 seconds even with uncompressed ilsts. It could be that there are just more lists to search through under my Armbian install than on my others, but I don't think the differences are enough to account for that, even considering that the bug causes the time it takes to load a file to scale with the third power of the file size.
 
Anyway, a bug report clearly needs to be opened on apt upstream, and Armbian's configuration tweak to enable compression of index files should probably be removed or disabled, at least until the upstream bug is fixed.

i have reviewed the strace output helpfully provided by Fluora and most of it is taken up by repeatedly opening, reading, and closing the same index file over 26 thousand times. specifically, the file is opened, one chunk is read, then it is closed, and the process repeats. eventually it gets to reading 2 chunks on each iteration, and then 3, and so on
 
that seems like the problem! there's no reason to be repeatedly opening and reading a file from the beginning tens of thousands of times just for one search. and this does sound like an apt bug -- somehow it is deciding to just spin the same file read for 20 minutes, rather than just reading it once

I say we go and change the recommendation to USBImager and leave Etcher there as "also usable, but includes spyware"  

I have used USBImager for the last few sd card writes. Works well. 

@Ash Martin @Werner @guidol  You do know that this thread is about a BETTER software than Etcher, right?
And you do know we recommend USBimager OVER Etcher, right?
 
If not, I recommend to read the first couple posts of this thread. Instead of misleading people @Ash Martin  just be quiet. It is not as if you had to comment every post.

https://twitter.com/nixcraft/status/1351224938980667393

Yes that is old and only limited switch capability given.
 
 
Correct that thread is pretty up-to-date. I have received the boards and confirmed the Power and Serial Mux is working (with minor changes). Currently we are developing the firmware for the sdcard muxer (STM32 based). The hardware of the sdcard mux seems good, I was able to connect a sd card to USB (and read with PC) and also to some SBC and boot it with reasonable fast speeds. 
 
The current step is advancing the firmware so it is possible to select which SD card to mux where via USB or I2C. 
 
You can check the state on the github https://github.com/armbian/mpads

Thanks Tido, Seriously, I wish I was kidding.  I have already followed the steps prior to your message.  and I get the same error regardless of the dtb file I use.  I have renamed and tried both u-boot-s905x-s912 and the s922 --> renamed to u-boot.ext
 
See the screen capture below.  Note I have even tried copying the files and renaming it to dtb.img and I get the same crappy error message.  The 1st screen capture shows the use of the "meson-gxl-s905x-p212.dtb" which btw like all makes no difference.
 


 

You have an error in your extlinux.conf: you should comment the rk3399 lines and uncomment 1 line of amlogic starting with fdt and the last one starting with append.
Here is the one I use for s912 boxes (you may change the dtb if the generic q200 is not relevant):
And you may also change the extlinux.conf-menu file:
 

embedded,
VPU - video processing unit (encoding/decoding)
 
GPU - graphic processing unit (3D acceleration)
SoC - System on a Chip
SBC - Single Board Computer
WIP - Work in progress
NAND - Flash storage
GPIO - general purpose input/output
 
CSC - the weirdo.. no support abbreviation
EOS - End of Support -  Hey Werner, die beiden schreien nahe zu nach einer Zusammenführung.
 

It is. I'll fix that.
 
Edit: fixed

In the past I did also install vsftpd, but some time ago I did see that the package oppenssh not only has openssh-client / openssh-server...

As third part there is the openssh-sftp-server which armbian does install.
So I never installed vsftpd additionally again

The 3 packets in armbian (on my installation) are:
 
openssh-client 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) client, for secure access to remote machines openssh-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) server, for secure access from remote machines openssh-sftp-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) sftp server module, for SFTP access from remote machines An idea for the configuration of openssh-sftp-server could be found at
https://www.allthingsdigital.nl/2013/05/12/setting-up-an-sftp-only-account-with-openssh/

@Tido I made an edit to top of post. https://github.com/sgjava/java-periphery

Agree. Maybe things should not be pushed so hard. Not only there is (from gut feels) little effect on (to use @Tido's scheme for simplification) patch releases, it also increases the administration effort as @Igor noted.
What about this? Do not push out intermediate releases (like 20.08.4) UNLESS there are critical issues like board does not boot.
Everything else can most likely be pushed via apt kernel upgrade anyways and will be merged in the next 3-month-release as well.
If somebody wants a provided fix faster they have to build their own either image or kernel package from master or wait. No discussion.
 
my two cents.

For a common understanding..  semantic versioning   8.5.4 == MAJOR.MINOR.PATCH - for a programm, not a distribution. But, people really care which version they have and they want the latest an greatest - as we know from questions in the forum.
Ubuntu LTS on the other hand fixes stuff and after a period they release 20.04.1  that incorporates all the fixes. However, I guess your release cycle is too short.

USBImager V1.0..4 is now 2 months old, but I today recommend by cnx-software:
https://www.cnx-software.com/2020/09/08/usbimager-a-lightweight-alternative-to-balenaetcher/
 
Filter out drives on the same disk as C:
https://gitlab.com/bztsrc/usbimager/-/commit/1775cdc628a3d28ce454c181952aa283334d0991

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

Fixed.

Yep, something like this.
Another reason to get rid of one of those 
 
Understand. But it seems to me it is kind a mixed at the moment because there was not much such "movement".

Another minor update.
Contact information has been updated. You can access and edit these information by clicking on your avatar at the very top right corner, click on Profile and then hit the Edit Profile button.
 

Here are the Armbian bionic images with installed RTSP streamer using H264 HW encoding on Allwinner H3 boards
Orange Pi One
Orange Pi Zero
Images are able to run on any board with Allwinner H3