Split Armbian in two branches with different names
5 5

26 posts in this topic

The past few weeks I did see a lot of anger and frustration on this forum. Key contributors of the forum (.. Armbian developers) seem to struggle with the level of their audience. People ask for functionality which is not around because of bad hardware, people aspect certain things from Armbian which are not possible, people expect  “out of the box” solutions, no feedback from users, etc., etc. 


I personally think this is getting more and more a problem. The risk is that key Armbian developers get frustrated and not motivated to continue their absolute fantastic contribution to the development of “THE NUMBER ONE OS” for SoC Arm boards!


I think it is best to accept that there are two categories of users of the boards:


-    Users who buy a board and hope that it will fulfil their technical dreams (fantasies), like a TV streaming box, a flight radar, a weather station, a IoT “thingy”, etc.
-    Developers who want to take software (and hardware) to a higher level


The problem arise if people of category one, users mix with category two, developers
I think this problem will stay if there is not a serious change in how to deal with this.


My proposal, idea, is to separate the two. Why don’t we have a look at how the people of our Red Hat 'friends' are doing this. They separate their stable and development branches in two categories:


-    Red Hat (paid) / Centos (free) as the main OS. These are stable and ready to use
-    Fedora is the development OS. New things are tested in this OS. You should be aware that not all will work out of the box.


Would this concept work for Armbian?

 

If you have two different branches with separate names it will be more easy for people to choose what they will use. 

 


See for more information about Red Hat, Centos, Fedora

 

https://danielmiessler.com/study/fedora_redhat_centos/#gs.IQHoBY8
https://www.redhat.com/en
https://www.centos.org/
https://getfedora.org/en/

Share this post


Link to post
Share on other sites
52 minutes ago, op1tjaap said:

Would this concept work for Armbian?

Highly doubt it because of totally different situations - different target audience, different software state to begin with (linux support for generic x86/x64 vs ARM), people buying hardware first (due to its low price) and trying to fit it to their use cases later

 

54 minutes ago, op1tjaap said:

If you have two different branches with separate names it will be more easy for people to choose what they will use. 

We are already splitting kernel branches (default/next/dev) and image types (stable/nightly), and this doesn't work in general since people don't get the difference between them.

op1tjaap likes this

Share this post


Link to post
Share on other sites

That is exactly the point. People don't see the difference. My proposal is to rename the development branch in a new name. Like Fedora is the development branch of Red Hat. 

Share this post


Link to post
Share on other sites
We are already splitting kernel branches (default/next/dev) and image types (stable/nightly), and this doesn't work in general since people don't get the difference between them.


I agree that this will resp. does not make a big difference. RedHat vs. CentOS works because RedHat charges money for support. RedHat also has far less versions and releases and supported hardware to handle. Armbian has anything from X11, accelerated 3D video, sound via IIS, USB, TosLink, HDMI and analog. Also SPI, I2C, serial ports and other oddities.
Making all of those work is hard (impossible maybe even unless you have supported hardware).

My take:

Support some hardware fully. List the things which are supposed to work. Make sure they do.
If there are problems, users can file a bug report with most data like hardware configuration being collected automatically.

Everything else is not supported and if not working go to a dev forum.

List all supported boards and features like the Allwinner matrix and the mainline support for the various features.

Lastly make sure users with problems go to the right place: support for things which should work, or if it's unsupported, the dev forum.

Also moderators moving threads to the right place helps a lot as users will pick the wrong place.

Share this post


Link to post
Share on other sites
12 hours ago, op1tjaap said:

That is exactly the point. People don't see the difference. My proposal is to rename the development branch in a new name. Like Fedora is the development branch of Red Hat. 

IMO no! Make it easier for people who aren't able/willing to read could not be the ambition of armbian.  I think it would be better if we try to explain what WIP means (also explain that WIP doesn't mean that this is finished in the next months), what the difference between mainline and legacy is. Not only in one or two sentences about mainline is for *random application* and legacy is for *other random application*. Bring examples so that people can imagine that legacy/mainline is the better choice for their use cases (showing performance of multimedia application in mainline/legacy, or a serverapplication moved from legacy to mainline). Explain why mainline needs so much time to implement. 

If there are two "brands" you have to decide what's needed to call it armbian or 'WIPian'. A propper definiton of 'stable' 'testing' 'experimental'  is IMO way to go. 

