rodolfo

@boobypi
 
You're welcome. X2goserver on OPI is definitely on my wishlist and your information is very much appreciated. For pure linux environments I prefer x2goserver/x2goclient over xrdp/rdesktop, except for android clients which lack x2goclient capabilities.
 
I'll try your recipe to get a working x2goserver on arm and report back.
 
Just set up a working x2goserver installation as per your instructions. Thanks, you are my hero !
 
 
Screenshot of x2goclient running in (virtual) windows7 connected to x2goserver running on OPIONE.
 
 

 
 
Have a nice day.

Hi guys,

Thanks for tutorial, i discover rdesktop / xrdp...

But i would try to make thing in the reverse way : Put x2goserver on OPPC and view from remote (linux or windows).

It's finally easy with all needed .deb files and some helper from web.

 
apt-get install libc6 lsof bc openssh-server openssh-client libconfig-simple-perl pwgen libdbd-pg-perl libdbd-sqlite3-perl libfile-basedir-perl libcapture-tiny-perl adduser xauth psmisc net-tools sshfs x11-apps x11-session-utils x11-utils x11-xfs-utils x11-xkb-utils x11-xserver-utils fontconfig xinit xfonts-base x11-common wget http://ftp.igh.cnrs.fr/pub/os/linux/raspbian/raspbian/pool/main/libj/libjpeg8/libjpeg8_8d-1+deb7u1_armhf.deb sudo dpkg [--force-conflicts --force-depends] -i libjpeg8_8d-1+deb7u1_armhf.deb git clone https://github.com/kapolos/armhf-x2go.git cd armhf-x2go-master/ sudo dpkg [--force-depends] -i *.deb sudo apt-get -f install WILL INSTALL ===> cups cups-client cups-common cups-core-drivers cups-daemon cups-filters cups-filters-core-drivers cups-ppdc cups-server-common desktop-file-utils ghostscript gsfonts libcupscgi1 libcupsmime1 libcupsppdc1 libfile-which-perl libfontembed1 libqpdf13 poppler-utils ssl-cert sudo apt-get install x2goclient on the remote machine. run x2goclient and type (server ip address) and your username and pwd as your remote ssh acces. Enjoy! I m happy to find my x2go app.
Also a real firefox (firefox_45.0.2+build1-0ubuntu0.12.04.1_armhf.deb) (Webgl support with mesa compiled = glmark2 give 5 poor points but it's work lol

1. Select your images ( attach files -> button : choose files ) and upload them to the forum 
 

 

 
2. Insert the displayed attachments into the forum text (Add to Post)
 

 
 
3. Preview and upload the post

Nope - just x2goclient on Armbian. Successfully installed xrdp/tightvnc on OPI ONE and accessed it via rdesktop client from linux and aRDP from android.
For graphical access to OPI ONE running remotely through firewalls, I tunnel and relay the rdesktop-session via ssh/x2goserver running on a x86 server.
 
see http://forum.armbian.com/index.php/topic/1044-remote-desktop-fun-with-armbian-505-on-opi-one/

1. Select your images ( attach files -> button : choose files ) and upload them to the forum 
 

 

 
2. Insert the displayed attachments into the forum text (Add to Post)
 

 
 
3. Preview and upload the post

Let's move this off topic to other:
specific info what we are working on general. open or join topic.  i am following this basic task handling logic I am always open for suggestions to make things different way. I am not saying my approach is the best or most perfect but sometimes I am (we are) just not in a coding mood or I am (we are) simply doing on strategy and can't focus much on tiny things and vice versa.

Yes - that is exactly what I mean. Real people doing real stuff for real. RK was progressing nicely and then unfortunately stumbled over their own greed. Actually, I would prefer a stripped OrangePi (ONE/LITE without LAN, WIFI, OTG) with 3xUSB2 and solder pads for the rest, power-optimized with a LiIon-battery-circuit for < $10. The next interesting board would be ARM64-based, exposing USB3 and featuring HW-accelerated graphics for <$20. LAN/WIFI/SATA are no problem with properly exposed USB at highspeed/superspeed, avoiding crappy components on the boards.

I have just received cheap WiFi dongle (paid $1.6 in Aliexpress). I don't know yet if I will solder it directly to Orange Pi One extra USB exposed solder points.
Currently I want to share how to disassemble this dongle without damaging anything.
Watch my short tutorial video:

Using this module without the case significantly improves WiFi signal quality and range. Finally it would be possible to solder external antenna socket.
Some photos:

Common Edimax dongle EW-7811UN is now fully working by following Igor's procedure for Armbian-5.05.. Thanks !  After configuring wlan0 and testing the connection I disabled old / enabled new WIFI driver
/etc/modules-load.d/modules.conf #----------disable standard Armbian driver # 8189es #----------enable fixed WIFI driver for EDIMAX EW-7811UN 8192cu The board now reliably starts up and connects to configured wireless network. Performance is adequate in a noisy busy environment, iperf reaches 87 mbps.
 
Problem SOLVED !

Then I'm looking forward to complete H3 support in mainline kernel appearing tomorrow out of thin air.    Maybe then I'll even buy some H3 based Orange device to play with.

Please, please spare us any sort of "auto-configuration" and thank you for keeping Armbian straight and simple! I am currently testing Armbian_5.05 on OrangePiOne using the jessie server version as a basis. Adding needed packages one by one, the restricted ressources should be best used for production use cases.
 
By far the easiest ways to "find" a headless server is to look at the end of the serial console cable attached to it  or ssh to a STATIC IP configured in /etc/network/interfaces.

Oh, you wouldn't believe how many network admins hate Bonjour/avahi (and any sorts of auto configuration stuff)
 
While i agree that having avahi-daemon enabled from the very beginning would be nice it's still a problem adding packets since we also want to stay 'slim' (Ubuntu Xenial for example wants to install the following packages together with avahi-daemon: bind9-host, geoip-database, libavahi-common-data, libavahi-common3, libavahi-core7, libbind9-140, libdaemon0, libdns162, libgeoip1, libisc160, libisccc140, libisccfg140, liblwres141 and libnss-mdns wasting an additional 10MB)
 
To understand what your request is about... you want to be able to do an
avahi-browse -rtkp _armbian-ssh._tcp for example to find the board?
 
I didn't care that much in the past since in the installations where we deploy boards it's both easy to quickly scan the DHCP range (nmap -sV -p 22 192.168.$subnet.1-254) and when it's about one board and a DHCP server implementing dynamic DNS updates then it's also easy to  connect to the Armbian installation since an Orange Pi PC will then be accessible using
slogin -l root orangepipc (if you look at all the fex files here you get the names of every board we support since we set this name as hostname). Or is your situation different and no DHCP server is available and it's really about Zeroconf networking?

This is still not backup since backup needs versioning (to protect from accidentally damaging/deleting files). And 100% identical clones can be created way more efficient.
 
One approach is to use rsync combined with hardlinks (web search for "rsync hardlinks backup" or something like that) and anyone using mainline kernel should have a look into btrfs snapshots and 'btrfs send/receive'.

Of course, I would try to put 2 litters of milk in a 750ml bottle ...
 
But the beauty of "tar piped in another tar" is that you can even do it across SSH.
(For full backup, you still need to be aware of not including backup of special folders, such as "/lost+found" or "/proc" )
 
Or course, the rsync method is good too !

General public is easy to mislead to backup the project - general public aka kick-starter community is dumb as hell. It's all about marketing. SBC's are still hot stuff and hardware development become ridiculous cheap so it's a great way to make money.
 
As I see you already made it to persuade investors. Why bother developers community, where you don't intent to invest more then few free boards here and there and use our channels for free marketing? BTW: You can run your marketing campaign on your own website or wherever but here you need to ask for permission. I hate ads.
 
Even before your boards become stable (to be used by professionals which is stated in your first line of your marketing appeal) you will probably restart the whole thing with a "new and better" board and hope to catch as many backers as possible. All board manufacturers are using community's current and future contribution in their business models and everyone want's to become next RPi in numbers. This is the only way you don't need to pledge anyone. Until then, we control the game.
 
Free sample? I have a bunch of boards and so do other people who develop and contribute. I don't even think to support your boards without paradigm change toward community. You collected the money for our work and you kept it. What the f*?
 
You are an engineer. It's is not your fault nor responsibility to think about this in such way. Don't take it personally either.

BTW: I chose the Orange Pi Plus as an example for a reason. Since this is a device where everyone will get the idea that it's necessary to test stuff individually.
 
When you connect a SATA disk to the Orange Pi Plus which seems the most reasonable choice you probably won't see any performance improvement compared to CubieTruck now. If you use the very same SATA disk, put it in an external enclosure and connect it through USB then performance will improve. Why? Is SATA and USB different on the Orange Pi Plus? No, it's just the H3 SoC features no SATA and the SATA port on the OPi+ has been implemented using the slowest USB-to-SATA bridge in the world (GL830) which isn't able to exceed 15 MB/s write speeds and will be outperformed by any external USB disk not relying on GL830.
 
So refusing to 'benchmark correctly' will just lead to another frustrating situation and a device you might throw into the bin. Measuring all the stuff individually you're able to identify the real bottlenecks and improve the situation.
 
 
In case you asked me: Sure, you can always loose data as long as you're not doing backups
 
Really, running any sort of real benchmark might put significantly more load on a device which might lead to stability problems caused by an insufficient PSU for example. The 'armbianmonitor -c' check was designed to verify the speed/reliability of SD cards and thumb drives (and no, the tests do not destroy anything, just try to fill the storage in question with test patterns that are verified later) but being used with a disk and insufficient power supply they might lead to data/filesystem corruption.
 
But that's what benchmarks are for (when used in an active approach), identifying bottlenecks be it performance or reliability relevant. In case anyone's interested: We used the linpack high performance benchmark to identify reliability issues caused by undervoltage settings with Pine64 in the past: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-196399188

Strange indeed. I've just successfully tested OrangePiOne with Armbian_5.05 on any old crappy sdcards ( "class" 4,6,10 4G ). Cards were prepared on a linux host ( dd ), installed on OrangePiOne  and heavily used ( actually misused ) with random reboots, shutdowns, disconnecting power. Despite some (probably erroneous) error messages (mmc) the boards booted without any problems and even heavy abuse did not corrupt the sdcards.
 
I've noticed some other phenomena which are HW-related. Crappy power cables or crappy power supplies lead to erratic boot behaviour. Attach the serial console and run the board power cable through a voltmeter/ammeter. During a normal boot you'll notice current going up from <100mA to >200mA. I've traced all boot failures to problems with power supply. Practical jokes like powering an USB-attached disk from the USB connection yield rather strange results too
 
By the way - use a cheap working any-old-class 4G sdcard for testing until you are satisfied with a working basic image. Create a backup image and use this as a basis for copying to a "high class zillion-G"  sdcard. Expanding is so much more fun than shrinking.

Instead of participating in a soldering contest I looked at the OrangePiOne board and found two fully functioning USB ports ( regular and microUSB dubbed OTG ) ready to be used. Two fast connections or one fast and several slower ones via external hub for testing are usually plenty. If you need more - the solution is called OrangePiPc.
 
Please let us know who won the soldering competition and post some pictures of successfully added DIY USB host ports before hotgluing the mess to a repurposed old X86 PC with spare USB ports

Amazing. You looked at an image where a chip is shown that is 14x14mm in size and don't get the idea that these solder points nearby have to be rather tiny?
 
And now you're searching in a software forum (Armbian you know) for tutorials how to improve your soldering skills since you tried to save $5 and ended up with the wrong device for your use cases? Really?

Strange indeed. I've just successfully tested OrangePiOne with Armbian_5.05 on any old crappy sdcards ( "class" 4,6,10 4G ). Cards were prepared on a linux host ( dd ), installed on OrangePiOne  and heavily used ( actually misused ) with random reboots, shutdowns, disconnecting power. Despite some (probably erroneous) error messages (mmc) the boards booted without any problems and even heavy abuse did not corrupt the sdcards.
 
I've noticed some other phenomena which are HW-related. Crappy power cables or crappy power supplies lead to erratic boot behaviour. Attach the serial console and run the board power cable through a voltmeter/ammeter. During a normal boot you'll notice current going up from <100mA to >200mA. I've traced all boot failures to problems with power supply. Practical jokes like powering an USB-attached disk from the USB connection yield rather strange results too
 
By the way - use a cheap working any-old-class 4G sdcard for testing until you are satisfied with a working basic image. Create a backup image and use this as a basis for copying to a "high class zillion-G"  sdcard. Expanding is so much more fun than shrinking.

@igor
Thanks for the info and keep up the good work. I'll try to contribute in areas I'm knowledgeable about, mainly testing, documenting and high level use cases.

Hi
apt-get install tightvncserver

Maybe my UG802 (RK3066 dual core) with Picuntu running several days a week as torrent downloader since 2012 and update from Ubuntu 12.10 to 14.04 and I hope in next months go to 16.04 is a good example of benchmark. And also chinese people lost an opportunity to have a PiZero killer 4 years ago.
 

 

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
 
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
 

 
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
 
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
 
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
 
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
 
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
 
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
 
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
 
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
 
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
 
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
 
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
 
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
 
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)