Thursday, September 25, 2014

Tablets are controlled by corporations

I admit I was wrong. In my previous post, I claimed that mobile devices would be free of corporate bureaucracy (and control). That's not true.

It's true in the sense that when the Acme corporation buys PCs it can control them with ActiveDirectory and group policies, and that similar infrastructure is not in place for tablets and smartphones. (I'm ignoring the third-party Mobile Device Management software.)

But it's false in the sense that corporations do control the mobile devices. The corporations are not Acme or whoever buys the devices. The controlling corporations are the owners of the walled gardens: Apple, Google,, and Microsoft. These corporations control the software available and the updates that occur automatically. (Yes, you can turn some updates off, but only while those corporations let you.)

The control that these companies exert is indisputable. Apple just recently placed a copy of a U2 album on every iPod and iPhone. Some time ago, deleted books from various Kindle e-readers. These companies are the "tribal chieftains", with immense power over the devices.

Android and iOS are popular in part because they are easy to use. That ease of use comes from the absence of administration tasks. The administration has not disappeared, it has moved from the "owner" of the device to the controlling company. Apple builds the updates for iOS and distributes those updates (along with updates to apps) to iPhones and iPads. Google does the same for Android devices. Microsoft does the same for "Metro" apps.

It may be this control that makes corporations reluctant to use tablets. They may know, deep down, that they are not in control of the devices. They may realize that at any moment the tribal chieftains may change the software, or worse, read or modify (or possibly delete) data on the devices. They may grant other individuals access to mobile devices.

All of this does not mean that corporations (the Acme variety, who are using the devices) should avoid mobile devices. It *does* mean that corporations should use them intelligently. They should not manage tablets and smartphones in the same way that they manage PCs, and they should not use tablets and smartphones in the same way as they use PCs. The model for mobile devices is very different from PCs.

Business can use tablets and smartphones, but differently than PCs. Data should be handled by specific apps, not generic applications like Microsoft Word and Excel. Mobile apps should authenticate users, retrieve a limited set of data from servers, present that data, manipulate that data, and then store the data on the server. Apps should not store data on the local device. (This is also good for the scenario of a lost device -- if it has no data, there can be no data "leakage" to unauthorized parties.)

Mobile devices are controlled by the tribal chieftains. Yet they can still be used by corporations -- and individuals.

Wednesday, September 24, 2014

Mobile devices may always be independent from corporate bureaucracy

The mobile revolution is different from the PC revolution.

The PC revolution saw the IBM PC adopted as the standard for personal computing. It was adopted by businesses and consumers, but most spending was from businesses.

The mobile revolution, in contrast, is driven by consumers. Individuals are buying smart phones and tablets. Businesses may be purchasing some mobile devices, but the bulk of the spending is on the consumer side.

Why is this distinction important?

To answer that, let's look at PCs and their history. Personal computers in corporations are anything but personal. They are purchased by the corporation and controlled by the corporation. The people using PCs rarely have administrator privileges for those PCs. Instead, the ability to install software and make significant changes is governed by the local copy of Windows and configurations in a central ActiveDirectory server.

The infrastructure of ActiveDirectory and Windows group policies was not built overnight, and was not part of the original PC. The first PCs ran PC-DOS and had no administrative controls at all -- any user could do anything, see anything, and change anything. Microsoft worked on PC-DOS for IBM, then MS-DOS for non-IBM computers, then Windows, and finally server software and ActiveDirectory. It took about twenty years to create, from the introduction of the IBM PC in 1981 to the introduction of ActiveDirectory in 1999.

That work was done by Microsoft because corporations wanted it. They wanted mechanisms to control the PCs and the access to data on PCs and servers. (And even with all of that interest, it took two decades to "enterprise-ify" PCs and make them part of the bureaucracy.)

Corporations were interested in PCs from the introduction of the IBM PC. (Some corporations were interested in earlier microcomputers, but they were a minority.) Corporations were interested in PCs because PCs ran Lotus 1-2-3, the popular spreadsheet at the time.

