The future of linux

For years, I've been hearing about Linux, about how good this open-source, free operating system is, and how it might someday overtake Windows as the next desktop operating system. Two years ago, I finally got my hands on a true Linux OS, namely the Ubuntu 9.10, which has been praised for its usability for beginners, and thus may have the potential of 'leading Linux into the mainstream'.
Two years have passed, yet nothing changes. Linux is still only the operating system of choice for (certain) servers, while in the PC market for end users, changes are very slight. Still around 1.6% market share. And for me, I haven't changed my idea toward the usability of Ubuntu, perhaps due to the fact that I am still using old hardware, but I can't help noticing that some people must have mentioned 'low-cost' as a factor for using Linux, right? And that fact stands, until very recently.
Yes, just recently, I got my very first Android cell purchased. Mainly chosen for its flexibility and (especially) its low price, I was initially unsatisfied with the huge number of crapware that comes with it. But once I've rooted it, cleared away all those junk, I found in amazement that it is nearly as powerful as my old laptop, and once I've installed a terminal emulator, busybox, vim and sl4a (which later replaced the terminal), it turned into a nearly fully-functional Linux computer. And that was how I got to appreciate the point of using Linux, finally. Throughout the tweaking, I got to know much of the Linux 'commands', vim, other fundamental differences between Linux and Windows, and its superiority. And so I thought, maybe I should give Ubuntu another try? Don't even think about it. Slow as ever, Ubuntu never lived up to its name for me, even till now.

Just to illustrate the problem, and to show my frustration (you can alway jump this paragraph if you're bored): Ever since I installed the Ubuntu on my computer I've been haunted by numerous problems, starting with a problem with the screen, which won't come back to life should I ever try to close the lid; later to the non-functional suspend, which so annoyingly gets activated every time I close the lid for too long, regardless of the absolutely useless power options until I found the inhibitor widget. Just now, I simply clicked the 'Check' button in the so annoying Update Manager and it never responded: it took a good three minutes to react, and then it CRASHED the WHOLE SYSTEM, just like the suspend function. I might ignore the problem of not having a proper IDE, but this stability problem is just unbearable. Oh, and it really isn't less space hungry than a Windows 7 running the Windows XP MSI.

Now that isn't the point. The point is, Linux has just overtaken Microsoft. Yes, the long anticipated overtaking event has finally happened. What astonishes most people is, however, that it didn't happen in the PC market, the long predicted yet never realistic myth; instead, it succeeded in the hand-held devices market. Strange thing, but lots of things often don't work in the work most people thought it would; instead, it might turn out to be a complete surprise.
The thing is, Linux might never stand a chance in the PC (end user) market, because:

1. Microsoft products aren't that bad. They're at least usable, and they get to improve
2. Microsoft has such a big user base that most problems get to be solved with a single search, which definitely doesn't apply to the so-called 'community support' Linux. Nothing can be less helpful than the reply on this site: http://ubuntuforums.org/showthread.php?t=1538892. As if we get paid to answer Windows problems.
3. Habit. People are used to the 'Windows way' of doing things, and that can't be changed with reason. The problem worsens with any innovation in the GUI part, Gnome and MSO 2007 are two good examples of that. Though, Windows 7 did succeed for some reason.
4. Microsoft won't allow it. This is the most crucial. Microsoft is the leader in the PC market, and if it feels pressure from the community, it can always lower its price a bit. Besides, the Windows ecosystem is big, Microsoft created this system not only to earn its sales, but also the sales of 'Windows only' software. They cannot exist without Windows, yet in return, they also support the existence of Windows.

Yet, for whatever reason, Microsoft never actually paid attention to the mobile market, at least properly, until iPhone emerged. Now they have already lost to the other two competitors, as the habit of using a mobile has already been set by iPhone and Android. Good news here is, both iOS and Android runs on top of Linux. And this is where they've overtaken Microsoft. 

Linux might not be the king yet, but it has already dominated quite a big market. All we are going to need is to wait for PCs to become, at long last, obsolete. 

So, spare your efforts. There's no need to create so many 'user-friendly' distros of Linux. Focus on the server platform instead, and make those who prefer to use the console only use the console, those who prefer the GUI, Android.

Inception

Evidently, this is about the movie Inception. Nice film, but some doubts creep onto me.

1. Most troubling is the 'kicks'. Isn't the kicks supposed to be performed from outside the dream? Then why, toward the end, was the 4 people pulled out of the dream by 'kicking' themselves from within the dreams? Like jumping from that building in the last level then waking up in the third without perceiving a fall.
2. Gravity. 'There's no gravity when in a free fall'? Free fall != no gravity. There are two points that support this:
1. In free fall you receive a constant, non-changing force downwards, i.e. the gravity, that accelerates you constantly. The only problem is, it seems the human inner ear can only perceive angular acceleration and the speed of acceleration, or in other words, the speed the acceleration changes. In free fall, there's no acceleration.
2. In the movie, Arthur's free fall resulted in the loss of gravity in the second layer, while this loss of gravity did nothing to the gravity on the third level.
3. Limbo. What happens if you get killed or kill yourself in the limbo? Will you go one further level down or will you leave the limbo? It doesn't get explained either way. If the previous, then why would Cobb tell Saito to come back by killing himself? If the latter, why can't they escape limbo earlier by committing suicide? But then, that part were not in the film, which may actually become a possible thread for a sequel.
4. Subconscious attacks from Fischer? Aren't they supposed to be attacking the dreamer? Then why would they attack the cab that carried Fischer, Arthur, Saito and Eames when non of them is the dreamer? Some training, huh?
5. That 'idea' is the most resilient parasite. Once an idea grabs hold of the mind, it would be impossible to eradicate it? It isn't just about an idea, it's about faith: whether you believe in that idea. If it's just a simple idea, you can always put it off your mind with whatever means; but if you believe in it, well, you won't even bother to eradicate it.
6. Do you dream in a limbo when sleeping? What about that dream?

About possible expansions, speculation over the result of the movie are plenty, but for me, the toppling of that top doesn't seem like the kind of topic to continue on. It was nearly falling, and there really shouldn't be a way for it not to be reality. Instead, there are at least two places that's worth continuing on:

1. A prequel. What happened before this story? How did Cobb and Mal get lost in the limbo? What was that dream that led them to get together? There's lots to say.
2. Saito. How Cobb got to him, and most importantly, how Cobb got Saito back to reality. That sudden shift between the scenes seem like a possible start for another story.

Most wondrous is the way people get lost in limbo, because you simply can't tell the difference between going into a dream and coming out of one, except perhaps that you're drowsy when waking. And, it seems the traditional way of slapping yourself in a dream doesn't work. And it rings a bell, what about explaining the movie 'Groundhog day' with this dreaming? Only that person's entering and leaving the same dream every morning. It's up to the viewer.

Native vim for Android with mbyte and color

[Edit]
I've uploaded the compiled binaries for this version of vim, which can be found at http://cid-0e29e4b9a313ea5b.office.live.com/self.aspx/Releases/Vim%5E_Android%5E_With%5E_Multibyte.zip.Please copy the files to /data/vim (or any directory you can access that's not on the sdcard), set executable by chmod 7777 ./vim, export PATH, then you're good to go. The xxd file is also an executable that enables binary editing, may come handy if you're editing any binary files on android (discouraged).

