Igor

Aha you mean like having a proper "software design" phase ... Currently we have "I have an idea and will work on" and we want to have some process: idea -> discussion / developers meetings / comment on that / co-design -> Jira story (or a plain document). And repeating those cycles until we are happy. Then coding. Yes, that would be ideal. The problem is that all this planning require a lot of resources we don't have. Ideally we would have a dedicated manager of software development. I am now doing this, running a business, doing paperwork. I am forced to improvise, make things on a "best effort" way. I hope that we will implement design mechanism into developers meeting and after. But at this stage we have a large branch of a build system that was not designed together, but is based on common design.

1. Feature implementation is different and you don't like it - propose changes (if its questionable, we vote), task if small, story if big 2. Something doesn't work - bug ticket 3. Feature is missing - describe what you are missing (task if small, story if big) You mean this?

Yes of course. I can say that current focus is optimisation for running as stable as possible and running within CI. We need to have this phase in near to perfect state before heading to optimising it for low resource systems. There are bugs that needs to be discovered and fixed before we proceed. I would suggest that for those ideas simply simply open a ticket. Our build system contains configurations, build lists, helper tools, speak multi arch, speak multi branches, supports different underlying packages assemblies, can be assembled on different arch, have many levels of caching ... acts like a giant compiler and linker. Perhaps a bit philosophical

Agree, I already opened a ticket: https://armbian.atlassian.net/browse/AR-1454 Current state of logging is terrible on the other end while if something breaks, logs can help to diagnose - the more the better. Perhaps we could introduce better levels of logging? Dunno how hard this is from current perspective? Cross compilation is one of the core tool advantages - removing would be a mistake. The rest I can't comment as I didn't study enough yet.

Looking for a volunteer to split kernel-drivers.sh into functions, for aufs/wireguard/kali/exfat https://armbian.atlassian.net/browse/AR-1478 If this is not ported, we will probably just drop it. But on the other hand, this is easy task and nice opportunity to understand armbian-next better and help.

Fix for packaging mechanism https://github.com/armbian/build/tree/master/packages/armbian won't be accepted as the problem is not there. This has to be solved with a kernel patch. Since this is a private kernel, it doesn't get most of common fixes. I remember lds problem was present some time ago in all kernels, but solution is long gone from my head.

Profit is that sweet deal when you cover costs. Community / amateurs rarely work on boring cases that last weeks or months to finish in exchange for absolutely nothing, not even satisfaction of helping people as nobody will notice or understand their sacrifice. You can bump into the people, this community is full of them, that will help you with extremely valuable advise or hint - most things are solved for free. By us, by community. But you also want that hard things are solved for free and here things stops, sometimes brutally. In most cases they don't progress as they are costly in technical and organisational sense. If you treat this project with 20 or 200 USD per week, while we need 5000 USD per day to match costs, we are very very far apart. Most used business model to profit in OSS is to steal from someone and sign below. Nobody will sue you as its too complicated and how a non-profit can allocate money for that? Certain % of people will fill sick, some will complain and point towards dirty players, while you / end users just want to have free fun. This seems to be pretty typical profile around here I could point myself close to that, except that I am using my experiences and skills to progress this project. Alongside with others.

You should create one in the 1st boot process. Otherwise: https://www.google.com/search?q=how+to+create+user+on+debian+system

Common to all modern kernel based Linux distributions that does not chain load with propriety kernel? Armbian is a build system that assembles and provide ready to run Debian like / based OS for single board computers. Yes of course, but open source boot loader is not done yet, dunno what is the status ATM, while we decide to not provide Armbian images with proprietary vendor (Petit)boot / kernel. I don't know if there is a solution. Only a workaround - that you use some other WiFi dongle.

Just keep it on community level - you are a peer at best, not a customer. If you want that someone do your homework, trade, provide a compensation. Keeping this project alive, without helping you, costs. Developers are fully aware of troubles, but the problem is that resources are 1/1000 of needed. We are shooting monsters with slingshots, while you remain blind and ignorant no matter what is sent your way. Your startup dug lets say 5M EUR of starting capital which you waste to develop software that anyone can download for free and you also support it for free until you ran out money? I am sure you were not that stupid. This is automated test report from a few days ago: It is called "smoke test". It power boards on, checks basic functions following by reboot and powers off when done. And record few things ... We can run this at any moment and the plan is that it runs automatically at every code change. If end users refuse to fund software development and you do, perhaps rather help where project is asking for help? We are also asking for help developing this test system, which saves us a lot of time, or armbian-configurator, which saves you a lot of time, for several years now. Nice way or with applying a pressure (as now). Nothing. Cash to code with pros? Nothing. At least for things you want and need (problem from this topic) and you can't just steal from someone / download for free? Nothing. Back to topic? Who will spent several weeks digging into this driver? Biggest frustration is that I can't give that person anything, not even a comfort: "Its a hard work, there is a big possibility of failure and you will get no compensation because users do not respect this work or you". While our competitors will tell: "Dear John, we are working hard to solve this problem for you. You are important to us. It will probably take several months", while they will be opening a bug to us and applying a constant pressure. Welcome to the dark side of the FOSS projects.