Now let's look at mobile devices. Corporations have a mild interest in mobile devices. It is only a fraction of the interest in PCs. There is no killer app for tablets, no must-have app for smart phones. (At least, not for corporations.) It is quite possible that phones and tablets are too personal for corporations.

It is telling that the Microsoft Surface tablet, with its ready-to-use connections to ActiveDirectory, has seen little interest. For consumers, the Surface (and other Windows tablets) are more expensive and not as useful as the iPad and Android tablets. But even corporations have little interest in the Microsoft offerings.

Without corporate interest (and corporate spending), neither Apple nor Google have incentive to make their tablets "safe for the enterprise" -- that is, controlled through a central administration point. (Yes, there are "mobile device management" packages, but they have little interest.)

Apple and Google will invest their efforts in other areas, such as better hardware and improved reliability of apps in their stores (and maybe higher profits).

Corporations will use tablets for small, isolated projects, if at all. I suspect most corporations view their proven and familiar desktops and laptops as sufficient, with little benefit from tablets.

But all is not lost for tablets and smart phones. Some folks will use them for critical business purposes. These folks will not be the large corporations with established IT infrastructure. They will be the start-ups, the small companies who will build completely new apps to solve completely new business problems.

Sunday, September 21, 2014

Keeping our keyboards

Tablets are quite different from desktop PCs and laptop PCs. (Obviously.)

PCs have large displays, keyboards, mice, and wired network connections. They often have CD or DVD drives. Tablets, in contrast, have small displays, virtual keyboards, a touch screen (so no mice), no wired network connection, and media storage (if any) is limited to memory cards.

So we can view the transition from PC to tablet as a shift in peripherals. The "old school" PC used physical keyboards, mice, and disks; the "new school" tablets use touch screens, virtual keyboards, and no mice tor disks.

Except for one small detail.

Tablet users are using keyboards.

Not mice.

Not printers.


I do understand that some people are using tablets with mice and printers. A small minority of people, but nowhere near the sizable number of people are using physical keyboards.

The appeal of keyboards is such that people continue to use them as an input device. They carry a keyboard with their tablet. They buy tablet covers that have built-in keyboards.

I think this tells us something about keyboards.

Wednesday, September 10, 2014

The Apple Watch

Lots of folks have commented on the newly-announced Apple Watch. Many have praised the features. Some have criticized the design. Others have questioned the battery life.

Here's my take: the Apple Watch is not a watch. Yes, it will tell you the time, but it is more than that. The Apple Watch is it a "smartwatch". Yes it can present the time in lots of nifty formats (digital, retro analog, black-and-white, color) and it connects with Siri.

The Apple Watch is single product in a line of products that are designed to make things easy for people. Let's look at previous Apple products:

The iPod was more than a simple MP3 player. It was a system that made it easy to purchase and play music. There were plenty of MP3 players that only played music and left the acquisition of music to the user. The combination of iPod and iTunes (and the impressive collection available on iTunes) was the genius of the iPod.

The iPhone was more than a smart cell phone. It expanded iTunes to allow for the easy purchase and installation of apps. The ease of installation is often overlooked when it comes to the features of the iPhone. Remember, prior to the iPhone the standard model for installing applications was Microsoft's "Setup" or "MSI" packages, which often required special privileges and technical knowledge.

The iPad expanded the possibilities for apps. Apps for the iPhone were designed for the small screen. One could play music on an iPhone, but reading a book is much better on an iPad. One can use Twitter and Facebook on an iPhone, but documents and spreadsheets are much better on an iPad.

The trend has been for larger devices. The Apple Watch moves in the opposite direction, providing a smaller screen. The obvious conclusion is that one will not be using the Apple Watch for spreadsheets and documents. (Twitter may be okay, but I suspect that Facebook is not useful on the Apple Watch.) The less obvious conclusion is that the Apple Watch will be used for something else.

The question is: what will the Apple Watch make simpler for us, in such a way that Apple can profit from it?

A watch is more personal than a phone, more intimate, as it is physical contact with us. Sensors in the watch could be used for biometric information and possibly health information.