Something like: stable means network works, usb works, gpio works (e.g. onewire, i2s, i2c), wifi works etc.  testing means: we think that all these things should work but aren't sure, experimental means: not recommended for end users, use this images only when you're able to solve problems by yourself or you're able to improve the support status (I like tkaisers link about smart questions, maybe this should be a 'must read' bevor asking questions about experimental builds).

For example: Asus Tinker is claimed to be stable (mainline) but:

  • Known issues: Ethernet driver needs some fixing (Downloadpage)
  • Bluetooth seems to be still WIP (Forum)
  • Camera on CSI seems only work with a 'questionable' move 
  • Display on DSI

Don't understand me wrong, especially @TonyMac32 does a really good job on the thinker board, he spends a lot of time explain the current status, give support (for sure the most activ supporter in the rockchip subforum). But, as long as these things aren't solved it's not stable for me (thinkting as a user not as a dev). Especially for a SBC which is claimed to be a 'RPi with more power' (it's not armbians faults that average joe thinks this is a overpowered RPi) but this is a board where a lot of former RPi users will join armbian with an atitute like 'my VW golf has now a ferrari engine! so why does the gear not working anymore?'. When I started with my first RPi (Model B ), nobody asked for CSI or DSI cause there weren't any cameras and displays on the market. But this changed and an average SBC user thinks this should work (especially cause the tinker looks like a nice colored RPi).  Just flag it as 'testing' could help that people understand that not everything is working at the moment. For sure, there will be still stupid questions why *random function* does not work but it's easier to understand when your armbian is flaged yellow or red that something doesn't work than if it's green. 

lanefu likes this

Share this post


Link to post
Share on other sites
5 hours ago, chwe said:

For example: Asus Tinker is claimed to be stable (mainline) but:

 

I could describe stable like this: "stable functionality with lack of some functions and acceptable bugs". With strict criteria, there would be only few boards left in download section, others would remain in WIP for ever :D
 

When board boots and Ethernet works, USB works and perhaps little more ... is already a criteria for providing experimental images, since board can be used (for testing) in certain, mostly headless, cases. All those "rules" are unwritten and developers / power users doesn't have problems with that, while average Joe perspective can be & it is different. We are talking about educating and bringing Linux to newbies. To people who are totally spoiled. First with windows experience, than with Rpi and they never been away from predefined menu structure. Whole problem become even more complex when digging in.

We just reorganise forum, download section and manual (WIP) and positive changes should be noticed. In general - we need to motivate people to read more (before ask) and to help them understand (with tips), what is written. It's an educating process, which is related to other goals and skills than R&D. Helping users and educating them can also be fun, but it's very resourceful.

Dividing project into community and commercial would probably be one positive step further, since now users are mixed and we have lot's of confusions. Well, hardly with the model, which works for multi million corporation with 10k employees. We are still few billions and 9990 people away :D:lol: If we go into such direction, it must be achieved simply, without large organisational changes: images with support for customers and community without our support. To send a message to average Joe: we provide you software for free of charge, while learning you (individually) is not part of this deal. It's a different concept, which they (we) are used to, when purchasing some item or service. That's why we should point this out clearly.

Share this post


Link to post
Share on other sites
5 hours ago, Igor said:

I could describe stable like this: "stable functionality with lack of some functions and acceptable bugs".

Whats about doing some 'psycological housekeeping'? 

-Red: experimental

-Orange: testing

-Yellow: stable

-Green: RPi like (no idea how we should name it)

 

