Preparing for a Prototype

[erico]

Yep. Of course size/speed matters and also the screen response time. If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).

 

[Grench]

Yep. Of course size/speed matters and also the screen response time. If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).

Yes, screen response time matters in what the unit is -capable- of producing. I'm pretty sure the screen -can- do it, it is a very nice screen.

However, I argue, that even if it's able to produce 60fps, beyond being a spec number claim, there isn't much point to spending battery on CPU cycles for it when the difference between 30fps and 60fps on a 5" screen displaying sprite graphics is imperceptible.

Optimization on a battery operated handheld computer is about using as little battery as possible while giving the end user a solid experience. The Pyra is 'overpowered' for a lot of these games - that spend all available CPU cycles anyway - resulting in waste heat that doesn't add to the experience.

 

[Letalis Sonus]

If ours is at least 16ms it will be able to render 60fps without blurring frames (imho).

Careful about those manufacturer-provided response times, though, they do not apply to generic color switches. The most dominant value advertised for PC monitors is the gray-to-gray response time - simply because it commonly is the lowest, and that motivates a lot of manufacturers to cheat by optimizing their low-cost screens only for that value. I do not expect this to be an issue on embedded screens for mobile devices, but you should still always handle them with a grain of salt, especially if you want to compare them to calculated absolute limits. The worst-case scenario will always take a lot longer than the advertised gray-to-gray response time.

Which is why some of us are doing the Sonic benchmark: These fast switching harshly contrasting colors are pretty much the worst you can throw at any TFT screen. If you don't notice any ghosting while playing Sonic, you've found the holy grail of screens.

 

[levi]

I take your point for most desktop uses like web browsing and messaging, but if you take away 60fps from my outrun emulation then you'll have another thing coming!

I don't see any difference in that horse animation by the way, other than it getting bigger when I zoom in. It's arguably a bit janky when it hits full screen, but actually when you look again it's janky all the way up.

Edit: The grey-to-grey time was meant to be an improvement on the old black-to-white measurement, which was easily hacked by manufacturers overdriving their pixels. It used to be especially on the chepeaper end that they could flash black and white quickly, but going from grey to grey they'd overshoot, leading to a bright edge on anything moving across the screen, and a trailing shadow the other side. Thankfully publishing grey-to-grey metrics largely stopped those kind of shenanigans for a good few years now.

 

[Letalis Sonus]

The grey-to-grey time was meant to be an improvement on the old black-to-white measurement

That's the theory. However, the black-to-white metric provides a kind of worst-case value whereas the gray-to-gray value might provide something more similar to the average usage, but it is also much more akin to meddling.

Thankfully publishing grey-to-grey metrics largely stopped those kind of shenanigans for a good few years now.

...if there was a standardized measurement method to actually generate the metrics, black-to-white response times are not just a worst-case value but also part of an ISO standard. Gray-to-gray on the other hand is pretty much a bullshit PR value.

Note that overdrive only affects one direction of transition, whereas black-to-white measurements have to include both transitions. This makes overdrive all the more exploitable for extra low gray-to-gray values.

 

[aTc]

I've created some new os images.

Index of /images/buster

packages.pyra-handheld.com

the img.zip need to be unpacked, then written to an sd card.

If you've previously made an installer sd card, you can remove the rootfs.tgz from that, copy pyra-debian-buster-mate-rootfs.tgz to the card, and rename it to rootfs.tgz , it can then be used to flash the new image.

These include bluetooth and modemmanager, and uses the uboot version that doesn't remove the emmc when the shoulderbutton is pressed.

To update without reflashing the entire emmc/sd card, you can just do an "apt update; apt upgrade"
Because i forgot to add some packages, you also need to do a "apt install pyra-meta-extra" to get the bt/etc stuff.
Updating uboot also needs to be done manually, which can be done with "sudo /usr/share/pyra/scripts/pyra-install-uboot.sh /usr/share/pyra/u-boot/pyra-u-boot-4g/ /dev/mmcblk0"
Replace /dev/mmcblk0 with /dev/mmcblk3 if you're running from sd, (or just look at the output of lsblk, and use the device that has the /boot partition on it (without any p1 added to the end))


