armbian-config RFC ideas

[Werner]

The idea is great. However it might become complicated once the script reaches multiple thousands of scripts since it needs to collect all the names and info before running and that increases loading time.... but at this time I simply assume it never will grow this big

[gprovost]

Quote

all software via Docker deployment https://fleet.linuxserver.io/ but also prepare APT and manual (from git) install mechanism

 

I really like the idea to put the constrain that all 3rd party applications must only be supported through containers. That will clearly help to improve user experience thanks to well maintained container but mainly avoid app installation that would potentially mess up the OS. We need to think of a way to list in the menu the already installed containers (of course only list the container installed by armbian-config). Also the question will be do we want to make docker and docker-compose packages a dependency of new armbian-config ? I think we should, it will make thing easier... but of course also not a big deal to install them only when first 3rd app is being installed.

 

I also like the fragmented approached made by @tparys clearly it will help a lot for maintenance and contribution. We will need to define a clear policy on how to handle local and global variables between the different chunk of scripts.

 

On the CI topic, I unfortunately also don't see what could be really easily tested in an automated pipeline.

 

Happy to participate in the refactoring effort.

 

 

[Igor]

5 hours ago, gprovost said:

On the CI topic, I unfortunately also don't see what could be really easily tested in an automated pipeline.

CI install & deploy containers on every change + cron and catch exit codes. So we have an overview if this and that application or functionality is broken. If we only allow containerised installs, this should not happen very often, but still. We need to know if installation is (still) working.

[gprovost]

Will the runners of the CI pipeline be VMs running latest Armbian OS version in which we test armbian-config ?

 

Because a docker deployment can fail for 2 category of reasons, the container / compose file issues or because of the host OS itself. So to catch the second category we need to emulate the Armbian OS host.

[Igor]

4 hours ago, gprovost said:

Will the runners of the CI pipeline be VMs running latest Armbian OS version in which we test armbian-config ?

We can run this on actual Armbian, but for the most of the part that is not needed. We can use stock Github runners and x86 Debian & Ubuntu userland to run tests. Code must be designed as architecture independen from start and HW features has to be tested on the actual devices. But since that is a bit more complicated it doesn't need to be the part of this pipeline.

[Igor]

Significant part of armbian-config represent installing certain packages, deploying containers, ... things are done in many styles. Can we build engine, where we could fit them all? I don't have a clear picture yet how to proceed, where are problems, limitations. Should we create some sort of application template and / or import what to ask user (ports and dirs to map) from Docker compose https://fleet.linuxserver.io/ docker images? Do that on the fly or import?

 

Create install / deinstall routine

https://armbian.atlassian.net/browse/AR-669

In application menu user will have an option to install “Apache”. We will provide info about the install type and ask user to provide additional info. Like port or directories to map from a docker container. When we choose to deinstall, container has to be removed.

[TRS-80]

On 3/11/2021 at 7:42 PM, Igor said:

I don't have a clear picture yet how to proceed

 

OK, what follows is not trying to rain on anyone's parade.  Just my perspective.  Because honestly I never actually use armbian-config for anything.  I just learn to install whatever software I need myself, either from packages and/or use a container, or whatever.  Because personally, I do not like "wizards" and automated things which hide important details from me.

 

So, coming from this perspective, I always wondered who actually uses armbian-config?  Do a lot of people use it?  I am totally ignorant here.

 

I just know that we are always talking about the burden of maintaining things, especially with what resources we have available.  And I can't help but think that we are slightly re-inventing the wheel here.  There is already Docker and others for people who want to containerize things.  There are projects who maintain ready to go containers.  Then there are Ansible scripts.  And many other things, too.

 

I guess I can't help but wonder if armbian-config even needs to be a core component of Armbian at all?  I guess to some people, the answer is "yes" but it has never been that way for me, personally.  To me, Armbian has always been "a Debian based distribution for SBCs."  Later I learned that in reality it is actually some build script framework, and the published images are simply an automated output of that.  OK, so I am fine with either/both of those definitions.

 

But now, as hinted by what I quoted from Igor, we are getting into a lot of complexity and maintenance burden (with armbian-config), and for what?  Should we instead perhaps be talking about scope creep?  Or defining what this project actually is?

 

