TRS-80

I also got the same email, three days ago now ... three failed attempts from London UK, and three from Finland... not even the right continent... needless to say, nice long new password generated.

@TRS-80 I think it's important once in a while to re-question the whole thing because it helps to clarify the real objective that we might sometimes forget... or justify that energy should be focused somewhere else.
 
I think ultimately the life of a distro will always depends on the size of its user base and lets distinguish here community and user base. User base includes all the passive users that we never hear from, I have no clue how much that represent for Armbian. @Igor Maybe you have such numbers : number of d/l per image and number of active forum user ? Even though this will not necessary help to say if armband-config is useful, it will help to give a sense of proportion of user we never hear from which to my assumption are often users that don't hack/tinker too much with their boards.
 
Then I think it could be useful to run a poll on the forum & twitter and simply ask what the people are using their SBC + Armbian for :
1/ Hacking / Tinkering
2/ Headless server
3/ Set-top TV box
4/ Work Desktop
 
Such kind of poll could will help understand the audience usage. If the great majority vote for option 1, then it would back up @TRS-80 assumption. But if majority is 3 and 4, then clearly we are talking about a user based that is not really CLI oriented. As for option 2, is a bit 50 / 50.
 
We should also be aware of what's happening out there.
1/ DietPi user base is growing and I guess it's because of their approach of making a big eco system of 3rd party app available to user via an interface a bit similar to armbian-config.
2/ Debian / Ubuntu install, even in headless mode, is actually not purely CLI so we all get use to a bit of GUI even if we are advanced CLI users.
 
I agree with Igor that the strength of armbian-config is also a lot the configuration features (without forgetting nand-sata-install which also deserve its attention). So personally I see a big plus to have armbian-config around, because it can only help to widen the user base which in fine is beneficial to Armbian sustainability.
 
Yes that's a lot of assumption I made, It's why I think the poll would be really a nice driver for this refactoring effort.

I received an email notification same as title of this post 2 days ago.  Just now I changed my password.  But I thought I would make a post to see if anyone else might have been targeted (as I am a Moderator), especially any other Admins or Moderators.
 
I am going to ping everyone I can think of (actually, I simply use the list here) below, but please add anyone else who I miss.
 
@Igor @lanefu @Werner @TonyMac32 @SteeMan @soerenderfor @pfeerick @NicoD @JMCC @balbes150 @_r9

I received an email notification same as title of this post 2 days ago.  Just now I changed my password.  But I thought I would make a post to see if anyone else might have been targeted (as I am a Moderator), especially any other Admins or Moderators.
 
I am going to ping everyone I can think of (actually, I simply use the list here) below, but please add anyone else who I miss.
 
@Igor @lanefu @Werner @TonyMac32 @SteeMan @soerenderfor @pfeerick @NicoD @JMCC @balbes150 @_r9

I received an email notification same as title of this post 2 days ago.  Just now I changed my password.  But I thought I would make a post to see if anyone else might have been targeted (as I am a Moderator), especially any other Admins or Moderators.
 
I am going to ping everyone I can think of (actually, I simply use the list here) below, but please add anyone else who I miss.
 
@Igor @lanefu @Werner @TonyMac32 @SteeMan @soerenderfor @pfeerick @NicoD @JMCC @balbes150 @_r9

Dear Armbian community,
 
although I'm using Armbian a lot, I never had to submit anything to this forum (fortunately, because it works so well :-)),
 
On my PC I've experienced lags on heavy IO operations. After a short dig into available information,
I found a useful Cloudflare article on Kernel queues together with dm-crypt.
 
A good & short summary on possible actions for users can be found here:
 
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance
 
Enabling the no-read-workqueue & no-write-workqueue options helped a lot!
 
 
As I'm using a RockPi4 with the NVMe SSD with encryption, I thought this should apply to my SBC as well.
 
Unfortunately, Armbian/Debian Buster uses cryptsetup v2.1.0
 
which does NOT support these options.
According to the changelog, this option was introduced in v2.3.4:
https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/v2.3.4-ReleaseNotes
 
As Armbian uses a kernel > 5.9, the kernel infrastructure should be available.
 
Fortunately, crypsetup v2.3.4 exists in the buster-backports repo:
https://packages.debian.org/buster-backports/cryptsetup
 
Solution:
 
# sudo apt install cryptsetup/buster-backports
 

I received an email notification same as title of this post 2 days ago.  Just now I changed my password.  But I thought I would make a post to see if anyone else might have been targeted (as I am a Moderator), especially any other Admins or Moderators.
 
I am going to ping everyone I can think of (actually, I simply use the list here) below, but please add anyone else who I miss.
 
@Igor @lanefu @Werner @TonyMac32 @SteeMan @soerenderfor @pfeerick @NicoD @JMCC @balbes150 @_r9

I had to try 🤓

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Good!  Let them read some books, lest they never become as studious as their father! 

I don't follow the cluster stuff as much as you do lanefu (yet) but because of my recent interest in Pine64 I became aware they sell a CLUSTERBOARD with 7 slots for their SOPINE A64 COMPUTE MODULEs.  Now of course being A64 based these would be less powerful than what you are describing in OP (as well as having different form factor), however OTOH these are actual things you can buy in their store, right now.
 
Not sure how relevant PCIe lanes are to cluster computing, but I guess it depends what the work load is.  Especially if the workload is not CPU based, that could potentially be a killer feature.
 
I also cannot help but speculate it might be too niche a market to interest some mfr.  But what do I know.  A counter point, Pine64 are selling something already in this space, so... who knows?
 
