"[CafeScribe], F*** You! [*flips off the camera*]"... for not supporting offline use on Chrome OS

Being a student with a Chromebook should be a very straightforward process. At least in theory. Google Docs/Drive is definitely all that's needed for an English class, even for full-fledged MLA-formatted essay papers. For a math class, computers aren't even allowed at all. Science? History? Answering questions in those subjects shouldn't be that hard either, because again, there's the power of Google's web-based -- and free -- productivity suite, baked right into Google Drive itself. And, most importantly, software development, especially web development, classes, thanks to the plethora of online (and even offline) code editing tools for Chrome and Chrome OS users abroad, should also be a straightforward process. And it is, at least if your e-reader that's needed to access textbooks isn't down for maintenance.

However, there's a clear impediment if you need to access digital e-textbooks offline: Adobe AIR. I got an email from the CafeScribe team telling me that the textbook I need for my JavaScript class would be inaccessible on November 29-30 if not downloaded for offline use due to scheduled server maintenance during those days. Well, the site is Flash-based, so I knew something was fishy when it comes to offline use, that I might need some additional plugin or something. Well, yes, I tried, and Adobe AIR was the first thing that it attempted -- and failed, since Chrome OS doesn't have libhal installed, and the root partition is read-only which requires apps to be installed on a separate stateful partition -- to install on my Chromebook (a two-year-old Acer AC700-1099, of course with an up-to-date Chrome OS, at that).

It's a nightmare, alright. I'm glad my professor is able to provide alternative reading material from online sources other than the textbook as the material for the assignments in question, because that does indeed relieve my burden considerably. On top of the offline problems, scrolling is also severely underperformed -- the CafeScribe reader has its own built-in scroll bars instead of embracing the system ones, and I need to often times move two fingers on the touchpad 100 times just to scroll an inch, not to mention that in full-page mode, the text is so small and pixelated that I need to put my face within inches of the screen to be able to read anything at all.

I'm actually glad they're going to be down for maintenance. Why? Because that may (hopefully) mean that they'll FINALLY be embracing HTML5 for a change when it goes back online December 1. I for one certainly am not giving up on my beloved Chromebook -- after all, everything that's needed to do schoolwork and code is readily available for me to use -- it's just these random, stuck-in-the-past offenders who depend on proprietary browser plugins to get work done that get me every time. In the meantime, I'm done here. I'll be reading all the alternative reading material I can get my hands on (including some other books on HTML5 and JavaScript that I own and actually have laying around my room, not to mention iBooks on these that I also have on my iPhone 4S, which of course CafeScribe doesn't have an offline mode in its app for) until CafeScribe can get its act together.

Patenting inventions vs. patenting code: Where to draw the line

November 12, 2013 — Just when one thought the software patent wars were over, a few weeks ago the unthinkable happened. Google was outbid a couple of years ago by a consortium of companies calling themselves Rockstar for some patents that Nortel — a known patent troll — had possessed — and then sued. They were patents that certainly predated Google's existence... well, when it comes to the filing date (rather than publication) anyway. However, the irony is they have no real invention to back them.

People who create these kinds of litigation companies do it for one purpose and one purpose only: to see how far they can push the broken patent system for the sake of pure greed. Sorry guys, but greed is greed. There's a clear fine line that people have crossed, over innovation-stifling software patents that shouldn't be given the grant to begin with.

To be very fair to the pharmaceutical companies: What I'm lambasting certainly isn't patents in general. That's been settled by the fact that industries like the pharmaceutical industry actually benefit from patents, because the patents have visible, tangible inventions (chemicals with medical benefits) to support them. Yes, patenting chemicals is fine. Patenting code, however, isn't.

Remember how Richard Stallman appeared in the "Patent Absurdity" video? How he stated perfect facts about how the use of patents in music, the ability to patent certain note sequences, would be completely detrimental to it? Well, even in the multi-billion-dollar modern record industry, that claim has merit.

The record companies are highly competitive, with countless labels all serving their niches, not to mention ordinary celebrities, like Madonna and certain hip-hop artists, founding their own record labels at will. They're also making very large multi-million- to billion-dollar profits on the music they produce. The irony? Music still isn't patentable! It may be copyrightable, but not patentable. And this is probably the best example I can throw out there of why copyright is good enough for software.

When you cross that line from copyrighting things that should be copyrighted to patenting AND copyrighting the same item, you've gone from a legitimate inventor to a Scrooge. Not the least bit cool, and unless action, like what some people in Congress are considering with the proposed Innovation Act, is taken quickly, the tendency for corporations to want to use patents to create artificial software monopolies could go so unchecked that the consequences for the entire software industry could be dire.