For a poweruser still no problem to use a yellow image and for the Windows ->RPi ->armbian user (I'm a normal Windows user, started with RPi years ago, maybe, I read a little bit more than others before I ask things) hopefully a hint that not everything works at the moment. 

For the educational part, I would love to see a post where someone shows the difference between mainline and legacy on some use cases, cause that's something I think that the 'WinPiA' ( lWindows ->RPi ->armbian) user does not understand from begining.

Share this post


Link to post
Share on other sites

Thanks for your contributions to this post!

 

I think we agree about one thing. There are different users with different needs and different ways of using Armbian. How do we mix that!?!?


Again….that’s why I would like separate environments. I feel when using Fedora Linux that I'm part of a Development environment. I feel when I use Red Hat that I'm part of a Stable tested environment. But it is just a way I would like it. Armbian for the average users and Arm....???  for developers and power users.

 

I agree if we now succeed in directing  the 'WinPiA' users more clearly to what is really stable, tested and use cases which work we can achieve a lot. I also like the colour idea. Don't use red and orange for use cases that are beyond your scope and try to find a green or yellow way to archive this.
In my work I also have to explain a lot what is possible with our IT and what not. I like to give as illustration the famous Dutch "snack wall" of a company called FEBO. Enter a coin and choose your snack.

 

27ee4fb559a43839e009edc70f4fd225.jpg

 

This it it! And ......this is all there is! What’s in the wall you can have. What’s not in the wall you cannot have. (Unless…the people behind the wall succeed to deliver something new and put it in the wall. Until that time your request / order is not possible).


Let’s put in the "Armbian wall" the green and yellow stuff and let’s keep orange and red strictly for power users or people who are seriously interested to become one. If products are really ready to “put in the wall” they will become yellow or green. 

 

About our user scope
Personally I'm not a WinPiA. I never used a Raspberry Pi before I started with Armbian. I’m just a Linux sysadmin with special interest in building a certain use case for a small cheap device; the MacIPpi. It became an Orange Pi One. I discovered Armbian and did see it was ‘THE’ OS for devices like this. It gave me power to build my own kernel with heavy "under construction" drivers. I succeeded and I'm very happy with this. I got help from many people on this forum and have found my way in working with the development tools.


About user help and frustration
I tried myself to help some people with simple questions. It was not always nice. Two examples:
I found it really frustrating that people don’t do what you advise them:

 

Quote

 

<snip>

</snip>
.....
You are missing the basic knowledge in playing around with these boards. 
 
Start from scratch and read the documentation. Do you self a favor and learn how to use a serial connection to the boards. 
 
There is no way you will get an Android system with an Armbian image. 

 
So please go the section of your boards on the Armbian site and follow instructions. 

 

 

 

Source: https://forum.armbian.com/index.php?/topic/4520-problems-with-orange-pc

 

Or when they post a hardly understandable question you try to answer and just never get an answer again:

 

Quote

My solution….
<bla bla bla>
</bla bla bla>
……….
This is tested on an Orange Pi One
 
Is this what you where you are looking for Sergio?

 

Source: https://forum.armbian.com/index.php?/topic/4620-docker-baseimage-for-armbian


It is really understandable that people get frustrated in helping people. 

 

@Igor
Last but not least I’m intrigued by Igor his comment about a community and commercial edition of Armbian. Would you be in favour of a system like Red Hat, where you can buy support over your open source Linux distribution ( that is what Red Hat is…..)?
 I think that is almost the same as where I’m thinking of. Separation of two branches. And in this way separate user expectation. In the case of Armbian I should maybe read commercial as the stable version and community as the development / power user version? Maybe you could explain this point a little bit more?
 

Share this post


Link to post
Share on other sites
37 minutes ago, op1tjaap said:

@Igor
Last but not least I’m intrigued by Igor his comment about a community and commercial edition of Armbian. Would you be in favour of a system like Red Hat, where you can buy support over your open source Linux distribution ( that is what Red Hat is…..)?
 I think that is almost the same as where I’m thinking of. Separation of two branches. And in this way separate user expectation. In the case of Armbian I should maybe read commercial as the stable version and community as the development / power user version? Maybe you could explain this point a little bit more?

IMO it's a question of the quality and amount of paid support that can be provided with the current team size, in addition not everybody on the team may want to provide support for particular devices, to particular people/companies or any support at all, and how the commercial project part will affect the other one.

And I'm not talking about the preparations needed like finding a payment provider, making support contracts that will legally bind the amount of support and responsibilities, etc.

Share this post


Link to post
Share on other sites

I think paid/unpaid and branching is a fools errand. Anyone who expects to have full support for any rando board isn't going to know the reason for the difference (much less make the Redhat/Fedora association) because they didn't even bother to research into the board or it's kernel before purchase to really get a feel for it's abilities, limitations and current status.

Stable/Experimental, in my mind, is more than sufficient. Keep it as a single branch. Do think things can get a little heated especially with Tech support but no different than any other forum and especially no different than real life tech support, believe me. I have some stories.

I kinda zoomed through the past few comments but I liked the idea of offering a slightly tiered system in terms of payment. For instance, if I could donate towards Armbian dev on a specific board, that would be dope. I would throw several pretty pennies at NanoPiNeoAir. To be honest though, it probably wouldn't affect my donating habits, which is as much and as often as I can afford. W/e though, I'm a strange fruit ;D

Maybe a trend could become visable though if hundreds of cheapos buy OPi Zeros and never donate to the dev of it. Something can be said for the demand and visibility to Armbian by supporting it but something can also be said for the willingness and ability to support.

 

For instance:

~ "Donate here to support X feature of Y board" *Thermometer to goal* :P

~ Info graphic: Armbian on 9999 OPiZero boards. $50 donated. Armbian on 300 NanoPi Neo boards. $600 donated.

 

lanefu likes this

Share this post


Link to post
Share on other sites
12 minutes ago, StuxNet said:

For instance:

~ "Donate here to support X feature of Y board" *Thermometer to goal* :P

Don't really like the idea of "X feature on Y board" because there are many boards with many features and most of the features depend on upstream kernel development, not on us.

Though I like the idea of fundraising campaigns i.e. for hardware upgrades or offering better support for 3rd party hardware, i.e. DT overlays for LCD displays, touch screents, I2S codecs, etc. which requires buying and testing the hardware in question to offer good enough support.

Share this post


Link to post
Share on other sites

Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:

https://www.w3schools.com/cssref/css3_browsersupport.asp

 

If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells :)

 

