Jump to content

Linux for mobile computing: Difference between revisions

From IdeaWazaWiki
← Older edit

Idea (talk | contribs)

3 user groups
775 edits
No edit summary
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This article contains adjustments necessairy to the Linux OS in order to allow a special way of working with a proposed UMPC-design.
'''Linux for mobile computing''' concerns the use and development of Linux-based operating systems for smartphones, tablets, handheld computers, laptops, Ultra-Mobile PCs, and other portable computing devices.
__NOTOC__
Linux has become deeply important to mobile computing, although it appears in several substantially different forms. [[Android]] uses the Linux kernel and provides a mobile-oriented software platform designed around applications, touch input, power management, wireless communication, sensors, and strong application sandboxing. Other projects attempt to bring more conventional Linux distributions and desktop technologies directly to smartphones and tablets.


==Suggestion 1:Simplification of the Bourne Again Shell (on which Linux ;eg Fedora, ... works)==
The goals of Linux for mobile computing can include open software, user control, privacy, security, long hardware life, energy efficiency, touch-friendly interfaces, application compatibility, repairability, and the ability to use one device for both mobile and more traditional computing.
The Bourne Again Shell has, during its long lifetime, gained several improvements and thus new programs. This has had as a result that to perform a same specific task, the user is bothered with a amount of overlapping programs.  


Aldough Linux' self-correcting community might have resolved this earlier, as it is no longer actively used (now graphic interfaces are used instead) no corrections have been made for these flaws. Besides a large amount of overlapping programs, the command line interface has also a number of features which can be dismissed and replaced by other existing commands, hereby making a huge simplification possible.
Modern mobile Linux should therefore not be thought of simply as desktop Linux placed onto a smaller screen. Mobile devices create their own requirements involving cellular modems, battery life, cameras, GPS, suspend and resume, touch input, application permissions, sensors, hardware security, and limited physical input devices.


Examples on this are:
== Android and the Linux kernel ==
*viewing of a text file: this can be done by an excessive amount of programs as vi, pico, less, more, ...


*the unnecessairy grep-command; instead locate with a specific option (thus locate -xx) can perform this function if locate is altered so it allows this
[[Android]] is one of the most important examples of Linux in mobile computing.


*The unnecessairy possibility of using relative pathnames, this can be replaced by only allowing absolute pathnames
The Android Open Source Project, or [[Android Open Source Project|AOSP]], provides publicly available and modifiable source code for the Android operating system. Android kernels are based on the upstream Linux kernel with Android-specific changes and hardware support.


*The unnecessairy pwd-command; instead the current directory can just be shown in the command line itself (similar as in DOS).  
Android differs significantly from a conventional GNU/Linux desktop distribution. It has its own application framework, runtime, security architecture, hardware abstraction layers, user interface conventions, and application packaging system.


*The unnecessairy append I/O redirection and piping option; instead of using append (>>) one can simply use overwrite (>) instead
Android demonstrates that Linux can serve as the foundation for a mobile operating system without requiring the system to behave like a traditional Linux workstation.


