Tido

I mean that outside links should not contain exact kernel and release versions, they should look like
http://image.armbian.com/betaimages/Armbian_Nightly_Orangepizero_Ubuntu_xenial_default.7z
or
http://armbian.com/download?type=nightly&board=orangepizero&release=xenial&kernel=default
that should get HTTP 302 redirect to actual image file Armbian_5.24.161208_Orangepizero_Ubuntu_xenial_3.4.113.7z
 
 
Meaning of "legacy" or "vanilla" depends on board family/SoC and it needs to be stated on the download page (like it was before, but it should be shorter)
I don't have a better word to replace "legacy", but "vanilla" should probably be changed to "mainline"
For example in case of sun4i/sun7i it would be good to have at least this:
Legacy kernel - optimal for multimedia and desktop usage scenarios Mainline kernel - optimal for headless server usage See "Status matrix" for detailed comparison and we could have a table (I'm assuming Markdown tables are supported) that would show that currently HDMI audio, VE accelerated video decoding, DRM video driver and Mali are not available on mainline
 
Maybe nightly tab should also have "buttons" instead of links for consistency, and images buttons/links should be on top and repository info/instructions should be lower

BTW: This also prevents me contributing to any documentation in the meantime. Since writing documentation that is not accessible afterwards doesn't make any sense.
 
We still fail horribly to look at Armbian from the outside. We know that the average users hates to read stuff (instructions, documentation, whatever). He gets a new toy and wants it up and running. Or he gets annoyed by the vendor offerings and wants to try out an Armbian image.
 
Eg. a Pine64 user has been told to try out Armbian to make use of the LCD (nightly image!). Most probably the journey is like this:
Arriving at https://www.armbian.com (text, images, nothing he's interested in except of the next link) https://www.armbian.com/download/ -- aha, spotted Pine64 https://www.armbian.com/pine64/ -- aha, 'legacy' and 'vanilla' (WTF?!) and 'Jessie/Xenial server', so let's try out vanilla (sounds nice) and of course Jessie since that's what I know from Raspbian and the featured Lenny-builds from pine64.pro Let's take that crappy 4GB SD card flying around and use WinDiskimager since this tool ensures that I don't get notified when burning fails Ok, Armbian is crap, doesn't even boot, back to Jessie from pine64.pro One week later: Let's try out this Armbian stuff again since I realized that the crappy SD card I used is really broken So let's burn Armbian Jessie (5.20) again, this time it boots but there's no HDMI output (vanilla!) and no way to activate the LCD as described in their 'Hardware info' tab (there they're talking about 5.21, 5.24 and 5.25 but they only provide 5.20. WTF?!) Ok, Armbian sucks, back to the pine64.pro offerings @Igor: Currently no one who is not an Armbian developer or is guided by responsible guys like @pfeerick is able to find the nightly build for Pine64 and can benefit from all the great stuff we include. It's simply unaccessible and really a mess. And it won't change unless we start to look at this here from the outside.
 
I second Zador's suggestion: there have to be maximum 3 sentences that outline the most important stuff directly. Users start to read the fine print later if at all. When they want to download an image they need just a little information but that has to be easily accessible.
 
Also I think it would be a great idea to not link to an image with static version information (Armbian_5.20_Pine64_Debian_jessie_3.10.102.7z) but to a symlink that always resolves to latest version (Armbian_stable_Pine64_Debian_jessie_legacy.7z). Currently people link to OS images below http://http://image.armbian.com that get outdated automagically with Armbian improving. That's bad.
 
And as soon as Etcher 1.0 is released we should completely switch to .etch format (download checksum integrated, using Etcher guaranteed, no more hassles with broken download/burning processes. Saves our users and us a lot of time and frustration).

And previous post of this user is the exact copy of this.

Edit: Light version added
 
Hey guys,
Great work you're doing with armbian. Just created an account to post a couple of ideas I came up with. I've only got the largest resolution right now, but if you like any of them I can easily save out others.
  Linen - Dark   Linen - Light   Vertical blur   Vertical blur - Light

That's the reason I switched over to Etcher completely: Since here a verify is mandatory which will save you huge amounts of time (the SD reader in my build host PC died a few months ago, took me 2 days to get the idea, in between an USB card reader was responsible for several failure burns so now I simply rely on Etcher and my MacBook's internal card reader -- also way faster).
 
Maybe you got a counterfeit card and already exceeded the real capacity (you described the typical symptoms). Did you run F3 or H2testw already?

We don't have to test anything every day or even every week. Testing is required mostly when bumping u-boot and/or kernel versions and before releasing new packages and/or images.

Yes, we could (formally) engage more people into developing process as testers. It could be helpful and we would be little relieved.
 