the -nobat image is still the old one, so don't use that.

To set up a mobile broadband connection, open the mate menu and go to System Tools->Modem Manager GUI ( wait for the modem to appear, it takes about 256 seconds after booting)
On the Connection bar, click "Edit" , "Add connection" and make sure all values are right. "Ok" , then click "Activate" and it should all work.

 

[docbroke]

Actually, screen size makes a big difference in where the threshold for animation occurs.
From the page: https://en.wikipedia.org/wiki/Frame_rate

https://en.wikipedia.org/wiki/Frame_rate#/media/File:Animhorse.gif

You can just use ctrl +/- to resize the 12fps gif.
Sized down to about 2" it barely meets the threshold of animation, but your mind perceives it as animated.
Sized up to about 5" it appears quite choppy.
Sized up to 12" it's 'unwatchable'.
Games that will appear choppy as hell at 20fps on a 21" screen will be quite playable at 20fps on a 5" screen.

I would argue, then, that processing cycles being used to generate frame rates on a mobile device that are higher than 'needed' (admittedly variable on many factors) aren't doing any 'good' and are doing basic 'harm' to the experience by wasting battery power by turning it into heat without enhancing the user experience.

Where that threshold is will be variable on the user and the application/game being used. If we were to be able to put in a user configurable 'restriction' at the .dbp layer (so that it is application dependent), that would allow the device user to be able to adjust up/down how much CPU gets allocated to the application - which translates into a choice between battery life or frame rate - and would let the user choose where that balance best suits them.

That is the idea. I don't know if it is possible to implement. But, as is, 'greedy apps' will draw every scrap of CPU they can, regardless of whether doing so actually improves the perceived user experience.

That wikipedia page doesn't say a word about screen size.
Just as levi mentioned I couldn't see any difference when changing the size of that animation, it looks like time lapse at all the sizes, unless you want to make it so small that I can't see it at all.

Btw., I don't mind if .dbp or emulators allow adjusting frame rate, it may be helpful ( I don't know how much though ).

 

[erico]

Yep. Above the specs, we are sure looking for the best human experience with what we have.

 

[directive0]

However, when using the stylus or touch-screen, count on needing to 'back it up' with a finger.

So pretty much on par with the pandora you'd say?

 

