lanefu

Suggestion for a (near future) product.
 
We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
 
A Lean SBC exclusively for server tasks.
"The Ultimate Homelab SBC"

Real 802.11at POE+ means only 1 cable for your compute node
Use SPI flash for custom provisioning configuration
 
Optimized for Compute
"Ready for clustering and kubernetes"
Has the Performance and Storage you need to easily deploy for clustered computing

Suggested Reference Specs
RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options

If the cluster is needed for real productive work, and not for "try and practice". Need to look at the correct configuration of the entire complex. Required elements.
1. High-quality metal housing for use in racks. The metal of the housing shields the interference, ensures proper cooling and stability of the parameters.
2. Power supply unit. There is not even anything to discuss here, only a high-quality product and it is very desirable with hot replacement and redundancy. If the cluster is running, it is not allowed to interrupt it due to a power drop.
3. Smart cooling system (passive radiators on the elements and a general active fan system with control sensors). It is a "system", and not a set of mismatched fans with difficult docking and control. Independent hardware management.
4. Easy extensibility and scalability (different modules by performance and configuration from minimum to maximum). And the free build-up (addition) of modules without complex reconfiguration of the entire system.
Firefly R1 R2 servers are well suited for these requirements. But this is for those who really understand that they need the maximum cost / result ratio from the cluster system. For those who only want to practice and learn the principles-you can use any model, up to the simplest TV boxes. 

I had to try 🤓

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.
 
 

Suggestion for a (near future) product.
 
We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
 
A Lean SBC exclusively for server tasks.
"The Ultimate Homelab SBC"

Real 802.11at POE+ means only 1 cable for your compute node
Use SPI flash for custom provisioning configuration
 
Optimized for Compute
"Ready for clustering and kubernetes"
Has the Performance and Storage you need to easily deploy for clustered computing

Suggested Reference Specs
RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options

@lanefu Ahahah yeah it seems you are describing more a Cluster Node SBC than a NAS which is our main focus at Kobol ;-) Sorry... But yeah while for me PoE = Remote Power Supply for the big family of everything & nothing that we call IoT... I can clearly see the benefit of it for easy clustering of a small SBC compute node.
 
Maybe you should move the topic to a more general Rockchip thread, because honestly I don't think such design would be a priority for us right now... but who knows ;-)

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

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

Suggestion for a (near future) product.
 
We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
 
A Lean SBC exclusively for server tasks.
"The Ultimate Homelab SBC"

Real 802.11at POE+ means only 1 cable for your compute node
Use SPI flash for custom provisioning configuration
 
Optimized for Compute
"Ready for clustering and kubernetes"
Has the Performance and Storage you need to easily deploy for clustered computing

Suggested Reference Specs
RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

https://status.uptimerobot.com
 
lol

We have a realtime status page for primary Armbian web resources available here:
 
https://status.armbian.com
 

I'll continue to help with PBP..   As you all are familiar my work usually comes in bursts..  But yeah i'd like to build kind of a specific community up for it.. almost wonder if its worth a subforum under RK3399 or osmething.

I'm getting a PBP bare motherboard that i can use for the bare metal testing of liek uboot etc... and @Rich Neesehas a PBP coming in the mail
 

I suppose my question was less where you would run it, and rather what exactly you would want to test.
 
Unit tests are great for functional libraries with known inputs/outputs, but are somewhat trickier with user interfaces.
 
Testing the individual scripts should be more possible if you're looking for actual run products (eg - changes to /etc/apt/sources, or edits to config files).

Well we have a big arm server already configured as a github runner. I suppose we could chroot an armbian rootfs or place in a container 
 
So i guess something that can test armbian-config works as expected

Follow some bash tutorials.  Maybe the advanced bash scripting guide.
 
then just use a text editor and mess with the code
https://github.com/armbian/config
 

@Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ...
 
best wishes and good luck - hexdump

Since linux v5.4 armbian_build enables the CONFIG_RT_GROUP_SCHED config option.
 
Some armbian users use the soft real-time features for either real-time audio (jackd), or control (eg. klipper_host_mcu),
However, real-time group scheduling, enabled by this options complicates the user space configuration required to acquire real-time scheduling in applications and daemons.
 
Setting ulimit -r or LimitRTPRIO= is no longer enough, it is also required to allocate CPU time for RT task. In a brutal way this can be done as 
 
echo 950000 > /sys/fs/cgroup/cpu,cpuacct/{system,user}.slice/cpu.rt_runtime_us JACK documentation recommends using cgroup-tools for configuration. This is redundant with systemd's own configuration of cgroups hierarchies.
 
However, it is currently not possible to setup with systemd configs files: the team responded "wontfix, accounting rules for RT_GROUP_SCHED are too convoluted for systemd to support"
The systemd's README was updated with the follwing warning:
 
I was hesitant to open an issue on armbuild_config. The changes in the config file are quite recent (Dec 2019) and probably unintentional (kernel default).
But, I could be missing something. Surely lots of folks use RT scheduling on their board. Maybe along with an older kernel ?
Does real-time group scheduling have any use on SBC ?
Do you have simpler solution for this problem (other than CONFIG_RT_GROUP_SCHED=n) ?

So, there are GUI based dialog frontends. Where you would do something like this in dialog:
 
$ dialog --menu "Choose an option" 0 0 0 a argle b bargle  
Or whiptail ...
 
$ whiptail --menu "Choose an option" 0 0 0 a argle b bargle  
You could use a different frontend like zenity to do something similar. Obviously the arguments would change:
 
$ zenity --title "Choose an option" --column tag --column Description --list a argle b bargle  
If you could distill it down to minimum information required to populate either list, you could have a bash wrapper that just calls the specified frontend, or just defaults to the GUI version if the $DISPLAY variable is set.