Perhaps we start to seek & assign few testers / maintainer for each board? We can provide access to daily upgrades to make things easy on technical level. I can provide extra repository (aptdev.armbian.com) with daily updated deb packages, while creating images takes way too much time for daily builds. I am already working on this for some time and it's not far away from running it daily.
 
Subforum "Development" is not that busy, so we can have those things here.

I think introducing new tools for this job is not a good idea regardless of resources. We already have them, we just don't use them this way. Resources are always tiny and something not to waste.
 
It might sound a bit "new age" but using simple tools leads to creativity and innovation, while using complex tools leads to procrastination. In first case you deal with the problem in second you usually don't get anywhere. You have tools to play with. That was my point, nothing personal.

An alternative for isc-dhcp on Page 9,
written from Ashok Aiyar, I put it here because it is not just a fix but an instruction how to replace the isc-dhcp server with dnsmasq.
 
 
I find dnsmasq to be a better option to isc-dhcp-server, because it provides both DNS and DHCP servers in a single package and configuration file.
Also, dnsmasq supports caching, so with a large cache, it provides really fast name resolution after using it for a little while.
 
Here is a dnsmasq setup consistent with the rest of the Armbian BPi R1 configuration given in this very helpful guide.
 
a) Install dnsmasq (apt-get install dnsmasq)
 
b  shutdown dnsmasq (service dnsmasq stop)
 
c) Edit "/etc/dnsmasq.d/dnsmasq.conf" with the contents shown below:
 


# interfaces
interface=br0
no-dhcp-interface=eth0.101
#
# DNS configuration
min-port=4096
cache-size=10000
local-ttl=3600
neg-ttl=3600
bogus-priv
domain-needed
expand-hosts
resolv-file=/etc/resolv.conf
#
# DHCP configuration
dhcp-authoritative
dhcp-leasefile=/var/lib/misc/dnsmasq.leases
dhcp-option=br0,1,255.255.255.0
dhcp-option=br0,3,192.168.9.2
dhcp-option=br0,6,192.168.9.2
dhcp-option=br0,28,192.168.9.255
dhcp-range=br0,192.168.9.150,192.168.9.250,255.255.255.0,72h
# explanation of options:
# option 1 = net mask
# option 3 = gateway
# option 6 = DNS
# option 28 = broadcast address
# assign address range = 150-250
# lease time = 3 day (72h)


d) shutdown isc-dhcp-server (service isc-dhcp-server stop)
 
e) start dnsmasq (service dnsmasq start)
 
f) confirm that IP assignment is working and that you are making use of the caching nameserver within dnsmasq
 
g) If it works, then remove isc-dhcp-server (apt-get remove isc-dhcp-server)
 
 
Thank you Ashok for your contribution 

Hi
 
Back in February '15 I have started to write an instruction about the setup of a BPi-R1 (Router).
In the threads of the Forum, the information is scattered and it takes so much time for each to get along.
So I thought such a document would help to become not only faster, but to achieve a better result as well, as you can faster spend time with the device and tweak it.
My know how is getting better, but things are still missing.
If you like to help the 'community' with your know how, please leave comments in the document if you find errors or you find something missing.
 
Google Docs 
 
Thank you in advance - for your support
 
Cheers
Tido

I agree that this is not "core functionality" to the SoC of the board, but it is "core functionality" to the SBC Lamobo R1, whether some people like it or not.
I fully agree with second line above and without your work, help, support so many of us only had a paper weight.
 
Last but not least, can 2 or 3 of us R1 owners test the release candidate before you release it - or what else can be done to keep it 'stable' ?

Bronco = TKaiser in this forum
 
Why not simply taking the original image with optimiziations included ?
 
And information which and how to use it. http://docs.armbian.com/User-Guide_Getting-Started/

Why not decreasing DRAM clockspeeds for both variants and keep one image? My understanding is that literally no one ever tested DRAM reliability on any Lime2 (Olimex' Tsvetan proudly announced DRAM trace routing would've been improved compared to Lime and 532 MHz are possible based on playing video for a few hours since this is their usual test procedure). On the other hand based on forum discussions the serious Lime2 users are all interested in stability over laughable performance gains (downclock DRAM to 432 MHz and you loose how much percent performance in real world applications? 2? Or even 3?)
 
Edit: Here it's still 384 MHz, in our fex files it's 384 MHz and I wouldn't be surprised if the very same value is still used by Olimex themselves in their OS image for Lime2. So we currently deal with one 532 MHz claim made by a proud vendor that led to u-boot maintainer choosing 480 MHz (upper limit -- 532 not possible) and now all Lime2 users who rely on mainline u-boot have a problem, right? And everyone thinks this 480 MHz value is something that's the result of reliability testing but in reality it's quite the opposite and users face all sorts of problems.
 