*The write permissions included with files should no longer include type-information (only gives extremely limited information and would be better checked with the filename-extension. Also, support for a sticky bit (-t permission) should be dropped. Thus instead of presenting eg drwxrw-rw- this would become rwxrw-rw-
Important Android concepts include:


*the possible use of general points in folders (not being part of the extension) should be dropped. Thus folders named foo.bar etc can no longer be created. This has caused allot of confusion in the past.
{{Col}}
* Linux kernel
* Application sandboxing
* Application permissions
* [[Android Runtime]]
* Hardware abstraction layers
* Touch-oriented interfaces
* Mobile power management
{{break}}
* Cellular networking
* GPS and location
* Cameras
* Sensors
* Bluetooth
* Wi-Fi
* Application lifecycle management
{{colend}}


*finally, commands as ls for listing folders, ... are best changed to list. Changing the commands to these makes it easier to remember them.  
For Linux mobile computing research, Android is useful both as an existing implementation and as a source of ideas concerning security, battery management, hardware abstraction, and application design.


P.S.: Text also implemented to http://en.wikipedia.org/wiki/Talk:Bash#The_BASH.27_lack_of_simplification
== GrapheneOS ==


==Suggestion 2: Altering of the standard Linux directory tree structure==
[[GrapheneOS]] is an open-source mobile operating system based on AOSP with a strong emphasis on privacy and security.
Secondly, linux's Filesystem Hierarchy Standard' (FHS) directory tree structure should be altered, so that physical drives and imiginary folders/directory's are no longer used together. At the moment, for example physical drives are mapped in /dev while /, or /root (which are actually on a physical drive and should of been thus actually marked in a folder under /dev), ... are at a maplevel higher. It would be far better sense if simply the ports are detected and presented (thus a computer with 2 USB drives and a serial ATA-connection would get 3 folders under the root folder (/) knowingly SATA1, USB1, and USB2. The drives connected hereon would simply show their contence. The main drive (on which Fedora is placed) would then get the systems folder and user folders, ...  


In addition to this renaming of the logical drives, standard names for partitions too are to be altered. Instead of the now common names (hda, sdb, hda1, hda2, ..) these are to become Partition1, Partition2, Partition3, Swap (for the swap partition), ... The extra information obtained from the hd+a-d difference is negligable, especially as only hot swappable drives should be supported anyway (which have no slave/master/auto option) and only tend to confuse users.
GrapheneOS is particularly relevant to Linux for mobile computing because it demonstrates how an existing Linux-based mobile platform can be modified rather than designing an entirely new mobile operating system.


More information
The project adds substantial security and privacy improvements involving areas such as:
Filesystem Hierarchy Standard (FHS)
http://www.pathname.com/fhs/


Standard linux partition names
* Application sandboxing.
http://linux.org.mt/article/partnames
* Exploit mitigations.
* Memory protection.
* Permission controls.
* Network access controls.
* Hardware-backed device verification.
* Browser and WebView hardening.


==Suggestion 3: Dropping support for a variety of useless/surplus file formats and protocols  in favor of one good file format/protocol (per type)==
GrapheneOS does not include Google applications and services as privileged components of the operating system. Users who need Google Play compatibility can optionally install Google Play components in the normal application sandbox.


Firstly, the linux-distro (eg Fedora) could drop its support for outdated/archaïc aswell as recent/new but unusable file formats. Rather than supporting a wealth of file formats, it is better to only support one good file format per type ( e.g. lossy/lossless audio encoding, lossless and lossy video encoding, compression and/or archiving format, ...). By a good file format I mean that one that has the best qualifications for which it is intented and which is open-source/free file format.  
This creates an interesting model for an open mobile operating system: retain compatibility with a large existing application ecosystem while reducing the amount of privileged software that users must trust.


Aldough thus fewer formats can be played/executed, simplification and thus no longer supporting it would make computing simpler for the user itself and it would also allow Fedora of operating faster (as lesser code is required). Having a wealth of file formats supported not only confuses the user, but also makes him unaware what file-type to use in what situation (eg .tar.gz or .bz2 for tape archiving?) As Fedora is specifically targeted at the developing world (which still has mostly low-schooled people), this simplification may prove essential.  
GrapheneOS is not a conventional GNU/Linux distribution such as Debian or Fedora. However, because Android itself uses the Linux kernel, GrapheneOS is directly relevant to the larger subject of Linux-based mobile computing.


PS: Other Linux distributions as Gobuntu also feature solely open formats, yet this suggestion would still be different as it would allow but a single format per type, with the intent to simplify matters. This offcourse is not yet achieved in these distrubutions.  
* [https://grapheneos.org/ GrapheneOS]
* [https://source.android.com/ Android Open Source Project]


Examples are :
== Conventional mobile Linux ==
*.xcf and .svg for pictures
*OGG Vorbis instead of MP3, WMA, ... for lossy audio encoding
*Flac or Monkey's Audio instead of WAV, ... for lossless audio encoding
*.odt-files instead of .doc
*an open source combined compression and archiving file format as .7z to make a compressed and archived file (compressed file format alone aswell as archived file format alone not needed; when an open-source executable/install archiving format as rpm or paf aswell is supported )
*an open source archiving file format as .tar
*only UTF-8 for emails


In addition to dropping support for these file formats, allot of protocols aswell as environmentally damaging media should be dropped aswell. Besides in the intrest of the environment, the cd media (CD/DVD/DVDRAM/Blue-Ray, ...)would also be dropped as they only have a very limited lifetime, are easily corrupted and are not at all durable.
Another approach is to adapt conventional Linux distributions and desktop Linux technologies directly to phones and tablets.


Examples:
Current projects include:
SFTP instead of FTP
support for parallel and serial connections with devices should be dropped in favor of SATA, USB2 and FireWire800
support for USB1 should be dropped
support for appletalk should be dropped
support for the older ethernet cards/cables and protocols should be dropped, aswell as token ring ATM, ... in favor of PowerLine Communication (PLC)and gigabit ethernet
support for old forms of WiFi (802.11a-g) should be dropped in favor of WiMax and the new WiFi-protocol (802.11n) (if used)
support for Floppy's, CD/DVD/DVDRAM/Blue-Ray, should be dropped in favor of the best type of flash memory (CompactFlash?), and USB-sticks and external harddisks


Aldough this would transform the Linux version on which these suggestions are implemented  more and more to a embedded form of Linux, this would actually be very beneficial. This as not only matters are simplified greatly, but also as the processor needed to run the Linux-distro can be far less potent/energy consuming than normal. A example on this can be seen with the ECB_AT91 microcomputer and the ECB_ATmega32/644 microcomputer.
{{Col}}
* [[Nura]]
* [[Mobian]]
* [[Ubuntu Touch]]
* [[Plasma Mobile]]
{{break}}
* [[Phosh]]
* [[Sxmo]]
* [[Wayland]]
* [[ModemManager]]
{{colend}}


More information
'''Nura''', formerly known as postmarketOS, is an Alpine Linux-based operating system focused on mobile devices and extending the useful life of consumer electronics. It works with existing Linux projects rather than building an entirely separate software ecosystem.
Free file formats
http://en.wikipedia.org/wiki/Free_file_format
Comparisation of audio codecs
http://en.wikipedia.org/wiki/Comparison_of_audio_codecs
Comparisation of container formats
http://en.wikipedia.org/wiki/Comparison_of_container_formats
Comparisation of archive formats
http://en.wikipedia.org/wiki/List_of_archive_formats
Secure FTP
http://en.wikipedia.org/wiki/SFTP
USB2
http://en.wikipedia.org/wiki/USB2#USB_2.0
FireWire 800
http://en.wikipedia.org/wiki/Firewire#FireWire_800_.28IEEE_1394b.29
Serial ATA
http://en.wikipedia.org/wiki/SATA
WiFi
http://en.wikipedia.org/wiki/Wi-Fi
Flash Memory
http://en.wikipedia.org/wiki/Flash_memory
Powerline Communication
http://en.wikipedia.org/wiki/Power_line_communication
Gigabit Ethernet
http://en.wikipedia.org/wiki/Category_5_cable
http://en.wikipedia.org/wiki/10_gigabit_Ethernet


ECB AT91 and ECB_ATmega32/644 using a embedded linux and being able to run on a 180mhz cpu and 20 mhz cpu respectively
'''Mobian''' combines Debian with mobile-specific software and modifications. It provides another example of adapting an established Linux distribution to phones and tablets.
http://en.wikipedia.org/wiki/ECB_AT91
http://en.wikipedia.org/wiki/ECB_ATmega32/644


==Suggestion 4: Dropping support for dual booting==
'''Ubuntu Touch''' is maintained by the UBports community and provides a complete mobile operating system based on Ubuntu technologies.
At the moment, most linux-distro's still support the possibility of dual booting (that is: having multiple Operating Systems on a single device/drive from which one may be selected to run on startup). I believe it is best that this dual booting feature, along with the programs which support this and which are usually standard included in a regular installation should be best dropped. This will reduce many of the hassles frequently encountered with linux installations and make sure that everything is kept simple and more efficient. Instead of this dual booting by having 2 OS' on 1 disk, random booting of other OS's may still be done, but then trough physically connecting another drive (HD, USB-stick, ...) on which an other OS is installed. Selecting which OS to load first would be done merely trough the BIOS (boot sequence can be altered here).  


As people will revert to this technique, this approach would become more popular/easy and fits with the trend emerging to divert to a more easy and hot swappable form of computing/connecting of devices. As USB-sticks are rapidly becoming cheap and are already capable of storing entire OS' (eg Mac-on-a-Stick, Knoppix, LindowsLive, MojoPac, ...) and as all HD's are becoming hot swappable nowadays (trough Serial ATA/USB2/IEEE1394/...), this would prove far easier/simpler.  
'''Plasma Mobile''' is a mobile interface based on KDE Plasma technologies. It can be packaged by multiple Linux distributions rather than functioning solely as one operating system.


Having gone trough the troubles described myself with this "dual booting", lack of hot swappability (with E-IDE HD's, "jumpers" had to be manually set) and troubles/corruption of the "bootloaders/master boot record" on HD's, I am hoping that this might become a valid action which may be taken to make computers simpler/more efficient to operate.  
'''Phosh''' is another mobile graphical shell, originally developed for mobile Linux devices using GNOME technologies.


More information:
These projects demonstrate a different approach from Android. Rather than building a separate application and userspace platform around the Linux kernel, they attempt to reuse more of the traditional Linux software ecosystem.
Hot swapping and types of HD's and other devices
http://en.wikipedia.org/wiki/Serial_ATA
http://en.wikipedia.org/wiki/Hot_swapping
http://en.wikipedia.org/wiki/MojoPac
http://portableapps.com/apps/operating_systems/mac-on-stick


Live Linux disributions becoming more popular
== Hardware remains a major challenge ==
http://en.wikipedia.org/wiki/LiveDistro
http://en.wikipedia.org/wiki/List_of_LiveDistros


Dual booting, bootloaders and the master boot record of devices
One of the largest challenges for mobile Linux is hardware support.
http://en.wikipedia.org/wiki/GNU_GRUB
http://en.wikipedia.org/wiki/LILO_%28boot_loader%29
http://en.wikipedia.org/wiki/Dual_booting
http://en.wikipedia.org/wiki/Master_boot_record


==Suggestion 5: Fedora's possible feature of switching to a command line-executed programs split screen configuration==
Desktop and laptop Linux can often rely on standardized interfaces and hardware that already has upstream Linux drivers. Smartphones may rely heavily on vendor-specific software for:
In the past, Linux developments have been focusing on improving the Graphical User Interface (GUI) of Linux, so that inexperienced users (that do not know how to use the command line) may use Linux easier. However, this implementing of the extra subroutines needed to recognise mouse control has had an adverse effect on the systems speed and performanence. Also, besides making the system slower, one wonders why such mouse control needs to implemented anyhow as if is also the cause of 2 additional disadvantages. These are


the unpracticality of using a mouse when on the road (e.g. with a portable computer, or in crammed/busy environments as with public computers at airports, libraries, subways, ..)
* Cellular modems.
* Cameras.
* Graphics processors.
* Fingerprint readers.
* GPS.
* Audio hardware.
* Power management.
* Accelerometers and other sensors.


the slower speed at which you can operate a computer with a mouse versus with the command line, via keyboard (e.g. to perform the action of manually clicking the mouse, and not just the reduced speed of the computer)
A mobile operating system can boot successfully while still lacking important functions such as reliable calling, camera support, accelerated graphics, suspend, or acceptable battery life.


As such, it may be better to include the option of controlling Fedora Linux via keyboard, in a split screen configuration. This configuration would be composed at one side of a command-line window (BASH, ...) and on the other side a window with the executed programs (e.g. FireFox-syle browser, OpenOffice-style text-editor, ...). This configuration proposed would make the system speedier and more stable (as the GUI itself or less subroutines in the GUI are needed) and would also still allow a great deal of eye candy. More so, with some extra work, the configuration would also make it possible to make this OS even nicer than any other existing OS as it may allow complete 3D.  
Supporting hardware through the upstream Linux kernel can improve maintainability because devices are less dependent on old vendor-specific kernels and software.


Aldough the 3D features proposed may need some more time to implement, the terminal/program configuration can be implemented nearly immediatly and improve Fedora. For the 3D features, some of the coding done by OS's as IRIX and Linux-3D-modifications as Project Looking Glass can be used to create the modification to Fedora.
This is one reason that mobile Linux development involves substantial work beyond creating a graphical interface.


Finally, I wish to mention that, if you wish to implement the terminal window-program window - split screen configuration (described in the previous letter), a possible simplification of the current command line (BASH) can be implemented . This simplification of commands would allow more users to use this configuration as it would be much easier to learn the commands. Also, the combined terminal window - program window set-up would allow even further simplification. If you decide to implement the split-screen configuration and wishes to also reduce the commands used (simplify the BASH), please contact me for further assistance.
== Mobile-first interface design ==


P.S.: As noted, the suggestions on the Linux-distro above can be supplied as a optional packet with Fedora, leaving the user the liberty of installing it -or not-. As such, Fedora may still be controlled by mouse for those people that really don't want to change the way how they control their computers.  
The earlier idea of simply simplifying a desktop environment should be expanded.


More information:
A mobile Linux interface needs to account for:
Graphical User Interfaces (GUI)'s
http://en.wikipedia.org/wiki/Graphical_user_interface#Graphical_user_interfaces_compared_to_command_line_interfaces
Goobuntu (Google Linux distribution)
http://en.wikipedia.org/wiki/Goobuntu


IRIX (Unix distribution with 3D functionality)
* Small screens.
http://en.wikipedia.org/wiki/Irix
* Touch input.
Project Looking Glass (3D Modification for Linux)
* On-screen keyboards.
http://en.wikipedia.org/wiki/Project_Looking_Glass
* Gestures.
* Automatic screen rotation.
* High pixel density.
* Limited simultaneous windows.
* One-handed operation.
* External displays.
* Bluetooth keyboards and mice.


Compiz (3D Modification for Linux)
At the same time, mobile Linux can potentially support '''convergence''', where a portable device behaves differently depending on how it is being used.
http://en.wikipedia.org/wiki/Compiz


Croquet Project (3D Modification for Linux)
A phone could use a touch-oriented interface while handheld, then provide a more conventional windowed environment when connected to a monitor, keyboard, and mouse.
http://en.wikipedia.org/wiki/Croquet_Project


==Suggestion 6: Inclusion of a scaled-down virusscanner,  and other software==
This provides an interesting long-term goal for Linux mobile computing: one computer that can move between phone, tablet, and desktop-style roles.
There is a number of extra software that may be included with Linux-distro's. This includes programs as Sunbird, KeePass, the WeatherBug, BOINC (with climate change grid computing software) ..I would also suggest to implement a Linux-only virusscanner (to be used not in continuous and on-access scanning but only shedueled (weekly/monthly). Candidates herefore are Clam Antivirus and OpenAntivirus. In addition to a virusscanner, a open-source defragmentation program should be included.


The browser (eg Firefox) should be standardly equipped with plug ins that allow the clearing of the browsers cache after each session (to negate the effect of the harddisk slowly being clogged with unnecessairy data) and privacy measures/data erases (the plug-in should be able to perform the same tasks as the Wash 'N Go-program)
==Suggestion 1: Simplification without breaking Linux compatibility==
a cookie and spyware sweeper (eg as Avast Ad-aware)
the browser itself finally should drop support for the 'autocomplete'-function (to reduce risk of data-loss to third parties and malicious users)


In addition, a calender may be included (eg Mozilla Sunbird), and a program should be included to allow direct ebook-downloads. Such programs are eg [http://www.tomeraider.com/ Tomeraider] and [http://en.wikipedia.org/wiki/Mobipocket Mobipocket].
The original proposal suggested simplifying the [[Bash (Unix shell)|Bourne Again Shell]] by eliminating commands and features.


Also, text-translation tools should be implemented (eg trough on-line tools as Google Translate or -even better- off-line tools as [http://en.wikipedia.org/wiki/Comparison_of_machine_translation_applications Apertium]). A sentence-based translation device, capable of delivering direct speech translation should also be included, to allow (basic) inmediate translation assistance from the UMPC (still a small, mobile device). Programs able to provide this are eg the [http://www.engadget.com/2005/11/19/darpa-testing-laptop-based-translation-system-for-iraq/ new software program], derived from its Phraselator being build by DARPA.
The general desire for simplicity remains reasonable, but removing standard Linux functionality would create major compatibility problems.
'''More information''' <br />
Clam Antivirus <br />
http://en.wikipedia.org/wiki/ClamAV <br />


OpenAntivirus <br />
Commands such as <code>grep</code>, <code>pwd</code>, pipelines, relative paths, and I/O redirection remain important parts of Linux and Unix computing.
http://en.wikipedia.org/wiki/OpenAntiVirus <br />


Defragmentation utilities <br />
A better approach would be to provide an optional simplified layer.
http://en.wikipedia.org/wiki/Defragmentation <br />


==Suggestion 7: Use of a better filesystem and X-window Desktop Environment==
Examples include:
It is best that instead of the standard filesystem used by most Linux distrubutions (ext3) to opt for a newer and better filesystem as Reiser4, GFS-2, ext4, ...


Also, rather than the standard X-Window Destop Environment (GNOME and KDE) in use by most Linux distributions today, it is best to switch to a different/newer Window Manager. These include Enlightenment, Blackbox, Xfce, ...
* Human-readable command aliases.
* Command completion.
* Searchable history.
* Interactive help.
* Beginner-oriented examples.
* Graphical command launchers.
* Touch-friendly terminal interfaces.


More information
The underlying Linux tools can remain available for compatibility and advanced use.
Comparisation of file systems
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Comparisation of X Window Desktop Environments
http://en.wikipedia.org/wiki/Comparison_of_X_Window_System_desktop_environments


==Suggestion 8: Support for speech recognition and touchscreen==
On a mobile device, the command line itself can be extremely useful because many complicated tasks can be performed with relatively little screen space.
Speech recognition and the use of a touchscreen might be made standardly supported. This may allow tablet pc's or XO-1 PC's of being made smaller as no more mouse or keyboard is needed (taking up a massive amount of space). Rather than this, the speech recognition (along with a headset) may be used for writing letters, ...


More information
==Suggestion 2: Simplified storage presentation==
Ultra Mobile PC
http://en.wikipedia.org/wiki/Ultra-Mobile_PC
Tablet pc
http://en.wikipedia.org/wiki/Tablet_PC


Speech recognition
Linux should retain its standard filesystem architecture internally while providing mobile users with a much simpler representation.
http://en.wikipedia.org/wiki/Speech_recognition
http://en.wikipedia.org/wiki/NaturallySpeaking


==Suggestion 9: Cooperation with other companies and use of Google Services==
A file manager could present:
In order to achieve the more or less complicated suggestions/tasks layed out here, it may be helpful to cooperate with Google, Canonical Ltd. As Google has many useful services for the developing world (eg Google Maps/Earth for GPS navigation, Google Mail for emailing, Google Docs, ...) a cooperation with them seems logical. Also, Canonical is already developing Goobuntu (for Google Ubuntu) in cooperation with Google; as some features of this Linux distribution may be copied for use in Linux, cooperation with them too would prove beneficial. Finally, Canonical also has a cooperation with Dell which would finish the cycle of creating a powerful alliance against companies now working together solely in the intrest of profits.


Such lucrative alliances by other companies are for example Microsoft and Novell aswell as SUSE Linux which have recently promised to work together. This event will surely put stress on Linux companies operating on their own and at the moment; especially in the intrest of bridging the digital divide, it may be best to form open-source/humanitarian linux companies-alliances.  
* Internal storage.
* Downloads.
* Documents.
* Photos.
* Removable storage.
* Network storage.
* Application files where appropriate.


Canonical and Google working together
Users should not normally need to understand device identifiers such as <code>/dev/nvme0n1p2</code> simply to locate personal files.
http://en.wikipedia.org/wiki/Goobuntu


Goobuntu being installed on Dell computers
Advanced users should still be able to access the complete filesystem and normal Linux tools.
http://digg.com/linux_unix/Goobuntu_is_coming_


Microsoft and Novell and SUSE working together
==Suggestion 3: Prefer open formats and open protocols==
http://www.novell.com/linux/microsoft/
http://www.novell.com/linux/


==Suggestion 10: software for GPS-tracking via WiMax and other internet connections==
A mobile Linux system should prefer open and well-documented formats where practical.
A deamon should be integrated for automatic GPS/Galileo coordinate uploading. This should be automated in the deamon by the regular GPS-unit within the device (so w:GPS_tracking|no GPS-push tracker]]). GPS/Galileo coordinate uploading needs to be done automatic whenever a WiMax connection is detected with enabled internet-sharing. Also, whenever internet-connection is made via ethernet or satellite internet, the coordinates can be automatically uploaded. The deamon should include encrypted transmission, to ensure that the owners of free internet access points cannot read the information. Transmission can be done to a worldwide (or alternatively -communal-) database.


==Suggestion 11:VoIP program==
Possible preferred technologies include:
A VoIP-program allowing VoIP over WiFi/WiMax, aswell as accepting incoming phone calls and allowing outgoing one (both to regular telephones/GSM's as computers should be added. Candidates are Skype, or possibly X-lite, GnomeMeeting, Kphone or Ekiga. See [http://www.voidspace.org.uk/technology/voip_mobile.shtml this site].


A plug-in should also be created for the program, to allow automatic calling to people by issuing the command "call personname" trough the microphone. 
{{Col}}
* [[PNG]]
* [[SVG]]
* [[AVIF]]
* [[Opus]]
* [[FLAC]]
* [[AV1]]
{{break}}
* [[OpenDocument]]
* [[UTF-8]]
* [[WebM]]
* [[Matroska]]
* [[SFTP]]
* Open web standards
{{colend}}


The original idea of supporting only one format of each type should not be retained. A modern mobile device needs compatibility with files and services used by other computers.
Open formats can be recommended without deliberately making the device unable to read common alternatives.
== Modern mobile connectivity ==
Earlier versions of this proposal discussed WiMAX, FireWire, USB 2, and other technologies that reflected the mobile computing environment of their time.
A modern mobile Linux device may instead need support for:
* 4G and 5G cellular networks.
* [[Wi-Fi]].
* [[Bluetooth]].
* [[USB-C]].
* USB 3 and [[USB4]] where supported.
* NFC.
* GPS and other satellite navigation systems.
* eSIM or physical SIM technologies where appropriate.
* Wi-Fi hotspot and tethering functions.
Cellular support is particularly important for smartphones because calls, SMS, mobile data, emergency calling, and carrier technologies can depend on modem hardware and network compatibility.
== Security model ==
Mobile devices contain unusually large amounts of personal information and are frequently connected to untrusted networks.
Security should therefore be a central design concern rather than an optional application installed later.
Important protections can include:
* Application sandboxing.
* Mandatory access controls.
* Verified boot.
* Full-device or file-based encryption.
* Strong application permissions.
* Automatic security updates.
* Hardware-backed cryptography where available.
* Secure lock screens.
* Controls for microphones, cameras, location, and sensors.
Android and GrapheneOS provide particularly useful examples for studying mobile sandboxing and permission systems.
Conventional mobile Linux distributions can also use technologies such as AppArmor, SELinux, Flatpak permissions, containers, and application portals.
== Privacy and user control ==
A Linux mobile system can also provide strong user control over information.
Users should be able to determine whether applications can access:
{{Col}}
* Location
* Microphone
* Camera
* Contacts
* Files
{{break}}
* Bluetooth
* Sensors
* Network access
* Notifications
* Background activity
{{colend}}
Location history should not automatically be uploaded simply because an Internet connection becomes available.
An optional device-location or recovery system could instead offer:
* Explicit opt-in.
* Encryption.
* User-controlled retention.
* Self-hosting where practical.
* Clear indications when location is shared.
* Easy disabling.
== Applications and compatibility ==
Application availability is one of the most important questions for any mobile platform.
Android has an enormous existing application ecosystem. AOSP-derived systems can potentially retain Android application compatibility, as GrapheneOS demonstrates.
Traditional Linux mobile platforms can use Linux applications adapted to small screens. Technologies such as responsive GTK and KDE applications can allow programs to function on both desktop and mobile displays.
Projects such as [[Waydroid]] can also provide Android application compatibility on some conventional Linux systems by running Android in a containerized environment.
A future mobile Linux environment could therefore potentially support several application classes:
* Native mobile Linux applications.
* Responsive desktop Linux applications.
* Web applications.
* Android applications through compatibility systems.
* Terminal applications.
== Power management ==
Battery life is fundamental to mobile computing.
A technically powerful operating system that rapidly drains the battery is not practical for a phone or portable computer.
Mobile Linux development therefore needs to consider:
* CPU power states.
* Display power.
* Suspend and resume.
* Modem power consumption.
* Background applications.
* Wireless radios.
* GPU usage.
* Sensor activity.
* Application scheduling.
Power management should be tested on real hardware rather than assumed from desktop Linux behavior.
== Touchscreen, keyboard, and speech input ==
The older proposal suggested adding touchscreen and speech-recognition support. These are now normal mobile computing requirements.
A modern design should support several forms of input:
* Touch.
* Gestures.
* On-screen keyboard.
* Physical keyboard.
* Mouse or trackpad.
* Stylus.
* Speech recognition.
* Accessibility devices.
Local speech recognition can be particularly interesting for an open mobile platform because it can reduce dependence on cloud services.
Keyboard-oriented control should still be available. Linux can support both touch-first use and highly efficient keyboard workflows.
== Cameras, sensors, and location ==
Modern mobile computers commonly contain:
* Multiple cameras.
* Accelerometers.
* Gyroscopes.
* Magnetometers.
* Ambient light sensors.
* Proximity sensors.
* GPS receivers.
* Fingerprint readers.
* NFC hardware.
Linux mobile computing therefore requires more than networking and a small display.
Applications need secure and reliable ways to access these devices without automatically receiving unrestricted access to all hardware.
== Voice and real-time communication ==
The earlier proposal for a dedicated VoIP application remains relevant, although the software examples need updating.
Modern communication can involve:
* Cellular voice.
* [[Voice over IP]].
* [[SIP]].
* [[WebRTC]].
* Video conferencing.
* Encrypted messaging.
Possible open-source software and protocols include:
* [[Linphone]].
* [[Jitsi]].
* Matrix clients.
* SIP applications.
* WebRTC-compatible applications.
A Linux phone should ideally allow communication software to integrate with notifications, microphones, cameras, audio routing, Bluetooth headsets, and the system contact list while remaining subject to appropriate permissions.
== Desktop convergence ==
One particularly interesting area of mobile Linux is convergence.
A mobile computer could provide a simple touchscreen interface when used as a phone but become a more conventional Linux workstation when connected to external hardware.
Possible peripherals include:
* Monitor.
* Keyboard.
* Mouse.
* Dock.
* External storage.
* Ethernet.
* Game controller.
This could reduce the need for separate computers for some users.
Ubuntu Touch, KDE technologies, and other Linux mobile projects have experimented with this general concept.
== Open hardware and long device life ==
Linux for mobile computing also connects naturally with [[open source hardware]], repairability, and long-term device support.
Mobile devices can become obsolete because manufacturers stop distributing software updates even when the hardware remains functional.
Mainline Linux support can potentially help separate the useful life of hardware from the support schedule of one manufacturer.
An ideal open mobile computer could emphasize:
* Replaceable batteries where practical.
* Repairable components.
* Published hardware documentation.
* Long software support.
* Upstream Linux drivers.
* Unlockable bootloaders.
* Reinstallable operating systems.
* Standard connectors.
Projects such as Nura specifically explore extending useful device life through reusable Linux software.
== Different models for Linux mobile computing ==
There is no single approach that must be called Linux for mobile computing.
Several models can coexist:
{{Col}}
'''Android model'''
* Linux kernel
* AOSP userspace
* Android applications
* Strong mobile sandboxing
* Large application ecosystem
'''Hardened Android model'''
* AOSP foundation
* Android application compatibility
* Additional security and privacy
* Example: [[GrapheneOS]]
{{break}}
'''Traditional Linux model'''
* GNU/Linux or similar userspace
* Standard Linux packages
* Wayland
* Mobile shells
* Examples: Nura and Mobian
'''Convergent model'''
* Mobile interface when handheld
* Desktop interface when docked
* Shared applications and files
* Phone as a general-purpose computer
{{colend}}
These approaches can learn from one another.
Traditional Linux mobile systems can study Android's sandboxing, hardware abstractions, and power management. Android-derived systems can benefit from ideas involving open development, user control, terminal access, self-hosting, and the broader Linux ecosystem.
== Research and development questions ==
The modern question is therefore not simply, "How can Linux be made small enough for a UMPC?"
More useful questions include:
* How can mobile hardware remain supported for many years?
* How can applications be strongly sandboxed without making the device difficult to use?
* Can a phone also function as a full Linux workstation?
* Can Android application compatibility coexist with a more traditional Linux environment?
* How can mobile devices provide privacy without sacrificing basic functionality?
* How much mobile hardware can be supported using upstream Linux?
* Can open hardware make long-term mobile Linux support easier?
* How should mobile operating systems handle proprietary firmware?
* Can local artificial intelligence reduce dependence on cloud services?
* What can conventional Linux distributions learn from Android and GrapheneOS?
* What can Android-derived systems learn from conventional GNU/Linux?
* How can old smartphones be kept useful rather than becoming electronic waste?
== Current projects and resources ==
{{Col}}
* [[Android]]
* [[Android Open Source Project]]
* [[GrapheneOS]]
* [[Nura]]
* [[Mobian]]
* [[Ubuntu Touch]]
{{break}}
* [[Plasma Mobile]]
* [[Phosh]]
* [[Sxmo]]
* [[Waydroid]]
* [[Linux]]
* [[Wayland]]
{{colend}}
==Readings from Wikipedia==
* [[Wikipedia:Linux|Linux]]
* [[Wikipedia:Mobile operating system|Mobile operating system]]
* [[Wikipedia:Android (operating system)|Android]]
* [[Wikipedia:Android Open Source Project|Android Open Source Project]]
* [[Wikipedia:GrapheneOS|GrapheneOS]]
* [[Wikipedia:Linux for mobile devices|Linux for mobile devices]]
* [[Wikipedia:Ubuntu Touch|Ubuntu Touch]]
* [[Wikipedia:Plasma Mobile|Plasma Mobile]]
* [[Wikipedia:Phosh|Phosh]]
* [[Wikipedia:Wayland (protocol)|Wayland]]
* [[Wikipedia:Mobile computing|Mobile computing]]
* [[Wikipedia:Smartphone|Smartphone]]
* [[Wikipedia:Ultra-Mobile PC|Ultra-Mobile PC]]
* [[Wikipedia:Voice over IP|Voice over IP]]
* [[Wikipedia:Global Positioning System|Global Positioning System]]
== External links ==
* [https://source.android.com/ Android Open Source Project]
* [https://grapheneos.org/ GrapheneOS]
* [https://nura.eco/ Nura]
* [https://mobian-project.org/ Mobian]
* [https://www.ubuntu-touch.io/ Ubuntu Touch]
* [https://plasma-mobile.org/ Plasma Mobile]
* [https://phosh.mobi/ Phosh]
==See also==
{{Col}}
* [[Open design]]
* [[Open cellphone]]
* [[Open laptop]]
* [[Open wifi]]
* [[Open router]]
* [[Linux]]
* [[Ubuntu]]
* [[Android]]
{{break}}
* [[GrapheneOS]]
* [[Open source hardware]]
* [[Open source software]]
* [[Mobile computing]]
* [[Privacy]]
* [[Computer security]]
* [[Right to repair]]
* [[Self-sufficiency]]
{{colend}}
[[Category:Linux]]
[[Category:Mobile computing]]
[[Category:Mobile operating systems]]
[[Category:Design]]
[[Category:Design]]
[[Category:Self-sufficiency]]
[[Category:Self-sufficiency]]

Latest revision as of 04:34, 3 October 2026

Linux for mobile computing concerns the use and development of Linux-based operating systems for smartphones, tablets, handheld computers, laptops, Ultra-Mobile PCs, and other portable computing devices.

Linux has become deeply important to mobile computing, although it appears in several substantially different forms. Android uses the Linux kernel and provides a mobile-oriented software platform designed around applications, touch input, power management, wireless communication, sensors, and strong application sandboxing. Other projects attempt to bring more conventional Linux distributions and desktop technologies directly to smartphones and tablets.

The goals of Linux for mobile computing can include open software, user control, privacy, security, long hardware life, energy efficiency, touch-friendly interfaces, application compatibility, repairability, and the ability to use one device for both mobile and more traditional computing.

Modern mobile Linux should therefore not be thought of simply as desktop Linux placed onto a smaller screen. Mobile devices create their own requirements involving cellular modems, battery life, cameras, GPS, suspend and resume, touch input, application permissions, sensors, hardware security, and limited physical input devices.

Android and the Linux kernel

Android is one of the most important examples of Linux in mobile computing.

The Android Open Source Project, or AOSP, provides publicly available and modifiable source code for the Android operating system. Android kernels are based on the upstream Linux kernel with Android-specific changes and hardware support.

Android differs significantly from a conventional GNU/Linux desktop distribution. It has its own application framework, runtime, security architecture, hardware abstraction layers, user interface conventions, and application packaging system.

Android demonstrates that Linux can serve as the foundation for a mobile operating system without requiring the system to behave like a traditional Linux workstation.

Important Android concepts include:

  • Linux kernel
  • Application sandboxing
  • Application permissions
  • Android Runtime
  • Hardware abstraction layers
  • Touch-oriented interfaces
  • Mobile power management
  • Cellular networking
  • GPS and location
  • Cameras
  • Sensors
  • Bluetooth
  • Wi-Fi
  • Application lifecycle management

For Linux mobile computing research, Android is useful both as an existing implementation and as a source of ideas concerning security, battery management, hardware abstraction, and application design.

GrapheneOS

GrapheneOS is an open-source mobile operating system based on AOSP with a strong emphasis on privacy and security.

GrapheneOS is particularly relevant to Linux for mobile computing because it demonstrates how an existing Linux-based mobile platform can be modified rather than designing an entirely new mobile operating system.

The project adds substantial security and privacy improvements involving areas such as:

  • Application sandboxing.
  • Exploit mitigations.
  • Memory protection.
  • Permission controls.
  • Network access controls.
  • Hardware-backed device verification.
  • Browser and WebView hardening.

GrapheneOS does not include Google applications and services as privileged components of the operating system. Users who need Google Play compatibility can optionally install Google Play components in the normal application sandbox.

This creates an interesting model for an open mobile operating system: retain compatibility with a large existing application ecosystem while reducing the amount of privileged software that users must trust.

GrapheneOS is not a conventional GNU/Linux distribution such as Debian or Fedora. However, because Android itself uses the Linux kernel, GrapheneOS is directly relevant to the larger subject of Linux-based mobile computing.

Conventional mobile Linux

Another approach is to adapt conventional Linux distributions and desktop Linux technologies directly to phones and tablets.

Current projects include:

Nura, formerly known as postmarketOS, is an Alpine Linux-based operating system focused on mobile devices and extending the useful life of consumer electronics. It works with existing Linux projects rather than building an entirely separate software ecosystem.

Mobian combines Debian with mobile-specific software and modifications. It provides another example of adapting an established Linux distribution to phones and tablets.

Ubuntu Touch is maintained by the UBports community and provides a complete mobile operating system based on Ubuntu technologies.

Plasma Mobile is a mobile interface based on KDE Plasma technologies. It can be packaged by multiple Linux distributions rather than functioning solely as one operating system.

Phosh is another mobile graphical shell, originally developed for mobile Linux devices using GNOME technologies.

These projects demonstrate a different approach from Android. Rather than building a separate application and userspace platform around the Linux kernel, they attempt to reuse more of the traditional Linux software ecosystem.

Hardware remains a major challenge

One of the largest challenges for mobile Linux is hardware support.

Desktop and laptop Linux can often rely on standardized interfaces and hardware that already has upstream Linux drivers. Smartphones may rely heavily on vendor-specific software for:

  • Cellular modems.
  • Cameras.
  • Graphics processors.
  • Fingerprint readers.
  • GPS.
  • Audio hardware.
  • Power management.
  • Accelerometers and other sensors.

A mobile operating system can boot successfully while still lacking important functions such as reliable calling, camera support, accelerated graphics, suspend, or acceptable battery life.

Supporting hardware through the upstream Linux kernel can improve maintainability because devices are less dependent on old vendor-specific kernels and software.

This is one reason that mobile Linux development involves substantial work beyond creating a graphical interface.

Mobile-first interface design

The earlier idea of simply simplifying a desktop environment should be expanded.

A mobile Linux interface needs to account for:

  • Small screens.
  • Touch input.
  • On-screen keyboards.
  • Gestures.
  • Automatic screen rotation.
  • High pixel density.
  • Limited simultaneous windows.
  • One-handed operation.
  • External displays.
  • Bluetooth keyboards and mice.

At the same time, mobile Linux can potentially support convergence, where a portable device behaves differently depending on how it is being used.

A phone could use a touch-oriented interface while handheld, then provide a more conventional windowed environment when connected to a monitor, keyboard, and mouse.

This provides an interesting long-term goal for Linux mobile computing: one computer that can move between phone, tablet, and desktop-style roles.

Suggestion 1: Simplification without breaking Linux compatibility

The original proposal suggested simplifying the Bourne Again Shell by eliminating commands and features.

The general desire for simplicity remains reasonable, but removing standard Linux functionality would create major compatibility problems.

Commands such as grep, pwd, pipelines, relative paths, and I/O redirection remain important parts of Linux and Unix computing.

A better approach would be to provide an optional simplified layer.

Examples include:

  • Human-readable command aliases.
  • Command completion.
  • Searchable history.
  • Interactive help.
  • Beginner-oriented examples.
  • Graphical command launchers.
  • Touch-friendly terminal interfaces.

The underlying Linux tools can remain available for compatibility and advanced use.

On a mobile device, the command line itself can be extremely useful because many complicated tasks can be performed with relatively little screen space.

Suggestion 2: Simplified storage presentation

Linux should retain its standard filesystem architecture internally while providing mobile users with a much simpler representation.

A file manager could present:

  • Internal storage.
  • Downloads.
  • Documents.
  • Photos.
  • Removable storage.
  • Network storage.
  • Application files where appropriate.

Users should not normally need to understand device identifiers such as /dev/nvme0n1p2 simply to locate personal files.

Advanced users should still be able to access the complete filesystem and normal Linux tools.

Suggestion 3: Prefer open formats and open protocols

A mobile Linux system should prefer open and well-documented formats where practical.

Possible preferred technologies include:

The original idea of supporting only one format of each type should not be retained. A modern mobile device needs compatibility with files and services used by other computers.

Open formats can be recommended without deliberately making the device unable to read common alternatives.

Modern mobile connectivity

Earlier versions of this proposal discussed WiMAX, FireWire, USB 2, and other technologies that reflected the mobile computing environment of their time.

A modern mobile Linux device may instead need support for:

  • 4G and 5G cellular networks.
  • Wi-Fi.
  • Bluetooth.
  • USB-C.
  • USB 3 and USB4 where supported.
  • NFC.
  • GPS and other satellite navigation systems.
  • eSIM or physical SIM technologies where appropriate.
  • Wi-Fi hotspot and tethering functions.

Cellular support is particularly important for smartphones because calls, SMS, mobile data, emergency calling, and carrier technologies can depend on modem hardware and network compatibility.

Security model

Mobile devices contain unusually large amounts of personal information and are frequently connected to untrusted networks.

Security should therefore be a central design concern rather than an optional application installed later.

Important protections can include:

  • Application sandboxing.
  • Mandatory access controls.
  • Verified boot.
  • Full-device or file-based encryption.
  • Strong application permissions.
  • Automatic security updates.
  • Hardware-backed cryptography where available.
  • Secure lock screens.
  • Controls for microphones, cameras, location, and sensors.

Android and GrapheneOS provide particularly useful examples for studying mobile sandboxing and permission systems.

Conventional mobile Linux distributions can also use technologies such as AppArmor, SELinux, Flatpak permissions, containers, and application portals.

Privacy and user control

A Linux mobile system can also provide strong user control over information.

Users should be able to determine whether applications can access:

  • Location
  • Microphone
  • Camera
  • Contacts
  • Files
  • Bluetooth
  • Sensors
  • Network access
  • Notifications
  • Background activity

Location history should not automatically be uploaded simply because an Internet connection becomes available.

An optional device-location or recovery system could instead offer:

  • Explicit opt-in.
  • Encryption.
  • User-controlled retention.
  • Self-hosting where practical.
  • Clear indications when location is shared.
  • Easy disabling.

Applications and compatibility

Application availability is one of the most important questions for any mobile platform.

Android has an enormous existing application ecosystem. AOSP-derived systems can potentially retain Android application compatibility, as GrapheneOS demonstrates.

Traditional Linux mobile platforms can use Linux applications adapted to small screens. Technologies such as responsive GTK and KDE applications can allow programs to function on both desktop and mobile displays.

Projects such as Waydroid can also provide Android application compatibility on some conventional Linux systems by running Android in a containerized environment.

A future mobile Linux environment could therefore potentially support several application classes:

  • Native mobile Linux applications.
  • Responsive desktop Linux applications.
  • Web applications.
  • Android applications through compatibility systems.
  • Terminal applications.

Power management

Battery life is fundamental to mobile computing.

A technically powerful operating system that rapidly drains the battery is not practical for a phone or portable computer.

Mobile Linux development therefore needs to consider:

  • CPU power states.
  • Display power.
  • Suspend and resume.
  • Modem power consumption.
  • Background applications.
  • Wireless radios.
  • GPU usage.
  • Sensor activity.
  • Application scheduling.

Power management should be tested on real hardware rather than assumed from desktop Linux behavior.

Touchscreen, keyboard, and speech input

The older proposal suggested adding touchscreen and speech-recognition support. These are now normal mobile computing requirements.

A modern design should support several forms of input:

  • Touch.
  • Gestures.
  • On-screen keyboard.
  • Physical keyboard.
  • Mouse or trackpad.
  • Stylus.
  • Speech recognition.
  • Accessibility devices.

Local speech recognition can be particularly interesting for an open mobile platform because it can reduce dependence on cloud services.

Keyboard-oriented control should still be available. Linux can support both touch-first use and highly efficient keyboard workflows.

Cameras, sensors, and location

Modern mobile computers commonly contain:

  • Multiple cameras.
  • Accelerometers.
  • Gyroscopes.
  • Magnetometers.
  • Ambient light sensors.
  • Proximity sensors.
  • GPS receivers.
  • Fingerprint readers.
  • NFC hardware.

Linux mobile computing therefore requires more than networking and a small display.

Applications need secure and reliable ways to access these devices without automatically receiving unrestricted access to all hardware.

Voice and real-time communication

The earlier proposal for a dedicated VoIP application remains relevant, although the software examples need updating.

Modern communication can involve:

Possible open-source software and protocols include:

  • Linphone.
  • Jitsi.
  • Matrix clients.
  • SIP applications.
  • WebRTC-compatible applications.

A Linux phone should ideally allow communication software to integrate with notifications, microphones, cameras, audio routing, Bluetooth headsets, and the system contact list while remaining subject to appropriate permissions.

Desktop convergence

One particularly interesting area of mobile Linux is convergence.

A mobile computer could provide a simple touchscreen interface when used as a phone but become a more conventional Linux workstation when connected to external hardware.

Possible peripherals include:

  • Monitor.
  • Keyboard.
  • Mouse.
  • Dock.
  • External storage.
  • Ethernet.
  • Game controller.

This could reduce the need for separate computers for some users.

Ubuntu Touch, KDE technologies, and other Linux mobile projects have experimented with this general concept.

Open hardware and long device life

Linux for mobile computing also connects naturally with open source hardware, repairability, and long-term device support.

Mobile devices can become obsolete because manufacturers stop distributing software updates even when the hardware remains functional.

Mainline Linux support can potentially help separate the useful life of hardware from the support schedule of one manufacturer.

An ideal open mobile computer could emphasize:

  • Replaceable batteries where practical.
  • Repairable components.
  • Published hardware documentation.
  • Long software support.
  • Upstream Linux drivers.
  • Unlockable bootloaders.
  • Reinstallable operating systems.
  • Standard connectors.

Projects such as Nura specifically explore extending useful device life through reusable Linux software.

Different models for Linux mobile computing

There is no single approach that must be called Linux for mobile computing.

Several models can coexist:

Android model

  • Linux kernel
  • AOSP userspace
  • Android applications
  • Strong mobile sandboxing
  • Large application ecosystem

Hardened Android model

  • AOSP foundation
  • Android application compatibility
  • Additional security and privacy
  • Example: GrapheneOS

Traditional Linux model

  • GNU/Linux or similar userspace
  • Standard Linux packages
  • Wayland
  • Mobile shells
  • Examples: Nura and Mobian

Convergent model

  • Mobile interface when handheld
  • Desktop interface when docked
  • Shared applications and files
  • Phone as a general-purpose computer

These approaches can learn from one another.

Traditional Linux mobile systems can study Android's sandboxing, hardware abstractions, and power management. Android-derived systems can benefit from ideas involving open development, user control, terminal access, self-hosting, and the broader Linux ecosystem.

Research and development questions

The modern question is therefore not simply, "How can Linux be made small enough for a UMPC?"

More useful questions include:

  • How can mobile hardware remain supported for many years?
  • How can applications be strongly sandboxed without making the device difficult to use?
  • Can a phone also function as a full Linux workstation?
  • Can Android application compatibility coexist with a more traditional Linux environment?
  • How can mobile devices provide privacy without sacrificing basic functionality?
  • How much mobile hardware can be supported using upstream Linux?
  • Can open hardware make long-term mobile Linux support easier?
  • How should mobile operating systems handle proprietary firmware?
  • Can local artificial intelligence reduce dependence on cloud services?
  • What can conventional Linux distributions learn from Android and GrapheneOS?
  • What can Android-derived systems learn from conventional GNU/Linux?
  • How can old smartphones be kept useful rather than becoming electronic waste?

Current projects and resources

Readings from Wikipedia

See also

Retrieved from "https://ideawaza.com/index.php?title=Linux_for_mobile_computing&oldid=84158"