scaleddownapertisimage: replace minimal by fixedfunction

Rename `minimal` to `fixedfunction` to reflects the "Fixed function device
scenario" from Apertis Platform Technical Vision.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

content/guides/scaleddownapertisimage.md

 +++
 date = "2019-11-26"
+lastmod = "2021-09-15"
 weight = 100
 toc = true
 
@@ -23,7 +24,7 @@ usage (flash, cpu, ram) needs to be at an absolute minimum.
 
 # Proof of concept goals
 
-The goal of the minimal Apertis image is to show that it is possible to
+The goal of the fixedfunction Apertis image is to show that it is possible to
 use Apertis in such situation. To validate that an initial set of
 resource targets was set out and initial image create to see if we can
 match those.
@@ -166,7 +167,7 @@ isn't expected to be used at runtime. Further analysis revealed that the
 reason python was installed was due to the AppArmor package containing a
 small command line utility to query AppArmor status, as this is not
 expected to be used in production the Python dependency from AppArmor
-could be reduced to a Recommends. As a result of this the minimal images
+could be reduced to a Recommends. As a result of this the fixedfunction images
 no longer have Python, saving over 32 megabytes of space on the system.
 
 ## Flash footprint reduction results
@@ -194,7 +195,7 @@ flash footprint.
 
 Analysing the current image further it is clear that the footprint can be
 reduced even further, the work thusfar has focussed on the biggest wins
-with the smallest impact on the overall Apertis sytem (allowing minimal
+with the smallest impact on the overall Apertis sytem (allowing fixedfunction
 images to be build with a small extra effort next to the normal set of
 images).
 
@@ -214,7 +215,7 @@ complex. Apart from the programs required for the updating themselves a
 lot of meta-data is required on the system itself for determining both
 the current state of the system, for the available packages as the
 packaging tools need to be able to calculate the exact dependency tree
-and determine what can be upgrade etc. Even on our minimal system the
+and determine what can be upgrade etc. Even on our fixedfunction system the
 combination of the updating tools and their data files & caches uses
 about 17 megabytes of space, more then 10 percent of the system
 footprint\!
@@ -227,7 +228,7 @@ files to be installed onto the system (e.g. documentation, localisation
 files) to lower the system footprint without requiring all the packages
 to be changed (which would not make them suitable for other types of
 systems). Which is essentially what made it possible to build the
-minimal images with a small amount of effort based on the same package
+fixedfunction images with a small amount of effort based on the same package
 set used for other image types. However this means that the downloaded
 packages for updates will still have these files included which means
 bigger downloads and a bigger amount of temporary storage is required
@@ -244,7 +245,7 @@ side.
 
 # Runtime system tests
 
-With a minimal image available some basic runtime tests were done on an
+With a fixedfunction image available some basic runtime tests were done on an
 i.MX6 (Quad core) SabreLite. To emulate a scaled-down system a modified
 device-tree was used to limit the total available system memory to 64
 Megabytes and limit the available CPU to one core clocked at the lowest
@@ -272,7 +273,7 @@ total available system memory.
 
 Overall the proof of concept images have successfully shown that the
 targets that were set out could be hit, making Apertis viable for
-minimal images of these size. But as always things can be futher
+fixedfunction images of these size. But as always things can be futher
 improved, to re-highlight the various topic mention in this overview:
 
   - Research/Analyse/improve the update strategy used for our systems.