Edit2: And here we're seeing 384 MHz, there again but there 480 MHz. But we still don't know where the 480 MHz originate from? Reliability testing or Tsvetan simply claiming '532 MHz!'?
 
Edit3: In mainline u-boot they rely on defaults which are 480 MHz (for whatever reasons) and according to their instructions they use it for both normal and eMMC variant. So we have 532 MHz as a 'it's working that fast!1!!' claim, 480 MHz as the results of trusting in this and 384 MHz as leftover from older Lime settings scattered all over the place. Why do we trust in any of these numbers?
 
Edit4: And after reading this I'm convinced we're dealing with random numbers without meaning

This looks like an old Armbian version
 
 
 Exactly. This issue with firstrun script was fixed a long time ago. Please try more recent version (5.14 is available and it can be upgraded to 5.16)

@aliceander
 
When possible, please, send us bird images from your special device
 
@TheTeam: Tido, Alex, Thomas, Mikhael
you rock for the birds 
 
note: I only take the credit for adding [bird watching station] in the title
 

 
note: if someone wants to preorder the Pepsi Co Phablet
http://www.gearbest.com/cell-phones/pp_399893.html
we could port Armbian... no, I am kidding

-

I went to "allwinner H3" section and I found two threads about camera, on the first page:
 
http://forum.armbian.com/index.php/topic/957-orange-pi-c%C3%A2mera-gc2035-works-fine-with-v4l2-applications/
 
http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/

I've added a welcome message to the docs Home, to temporarily minimally address some UX issues.
 
There are several use cases for the documentation:
 
1. New users, who might easily give up and try something else unless they're walked through everything right from the start.
- Getting Started should be prominent for them.
- "What is the current state of Armbian?" might need to be answered in the docs, since outdated info about hardware acceleration, HDMI etc. can be found elsewhere and may deter these users (or maybe that should be left to the main armbian.com site)
 
2. Users of all levels who have frequently asked questions.
- Do people still look for FAQ sections? If so one should exist and be easily seen.
 
3. People who've run into problems
- FAQ and/or Troubleshooting should be easily found.
 
4. Serious users who will actually read through the ToC and documentation

I feel that settling on filenames/URLs as quickly as possible should be a high priority. Are the current filenames settled? (including the "feel boot" typo?) If perfect permanent links are infeasible, breaking links and leaving temporary/WIP names for long periods should at least be avoided as much as we can. I don't know how much of a problem it could really be, but I imagine people googling a common question, and ending up at a permanent forum post somewhere that contains a broken link to the documentation.
 
 
 
I was curious about collapsible navigation links and came across this mkdocs theme example: http://developer.helpmonks.com/
Code and description can be found here: https://github.com/mkdocs/mkdocs/issues/588
This appears to be a WIP, has bugs and might be hacky, and is extra complication on top of readthedocs, so I don't recommend we use it, just an idea.
I downloaded the theme and tried it out on our docs. It doesn't display subsections in the navbar, which is a problem. It looks like their theme's toc.html removes it, and adds support for organizing .md files into subdirectories.

Looks like it's really coming along well!
 
Do you want UX feedback discussed here, or on https://github.com/igorpecovnik/lib.docs(are issues disabled for it???), or should we wait until it's ready for feedback?
 
 
 
For example... When I'm at docs Home, the User Guide sections are offscreen on my computer. Even if it is onscreen, it is below stuff like Task Tracking, Changelog etc. As a complete newb, if I go to the docs, I might skim the Home doc, maybe hit Next and stop reading by the FEX section at best. I might skim the sidebar topics... if I'm lucky I'll notice "Getting started" near the bottom. Otherwise I'll think that Home is all the getting started info there is and conclude that this all requires some expertise that I don't have.
 
I don't know if such an issue is already being addressed with a doc reorganization, or if it is now baked into the current design.

will save u time to read 10 min
 
http://docs.armbian.com/user-manual/

Consider the page as WIP. I didn't make any more progress and will update it with our findings when done.
 
I guess the location of the documentation will be o.k. "docs.armbian.com" ?

Here I have currently wildly collected most of the information and put in 4 topics suggestion.
 
Everybody who has the link can edit the document, if you are logged in on Gmail you can see who did what.

I also thought of BURN_TO_HELL.txt (TK mode)
 
Not a good idea
 
README_FIRST_BOOTING_ISSUES.txt (very short description file as a TO CHECK LIST)
 
BURN_IMAGE_CHECKLIST_README.txt

why don't we add a file in the zip?
 
YOU_HAVE_A_PROBLEM_READMEFIRST_PLEASE.txt
giving basic pieces of advice (check your SDcard, etc.)
and links to the documentation.