Its around 60,000 unique installs since we started (04/2015), minus any users who have disabled dietpi-survey, and downtime we had with the old webserver (which ran from my house).
How many people in the world are running DietPi on their SBCs today?
Unfortunately, we have no real way of knowing, only unique installs. The survey file upload, only occurs when users install something with dietpi-software.
Really interesting. I downloaded the survey files that are currently available:
3717 files today but since the filenames also contain version information these were based only on 3656 different UUIDs (the term ‘unique install’ is misleading anyway since everyone installing from scratch will end up with a new UUID):
So today DietPi is a RPi distro with some ODROID, x86, Rock64 and Tinkerboard installations:
macbookpro-tk:dietpi.com tk$ grep 'Hardware Name' * | awk -F" : " '{print $2}' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | sort -r
1298 rpi 3 model b (armv7l)
358 rpi 2 model b (armv7l)
301 rpi 3 model b+ (armv7l)
249 rpi b (armv6l)
221 rpi zero w (armv6l)
210 virtual machine (x86_64)
157 odroid xu3/xu4/hc1/hc2 (armv7l)
149 odroid c2 (aarch64)
96 rock64 (aarch64)
94 orangepi zero (armv7l)
84 rpi b+ (armv6l)
81 asus tinker board (armv7l)
70 native pc (x86_64)
40 rpi zero (armv6l)
31 pine a64 (aarch64)
29 orangepi pc (armv7l)
28 nanopi neo (armv7l)
27 rpi (armv7l)
25 sparky sbc (armv7l)
20 orangepi one (armv7l)
14 nanopi neo 2 (aarch64)
12 odroid c1 (armv7l)
12 nanopi m1/t1 (armv7l)
10 rpi b (ecn0001) (armv6l)
8 pine a64+ 2gb (aarch64)
8 generic device (armv7l)
7 rpi (armv6l)
7 nanopi m2/t2 (armv7l)
6 orangepi plus (armv7l)
6 opi pc2 (aarch64)
6 nanopi m3/t3 (armv7l)
5 generic device (aarch64)
4 unknown device (armv7l)
4 opi win (aarch64)
3 rpi a+ (armv6l)
3 pine a64+ 1gb (aarch64)
3 opi zero 2 plus (aarch64)
3 odroid xu3/4 (armv7l)
3 nanopi k1 plus (aarch64)
3 bananapi pro (armv7l)
2 rpi a (armv6l)
2 opi prime (aarch64)
2 odroid n1 (aarch64)
2 generic device (x86_64)
1 unknown device (armv6l)
1 rpi cm 3 (armv7l)
1 orangepi plus / plus 2 (armv7l)
1 opi zero 2 plus (armv7l)
1 nanopi m3/t3 (aarch64)
1 bananapi m2+ (armv7l)
1 bananapi (armv7l)
Also nice: You make it easy for your users to get hacked by encouraging them to use insecure protocols (FTP in 2018, what a funny idea!) with handlers that store logon credentials in a horribly insecure way and then upload these logon credentials to a publicly readable directory somewhere on the Internet without asking users first! Well done.
Now let’s have a look how DietPi deals with security issues in 2018: Simply censoring the reports and ignoring the problem as in the past or able to improve and fix issues?
I can confirm a potential risk due to $(df -h), contained at the end of our survey file, printing curlftp mount credentials in its output.
Although this is not an issue for local IP FTP servers, external FTP IP’s using curlftp mount are at risk (i counted 2 users), should this information come into the wrong hands.
I was unaware of this. As such, we’ve removed all the survey files and taken it offline. This data is no longer available, or, uploaded to our server.
We’ll re-review dietpi-survey at some point in the future.
bronco
Next time, if you really care about users security, it would be great if you inform us via email, PM or something like that, before spreading this further into the web and by this increase potential risk, instead of helping to solve it .
And adult wording in such serious topic would be helpful as well, to enable us taking it serious and constructively. Otherwise it looks and feels more like an attack for whatever reason, instead of a security advice/hint.
But we got the point and working on a solution to disable folder list and read permissions, as well as bringing data directly into secure locations. Until that, FTP server disabled for now, as mentioned by Fourdee. So thanks for the hint after all, just please be discreet, if it should be necessary another time.
bronco
We just release v6.9 with a huge security rework, related to our password handling, as well to the DietPi-Survey and DietPi-Bugreport upload and storage:
Any sensible data was removed from survey.
Upload is done via secured (pub host key) SFTP.
Public upload user has no read, nor file list permissions.
Everything is handled more transparent now: User dialog to opt in/out survey or even purge the uploaded data (by overwriting it with empty file).
Files contain unique hardware id only, thus there is just 1 file each system, which will be overwritten with new upload. Of course we have no chance to track users setup a fresh system, without some (definitely!) unwanted account system.
To have it transparent, we have a public report page that shows v6.9 statistics based on opt-in users: https://dietpi.com/survey/
Feel free to check, if it’s bullet prove as expected.
I’m learning to use DietPi for the Raspberry Pi; I recently got the latest model, started toying with it, and am experimenting with different OS’s. So far, the one I feel the most comfortable with is DietPi! Plus, if I am successful, I have a friend who may well follow me in this “adventure”.
Native PC (x86_64) means a real (non virtual) x86_64 machine.
Generic Device means that the exact kind of the machine is unknown.
It is only relevant if you use DietPi-PREP to turn an existing Debian-based image into DietPi. You will be asked, which device you run this script on. If the device is not in the list, you can select “Generic Device”. Although this means that some characteristic of the device needs to be estimated through different ways and DietPi might not be installed with full potential that the device actually offers. However the CPU architecture (ARMv6/7/8 or x86) can be determined reliable.
If on you system it is shown Native PC (x86_64) than actually you installed DietPi not ideal. It is an x86_64 machine, so if it’s not a virtual machine, select Native PC (x86_64) then.
Generic device choice is only the right choice, if you have an ARM device that is not in the list, e.g. some new OrangePi/BananaPi and such, where er don’t offer official images anymore.
Perhaps we can limit the preparation script options, when x86_64 is already detected to choose only between Native PC and Virtual Machine .
Success depends on the actual OrangePi and the Debian base image you use. Report back which particular OPi and which base Debian image you use. And if the DietPi-PREP script does not succeed or throws an error, report back an we can fix.
i’ve got new orange pi zero LTS, performance is great if compare to raspi zero. Here some benchmarks (tested 3x times with buster)
CPU 28 sek
Temp idle 15°C max 35°C (after a long “make” process it gets hotter 65°C)
SD write 11, read 20 MiB/s (class A, but on pc same speed)
RAM write 250, read 400 MiB/s
One thing disappoint me, it’s freezes. Maybe my SD card has errors, my raspi had the same problem
There are not hardware differences between LTS and non-LTS version right? At least the specifications don’t show differences.
There is a very slow CPU bench upload that probably pulls down the average of this device. I will remove it and see if this fits better to what you get: https://dietpi.com/survey/#benchmark EDIT: Done, looks much better now, representing the real performance of this device.
.
.