LibrePlanet2022: shrik FSF abstract to ~300 words

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>

1 files changed, 32 insertions, 48 deletions

diff --git a/LibrePlanet2022/abstract.txt b/LibrePlanet2022/abstract.txt
index 7b99949..8cb8ced 100644
--- a/LibrePlanet2022/abstract.txt
+++ b/LibrePlanet2022/abstract.txt
@@ -1,65 +1,49 @@
-While Android is very different from GNU/Linux, in both GNU/Linux and
-Android, not all the device drivers[1] are inside the Linux kernel.
+In both GNU/Linux and Android, not all the drivers[1] are inside the
+Linux kernel.
 
-In GNU/Linux, only a minority of drivers run outside the Linux
-kernel. For instance for a given (Intel, AMD or Nvidia) Graphic
-card[2] part of the drivers code that makes them work is in Linux, and
-part of it is in Mesa[3]. With modem drivers, part of the code is also
-not in Linux but in projects like oFono and ModemManager. The
-consequence is that in GNU/Linux the hardware abstraction is mostly
-done inside Linux.
+In GNU/Linux with Graphic Cards[2] and modems, where part of their
+drivers is in Linux and part is in other projects like Mesa[3] for the
+Graphic cards, or oFono[4] and ModemManager[5] for the modems.
 
-In Android most of the hardware abstraction is done in the Android
-hardware abstraction libraries instead. This smartphone and tablet
-manufacturers to ship heavily modified Linux kernels that were
-completely incompatible with GNU/Linux.
-
-For instance on the HTC Dream, the first Android smartphone that was
-released, the Linux kernel that was shipped on it had completely
-different API for many basic hardware features like sound.
+In GNU/Linux, the hardware abstraction is done mostly inside Linux
+because only a minority of drivers run outside Linux.
 
-So if you ran GNU/Linux with that kernel, sound would not work at all
-because none of the applications (like VLC, mplayer and so on) nor
-GNU/Linux components handling sound (like PulseAudio) implemented that
-completely different API.
+In Android most of the hardware abstraction is done in the Android
+hardware abstraction libraries instead: Smartphone and tablet
+manufacturers can then ship heavily modified Linux kernels that are
+incompatible with GNU/Linux.
 
-The kernel of that phone also used the wrong API for the backlight for
-instance, so to run GNU/Linux on it you had either to modify the
-vendor kernel to use the correct API or adapt all the GNU/Linux
-software that handled the backlight (like gnome, KDE, Xfce, etc) to
-handle the specifics of that phone.
+For instance on the first Android smartphone, the Linux kernel that
+was shipped on it had completely different APIs for many hardware
+features like sound. The upstream Linux Linux kernel didn't support
+that device and with the vendor kernel, sound didn't work in
+GNU/Linux.
 
-In Android however, since applications don't interact directly with
-the Linux kernel, hardware manufacturers can break the kernel API and
-ship Android hardware abstraction libraries, without breaking any
-applications.
+But sound worked in Android because Android applications don't
+interact directly with the Linux kernel, and because hardware
+manufacturers ship Android hardware abstraction libraries that
+abstract away these kenrel changes without breaking applications.
 
 Until Replicant 6 (included), most of the work on Replicant consisted
 in reusing free hardware abstraction libraries and replacing or
 avoiding the nonfree ones.
 
-This meant that most of our work was tied on:
-- Kernels based on those provided by the device manufacturers.
-- Android Distributions like LineageOS that keep the compatibility
-  with older kernels and hardware abstraction libraries in newer
-  Android versions.
-
-So if LineageOS stopped supporting a device we had to also stop
-supporting it. We were also not free to choose which project to
-collaborate with as we had to use what worked with the kernel provided
-by device manufacturers.
+This meant that most of our work was tied to the device manufacturer
+kernels and to Android distributions like LineageOS that keep the
+compatibility with older kernels and hardware abstraction libraries in
+newer Android versions, until they stop supporting the devices that
+use them.
 
-This talk will look at how we are trying to get rid of these unwanted
-dependencies, and the consequences of it for the Replicant project.
+This talk will look at why and how we are trying to get rid of these
+dependencies, and the consequences for the Replicant project.
 
 It will also answer question often asked by less technical people like
 why one can't easily install GNU/Linux on smartphones, why Android
-distributions don't support all smartphones, smartphones (planned or
-unplanned) obsolescence, etc.
+distributions don't support all smartphones, or issues related to
+(planned or unplanned) obsolescence.
 
 [1]https://en.wikipedia.org/wiki/Device_driver
 [2]https://en.wikipedia.org/wiki/Graphics_card
-[3]The mesa project provides drivers for many graphic cards that are
-   outside of the kernel and that talk to their kernel counterpart.
-[4]To use that compatibility you may need to recompile the kernel with
-   certain options though.
+[3]https://en.wikipedia.org/wiki/Mesa_(computer_graphics)
+[4]https://en.wikipedia.org/wiki/OFono
+[5]https://www.freedesktop.org/wiki/Software/ModemManager/