Linux adaptations for UMPC design
This article contains adjustments necessairy to the Linux OS in order to allow a special way of working with a proposed UMPC-design.
Suggestion 1:Simplification of the Bourne Again Shell (on which Linux ;eg Fedora, ... works) 
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.
Examples on this are:
- viewing of a text file: this can be done by an excessive amount of programs as vi, pico, less, more, ... One of these programs can be picked, and can be made executable by the command "read".
- 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
- The unnecessairy possibility of using relative pathnames, this can be replaced by only allowing absolute pathnames
- The unnecessairy pwd-command; instead the current directory can just be shown in the command line itself (similar as in DOS).
- The unnecessairy "mkdir" and "rmdir" commands; these can be swapped for the current "rm" command (which should be renamed to respectively the "make" and "remove" command)
- The "make" command can be renamed to the "compile" command
- The unnecessairy append I/O redirection and piping option; instead of using append (>>) one can simply use overwrite (>) instead
- 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-
- 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.
- commands as ls for listing folders, rm for deleting files, mv for renaming files, "cp for copying files, ... are best changed to simple commandnames as "list", "remove", "rename", "copy", ... Changing the commands to these simpler commandnames makes it easier to remember them. In the linux version proposed at http://en.wikiversity.org/wiki/Improved_UMPC_design ,the "list" command is no longer useful at all as by typing in "cd" together with a path, a window automatically opens showing the contents of that folder. So, "list" can be deleted in this linux version. However, in other linux versions it still has purpose. In these, "list" should automatically list the filenames as filename.extension. This way, the -F function no longer needs to be used. Folders should hereby be given their own specific extension aswell. The "remove" command should always be recursive; that way the -r option no longer needs to be used. Perhaps it can be made standard to let the system ask for a confirmation however.
- a new command can be created called "move". This can be used to copy a file to a different location, and delete the file at its old location.
P.S.: Text also implemented to http://en.wikipedia.org/wiki/Talk:Bash#The_BASH.27_lack_of_simplification
Suggestion 2: Altering of the standard Linux directory tree structure 
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, ...
It also makes good sense to actually make the main drive (on which the operating system is placed) non-writable (after the operating system is made fully ready -ie all required programs allready being installed-. Making the main drive non-writable can be done by setting the permissions. This has the advantage that the file system (ie register, ...) does not get corrupted after a period of use, which then requires a format and OS-reinstall.
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) the latter tending to confuse users.
More information Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/
Standard linux partition names http://linux.org.mt/article/partnames
Suggestion 3: Dropping support for a variety of useless/surplus file formats and protocols in favor of one good file format/protocol (per type) 
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.
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.
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.
Examples are :
- .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.
Examples: 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.
More information 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 http://en.wikipedia.org/wiki/ECB_AT91 http://en.wikipedia.org/wiki/ECB_ATmega32/644
Suggestion 4: Dropping support for dual booting 
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.
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.
More information: 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
Dual booting, bootloaders and the master boot record of devices 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 
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, ..)
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)
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.
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.
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.
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.
More information: 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) http://en.wikipedia.org/wiki/Irix Project Looking Glass (3D Modification for Linux) http://en.wikipedia.org/wiki/Project_Looking_Glass
Compiz (3D Modification for Linux) http://en.wikipedia.org/wiki/Compiz
Croquet Project (3D Modification for Linux) http://en.wikipedia.org/wiki/Croquet_Project
Suggestion 6: Inclusion of a scaled-down virusscanner, and other software 
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) 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)
Also, text-translation tools should be implemented (eg trough on-line tools as Google Translate or -even better- off-line tools as 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 new software program, derived from its Phraselator being build by DARPA.
Suggestion 7: Use of a better filesystem and X-window Desktop Environment 
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, ...
More information 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 
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, ...
Suggestion 9: Cooperation with other companies and use of Google Services 
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.
Canonical and Google working together http://en.wikipedia.org/wiki/Goobuntu
Goobuntu being installed on Dell computers http://digg.com/linux_unix/Goobuntu_is_coming_
Suggestion 10: software for GPS-tracking via WiMax and other internet connections 
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. GPS/Galileo coordinate uploading needs to be done automatic to a central online database whenever a WiMax connection with enabled internet-sharing is detected (so no GPS-push tracker). This is useful to know the general whereabouts of any a person's GPS-connected portable computer. RFID-monitoring of people (via RFID implant) on the same method should also be in place next to this system. This then also allows to see possible thefts of the portable computer. Also, GPS-position broadcasting should also be done via WiMax to all WiFi receivers in the location (in encrypted form). The latter is primarily to indicate your coordinates for friends (eg especially useful for specific jobs where friends are always within a few kilometers). 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.
Suggestion 11: adaptable health/activity 
Supplemental information on a person's current health or activity status should be able to be given. This can then be combined with the GPS tracking of a person noted above via eg a program as Google Earth. This supplemental information is especially useful for certain jobs (eg hazardous outdoor jobs as construction,...).
Suggestion 12:VoIP program 
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 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.
Suggestion 13: Restricted user permissions 
The user permissions should be heavily restricted. More precisely, there should be 2 types of users: regular users and 1 user with superuser permissions. Regular users should only be given write permission in their own document folder (called XXX's documents; XXX standing for user name). The rest of the hard drive is to be read-only for regular users; however they should still be able to see the whole hierarchy of the drive; not being restricted to only see their own folder. The superuser however is to be given read and write permission for the whole drive. This effectively eliminates the ability of regular users to corrupt the system by downloading and/or executing files & programs. If there is a necessity to update the system, install certain new software or files, the superuser (or computer administrator) can perform these tasks. In UMPC's (which are effectively used only by 1 person), this division of user permissions may seem unnecessairy; however it will eliminate the corruption of the system nonetheless. This is possible if the user always logs in as a regular user for doing daily use; when he wishes to (or when the user unknowingly downloads something) he will receive an error telling that nothing can be written to the system. This will notify or remind the user that he should not download the file (in certain cases; eg the download of an e-book, ... he may then also decide to log in as superuser and download the file for this single occasion).
Suggestion 14: support of battery-less motherboards 
In order to allow the use of battery-less motherboards, which rely on a very small (ie 128-512kb large) solid state drive (SSD) to save the motherboard settings on, an additional change to the OS needs to be foreseen. This change is the immediate synchronization of the clock shown in the OS with a time server. Support can also be added to write the current date to the small SSD after every synchronization with the time server. As a synchronization can only be done when an internet connection is established, the date will not be correct at every startup, but should nevertheless be close to it. The time will always be off, untill the time has been synchronized after booting the computer, this latter however is generally of less importance and the benefit of not having a battery on the motherboard justifies this.