Apple has already announced plans for payment systems. We tend to keep the smaller devices with us more, carrying phones more frequently than tablets, so we will probably carry a watch with us more than a phone. Matching payments to a watch is good sense.

Initial enthusiasm for the Apple Watch may see a lot of people porting their apps to the phone. Some of that enthusiasm will be misplaced; the Watch will be good for some things but not everything from the iPhone -- and especially not everything from the iPad. There may be some new apps that are suitable to the Watch and not the phone or tablet -- probably games.

I think the Apple Watch has potential. I also think that it will be its own thing, not merely a small iPhone.

Friday, August 29, 2014

Virtual PCs are different from real PCs

Virtual PCs started as an elaborate game of "let's pretend", in which we simulated a real PC (that is, a physical-hardware PC) in software. A virtual PC doesn't exist -- at least not in any tangible form. It has a processor and memory and disk drives and all the things we normally associate with a PC, but they are all constructed in software. The processor is emulated in software. The memory is emulated in software. The disk drive... you get the idea.

Virtualization offers several advantages. We can create new virtual PCs by simply running another copy of the virtualization software. We can move virtual PCs from one host PC to another host PC. We can make back-up images of virtual PCs by simply copying the files that define the virtual PC. We can take snapshots of the virtual PC at a moment in time, and restore those snapshots at our convenience, which lets us run risky experiments that would "brick" a real PC.

We like to think that virtual PCs are the same as physical PCs, only implemented purely in software. But that is not the case. Virtual PCs are a different breed. I can see three areas that virtual PCs will vary from real PCs.

The first is storage (disk drives) and the file system. Disk drives hold our data; file systems organize that data and let us access it. In real PCs, a disk drive is a fixed size. This makes sense, because a physical disk drive *is* a fixed size. In the virtual world, a disk drive can grow or shrink as needed. I expect that virtual PCs will soon have these flexible disk drives. File systems will have to change; they are built with the assumption of a fixed-size disk. (A reasonable assumption, given that they have been dealing with physical, fixed-size disks.) Linux will probably get a file system called "flexvfs" or something.

The second area that virtual PCs vary from real PCs is virtual memory. The concept of virtual memory is older than virtual PCs or even virtual machines in general (virtual machines date back to the mainframe era). Virtual memory allows a PC to use more memory than it really has, by swapping portions of memory to disk. Virtual PCs currently implement virtual memory because they are faithfully duplicating the behavior of real PCs, but they don't have to. A virtual PC can assume that it has all memory addressable by the processor and let the hypervisor handle the virtualization of memory. Delegating the virtualization of memory to the hypervisor lets the "guest" operating system become simpler, as it does not have to worry about virtual memory.

A final difference between virtual PCs and real PCs is the processor. In a physical PC, the processor is rarely upgraded. An upgrade is an expensive proposition: one must buy a compatible processor, shut down the PC, open the case, remove the old processor, carefully install the new processor, close the case, and start the PC. In a virtual PC, the processor is emulated in software, so an upgrade is nothing more that a new set of definition files. It may be possible to upgrade a processor "on the fly" as the virtual PC is running.

These three differences (flexible file systems, lack of virtual memory, and updateable processors) show that virtual PCs are not the same as the "real" physical-hardware PCs. I expect that the two will diverge over time, and that operating systems for the two will also diverge.

Tuesday, August 26, 2014

With no clear IT leader, expect lots of changes

The introduction of the IBM PC was market-wrenching. Overnight, the small, rough-and-tumble market of microcomputers with diverse designs from various small vendors became large and centered around the PC standard.

From 1981 to 1987, IBM was the technology leader. IBM lead in sales and also defined the computing platform.

IBM's leadership fell to Compaq in 1987, when IBM introduced the PS/2 line with its new (incompatible) hardware. Compaq delivered old-style PCs with a faster buss (the EISA buss) and notably the Intel 80386 processor. (IBM stayed with the older 80286 and 8086 processors, eventually consenting to provide 80386-based PS/2 units.) Compaq even worked with Microsoft to deliver newer versions of MS-DOS that recognized larger memory capacity and optical disc readers.