If I am completely off base then please disregard.  I gather that this has been a part of Armbian from the beginning.  Maybe a lot of people love/want/expect it.  I really have no idea.  And if it has already been determined to move forward no matter what, than I apologize for derailing the thread.  OTOH, maybe these questions need to be raised?  Maybe what Igor was struggling to grasp (and what I picked up on) was a clue to a larger question?  As someone who feels less experienced (in certain aspects) and perhaps even less involved (in some ways) than some others here, I will leave it to the rest of you guys which is correct.

[Igor]

26 minutes ago, TRS-80 said:

I just learn to install whatever software I need myself

Overall, we are in this <5% or even less  But its not just about the software install. That's just a part. Its about configuring particular (hardware) functions. As easy as possible. By making this easy, we will make lots of people that are not that skilled or just lazy, happy. Also we didn't promote current armbian-config much since it never left beta stage and was more or less my pet project.
 

26 minutes ago, TRS-80 said:

And I can't help but think that we are slightly re-inventing the wheel here.  There is already Docker and others for people who want to containerize things.

 

We have no plans to reinvent the wheel. You know what Docker is and how to use it. Many people don't and they never will. But they will know what Pi-hole is and how to configure it. We just need to build an easy Docker(+native) install wrapper.

 

26 minutes ago, TRS-80 said:

I guess I can't help but wonder if armbian-config even needs to be a core component of Armbian at all?

Absolutely. Just don't look on it as a software installer. It's much more than that. Especially in CLI, it comes handy and it's more user-friendly than stock Debian (dpkg-reconfigure tzdata) for changing timezone for example ... You can enable hardware functions such as SPI, tweak ZSH/BASH, install headers, edit DT, edit boot parameters, enable desktop, enable AP, connect BT keyboard, enable 2FA on SSH ...

 

26 minutes ago, TRS-80 said:

But now, as hinted by what I quoted from Igor, we are getting into a lot of complexity and maintenance burden

Biggest complexity represent build system and things people see as granted - "Debian on SBC".

 

But current armbian-config is not possible to develop and maintain properly which is why we are talking about and going into this RFC. The goal is to get it under control and provide as a full blown (non-beta) part of the Armbian. To keep functionality that is needed and drop what's pointless.

 

 

[TRS-80]

I guess in my mind, the notion of starting to play around with SBC (especially headless)[0] without wanting to learn how to do it "the old fashioned way" in plain vanilla Debian, via terminal, etc...  I just find bizarre!  But I guess I will just have to take your word for it.

 

In fact, I always considered the fact we try to stick as close as possible to plain Debian (/Ubuntu) as one of the main selling points.  For me anyway, the further things get away from those standard tools, the less I like them.  Am I alone in this?

 

Well, sorry for the noise.  Hopefully if we break this project up into some manageable bits as discussed, I will be able to contribute one or two little pieces at some point.  I guess I better get to looking at the existing code, as I never have even used the software, much less dug into the code yet. 

 

[0] Which Armbian have been more so historically, although changing recently with more desktop stuff and support things like PineBook Pro, etc.

[gprovost]

@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.

[lanefu]

Opi Zero still insanely popular.  IMHO that would be users wanting to "do something" in a hurry... which is where armbian-config shines

 

One could assume downloads with legacy kernel are being used in some sort of media or desktop way

 

 

 

[Igor]

3 hours ago, gprovost said:

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.

I can only add some numbers more like estimation. Active monthly users by Google analytics is 70-80k, whatever that means. It's difficult to say about the download numbers - between several hundred and several thousands per day - getting correct numbers would require some effort since we have many points of download, that only have standard log, or torrent download which is active all the time, but data is not collected. We don't abuse users by calling home on install ... dietpi still do that by default. Most popular downloads are: Orangepi Zero, PC, Zero2, RK322x, Opi4, Tinkerboard ... No wonder we have 4 known enterprise grade download mirrors in China, which majority was discovered last week 

 

3 hours ago, gprovost said:

without forgetting nand-sata-install which also deserve its attention

 

It's hard to decide which is more important, but yes, this part also needs attention. I know that in both cases there will be significant work and we can't do it alone / just amateur way. Crowdfunding campaign to additionally support this project is planned.

 

