gnasch

Yes, I understand, but I don't have tools needed for that. I tried scraping with a needle, but look like solder is deeper under the chip.
And by the way official seller will ship me new board for almost free (just buying tracking number for 0.91$). 

More or less the same. I have a nice little project with retrorangepie and an old monitor for a bar, but I prefer die with my ideas instead of joining Facebook. Just the fact to write the word let me the impression my fingers are dirty.
 
I have a BT gamepad working with Retropie and I want test it with retrorangepie on OPzero and it's beautiful composite output, perfect for an RF converter perfect for the antenna plug of the old monitor.

maybe start with this one:
 
https://www.youtube.com/watch?v=Ho2W902s5P8

Hello All,
 
it`s like Igor says: it`s all in the SD-Card. It seems, that my SANDISK Ultra 16gb SDCard for 10 EUR was or is the Problem. But it`s really special:
 
I bought this Card in EBAY with the description 80MB/sec. and when it comes to me, first i used H2TESTW from heise.de. The capacity was ok, but writing was constant at 10 MB/sec. and later reading was constant at 17MB/sec. OK, i wrote this to the Seller and 5 Min. later i got my money back (paypal). EBAY told me, that the seller has stopped the deal and i got a friendly mail in the ebay system from the seller, that they will look after it in their supply chain and so on.... i can keep the card. Now I think, that time of fake SD Cards about the capacity is over, next level are fake cards about speed. OK, when youre interested in SD Card testing Tools, look here:
 
https://www.geckoandfly.com/22803/detect-fake-usb-flash-drives-sd-cards-ssd-disk/
 
Next step: I took an old SANDISK 8 GB Card and performed the SD Card Writing Procedure now on Linux, not windows. Note, that i have written the 16 GB Fake Card on Linux before again under Linux too and it doesnt boot. OK, here we go with the 8 GB old Card:
 
dd bs=4M if=Armbian_5.25_Cubietruck_Debian_jessie_next_4.9.7.img of=/dev/sde status=progress
 
I put the card in the cubietruck and everything was allright, 1234 with root over ssh, great. At the moment the "cubie on SD-Card" is getting all updates and i can write this at the end:
 
Two hours ago, i purchased an 32GB SANDISK UHS SD Card, up to 95MB/sec for 26 EUR including shipping. Look here, if you like:
 
http://www.ebay.de/itm/132121757759
 
In prior Installation I was using SATA Disk as root file System, just booting up from 4 GB SD Card. Now i will follow Igors suggestion like this:
 
1) System complete on good, new and fast SD Card
2) SATA just for (private) Data
3) Backup System (on Card) once per month with dd
4) Backup Data by feeling with rsync
5) The best: possibility to boot from nand (and checking and mounting SATA) when SD Card fails
 
OK, i will keep you informed in a few days...
 
Best regards
 
Eckhard
 
 

@tkaiser: thank you very much for your help. I was able to track down the bug. Contrary to first belief, the kernel is not concerned, but in h3disp on line 196 the pll_video is initialized to 646 MHz. With kernels divisor of 4 this results in pixel frequency of 161.5 MHz, which is too high for Vesa 1280*1024.
So I  replaced this initialization with 432 MHz, which results in correct fD of 108 MHz. Now the monitor synchronizes.
Unfortunately I found a bugfix by @igor on 24.Oct.2016 which inserted the 646 MHz value. I could not read the reasoning behind this (facebook srsly?), so I would kindly ask to revert this change if no important reasons for it exist.
 
best wishes and thanks to armbian team for your great work!
gnasch

Okay, mainline kernel is now version 4.11 and H3 S/PDIF driver marked as working. Below is a brief guide on how to enable it.
 
Unlike legacy kernel, in which to configure gpio and device drivers it was necessary to edit the .fex file, in mainline we need device tree overlays.
Login as root First we need to find out which device tree is being used. To do this, you must execute: cat /proc/device-tree/model; echo In my NanoPI M1, for some reason, is used the device tree for OrangePI PC
In order to select the correct device tree and an overlay needed to enable the S/PDIF, we need to do some changes in /boot/armbianEnv.txt file.
Open it in editor (root privilegs required) and add 2 lines: fdtfile=sun8i-h3-nanopi-m1.dtb overlays=spdif-out If you need the driver of the IR receiver and (or) an analog audio codec, you need to add the cir and (or) analog-codec to the overlay list via spaces
It's all. Save file, exit editor and execute: sync reboot  
After reboot login as root again
Get the list of ALSA devices available: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [On-board SPDIF], device 0: spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0  

 

So, here is a first version of the tutorial - it is surely not perfect, so please comment, I would improve it:
 
https://drive.google.com/file/d/0B9rkZNVvi3bIaks1N2pQWEh3S1k/view?usp=sharing
 
In the tutorial, I tried to motivate why I think it is useful. Certainly, there are also other ways of avoiding writing to SD-cards (e.g. log2ram, etc.), but live-boot is really convenient, after you get it working.
 

Full root filesystem encryption on an Armbian/Orange Pi PC 2 system
 
MMGen (https://github.com/mmgen)
 
WARNING: This tutorial has been obsoleted by Full root filesystem encryption on an Armbian system. In addition, an automated script is available, which can be downloaded here or by cloning the following repository: git clone https://github.com/mmgen/mmgen-geek-tools
 
This tutorial provides detailed, step-by-step instructions for setting up full root filesystem encryption on an Armbian/Orange Pi PC2 system. With minor changes, it can be adapted to other Armbian-supported boards. The disk is unlocked remotely via ssh, permitting unattended bootup.
 
Requirements:
Linux host system One Orange Pi PC 2 Two blank Micro-SD cards (or a working Armbian system for your board + one blank SD card) USB Micro-SD card reader Ability to edit text files and do simple administrative tasks on the Linux command line  
 
Part 1 - Get, unpack and copy an Armbian image for your board
 
Create your build directory:
$ mkdir armbenc-build && cd armbenc-build Download and unpack an Armbian image for your board and place it in this directory.
 
If you have two blank SD cards, the first will hold an ordinary unencrypted Armbian system used for the setup process, while the second will hold the target encrypted system.
 
Alternatively, if you already have a working Armbian system for your board, you can use it for the setup process. In that case, your one blank SD card will be considered the “second” card, and you can ignore all instructions hereafter pertaining to the first card.
 
Note that for the remainder of this section, the first SD card will be referred to as '/dev/sdX' and the second as '/dev/sdY'. You'll replace these with the SD cards' true device filenames. The device names can be discovered using the command 'dmesg' or 'lsblk'. If you remove the first card before inserting the second, it's possible (but not guaranteed) that the cards will have the same device name.
 
Insert the first blank SD card and copy the image to it:
$ sudo dd if=$(echo *.img) of=/dev/sdX bs=4M After the command exits, you may remove the first card.
 
Now insert the second SD card, which will hold a small unencrypted boot partition plus your encrypted Armbian system. Copy the image's boot loader to it:
$ sudo dd if=$(echo *.img) of=/dev/sdY bs=512 count=32768 Now partition the card:
$ sudo fdisk /dev/sdY Within fdisk, create a new DOS disklabel with the 'o' command. Use the 'n' command to create a primary partition of size +200M beginning at sector 32768. Type 'p' to view the partition table. Note the end sector. Now create a second primary partition beginning one sector after the first partition's end sector and filling the remainder of the card. When you're finished, your partition table will look something like this:
Device Boot Start End Sectors Size Id Type /dev/sdY1 32768 442367 409600 200M 83 Linux /dev/sdY2 442368 123596799 123154432 58.7G 83 Linux Double-check that the second partition begins one sector after the end of the first one. If you mess something up, use 'd' to delete partitions or 'q' to exit fdisk and try again.
 
Once everything looks correct, type 'w' to write the partition table.
 
Now you'll begin the process of copying the system to the second card. First you'll associate the image file with a loop device and mount the device:
$ losetup -f # displays the name of the loop device; remember this $ sudo losetup -Pf *.img # associate image file with the above loop device $ mkdir mnt boot root $ sudo mount /dev/loopXp1 mnt # replace '/dev/loopX' with the above loop device Create a filesystem on the SD card's boot partition and copy the boot partition data from the image file to it:
$ sudo mkfs.ext4 /dev/sdY1 $ sudo e2label /dev/sdY1 OPI_PC2_BOOT # don't omit this step! $ sudo mount /dev/sdY1 boot $ sudo cp -av mnt/boot/* boot $ (cd boot; sudo ln -s . boot) Create the encrypted root partition (for this the 'cryptsetup-bin' package must be installed on the host). You'll be prompted for a passphrase. It's recommended to choose an easy one like 'abc' for now. The passphrase can easily be changed later (consult the 'cryptsetup' man page for details):
$ sudo cryptsetup --pbkdf argon2i --pbkdf-memory 600000 luksFormat /dev/sdY2 Note that the --pbkdf-memory argument must be less than the available free memory in kilobytes at bootup time.  Otherwise you’ll get an out-of-memory error and your disk will fail to unlock.  600000 is a safe value for the Orange Pi PC2 with its 1GB of RAM.
 
Activate the encrypted root partition, create a filesystem on it and mount it:
$ sudo cryptsetup luksOpen /dev/sdY2 foo # enter your passphrase from above $ sudo mkfs.ext4 /dev/mapper/foo $ sudo mount /dev/mapper/foo root Copy the system to the encrypted root partition:
$ (cd mnt && sudo rsync -av --exclude=boot * ../root) $ sync # be patient, this could take a while $ sudo mkdir root/boot $ sudo touch root/root/.no_rootfs_resize Unmount the mounted image and second SD card, and free the loop device and encrypted mapping:
$ sudo umount mnt boot root $ sudo losetup -d /dev/loopX $ sudo cryptsetup luksClose foo From here on, all your work will be done on the Orange Pi.
 
 
Part 2 - boot into the unencrypted Armbian system
 
If applicable, insert the first (unencrypted) SD card into the Pi's Micro-SD card slot.
 
Insert a USB card reader holding the second SD card into a USB port on the Pi.
 
Boot the Pi.
 
If applicable, log in as root with password '1234', follow the password update instructions, and stay logged in as root. The following steps will be performed from a root shell.
 
 
Part 3 - set up the unencrypted Armbian system
 
Update the APT package index and install cryptsetup:
# apt-get update # apt-get install cryptsetup  
 
Part 4 - set up the encrypted Armbian system
 
 Prepare the encrypted system chroot:
# BOOT_PART=($(lsblk -l -o NAME,LABEL | grep OPI_PC2_BOOT)) # ROOT_PART=${BOOT_PART%1}2 # cryptsetup luksOpen /dev/$ROOT_PART foo # mkdir /mnt/enc_root # mount /dev/mapper/foo /mnt/enc_root # mount /dev/$BOOT_PART /mnt/enc_root/boot # cd /mnt/enc_root # mount -o rbind /dev dev # mount -t proc proc proc # mount -t sysfs sys sys Copy some key files so you'll have a working Internet connection within the chroot:
# cat /etc/resolv.conf > etc/resolv.conf # cat /etc/hosts > etc/hosts Now chroot into the encrypted system. From this point on, all work will be done inside the chroot:
# chroot . # apt-get update # echo 'export CRYPTSETUP=y' > /etc/initramfs-tools/conf.d/cryptsetup # apt-get install cryptsetup-initramfs dropbear-initramfs # for focal and buster # apt-get install cryptsetup dropbear-initramfs # for bionic Check to see that the cryptsetup scripts are present in the initramfs (command should produce output):
# gunzip -c /boot/initrd.img* | cpio --quiet -t | grep cryptsetup Edit '/etc/fstab' to look exactly like this:
/dev/mapper/rootfs / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 /dev/mmcblk0p1 /boot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 Add the following lines to '/etc/initramfs-tools/initramfs.conf'. If the Orange Pi's IP address will be statically configured, substitute the correct static IP address after 'IP='. If it will be configured via DHCP, omit the IP line entirely:
DEVICE=eth0 IP=192.168.0.88:::255.255.255.0::eth0:off Add the following parameters to the quoted bootargs line in '/boot/boot.cmd'.  Note that the 'root' parameter replaces the existing one:
root=/dev/mapper/rootfs cryptopts=source=/dev/mmcblk0p2,target=rootfs If you want to be able to unlock the disk from the virtual console (which you probably do) as well as via ssh, then comment out the following line:
# if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS0,115200"; fi In case you're wondering, 'setenv console "display"' doesn't work. Don't ask me why.
 
Compile the boot menu:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Copy the SSH public key from the machine you'll be unlocking the disk from to the Armbian machine:
# rsync yourusername@remote_machine:.ssh/id_*.pub /etc/dropbear-initramfs/authorized_keys If you'll be unlocking the disk from more than one host, then edit the authorized_keys file by hand and add the additional SSH public keys.
 
Edit '/etc/dropbear-initramfs/config', adding the following lines:
DROPBEAR_OPTIONS="-p 2222" DROPBEAR=y Reconfigure dropbear:
# dpkg-reconfigure dropbear-initramfs Make sure everything was included in the initramfs (both commands should produce output):
# gunzip -c /boot/initrd.img* | cpio --quiet -t | grep dropbear # gunzip -c /boot/initrd.img* | cpio --quiet -t | grep authorized_keys Your work is finished! Exit the chroot and shut down the Orange Pi:
# exit # halt -p Swap the SD cards and restart the Pi. Unlock the disk by executing the following command on your remote machine. Substitute the Pi's correct static or DHCP-configured IP address for the one below. If necessary, also substitute the correct disk password in place of 'abc':
$ ssh -p 2222 -x root@192.168.0.88 'echo -n abc > /lib/cryptsetup/passfifo' If you choose to unlock the disk from the tty, just enter your disk password and hit ENTER.
 
If all went well, your root-filesystem encrypted Armbian system is now up and running!

This should be possible but you would've to adjust fex file:
 
1st step: check schematics how PL03 is handled to get the idea how this button works (I'm a hardware NOOB)
 
2nd step: choose the pin from the list of declared GPIO pins: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepiplus.fex#L331-L349 for example PG07 located at physical pin 40 on the header:
 

3rd step: edit the fex file (use either bin2fex and convert /boot/bin/orangepiplus.bin to a temporary location or use the link above), remove the GPIO definition so that it reads gpio_num = 18 and the order of pins in this section is intact. Then replace occurences of PL03 in line 232 and 1241 with the pin you chose (PG07).
 
4th step: please report back here in this thread

The HDMI relevant patches can be found here: https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default, kernel is pulled from there: https://github.com/igorpecovnik/lib/blob/master/config/sources/sun8i.conf#L10-L11 and there is an open bug report regarding h3disp: https://github.com/igorpecovnik/lib/issues/624
 
 

You are correct: it's not necessary to modify the FEX file to use the GPIO pins, and you should use the mainline formula to calculate pin numbers.
 
I'll share what I learned attempting to solve this problem in case anyone else runs into it.
 
As the error states, it's a permissions problem. Using "sudo echo" won't work because the redirection occurs before sudo is started, which ends up you trying to write to a file you don't have permissions to.
 
To do a one-off manipulation of a GPIO pin, you have to start a separate shell as a superuser first, then use echo. For instance to turn pin A10 on:
$ sudo sh # echo 10 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio10/direction # echo 1 > /sys/class/gpio/gpio10/value Or you can use tee to avoid creating a subshell:
$ echo 10 | sudo tee /sys/class/gpio/export $ echo out | sudo tee /sys/class/gpio/gpio10/direction $ echo 1 | sudo tee /sys/class/gpio/gpio10/value A better, more permanent solution is to create a separate GPIO group, add yourself as a user to that group, and then give the GPIO group permissions to modify the GPIO pin directories:
$ sudo groupadd gpio $ sudo usermod -aG gpio <your_username> $ su <your_username> $ sudo chgrp gpio /sys/class/gpio/export $ sudo chgrp gpio /sys/class/gpio/unexport $ sudo chmod 775 /sys/class/gpio/export $ sudo chmod 775 /sys/class/gpio/unexport You'll also have to modify the permissions on the directory of each GPIO pin you add. Again using pin A10 as an example:
$ echo 10 > /sys/class/gpio/export $ chgrp -HR /sys/class/gpio/gpio10 $ chmod -R 775 /sys/class/gpio/gpio10 Then you can change that pin as necessary without being a superuser:
$ echo out > /sys/class/gpio/gpio10/direction # set as output pin $ echo 1 > /sys/class/gpio/gpio10/value # set high $ echo 10 > /sys/class/gpio/gpio/unexport # reset the pin  
 

Hi twilipi
then it is clear. when you connect your two clients with a cable there is no DHCP server in this "network". So the desperate clients will construct an APIPA Address to try and communicate.
But when you connect the clients to your internet router, the DHCP server in it will give an other address to each client. you have to find out these new addresses! First on your macbook, say it will be something like 192.168.x.y. Then you can find out the address of your router, often 192.168.x.1.
and once you have this you enter your routers web interface with http://address.of.your.router .
There you can find out, what address it assigned to our opi, often in a list called "home network" or "DHCP table".
Finally connect to your opi at this address.
 

Hello,
 
I have solved my problem by the installation of gnome-terminal.
 
This terminal has large, more readable black fonts on white background.
And it supports cut and paste!
 
I am surprised that Armbian has such a lausy default terminal,
my recommendation is: implement gnome-terminal!
 
Best regards
Walter

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix.
 
I guess I'll read a book or something instead.

Anyone ever dealt with OpenMediaVault (OMV) on SBC? Great piece of software but pretty slow, right? One of the many reasons why that happened are outdated crappy kernels and bad settings. I looked at an OMV image for A20 based boards like Banana Pi Pro recently, ended up here http://simplenas.com/download/bananas-simple-system and simply thought: Are you kidding me? Your stable release is based on horribly outdated Debian Wheezy, a kernel 3.4.something and a 2.x OMV release?! What a mess...
 
Igor had an OMV install routine since a long time in his Debian-micro-home-server post-processing script but since an Armbian user evaluated using Armbian's build system to generate OMV images we thought... why not integrating it in Armbian?
 
We started yesterday to prepare all kernels for the Ethernet equipped boards to meet the OMV requirements (just Quota/ACL/NFS stuff) and then played around with an installation routine that can be used from our image customization script to generate OMV images without the need to tamper with them manually later (one of Armbian's design goals). A first preview is now available. All that's needed to create a fresh OMV image from scratch is checking out Armbian build system as outlined in the docs and then use the new customize-image.sh.template as userpatches/customize-image.sh, uncomment the InstallOpenMediaVault line and then create an Debian Jessie Armbian image that will be a full OMV 3 release afterwards.
 
This will take some time but then you have an OS image that can be booted on your device of choice, needs 2-3 minutes for housekeeping (finishing the installation -- network connection required!), reboots and will then be accessible through http://openmediavault.local (if your router's DHCP server is not broken then http://openmediavault will also work). No need to use any smelly OMV images you find in dark corners of the Internet. Just create one yourself if needed or ping your hardware vendor of choice to look into the possibilities he gets when relying on a solid foundation for creating OS images.
 
Quick performance test with the beefiest device we currently support (Solid-Run's Clearfog Pro):

 
86/98 MB/s (write/read) over a wired connection isn't that bad but with other/slower devices we've seen that there's some room for improvement. I will join openmediavault forum soon to discuss stuff there. Especially that Armbian's cpufreq scaling settings get overwritten (/etc/defaults/cpufrequtils) is a bad thing since the settings OMV uses are ok for x86 boxes but not for those small SBC.
 
All quick tests looked good. I tried hard to destroy configurations on OrangePi Plus 2E, Banana Pi Pro, Clearfog Pro and Pine64+... but to no avail. Even nasty things like creating btrfs stripes on the command line (USB3+SATA with kernel 4.10) and then importing into OMV worked flawlessly, Armbian's nand-sata-install mechanism executed while OMV running to transfer the installation to a SATA disk worked and even downgrading the above btrfs stripe to 4.4.59 and moving the USB3 connected disk out of its enclosure and behind an ASM1062 PCIe SATA controller worked flawlessly (though performance sucks for whatever reasons). I'm pretty impressed by OMV
 
No need to fiddle around with the command line, everything can be configured through a browser... nice. This is how the interface looks like:

 

info
I connect 60Gb 2.5" IDE HDD via Jmicon USB-PATA-SATA bridge with ext power supply
image S9xxx_4G_ICEWM_MATE_XFCE_LXDE_LXQT_20170129.img
The system is booted up and running
Also using gparted I ran a swap of 4GB  partition sda3
Using QEMU successfully launched winxpsp3 , 512 Mb RAM , with networking
Sandra 2005 determined the Pentium2-333 processor, the speed is about 70-200 MIPS
SoC S905X / TVBox MiniM8II / SZTomatoto vim v1.2
 

I already forgot how it was  What is wrong with current logic?
 
You can customise this "activity link" very much: https://forum.armbian.com/index.php?/discover/&do=create

Hey all,
I've been using Allwinner boards for the last couple of years and Armbian+forums have made this a workable thing that I promote to my friends as being The Way To Go instead of being a big fat waste of time. 
Igor + Tkaiser (and anyone else forgive me if I didn't give you a shout) - You fucking rock.  You really do; you've all provided amazing amounts of support for multiple kernels and userspaces and in the face of (at least) bullshit from the chip vendors, yet you are absolutely crucial to them being taken seriously.
The work from Armbian has (for me) made the difference between BananaPi, OrangePi, etc all being an unusable washout of #ShitDidn'tWork, to being something I am excited to build into things and personally promote.
 
Igor, Tkaiser; I've never met you but your work speaks for itself; you give a shit and you keep giving and shit and THANK YOU FOR THAT.
I just donated you some $. If you're still reading this and you're using their work, you might think about doing same.   FWIW; what turned my head is seeing Igor and crew putting _years_ of work into this. 
 
Anyway, much, much, much appreciated. From one to another; good job.
DrTune

To be honest, i don't like new look of the forum. It is used from some time, in some other forums i used to visit, so i have a look into this already. I can't explain it well, but the skin and arrangement itself are confusing and dysfunctional for me. The biggest problem is Unread Content/All activity. This focusing on posts and not topics itself is not comfortable for me. It is not so notably here, but in forums with more activity is madness and making following of new treads and topics impossible. Not all "improvements" are good and i can't guess who can decide this as better. But i guess you have some functional reason for this upgrade, which is downgrade in my eyes. Maybe going into some other forum platform is better idea. After all, this is me, maybe other visitors would find it better.

Back to the main topic of the thread. I do now have a working (beta) pine64 / Armbian based system that can connect to a Logitech Media Server and output PCM streams up to 24/384.
 
I made a mistake regarding native DSD as this is not supported in kernel 3.10.  Squeezelite/alsa is silently converting to PCM (which still sounds pretty good).
 
I have a thread on the slimdevices forums if anyone is interested in a cheap, audiophile quality device feeding a USB dac.
 

H3 does include RTC, but this board doesn't expose any option to use a backup battery for it. Additionally there may be a problem with RTC clock source configuration in the legacy kernel, but I don't think anybody is interested in investigating it (at least for the legacy kernel)

If you use newest build images, we now provide some overlays in the /boot/dtb/overlay folder, and your can activate them in /boot/armbianEnv.txt with :
overlays=uart1-enable uart2-enable i2c0 spi0-spidev

if your monitor is not of hdmi but of dvi type
then you need to use the -d switch in h3disp utility.

As I promised, I published helper tool. Please check this comment: https://github.com/igorpecovnik/lib/issues/594#issuecomment-272992961

why move into the distro its easily installed outside of the repo as is.. 
 
here is the reason i use armbian cause its lightweight non BS fluff, just pure console, stable and fast. If we start adding webui that requires a lot of dependencies its not gonna be lightweight its just gonna be another bloated distro.
 
rather do my management in console then thru a webui.
 
+1 on leaving this outside the distro all together.
+1 let the users that really want this to install it on their own.
 
hell im not forcing users have LMS into the distro so please dont force me to use software i dont want, let em install it on their own via adding repos.
 
plus the dev team is small enough so just keeping up with releases etc for webmin is bad enough rather let em focus on providing a solid kernel for the devices then looking at what software has been released this week.