[Djoga'Ro]

@Grench If there's no way to set a game's cpu time quota, one could still ensure not to waste processing power by making something else run one the same cpu, I guess. Is SETI still a thing? Or some other project technically like it?

 

[Rockthesmurf]

Putting aside how many people most certainly can very much notice visually 60 vs 30 vs 20 fps even on a small screen, it would really ruin any game that needs responsive input, 16ms at 60fps is below the 20ms barrier where you don't notice it, 33ms is already not ideal and why a lot of people struggle with 30fps console games, when you hit 50ms at 20fps it is going to be a poor experience for anything that requires snappy controls.

Sure, some games don't need snappy controls, and can probably play with lower frame rates okay, so having it as a per app setting makes sense (and allowing each user to set it also makes sense as some people are far more sensitive to others).

 

[matzesu]

Someone said a lot of 2 Months Cycles ago, underclocking could be that common on Pyra as overclocking was on Pandora..

Also : there was a lot possible on Pandora whit just 600 mhz, even N64 Emulation
So you don’t need the Full Power of Pyra for your normal tasks, so I think whit a bit optimizion, this Handheld could be pretty cool as a Low Power Consumer Work PC


Gesendet von iPhone mit Tapatalk Pro

 

[darkcpc]

Hope everyone had a good Christmas and New year.

Really excited to see the Pyra ever closer to mass production. Can't wait to get one. I follow retro gaming on many other devices as well as Pyra and there is one particular retro handheld device available called the GKD350h which uses a custom made Ingenic X1830 running at 1.5ghz. It lacks a GPU but is a 2d powerhouse has been tested running CPS3 arcade games at 60 fps fullspeed using the Fba emulator which is amazing!

The Pyra obviously uses a different CPU but since it also runs at 1.5ghz, I really hope that it will also be capable of emulating the CPS3 arcade games at 60fps. Could this be tested at some point later on the dev or prototype units?

 

[spud42]

@Grench If there's no way to set a game's cpu time quota, one could still ensure not to waste processing power by making something else run one the same cpu, I guess. Is SETI still a thing? Or some other project technically like it?

the point was to save battery and heat build up. just running another process wont achieve anything.

 

[Djoga'Ro]

@spud42 Yes, it'd help to ensure, that the cycles the game doesn't really need but would use don't go to waste, and wasting cpu power was one of Grench's points. Plus, I said "If there's no way to ..."

 

[asimov-solensan]

Hope everyone had a good Christmas and New year.

Really excited to see the Pyra ever closer to mass production. Can't wait to get one. I follow retro gaming on many other devices as well as Pyra and there is one particular retro handheld device available called the GKD350h which uses a custom made Ingenic X1830 running at 1.5ghz. It lacks a GPU but is a 2d powerhouse has been tested running CPS3 arcade games at 60 fps fullspeed using the Fba emulator which is amazing!

The Pyra obviously uses a different CPU but since it also runs at 1.5ghz, I really hope that it will also be capable of emulating the CPS3 arcade games at 60fps. Could this be tested at some point later on the dev or prototype units?

CPS3 already run pretty well on Pandora, can't tell if it was solid 60fps, but it felt prefectly smooth on a Ghz edition. I'm absolutely sure that Pyra can do perfect CPS3 emulation.

 

[Grench]

I've created some new os images.

Index of /images/buster

packages.pyra-handheld.com

the img.zip need to be unpacked, then written to an sd card.

If you've previously made an installer sd card, you can remove the rootfs.tgz from that, copy pyra-debian-buster-mate-rootfs.tgz to the card, and rename it to rootfs.tgz , it can then be used to flash the new image.

These include bluetooth and modemmanager, and uses the uboot version that doesn't remove the emmc when the shoulderbutton is pressed.

To update without reflashing the entire emmc/sd card, you can just do an "apt update; apt upgrade"
Because i forgot to add some packages, you also need to do a "apt install pyra-meta-extra" to get the bt/etc stuff.
Updating uboot also needs to be done manually, which can be done with "sudo /usr/share/pyra/scripts/pyra-install-uboot.sh /usr/share/pyra/u-boot/pyra-u-boot-4g/ /dev/mmcblk0"
Replace /dev/mmcblk0 with /dev/mmcblk3 if you're running from sd, (or just look at the output of lsblk, and use the device that has the /boot partition on it (without any p1 added to the end))


the -nobat image is still the old one, so don't use that.

To set up a mobile broadband connection, open the mate menu and go to System Tools->Modem Manager GUI ( wait for the modem to appear, it takes about 256 seconds after booting)
On the Connection bar, click "Edit" , "Add connection" and make sure all values are right. "Ok" , then click "Activate" and it should all work.

It took me a bit to work through and combine what aTc said above with how I know that the process works from having done it a few times. I thought it might help the other Pyra prototype owners if I made a stepwise instructions set for installing the OS fresh to the eMMC card. If it doesn't, then the only time I wasted was my own.

Stepwise instructions to updating the eMMC on a Pyra Prototype using a Linux workstation.
1. Download file pyra-install.img.zip from

Index of /images/buster

packages.pyra-handheld.com

2. Extract file pyra-install.img.
3. Open a root prompt in a terminal. #
4. Navigate to the folder where you have extracted the file pyra-install.img.
5. Insert an SD card in a reader into a USB drive on the workstation.
6. fdisk -l to list the disk devices on your Linux workstation. In my case the target SD card in a USB reader is /dev/sdj. MAKE SURE YOU GET THIS RIGHT! The next step could overwrite your main OS on the workstation if you get the wrong device!
7. dd if=./pyra-install.img of=/dev/sdj bs=1M; sync Wait for the sync to complete and return to the # prompt.
8. Open a file manager. If you see a drive called PYRAINSTALL, tell the file manager to eject this. When told that it is safe to do so, remove the media from the workstation.
9. Power down your Pyra. Remove ALL media from the SD slots.
10. Insert this newly created SD card into the left SD slot on your Pyra.
11. Power on the Pyra. Wait. Eventually you will come to a prompt to press any key to power down the Pyra. Touch the space button. Pyra powers down.
12. Remove the install media from the Pyra.
13. Power on the Pyra. It should now boot from the freshly installed OS on the eMMC.
14. At the Welcome! prompt, answer Start now.
15. Calibrate Touchscreen? Yes.
16. It skips the actual touchscreen calibration and hops to a box prompting to Please enter your full name and fills it with +++++++++++ characters. Quickly click the cursor into this and hit backspace once to 'catch it'. It is filling at around 60 characters a second. Use/hold backspace then delete to get rid of this +++++++ filler.
17. Enter your name. I use 'Grench'.
18. Please choose a short username. I use 'grench'.
19. Please choose a new password. Click on the empty box and enter your preferred password. Click OK.
20. Confirm your new password. Type in the same password as on 19. Click OK.
21. Please choose a name for your Pyra. I use 'Marble'. Click OK.
22. Enable Firewall? I pick yes to this. There is a bit of a wait after entering this - give it a minute or three.
23. Geographic area: Drop down box. I pick "America" Next.
24. Time zone: This is by city, not actual time zones. It does not have to be YOUR city, just one within your time zone. For US Central Time, I choose "Chicago". Next.
25. Locales to be generated: This one has been a tripping point for some prototype owners. You do not need or want them all. By default, "de_DE_UTF-8 UTF-8" and, "en_US.UTF-8 UTF-8" and, "nl_NL_UTF-8 UTF-8" are all pre-selected. Unless you know that your language requires character sets outside of German, US English or Dutch Netherlands, you can just leave these as defaults and select "Next". IF you select 'all', then it could take 20-30 minutes before you get to step 30. Most of us should just select, Next.
26. Default locale for the system environment: This defaults to en_US.UTF-8. Since that is my locale, I simply leave it and select, Next. This takes about a half minute per locale that you selected. By default about a minute and a half. Be patient.
27. Done! select OK. Your Pyra will shut down. Give it a good 30 seconds after it shuts down.
28. Power on.
29. Your user name should be pre-selected. Enter your password. Select Log In.
30. Connect to WiFi. Hover the mouse pointer over the icon of one screen behind the other - should be just to the left of the partially blue battery icon. Left click on this icon by moving the right nub to the left with the cursor over the icon. Your local wireless network should be in the list. Hover over it and left click on it. It will prompt for a password if one is configured on the router. Left click 'Connect'.

The following steps are not needed on a fresh install as above.

Spoiler

Now to take care of getting the 'extras' and uboot set up right.
31. On the Pyra, right click on the desktop, left click on "Open in Terminal". This should open a command line terminal. In my case the prompt is grench@Marble:~/Dexktop$.
32. Type in the command, sudo su This will prompt for a sudo password for your user name. It is the same password you used to login. Enter it, it will be masked. No characters or *s will appear on the screen, but characters will be registered.
33. You should now have a prompt that on my screen looks like: root@Marble:/home/grench/Desktop# Yours will vary from that.
34. Type in the command: apt install pyra-meta-extra This was not needed on mine though it is in the instructions above. My install was already at the newest version (0.23).
35. Type in the command: # /usr/share/pyra/scripts/pyra-install-uboot.sh /usr/share/pyra/u-boot/pyra-u-boot-4g/ /dev/mmcblk0
For the above, you might want to open a browser window so that you can copy/paste if you don't want to type the whole thing in. Accuracy is important on this.
Should look like:
Installing U-boot...
0+1 records in
0+1 records out
65548 bytes (66 kB, 64KiB) copied, 0.00262484 s, 25.0 MB/s
0+1 records in
0+1 records out
342912 bytes (343 kmB, 335 KiB) copied, 0.0134252 s, 25.5 MB/s
Done.
36. Exit the command line window. # exit $ exit

37. Left nub mouse to the Pyra icon in the lower left corner of the screen. Right nub left to select, Shut Down, confirm Shut Down.
38. Wait at least 30 seconds to make sure the exit scripts have completed.

All done. Should be ready to go.

 

[Confuzzled]

There are several mechanisms, of different utility and complexity. nice, cpulimit and cgroups. cgroups is a general resource controller which is complicated to set up, but has most flexibility.

Restricting process CPU usage using nice, cpulimit, and cgroups | Scout APM Blog

There are at least three ways in which you can control how much CPU time a process gets: use the nice command, cpulimit, or Linux's cgroups.

scoutapm.com

I recommend reading up on cgroups, because as well as enforcing relative cpu usage restrictions (e.g. one process gets twice as much as another if they are competing for the same thing), you can also set cpu usage ceilings with the cpu.cfs_period_us and cpu.cfs_quota_us ( https://access.redhat.com/documenta...ml/resource_management_guide/sec-cpu#sect-cfs ).

I don't know if the letux kernel offers the cgroups capability, and if so, whether it is V1 or V2.

OK.

Assuming the Letux kernel has the Control Groups (cgroups) capability (Manipulating cgroups needs you to be running with root privileges, either logged in as root, using su, or sudo.):

1) You can check it is there by looking at the output of mount.

# mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)

You can see that the resources that can be controlled are displayed as if they are a set of filesystems. You can navigate around just like an 'ordinary' filesystem, and the tunable parameters are presented as if they are the contents of text files.

# cd /sys/fs/cgroup/cpu
# ls -1
cgroup.clone_children
cgroup.procs
cgroup.sane_behavior
cpuacct.stat
cpuacct.usage
cpuacct.usage_all
cpuacct.usage_percpu
cpuacct.usage_percpu_sys
cpuacct.usage_percpu_user
cpuacct.usage_sys
cpuacct.usage_user
cpu.cfs_period_us
cpu.cfs_quota_us
cpu.shares
cpu.stat
notify_on_release
release_agent
tasks

# cat /sys/fs/cgroup/cpu/cpu.cfs_period_us
100000

2) If you look at this answer on StackOverflow, it tells you how to set things up so a process can be restricted to a fixed percentage of the cpu.
First we create a new control group

#cgcreate -g cpu:/fixedlimit

you will see that a new directory named fixedlimit appears in /sys/fs/cgroup/cpu

# ls -1 /sys/fs/cgroup/cpu
cgroup.clone_children
cgroup.procs
cgroup.sane_behavior
cpuacct.stat
cpuacct.usage
cpuacct.usage_all
cpuacct.usage_percpu
cpuacct.usage_percpu_sys
cpuacct.usage_percpu_user
cpuacct.usage_sys
cpuacct.usage_user
cpu.cfs_period_us
cpu.cfs_quota_us
cpu.shares
cpu.stat
fixedlimit
notify_on_release
release_agent
tasks

If you look inside that directory, some familar 'files' appear

# ls -1 /sys/fs/cgroup/cpu/fixedlimit
cgroup.clone_children
cgroup.procs
cpuacct.stat
cpuacct.usage
cpuacct.usage_all
cpuacct.usage_percpu
cpuacct.usage_percpu_sys
cpuacct.usage_percpu_user
cpuacct.usage_sys
cpuacct.usage_user
cpu.cfs_period_us
cpu.cfs_quota_us
cpu.shares
cpu.stat
notify_on_release
tasks

Now fix 25% cpu usage (1 cpu)

# cgset -r cpu.cfs_period_us=100000 fixedlimit
# cgset -r cpu.cfs_quota_us=25000 fixedlimit

If you look at the contents of the two 'files', you see the parameters set up as you asked.

# cat /sys/fs/cgroup/cpu/fixedlimit/cpu.cfs_period_us
100000
# cat /sys/fs/cgroup/cpu/fixedlimit/cpu.cfs_quota_us
25000

Now we can run the program with the restrictions applied

# cgexec -g cpu:fixedlimit /my/hungry/program

/my/hungry/program will then have the control groups restrictions applied as it executes.


The RedHat documentation tells us what these parameters mean

Ceiling Enforcement Tunable Parameters

cpu.cfs_period_us
specifies a period of time in microseconds (µs, represented here as "us") for how regularly a cgroup's access to CPU resources should be reallocated. If tasks in a cgroup should be able to access a single CPU for 0.2 seconds out of every 1 second, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 1000000. The upper limit of the cpu.cfs_quota_us parameter is 1 second and the lower limit is 1000 microseconds.
cpu.cfs_quota_us
specifies the total amount of time in microseconds (µs, represented here as "us") for which all tasks in a cgroup can run during one period (as defined by cpu.cfs_period_us). As soon as tasks in a cgroup use up all the time specified by the quota, they are throttled for the remainder of the time specified by the period and not allowed to run until the next period. If tasks in a cgroup should be able to access a single CPU for 0.2 seconds out of every 1 second, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 1000000. Note that the quota and period parameters operate on a CPU basis. To allow a process to fully utilize two CPUs, for example, set cpu.cfs_quota_us to 200000 and cpu.cfs_period_us to 100000.
Setting the value in cpu.cfs_quota_us to -1 indicates that the cgroup does not adhere to any CPU time restrictions. This is also the default value for every cgroup (except the root cgroup).

There are control groups capabilities that can restrict/bind the process to a single cpu, and if the game operates by forking of a set of sub-processes, it is possible to ensure that they are captured in the same overall cpu use restrictions.

So, to be clear, cgroups DO NOT only allow you to control relative cpu use, but also absolute, which is what you are after. I have tested this on my own machine (not a Pyra), in my case seeing how long it took to start up Libreoffice with and without cgroups restrictions using the above tunable parameters. The difference was clear.

I hope this helps, and shows that it is indeed possible to restrict the amount of cpu a game uses without having to implement hardware throttling.

Edit to Add:

If it appears that you don't have cgcreate, cgset, and cgexec on your system, if the cgroups are there, you may well need to install the cgroup-tools package.
As root, sudo, or su do

# apt list cgroup-tools

If the package is not installed, you should see something like this:

Listing... Done
cgroup-tools/bionic,now 0.41-8ubuntu2 amd64

If the package is installed, you will see something like this:

Listing... Done
cgroup-tools/bionic,now 0.41-8ubuntu2 amd64 [installed]

Note the '[installed]'. If not installed, you can install by doing:

# apt install cgroup-tools

 

[aTc]

It took me a bit to work through and combine what aTc said above with how I know that the process works from having done it a few times. I thought it might help the other Pyra prototype owners if I made a stepwise instructions set for installing the OS fresh to the eMMC card. If it doesn't, then the only time I wasted was my own.


4. Navigate to the folder where you have extracted the file pyra-install.img.
5. Insert an SD card in a reader into a USB drive on the workstation.
6. fdisk -l to list the disk devices on your Linux workstation. In my case the target SD card in a USB reader is /dev/sdj. MAKE SURE YOU GET THIS RIGHT! The next step could overwrite your main OS on the workstation if you get the wrong device!
7. dd if=./pyra-install.img of=/dev/sdj bs=1M; sync Wait for the sync to complete and return to the # prompt.

It's far safer to just use a disk image writing tool instead of messing about with dd.
raspberrypi points you to https://www.balena.io/etcher/ for example, which has a nice gui where you can just select the .img.zip and an sd card and it'll write it. Also works on mac and windows.

Now to take care of getting the 'extras' and uboot set up right.

You can skip all that, the latest image already has that stuff included.
That part is only needed if you have an old install and don't want to lose everything by doing a reinstall.

 

[Grench]

It's far safer to just use a disk image writing tool instead of messing about with dd.
raspberrypi points you to https://www.balena.io/etcher/ for example, which has a nice gui where you can just select the .img.zip and an sd card and it'll write it. Also works on mac and windows.

And isn't present in the debian repository, requiring side-loading an additional application binary and learning how to use it.
I agree that dd has inherent risks. Weighing that against pointing the users to download and run a 3rd party program from a British Indian Ocean domain, I'd rather just stick with what is bundled with Debain myself. To each their own on this. Risk of a typo dumping the OS but inherently 'safe' software Vs a nice graphical interface from an unknown software supplier. For those using Windows, they'll have to find something to use to write the image file to the drive though, so it is a very good reference to have.

You can skip all that, the latest image already has that stuff included.
That part is only needed if you have an old install and don't want to lose everything by doing a reinstall.

You're right - I figured that out after I had already done it. A few extra unneeded steps in the above then if anyone decides to write it up again for a Wiki.