But Compaq did not remain the leader. It's leadership declined gradually, to the clone makers and especially Dell, HP, and Gateway.

The mantle of leadership moved from a PC manufacturer to the Microsoft-Intel duopoly. The popularity of Windows, along with marketing skill and software development prowess led to a stable configuration for Microsoft and Intel. Together, they out-competed IBM's OS/2, Motorola's 68000 processor, DEC's Alpha processor, and Apple's Macintosh line.

That configuration held for two decades, roughly from 1990 to 2010, when Apple introduced the iPhone. The genius move was not the iPhone hardware, but the App Store and iTunes, which let one easily find and install apps on your phone (and pay for them).

Now Microsoft and Apple have the same problem: after years of competing in a well-defined market (the corporate PC market) they struggle to move into the world of mobile computing. Microsoft's attempts at mobile devices (Zune, Kin, Surface RT) have flopped. Intel is desperately attempting to design and build processors that are suitable for low-power devices.

I don't expect either Microsoft or Intel to disappear. (At least not for several years, possibly decades.) The PC market is strong, and Intel can sell a lot of its traditional (heat radiator that happen to compute data) processors. Microsoft is a competent player in the cloud arena with its Azure services.

But I will make an observation: for the first time in the PC era, we find that there is no clear leader for technology. The last time we were leaderless was prior to the IBM PC, in the "microcomputer era" of Radio Shack TRS-80 and Apple II computers. Back then, the market was fractured and tribal. Hardware ruled, and your choice of hardware defined your tribe. Apple owners were in the Apple tribe, using Apple-specific software and exchanging data on Apple-specific floppy disks. Radio Shack owners were in the Radio Shack tribe, using software specific to the TRS-80 computers and exchanging data on TRS-80 diskettes. Exchanging data between tribes was one of the advanced arts, and changing tribes was extremely difficult.

There were some efforts to unify computing: CP/M was the most significant. Built by Digital Research (a software company with no interest in hardware), CP/M ran on many different configurations. Yet even that effort could not span the differences in processors, memory layout, and video configurations.

Today we see tribes forming around multiple architectures. For cloud computing, we have's AWS, Microsoft's Azure, Google's App Engine. With virtualization we see VMware, Oracle's VirtualBox, the aforementioned cloud providers, and newcomer Docker as a rough analog of CP/M. Mobile computing sees Apple's iOS, Google's Android, and Microsoft's Windows RT as a (very) distant third.

With no clear leader and no clear standard, I expect each vendor to enhance their offerings and also attempt to lock in customers with proprietary features. In the mobile space, Apple's Swift and Microsoft's C# are both proprietary languages. Google's choice of Java puts them (possibly) at odds with Oracle -- although Oracle seems to be focussed on databases, servers, and cloud offerings, so there is no direct conflict. Things are a bit more collegial in the cloud space, with vendors supporting OpenStack and Docker. But I still expect proprietary enhancements, perhaps in the form of add-ons.

All of this means that the technology world is headed for change. Not just change from desktop PC to mobile/cloud, but changes in mobile/cloud. The competition from vendors will lead to enhancements and changes, possibly significant changes, in cloud computing and mobile platforms. The mobile/cloud platform will be a moving target, with revisions as each vendor attempts to out-do the others.

Those changes mean risk. As platforms change, applications and systems may break or fail in unexpected ways. New features may offer better ways of addressing problems and the temptation to use those new features will be great. Yet re-designing a system to take advantage of new infrastructure features may mean that other work -- such as new business features -- waits for resources.

One cannot ignore mobile/cloud computing. (Well, I suppose one can, but that is probably foolish.) But one cannot, with today's market, depend on a stable platform with slow, predictable changes like we had with Microsoft Windows.

With such an environment, what should one do?

My recommendations:

Build systems of small components  This is the Unix mindset, with small tools to perform specific tasks. Avoid large, monolithic systems.