I usually start this way: https://www.google.com/search?q=wifi+recognized+as+cd+rom then integrate it into our kernel or share on forums. Its not a problem specific to M1 nor Armbian.

My test device is now pretty stable: ____ _ _ ____ | _ \ ___ ___| | ___ __ (_) / ___| | |_) / _ \ / __| |/ / '_ \| | \___ \ | _ < (_) | (__| <| |_) | | ___) | |_| \_\___/ \___|_|\_\ .__/|_| |____/ |_| Welcome to Armbian 23.02.0-trunk.0118 Jammy with Linux 5.15.86-rockchip64 No end-user support: untested automated build System load: 2% Up time: 48 min Memory usage: 23% of 473M IP: 10.0.30.152 CPU temp: 36°C Usage of /: 7% of 29G RX today: 100.7 KiB [ General system configuration (beta): armbian-config ] Last login: Sun Jan 1 14:03:19 2023 from 10.0.10.12

Elsewhere you won't get much. Boot loader waits 1 or 2 seconds for input. This you can disable. Other services all together are close to nothing ... you can get down by shrinking kernel to support your use case only and use busy-box https://busybox.net/ and completely shrink OS functions, but its some work - if you can afford according to your use case. DHCP will sadly remain bottleneck, its also dependant on DHCP server ... this doesn't look like a hobby project?

Setting fixed IP address might get you some savings.

Bulk is recommended 😎

It is difficult to go back but staying on the same kernel branch. Which patches might not work properly. I could point you what to fix, but its pointless going that way. Lets try to stabilise M5 on K6.1 / latest (best working) u-boot. Which is the cause of this: SD card / eMMC initialisation is failing. This problem we are fighting with Amlogic for years.

I can understand you have good intentions, so thank you, but do you really think you (and community at large) are supporting this project in any way or it is perhaps the other way around? https://liberapay.com/armbian If you report a bug in software that you have downloaded for free, developers (you don't support), maintainers (you don't support) and support staff (you don't support) just looses more of their precious time and more of their private money. Development and fixing of those things is hard and time consuming work. Vendors that sold you hardware together are also unable to provide you quality software with their small sales margin and competition. FYI.

Event -> Video (with transcripts and comments) 1. Checking the progress of Armbian-next. most of open bugs has been fixed. How to help? users? continue to test various variants -> open a ticket developers? focus on cleaning rockchip64 / media patches, focus into config/ section -> moving family and board hacks into extensions 2. Armbian short description We are still not unified. Most sane idea is to better divide Armbian as OS for end users and Armbian as a build system for developers / integrator / business users and name those two more appropriate. We couldn't unite on a name to fit it all. 3. Mainlining of patches We generally agree and encourage this but we can deal with this gradually. Cleaning and squashing patches first, then move on. While doing this perhaps mark what could be good candidate to mainline so we don't press on people to proceed right on the spot.

We provide / have minimal images for software deployment purposes, where "nothing" comes preinstalled. Standard CLI image provides more things including possibility to recompile kernel, build armbian image, drivers, ... This was since ever, only default headers install was included recently.

To make it easier for installing drivers via DKMS is the only reason. But I guess its better to disable?

Welcome to Armbian forums! I have to be honest with you. We have no interest - it just bring more expenses & stress to the people that work on project. If we provide images that doesn't fully work, and they never do, we are loosing money which is very troublesome when having no income. There were never any support budget for this hardware. Not a single cent. Vendor is unfriendly and not "community driven" as they advertise. Pine64 also rather supports commercial Linux projects that are focused in taking advantage of other FOSS projects. Including ours. Most of their ARM section was ported from Armbian, PostmarketOS ... We were officially not notified about any hardware changes even they recommend our work. If LTS does not boot, is IMO expected. The problem officially does not exits. Our images were made for hardware called "Pine64+": https://github.com/armbian/build/blob/master/config/boards/pine64.conf#L4 LTS (probably) needs different boot loader config / settings. Towboot is just a fork of the same thing, a different UI with not enough people / activity to be taken seriously. Primary reason is anyway unrelated to low level hardware support, but to boot different kernels / user lands with the same boot image. Something that is not very important for Armbian.

Stable, weekly and CI builds https://www.armbian.com/orangepi-5/