Linux started with kernels of disk operating system, drivers, and network operating system for your generation of computers, i386 to i986 platforms. Then apps are made into package systems, such as targz, RPM and dpkg. Each one has many bugs that needs to be changed with each kernel version compiled by GCC. Suse has 50,000 and is the most bugs due to their apps complexity. RPM has 2500 bugs, apt-get dpkg has 650.

Here comes DistroWatch with each distro versions and their program versions including GCC version used. The list of programs tip you off the set of version numbers of programs that can work with each other with some bugs already fixed.

This is where you start to learn the compatibility and dependency of Linux reusable files in the Linux library. Once you see the listed version numbers, you know which distro you might like?

All Linux displays are 1024x768 resolution; so that is a sweetspot for all distros. You want to reconfig the resolution, all hell break loose.

Many expert Linux users search Google to fix bugs. But you have to know how to use keywords to do proper search?

You need to have file name version number in which distro version? Then you need the keyword that describes the bug?

Have fun. Linux bugs have a source, and that is the open source community. But DistroWatch and Google made it a simple job to fix bugs(usually missing bindings to other files, or forgot to blacklist symlinks for other distros and their files).

Since 2001, the trend in Linux is learn to strip down bloated if then or else logic for reusable files to work with every other functionsl files.

If you remove remarks, it will be harder to fix bugs. But mix and matched files can be too complex after a few years of existance. Over 500 distros also make things unnecessarily complex(missing bindings and missing blacklist of symlinks).

So, it is time to strip down functions, never have more than one function in each reusable file(theme of QNX). One function key per reusable file and let open source codes to jump around each function?

Using DistroWatch lists of Linux versions, one can see how Netbook manufacturers strip down full versions of Linux older and proven versions. Nothing to be ashamed. Bugs are eliminated better this way.

Repositories will be the way to add apps and upgrade Linux version in orderly progrssion, one killer app(study curriculum) at a time.

Linux experts buy netbooks and try their hands at adopting other distros will find much headaches as pioneers without DistroWatch sets of app versions tied together. Google search also may be too soon. So, we are stuck with Linpus, Xandros/Knoppix, Sled and ubuntu, so far. Fortunately, larger LCD displays may save the day for Linux sweetspot of 1024x768(many apps can be used without reconfiguring resolution).

So, what is next, netbook support for XP and Vista, to sell to older children and grownups? Or spruce up the repositories(special section) for Linux experts to fiddle with bugs galore? Many Linux experts live on bugs galore to prove their manhood? It is the Stillman way(free as in freedom to be wasting time).

Cloud computing is being improved as we go.

EdgeQam will start analog/digital mixed signals with station carrier frequencies, channel subcarrier frequencies, and intermediate frequency for data. This gives us many paths of data transfer.

Then we can see the squashfs and cramfs that get 3.5 to 1 data compression of Linux reusable files. Repeated words table(8bit ascii or 64bit ascii or 512bit ascii) can also compress data to over 3.5 ratio. RLL for double density is now obsoleted but can be overlaid. Mpeg4 can do 9 times the compression ratio, and can be alternately redundant with video braille data compression. Many other data compression schemes are neglected and can be put into service.

It is the most important part of computer science, the data compression encoders and decoders; and how to use alternate redundant sequence of data compression to reduce bandwidth requirement in data transmission.

Linux system is reusable files; each piece of hardware is a file. When newbies get themselves involved, they think the world is window manager. Then browser came and can run the computer functions on the internet, and has its own window manager.

Now, we discover by accident, that webpages are the operating system, not the browser.

Each webpage allows you to run an app; and it has to have trailer codes to do some organization(housekeeping) in your computer; such as webpage history and manipulation of links and data, and have a minimum of reaction with the webpage server. This is the Google gears concept?

If you find Eclipse webpages can run tcl/tk apps(who needs mono?); many tiny Linux distros had an advantage over the big three distros(legacy burden of backward compatibility?)?

If you become a Linux expert, then you must learn Eclipse, which made webpages its operating system from the servers. The eclipse standard made cloud computing universal, all databases can talk to each other.

If you find KDE and Gnome not used when you boot into browsers, it is only progress(no time for desert?).