Use standard interfaces  Use web services (either SOAP or REST) to connect components into larger systems. Use JSON and Unicode to exchange data, not proprietary formats.

Hedge your bets  Gain experience in at least two cloud platforms and two mobile platforms. Resist the temptation of "corporate standards". Standards are good with a predictable technology base. The current base is not predictable, and placing your eggs in one vendor's basket is risky.

Change your position  After a period of use, examine your systems, your tools, and your talent. Change vendors -- not for everything, but for small components. (You did build your system from small, connected components, right?) Migrate some components to another vendor; learn the process and the difficulties. You'll want to know them when you are forced to move to a different vendor.

Many folks involved in IT have been living in the "golden age" of a stable PC platform. They may have weathered the change from desktop to web -- which saw a brief period of uncertainty. More than likely, they think that the stable world is the norm. All that is fine -- except we're not in the normal world with mobile/cloud. Be prepared for change.

Sunday, August 17, 2014

Reducing the cost of programming

Different programming languages have different capabilities. And not surprisingly, different programming languages have different costs. Over the years, we have found ways of reducing those costs.

Costs include infrastructure (disk space for compiler, memory) and programmer training (how to write programs, how to compile, how to debug). Notice that the load on the programmer can be divided into three: infrastructure (editor, compiler), housekeeping (declarations, memory allocation), and business logic (the code that gets stuff done).

Symbolic assembly code was better than machine code. In machine code, every instruction and memory location must be laid out by the programmer. With a symbolic assembler, the computer did that work.

COBOL and FORTRAN reduced cost by letting the programmer not worry about the machine architecture, register assignment, and call stack management.

BASIC (and time-sharing) made editing easy, eliminated compiling, and made running a program easy. Results were available immediately.

Today we are awash in programming languages. The big ones today (C, Java, Objective C, C++, BASIC, Python, PHP, Perl, and JavaScript -- according to Tiobe) are all good at different things. That is perhaps not a coincidence. People pick the language best suited to the task at hand.

Still, it would be nice to calculate the cost of the different languages. Or if numeric metrics are not possible, at least rank the languages. Yet even that is difficult.

One can easily state that C++ is more complex than C, and therefore conclude that programming in C++ is more expensive that C. Yet that's not quite true. Small programs in C are easier to write than equivalent programs in C++. Large programs are easier to write in C++, since the ability to encapsulate data and group functions into classes helps one organize the code. (Where 'small' and 'large' are left to the reader to define.)

Some languages are compiled and some that are interpreted, and one can argue that a separate step to compile is an expense. (It certainly seems like an expense when I am waiting for the compiler to finish.) Yet languages with compilers (C, C++, Java, C#, Objective-C) all have static typing, which means that the editor built into an IDE can provide information about variables and functions. When editing a program written in one of the interpreted languages, on the other hand, one does not have that help from the editor. The interpreted languages (Perl, Python, PHP, and JavaScript) have dynamic typing, which means that the type of a variable (or function) is not constant but can change as the program runs.

Switching from an "expensive" programming language (let's say C++) to a "reduced cost" programming language (perhaps Python) is not always possible. Programs written in C++ perform better. (On one project, the C++ program ran for several hours; the equivalent program in Perl ran for several days.) C and C++ let one have access to the underlying hardware, something that is not possible in Java or C# (at least not without some add-in trickery, usually involving... C++.)

The line between "cost of programming" and "best language" quickly blurs, and nailing down the costs for the different dimensions of programming (program design, speed of coding, speed of execution, ability to control hardware) get in our way.

In the end, I find that it is easy to rank languages in the order of my preference rather than in an unbiased scheme. And even my preferences are subject to change, given the nature of the project. (Is there existing code? What are other team members using? What performance constraints must we meet?)

Reducing the cost of programming is really about trade-offs. What capabilities do we desire, and what capabilities are we willing to cede? To switch from C++ to C# may mean faster development but slower performance. To switch from PHP to Java may mean better organization of code through classes but slower development. What is it that we really want?