FOSS security: Why the FUD-spreaders are wrong

Ever wonder why the Google Play store has had the malware it's had in the past? Of course, Google has gone to great lengths to make sure this doesn't happen again. They've removed malware from the Play Store AND remotely deleted it from users' devices. They've introduced Bouncer — not that it's done a great job in the past — and went on to update it's definitions continuously. Well, people seem to think that because Android is insecure, all FOSS must be insecure, right? Wrong.

Android has a serious problem that makes it's software inherently insecure: the Apache License. Unlike the GPL, the Apache License is permissive. This means that Android can be Tivoized, which is why carriers lock bootloaders on Android devices. It also means that Android can be forked without the need to open up the source code of the forks, which is why manufacturers like Samsung, HTC, and others can get away with keeping TouchWiz, Sense, and other custom UIs proprietary. This of course also provides a boon for malware distributors: now, they have an app that they can add malicious code — for example, a backdoor, a keylogger, or spy code — to, and they can get away with keeping that added code proprietary so that no one knows it's malware until it's installed.

In contrast, most mainstream Linux userlands — KDE, GNOME, XFCE, Unity, LXDE, and the like — have a security stronghold: the GPL. Unlike the Apache and BSD licenses, the GPL is a copyleft license. This means that the license uses the power that is copyright law to *require* developers who make changes to the code to open those changes up, and irreversibly agree that the changes stay in the public domain. Meaning, of course, that hackers and malware distributors end up in a sort of Catch-22: Either comply with the GPL and get busted by the government, or violate the GPL and get busted by the FSF.

Also, there's another provision of the GPL that is easily capable of preventing locked bootloaders. It states that if GPL software is installed on a certain machine, that machine cannot implement hardware restrictions that hamper the freedom of users to modify said software without violating the GPL. Locked bootloaders, such as those that carriers install on Android powered smartphones, no doubt fall into that category.

So, the next time Microsoft or Apple tries to spread FUD about the open source model, refer to this blog post. There's no denying that the propaganda these corporations spread is almost in line with the propaganda spread by the Chinese and North Korean governments, and if users have any reason to believe what these people are saying, they've got their facts skewed to the brink of dystopianism.

Move over, Mavericks: Android 4.4 brings compressed memory to smartphones

We all knew this was coming. Google has supercharged Android with KitKat to make it use resources much better, even on extremely low-end devices with only 512MB of RAM on board. To that end, Google introduced several performance tweaks: less heap used by core processes, aggressive protection of system memory by the kernel and low-level processes, serial (instead of parallel) service startup, the ActivityManager.isLowRamDevice() API,  and, oh, yeah, zRAM, which uses the power of the Linux kernel to make compressed memory on not just desktop computing devices but smartphones a reality.

Compressed memory gained significant notoriety at WWDC 2013, when Apple unveiled iOS 7 and OS X Mavericks. Craig Federighi made a really big deal about memory compression being used in Mavericks, and yeah, Mac users would be able to notice that it makes a big difference when running Mavericks on old Macs. Notably lacking in terms of the performance tweaks, however, was iOS 7. Running iOS 7 on an iPhone 4S (in my case) may at least make it look nice, and of course the removal of skeuomorphism removed much of the software bloat, but the parallax effect tends to stutter and other features made the device lose out on the performance side, particularly because iOS 7 focused so much energy into user interface design that performance tweaks were often overlooked by Apple engineers. Well, even though iPhone users lose out on these performance tweaks, Android users don't.

What's more, in KitKat there's not only compressed memory but also, and if you can believe this, compressed swap space on the storage medium as well. Since smartphones use solid-state storage, and of course fast solid-state storage comparable to the speed of the RAM itself, even virtual memory partitions can become more RAM-like in terms of speed than ever before. Just like the physical RAM, however, the virtual RAM is also capable of being compressed. On my 2-year-old Acer AC700-1099 Chromebook, which of course also uses zRAM along with compressed swap space, it really shows, and most Linux distributions outside of Google are also taking advantage of this awesome power.

Google even has a code name for this aggressive performance tweaking campaign: Project Svelte. As the successor to the notorious Project Butter that has been ongoing since the first release of Jelly Bean (Android 4.1), it is only the start of Google's aggressive campaign to end fragmentation and make Android capable of running easily on low- to mid-range devices as the newest version regardless of what kind of forked home screens or carrier crapware may be installed. This is pretty incredible, and if Apple has anything to learn from this, it's the fact that smartphones are every bit as powerful of computers as desktops and laptops are, and therefore they deserve the same treatment in terms of features, and of making the most out of the hardware, that desktops and laptops do.