As a fun little hack, here's a little example wrapper for the dialog program. Mark it executable, toss it in /usr/local/bin, and fire up armbian-config.
 
Obviously delete it afterwards. don't leave it there. That's probably a bad idea.
 
But might work as a brief tech demo of what an X11 driven armbian-config might look like ...
 

dialog

I am not a user of Armbian and do not plan to.
 
Wanted to write here and thank to whoever provided UART U-Boot files as I used them to get my EspressoBin v5 running.
 
Now it has mainline U-Boot 2021.01 and works as normal EBBR board. I plan to use OpenWRT on it and use as a router for some time.
 
Few more words: https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/

Create own menu wrapper functions so menu functionality is not hard coded and we can switch between them easily.

OK. It seems we are sticking to BASH. What about desktop?
 
I open this Jira and put down few tasks, those which I am aware of at this moment. Feel free to add / remove things, so we can make some structure. Tasks are just a basic / quick draft.
 
https://armbian.atlassian.net/browse/AR-638
 
I am also cautious about not creating a project we would not be able to move forward. Which is why we have to count resources and see how we can handle this, to which extend and by when. 

Wherein I explain my conversion... 
 
Pine64 was barely on my radar in the past.  There are so many SBC and companies just trying to sell crap it can be hard to tell who is who some times, until you look into one company / board / device or another, a little more in depth.
 
I have been following Librem 5 development for a long time, so I was aware of PinePhone, but they seemed in my mind back then a bit like a "Johnny come lately" who were just trying to capitalize on whatever Purism were trying to do.
 
Then @lanefu was raving about his PineBookPro in IRC, it was only then I started really poking around their forums the last month or so, and now I must say my opinion of them have really changed a lot.
 
Now they seem to me like a really hacker mindset, hardware oriented company.  They really seem to just enjoy making and selling interesting/compelling hardware (for cheap! to get the stuff out there).  They sell spare parts for example, and have a wiki with lots of good information, and schematics, etc.  And they have a nice community forming around their devices, who are in turn, creating spin-off projects...  In short, they seem to be the genuine article (in a time where many other companies are riding on the wave of popularity of "open source" whilst in actuality being nothing of the sort).
 
Purism seem more committed to pushing the supply chain in a F/LOSS direction, but how can we know that Pine64 are not (without being mind readers)?  Well, I have always realized Pine64 are simply taking a different approach.  Some times I fear Purism may have bit off more than they can chew.  They are shipping now, but only in low numbers.  r/Purism is a cesspool of nasty, disgruntled people (maybe I expect too much, it is Reddit, after all).  But if Purism fail, I fear that will set back GNU/Linux on phones overall.  Which is the only thing I really care about.  At any rate, even if I were to order one now, it seems I would be waiting at least a year, also with a less than nil chance of never receiving the device at all, unfortunately.
 
The Pine64 approach, whilst admittedly not as appealing to my inner rms zealot , is perhaps more realistic and attainable.  The older I get, and more real world project / life experience, I start to wonder if this may be the better approach.  Smaller steps, and iteration.  Who knows where it will lead, if we can get more numbers of Linux phones actually in the hands of more people.  For example, apparently some guy already reverse engineered the PinePhone modem OS, and has it running with plain Linux, without blobs!  Amazing!
 
At some point I guess I realized that PinePhone and Librem 5 are not competing with one another, and that none of this is an either/or proposition.  In fact, both projects are advancing the state of the art of GNU/Linux phones; just in different ways.
 
Very recently, I was trying to upgrade to the latest LineageOS on my Galaxy s5.  Of course this is a pain in the arse and why I only get around to really doing it every year or two it seems.  And every time, it seems Google / carriers / whoever have tightened the noose a little bit more.  So, this time around, I finally reached the point where I became so disgusted, that I was willing to actually cancel my cellular service altogether, rather than continue dealing with this nonsense (specifically: VoLTE is becoming mandatory on US carriers, and LineageOS have said they cannot / will not support VoLTE for whatever reason).
 
Importantly, I think it's important to point out that I think any human being needs to reach some tipping point, where our disgust for ${current platform} exceeds the hassle and/or learning curve of switching to ${new platform}.  I have said this many times to people who are curious about switching from Windows -> Linux for example.  Also, this point varies for different people (I get there sooner as I care more about Freedom and have less patience for dinosaur sociopathic proprietary business models, etc.).
 
Anyway, reading some recent threads/posts at Pine64 forums revealed that the PinePhone is currently actually apparently quite usable as a "daily driver" at least for the bare minimum of things I would say that entails: phone/voice (including VoLTE(!)), SMS, and data (on most carriers in US, anyway[0]).  Which was honestly better than I was expecting.  Of course, there are many, many programs in the repositories that do not work properly (or at all) on a phone interface.  And what any individual will consider "bare minimum" acceptable will vary greatly!  But for me at least, that basic phone/data/SMS functionality is enough.  All the rest will not only come in time, if I have a PinePhone in hand I will be able to actively contribute to making it happen, sooner.
 
So, yeah, I pulled the trigger on a PinePhone.      And I plan to use it (more or less) as my "daily driver", likely with my old s5 along side for some period of time, just in case (I figure I should be able to tether it if needed, as tethering is also already working on PinePhone).
 
Long term, I think we still need to continue to push the supply chain in a more explicitly F/LOSS/H direction.  Therefore (assuming they don't go bankrupt before then) I will likely also purchase one or more Librem devices from Purism in the future to support that goal.
 
But buying a PinePhone now gets me in the game, sooner.  And I really started to like what they have going on over there.
 
Please discuss.
 
Cheers,
TRS-80
 
[0] some times requiring workarounds