10 hours ago, TRS-80 said:

In fact, I always considered the fact we try to stick as close as possible to plain Debian (/Ubuntu) as one of the main selling points.

 

In term of internals, yes. We use the same package base, while Armbian was never just Debian or Ubuntu. Yes we are aware, but most of users aren't - the most expensive part is hardware interface - where absolutely nothing connects us to Debian/Ubuntu. Its our product and we also pack it different. Networking defaults are ours, welcome, install, the way desktop looks, ... We don't use Debian / Ubuntu package base as is, but we select which packages we will use to form default userland. What we do keep is - in 99% - packages versions and their relation. Which is the key to secure "as close to Debian / Ubuntu" as possible. And yes, we also doesn't want to replace utilities that works well and use our dirty made rebranded replacement (what dietpi does in many cases). We provide functional better replacements like own hostapd (that is closer to the powers of openwrt) or improved htop, that contains data which are important in SBC world ...

[lanefu]

Half-relevant.  Had fun idea for new simple feature:  control mode of onboard leds.  (Heartbeat, io, etc)

 

Basically enumerate whats in /sys/class/led and pick their setting via the tui.  Just use a systemd.unit as a oneshot service that reads config file to set value at startup

[tparys]

Another things I've been playing with in my spare time. Better identification of the SoC that some of these boards use. For example my NanoPi M4V2 (RK3399) kicks back this:

 

tparys@hobbes:~$ ./arm-chip-id.sh 
4x Arm Cortex-A53 @ 1416 MHz
2x Arm Cortex-A72 @ 1800 MHz

 

Not sure if it's useful, but might be more descriptive for end users who don't know much about their systems, or for describing controls for each CPU cluster in their SoC (see this post). Apologies in advance the bash is a little hard to read as it's digging through sysfs topology bits.

 

It also breaks if the first CPU in a cluster is knocked offline. Not like anyone would do that, right?

arm-chip-id.sh arm-chip-id.db

[Igor]

Three subtasks (almost) done, more development design ideas has to be added / cut into more tasks. What else are we missing in https://armbian.atlassian.net/browse/AR-638
 

https://armbian.atlassian.net/si/jira.issueviews:issue-html/AR-638/AR-638.html (print version will be attached to funding proposal so let's do it well)
 

- add subtasks

- comment

- in case you are willing to participate in certain task(s), assign yourself

[Igor]

In current armbian-config,  we have a broken desktop install on top of CLI images, while I have made several checks and come to a conclusion its fairly simple to install desktop. Which could be a nice first working functionality in the new armbian-config. And a reason to start moving on.  

1. Available desktops per release for select box:

 

apt-cache search armbian-$(grep VERSION_CODENAME /etc/os-release | cut -d"=" -f2)-desktop- | cut -d" " -f1

 

armbian-focal-desktop-gnome
armbian-focal-desktop-xfce
armbian-focal-desktop-budgie
armbian-focal-desktop-cinnamon
armbian-focal-desktop-deepin
armbian-focal-desktop-i3-wm
armbian-focal-desktop-mate
armbian-focal-desktop-xmonad

 

All those exists in repository and are up2date.

 

2. Installation

 

echo lightdm | sudo tee -a /etc/X11/default-display-manager
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true apt-get install --install-recommends -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -y armbian-focal-desktop-xfce

 

3. After install - more or less copy / paste
https://github.com/armbian/config/blob/master/debian-config-functions#L780-L819

 

I would start, but my brain is stuck in stack overflow mode  

[Igor]

On 2/7/2021 at 2:40 PM, SpontaneousDuck said:

I would love to get involved with the redesign project! I don't have a ton of experience with CLI tools like this but really need to learn so this would be a good chance.

If you still interested ... ?

 

@jeanrhum @gprovost

 

Anyone! This is call out for wishes and what is possible, will be added to the plan. 

 

Now things are back in motion. A help on moving and searching useful ideas from this forum to actual plan is highly appreciated. No particular technical knowledge is required for that.

 

Stories - what will be done - are collecting in this Epic: https://armbian.atlassian.net/browse/AR-967 from which a top level plan is going to be created in a few weeks.

(who needs write access to Jira - PM)