I came across credentialitiy's 'Native Vim for Android' the other day, and it immediately solved my problem of wanting to program on Android with a powerful enough editor - Text Edit simply won't do. Here I'd like to first express my gratitude to credentiality for his excellent job on compiling Vim for Android in the first place.

But then nearly immediately, I found several problems: there's no color, either the environment color set using ":color somecolorname" command or syntax-highlighting; then, the jog-ball doesn't work.
If you're wondering if it's the problem of the terminal emulator, be assured that it isn't, as the 'ls' command that comes with busybox does show coloring on my terminal, while a version of bash compiled for Android accepts job-ball directional commands perfectly happily. And that troubled me for some while, till some extensive searches led me to a thread on LinuxQuestions.Org: http://www.linuxquestions.org/questions/aix-43/no-colors-in-vim-on-command-line-442695/. It turned out to be the setting of the 'TERM' environment variable and some initializations required by Vim to display colors in the terminal.
As it happened, it isn't the problem of just Android, it happened on other platforms too. So I added the lines of code to my vimrc, then it just worked!
Later on, I discovered that it is actually documented in vim. Just type ':help syntax' and scroll to the bottom of that help page.

Then problems arose about the mbyte support of that vim. I was quite astonished that it did have the 'encoding' setting, or the 'fileencoding' setting. Apparently, mbyte support wasn't compiled in. So I set out to compile one with that turned on.

It did take me some time to compile my first vim for android, and there was a mistake that bothered me for nearly an hour. Follow credentiality's instruction at 'Native Vim for Android'  to get your first vim for android compiled. Note that when configuring ncurses for compilation, there's a mistake in the instructions. Change:

CC=agcc ./configure --host=arm-eabi --without-cxx-binding

into:

CC=agcc.pl ./configure --host=arm-eabi --without-cxx-binding
 

After compiling vim, I found the appropriate configuration option in src/configure.in
Reconfigure with the following command:

vim_cv_memcpy_handles_overlap=no \

vim_cv_bcopy_handles_overlap=no \

vim_cv_memmove_handles_overlap=no \

vim_cv_stat_ignores_slash=no \

vim_cv_getcwd_broken=no \

vim_cv_tty_group=world \

vim_cv_terminfo=yes \

LDFLAGS="-L/path/to/ncurses-5.7/lib" \

CFLAGS="-I/path/to/ncurses-5.7/lib" \

vim_cv_toupper_broken=no \

CC=agcc.pl \

./configure --host=arm-eabi --with-tlib=ncurses --enable-multibyte


then patch the header file as instructed in credentiality's blog, and patch the following file:
src/mbyte.c:
Add:

#ifndef __amigaos4__

# define __amigaos4__

#endif




below other #include declarations.

As I figured out, that definition tricks vim into believing that there's no mblen() on the platform, which is true, as multibyte support is always faulty in NDK.

Then you can try it for yourself, it should work with Unicode encodings, I've tested UTF-8, UTF-16LE, but ANSI encodings like cp936 are still not supported. Good enough for me, at least I can now edit Chinese text documents with vim.

Photo (Still haven't figured out how to use the screenshot program):

Note that the photo has been post processed to remove lens distortion.