Fax machines were the replacement of teletype machines; it has pictures. Linux still uses ascii codes invented by Teletype. So, when data transfer speed needed to improve, Linux still has too much bloated codes to be speedy. Linux sequential steps of using software sometime hampered by forced time delay of 10 seconds, especially in installation scripts. Changing delay time and you boot faster?

So, we have to fax it by mpeg4 and use character recognition to extract ascii codes if necessary. And we can use video Braille to get more data compression ratios.

Then, we have to address data communication speeds of edgeQam system. EdgeQam is a faster version of DSL on your telephone pole. First generation is targeted to be 160 mbps on HFC9high frequency copper network). Not yet 1000 mbps. But faster than the 50 mbps in Korea and Japan. Linux people had yet to learn about the hardware system and the software packet format designed by CableLabs; which is Docsis v3.0.

Linux you have today, needs many directional changes in the near future?

Instant-on requires binary operating system. You can not wait for kernels to be installed each time you boot. Netbook architecture is always the same with hotplugged peripherals. So, binary codes to boot from a flash card is a natural.

Once you booted, the manufacturer can supply a binary version in the execution area either in flash card or DDR drams. Then package addition may need list of dependency files in the library, make(compile) and give root privilege and install in the ext3fs. No big deal there either. Some with static binary files(from dedicated repositories such as CnR) can install without any sweat.

People using static files realise soon enough that files are much longer and runs slower. It is because using repeated reusable files from a library of binary codes are shorter in length, and faster when prefetched small file by small file?

Binary files when trouble shooting require disassembly and compile again. People often use Cobol compiler(business basic) to make life easier.

This, of course, removes the GPL license and may require different copyright to cover your invention. Many video programs with different protocol get away from copyright laws.

Binary operating system will change Linux, and possibly remove many bugs.

Clues and common sense to config eyecandy is futile.

Linux was not built in one day. Experts must know historical facts to understand how it changes with today's hardware.

Linux started with Unix sysV command codes on top of 8 bit ascii code table. Then it uses reusable files, write once use forever(compiled by GCC or T2). The kernel is divided into three parts , disk operating system in the beginning, then /dev(or udev in /usr) drivers, then later network operating system(dhcp).

Now in the apps added, Linux uses window managers, which is layout engine and rendering engine(fonts, anti-aliasing codes). Many of them conflicts with Xorg driver which is come lately. Older S3 drivers(xvesa 791/2 VDA) work much better with many older monitors.

Ethernet is the network operating system, and wireless and others only need drivers(dhcpcd). Any devices using serial ports or USB bus, need apps to run them.

Browsers are written for multi operating systems, so they are kernel independent and static(10 mB), could be compiled by C++ and such. But different layout and rendering engines made them not compatible to each other unless resort to html and motion jpeg webpages.

Clues are not usable here, just a build up of historical codes of reusable file names and their assigned directory names.

One only has to know you compile open source codes to binary codes, then you have to compile a directory and file name in the partition to install any new apps already in binary codes. Then you may have to do housekeeping to get rid of other newbies who added missing binding or redundant file names(to be blacklisted).

Done easy if only all the files names are registered, or can be found in repositories, or remarks will tell you what some one added in codes.

Knowing this, we have been having distros strip down codes to have less mistakes. Tiny Linux distros thus have less bugs, if apps are kernel independent(Debian).

Desktop apps and webpage apps can be merged via astute use of trailer binary codes as operating system?

First, you change GUI panels to webpages using posix packets and converters(HAL Dbus). Which means desktop apps can be served from internet servers. You go from links to links of webpages in browser, instead of GUI panels in window manager.

Then you can use python or perl scripts to run gear(trailer codes) like functions on your computer offline without using the web, except when you need to change webpage.

Eventually, you replace the python and perl scripts with C++ compiled binary codes for static monolithic codes(small function files) for speed running webpages to do calculations or add/delete in display memory?

Its a natural to use PHP to convert GUI to webpages? Just make sure you have a list of gear files in your library? And make sure you store the data for workgroups/wiki type collaboration om the web? Does this sound like Ulteo web apps? C++ codes independent of Linux kernels will speed up Ulteo?