2c

 

 

 

 

 

 

Nick Allen and TonyMac32 like this

Share this post


Link to post
Share on other sites

I like the feature matrix idea personally, of course someone has to do the paperwork to keep it up to date.  Red. --> Yellow. --> Green. And gray (grey?) for untested.  The "champion" for each board could be the caretaker of the information, then we just need to lace it into each board's DL/info page.

 

 

 

Share this post


Link to post
Share on other sites
On 7/7/2017 at 9:25 AM, op1tjaap said:

-    Red Hat (paid) / Centos (free) as the main OS. These are stable and ready to use

Just to clarify. RedHat was forced by GNU license to open their sources. So some folks recompile it, and there you have CentOS. What is more important competition like Oracle can use those technologies for free :)CentOS very existence is salt in the eye of RedHat ;]

 

On 7/8/2017 at 8:46 AM, Igor said:

I could describe stable like this: "stable functionality with lack of some functions and acceptable bugs".

Agreed, but functionalities that are not quite working as expected, should be disabled by default.

 

 

Share this post


Link to post
Share on other sites

I am very grateful with Armbian and its community.

 

When you compare this with Raspbian, what you see is a closed distribution vs a very open one.  The Raspberry Pi has a very big community, but seldom this community can be so influential in the "official" distribution as we can see with Armbian.  This is like to work directly with the developers, a very nice experience.

 

But of course not everything can be done or, at least, when we need that to be done.  For example with the Orange Pi 2G-IOT, so weird machine, or about how to write to eMMc in a more standard way on whatever device appear having that type of storage.

I have been using RedHat derived products almost from RedHat creation (Slackware before that), and although that model seems to be effective, it really works around the PC model that it is extremely stable and "boring" (compared with the ARM based SBC machines).  Then, although RedHat do a lot of wonderful work for Linux, I think Armbian work it is much more difficult to accomplish, and to have "THE" Armbian could be almost impossible.

 

 

However, there is a lot of information in the forums that could be reorganized, something as a "Documentation Project".  Returning to the eMMc storage example, could be possible that some information about how to use the Orange Pi 2+ internal storage can be applied on the 2G-IOT alhtough the 2G-IOT it is not actively supported.  Maybe this could help a lot of people dancing around the project asking for things, for them to become a little more aggressive and to try new solutions .... and even to contribute to the project.

 

But please, don't feel depressed because of people requests.  Many times we are lost or we have the wrong idea about how to do something, and I am sure that with the right guidance even the experienced people can obtain something useful :-)

 

Share this post


Link to post
Share on other sites
On 7/8/2017 at 2:16 PM, chwe said:

Whats about doing some 'psycological housekeeping'? 

-Red: experimental

-Orange: testing

-Yellow: stable

-Green: RPi like (no idea how we should name it)

 

 

On 7/8/2017 at 3:18 PM, op1tjaap said:

Thanks for your contributions to this post!

 

I think we agree about one thing. There are different users with different needs and different ways of using Armbian. How do we mix that!?!?


Again….that’s why I would like separate environments. I feel when using Fedora Linux that I'm part of a Development environment. I feel when I use Red Hat that I'm part of a Stable tested environment. But it is just a way I would like it. Armbian for the average users and Arm....???  for developers and power users.

 

After reading a thousand topics - here is my mustard (not moustache)!

  • ArmBeyond - experimental
  • ArmBeyond - testing
  • ArmBian - stable
  • ArmBian - mainline

 

Beyond your experience? Forget it! :P

Share this post


Link to post
Share on other sites
On 11.7.2017 at 3:47 PM, adrb said:
On 8.7.2017 at 8:46 AM, Igor said:

I could describe stable like this: "stable functionality with lack of some functions and acceptable bugs".

Agreed, but functionalities that are not quite working as expected, should be disabled by default.

so disable Wifi on nearly every sbc cause a lot of people expect to run these in AP-Mode? :lol: I don't know how much time it needs to test everything that should work on every board which has a stable Armbian. 

On 12.7.2017 at 4:40 PM, finally said:
  • ArmBeyond - experimental
  • ArmBeyond - testing
  • ArmBian - stable
  • ArmBian - mainline

;ainline kernel is often experimental. Calling something else would confuse people.. :P 

 

Share this post


Link to post
Share on other sites

Another idea, which might help fighting confusing regarding base choice - Ubuntu / Debian. Currently Armbian would be Ubuntu Xenial and when Stretch is up and ready, Armbian become Debian Stretch. Which base was used for building is noted only in small print. Build script selection between those two is hidden under EXPERT=yes ? 

op1tjaap likes this

Share this post


Link to post
Share on other sites
10 hours ago, chwe said:

so disable Wifi on nearly every sbc cause a lot of people expect to run these in AP-Mode?

 

You clearly misunderstood what I wrote.

Change "functionalities" to "functions" in my sentence, better?

Share this post


Link to post
Share on other sites
2 hours ago, Igor said:

Currently Armbian would be Ubuntu Xenial and when Stretch is up and ready, Armbian become Debian Stretch.

Or not. Stretch won't work well with older kernels (3.4 and 3.10), so IMO we will need to still keep Jessie around for some configurations, and this means adding new switches to board configs indicating if the "default" kernel is recent enough to show/allow building Stretch based images.

Share this post


Link to post
Share on other sites

I dream of a world with mainline linux for all...

 

So, any chance a compliance matrix could be made per board, including key information such as default kernel capabilities, and parse this by the build script?  Instead of hard-coding everything into the script?  Ideally the same data source document (tab delimited or xml?) could be shared between the web page board description and the build script to reduce double work.

 

And not to try to add barriers, but perhaps we should somehow stop direct linking to images?  Require linking to the board's description?

Share this post


Link to post
Share on other sites
3 minutes ago, TonyMac32 said:

And not to try to add barriers, but perhaps we should somehow stop direct linking to images?  Require linking to the board's description?

What exactly do you mean by "direct linking to images"? Redirecting to the board page instead of the image file based by HTTP referrer (in case direct links to images are posted somewhere)? This can be done in theory, but usually it also breaks download managers that don't obtain referrer value from the browser.

Share this post


Link to post
Share on other sites

Something like that.  The drawbacks are considerable, and probably more trouble than it's worth, I just see it as an easy way for a well-intentioned blogger to completely bypass all attempts to educate the user.

Share this post


Link to post
Share on other sites

I don't know if it's possible to display, when posting for the first-time in a SBC sub-forum, a form like this :

 

[ ] I have checked my power supply requirements (Link how to check that for that board).

[ ] I have checked that my system is up-to-date by running (insert command here).

[ ] I have run this program.

[ ] Went there, done that !

 

And then, when posted, paste the result of the form at the top of the post, with an automatic bot response if some checkboxes are missing.

 

The form idea is based on Mastodon Issues template https://github.com/tootsuite/mastodon/issues/4210

 

Share this post


Link to post
Share on other sites
On 7/8/2017 at 10:08 AM, zador.blood.stained said:

Though I like the idea of fundraising campaigns i.e. for hardware upgrades or offering better support for 3rd party hardware, i.e. DT overlays for LCD displays, touch screents, I2S codecs, etc. which requires buying and testing the hardware in question to offer good enough support.

Lol. That's exactly what I meant. Leave the non automatable stuff for the users which leaves Armbian to devs :P
 

 

On 7/8/2017 at 10:08 AM, zador.blood.stained said:

Don't really like the idea of "X feature on Y board" because there are many boards with many features...


That's why I chose X and Y because there are too many board variables out there to list them all! :P However at the end of the day Armbian would be able to choose X and Y fundraising campaigns. Just because it's the World Wide Web doesn't mean it has to be the Wild Wild West. Armbian could pick and choose which boards are more aesthetically/functionally appealing to the community (that put's their money where their mouth is) and then make that support/development a priority.

I think we are already seeing a form of this happening with Olimex though. They seem to be open [reliant even] to the idea of Armbian support companies like FriendlyArm seem to maintain masquerading behind their own kernel, which probably has ties to Armbians 'openness'.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
5 5

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.