EDIT: I was just watching some NicoD video and was reminded that ODROID N2+ might be even better for this.  The I/O is hobbled (shared USB) but has Gigabit Ethernet (not PoE though) but rates pretty high in his CPU/rendering type benchmarks.
 
Also, I know, it's a "dream" thread, so I hope you don't mind too much my mini review of current solutions (as a comparison, or in case anyone is looking now).  OK, back to "dreaming"... 

Here's the video.
Thank you @balbes150 for the images and @JMCCfor the media script.
Now I can start with something else

@MX10.AC2N I think you are approaching your issue from the wrong perspective.  As balbes already mentioned he "doesn't use this software and has no idea what it requires'.  So essentially asking the same question in a different way isn't likely to get a different answer.
 
You need to understand that the armbian project is about getting the mainline linux (debian and ubuntu distributions) to run on arm SBCs (and luckily that often works on TV boes as well).  Information and support of the thousands of software programs that can then run on debian or ubuntu isn't something that armbian is about.
 
NextCloud is a software product and you want to run that program on your armbian based TV box, which is great, but you should be looking for support from the NextCloud community for support of their product.
 
You mention in your posts NextCloudPI.  I'm not sure why you are going down that particular path.  You should be able to just install NextCloud following their instructions for your chosen distribution (debian or ubuntu).  I have been running nextcloud on one of my amlogic s905w based TX3 mini boxes for over a year using the snap version for my ubuntu bionic install.  It was easy to install, it automatically updates itself and I haven't had to think about it in a long time.  That is exactly what you want from a server based software program.  Now if you ask me what i did over a year ago to get it installed, I will have no recollection, but I just followed the readily available instructions available from nextcloud to get it done - didn't need to post anything to armbian forums to install a generic software product.

I moved the above to a separate thread as the content is distinct from the thread it was originally posted in.

I'd like to buy one or more NanoPi NEO2 or NanoPi NEO2 BLACK. Preferably 1GB model.
 
The manufacturer stopped selling these boards and none of the currrent models fit in their CNC OLED case (which I would also be interested in but will otherwise buy from them).
 
(Actually, anything with 64-bit CPU that fits in that case, or similarly nano-size with display and buttons, is of interest)
 
Will pay shipping to Asia from wherever you are.

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

I get a message that I don't have permission to read that thread ... :[
Still interested in this, I'm much stronger in hardware.

I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics.
(This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.)
 
Components:
 
Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs.
Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel.
APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs.
Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.)
Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches.
Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm).
 
Codec status:
 
Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations):
 
 
Approaches:
 
Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older:
 
LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly.
Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which.
 
Kodi 19.0: 
 
LibreElec patches + mpv:
 
 
@megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.)
GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source.
 
@Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them.
 
@ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository.
 
 
The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments.
I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections.
 
Other related threads here:
https://forum.armbian.com/topic/11551-4kp30-video-on-orange-pi-lite-and-mainline-hardware-acceleration/
https://forum.armbian.com/topic/16804-orange-pi-pc-h3-armbian-focal-5104-sunxi-av-tv-out-cvbs-enable/page/2/
https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/
https://forum.armbian.com/topic/13622-mainline-vpu/

I realize you are probably joking, but look here. 

From little I know about Ansible, it seems like it may perhaps even be "the right" tool(?).
 
However, languages / frameworks that current (and likely future) maintainers already know and are comfortable with, IMO, should also be an important consideration.  Perhaps even more important?  I kind of lean this way, but... how willing are people to learn new tool and switch to it?  Especially if that would reduce work / maintenance burden in the long run (which I suspect is true, but do not even know for sure, maybe @lanefu can elaborate here as he seems to be the one with most experience with it)?
 
Just $0.02 from someone who fancies themselves a bit of a strategic thinker and student of computer / tech history.
 
EDIT:  This may seem like a "small" decision, but I don't think it should be rushed.  "Complete re-writes" in different language / framework have been known to kill entire projects (some with much. much more resources behind them than we have).  Therefore the benefits should be clear and real, and not simply based on personal preferences.

Have they released Office/Windows under F/LOSS license?  Tells you everything you need to know.  Leopard don't change their spots, which is why I am not buying that they suddenly "got religion" about open source.
 
Remember, they tried (very hard!) for decades to kill F/LOSS!  Referring to it as "cancer", etc.  Back then, the future was not certain, I can assure you!  By now, things look a lot better, it appears we won and they lost!  We are not only still here, but growing, which is why they had to switch tactic/marketing, or else become irrelevant.  But that is all it is, marketing (i.e., lies, as their actions prove otherwise, see first point).
 
So let them die off already, IMO.  By virtue of their past actions, they no longer deserve to be a part of the collaborative future we are building together.  Make no mistake, they are still the enemy.  And the enemy deserves neither aid nor comfort from us.
 
If you are going to disregard all the above and put it in anyway, then yes, Vscodium would be a more palatable alternative (removing the spyware).  But still misses the (IMO) more important political point.  Not to mention the fact that such a fork is necessary only serves to reinforce my earlier points that M$ still does not really "get it."  Even when trying to do "open source" they still cannot help themselves but put spyware into it, have a EULA, and all the other nonsense we have always expected from them.

IMHO I would not ship zsh by default. Simply because one of Armbians goals is to provide a mostly unmodified experience known from a fresh vanilla Debian/Ubuntu installation on other platforms. Providing as pre-configured and easy to install enhancement is perfectly fine.

LOL No, man, I'm not that old!

I am very impressed by how much feature we are getting... WOWIE
I don't know if anyone has said this to you but you are a legend!