Those waiting impatiently for Docker's container technology to be available natively in Windows might have to drum their fingers a while longer, given the amount of work still needed to make that happen. In the meantime, other parties are preparing similar, if not inherently compatible, technologies for Windows.
Spoon, creator of an application virtualization system, has released a containerization system for Windows that runs on both desktops and servers. Like Docker, the Spoon technology is equipped with a repository of container images delivering many common desktop or server applications -- Chrome, Firefox, Node.js, Java, the .Net framework -- that can run without other dependencies.

Unlike Docker, though, Spoon doesn't leverage any existing virtualization technologies in Windows -- not even Hyper-V. Instead, Spoon uses its own custom-built virtualization system. One advantage of this approach: It reduces dependencies on the operating system, so containerized apps can run on any version of Windows back to Windows XP.

Also unlike Docker, as a solution aimed at both desktops and servers Spoon can stream containerized applications across the network in the same manner as VMware's ThinApp.

Likewise, legacy XP applications can be crated up and ported forward to Windows 7 or Windows 8, via a "legacy OS emulation mode" feature. Locally installed applications can be scanned to see if they match apps in Spoon's repository, and those apps can be packaged to go with their user settings.

One advantage commonly associated with containers is security, and Spoon professes to offer various granular levels of isolation for containers, including network virtualization. In contrast to Docker, however, Spoon exposes the container to the network by default, but makes it easy for a container to be battened down, then selectively re-exposed to the network. Spoon's creators claim this allows desktop apps to run as they ought to by default.

Some of Spoon's other features hark back to its roots in a streamed-application solution for test deployments and trial software, setting it apart from Docker both in its technology and in the needs it's designed to address. Among them is continuation, the ability to suspend execution of a container on a device, migrate it to another device, and pick up where everything left off. Likewise, Spoon sports the ability to import application packages from ThinApp and convert them into Spoon containers.

Spoon points out other ways in which its architecture differs from Docker. There's no migrating of Docker containers -- not surprising, given that Docker is not native to Windows (yet). But Docker may value Spoon's focus on the desktop after it comes to Windows.

Spoon isn't open source, unlike Docker, but does offer a free tier with unlimited public repositories to get developers up and running. Private and more advanced services start at $19 per mont.

Last year, Google announced it was embarking on a multimonth program to phase out the use of plug-ins based on the NPAPI (Netscape API) standard, a move as radical as Internet Explorer ditching the use of ActiveX controls. A year later, the plan continues unabated, with a total phaseout scheduled for late in 2015.

Google has good reason to ditch NPAPI -- it's buggy, problematic, and a relic of a past that Google has been trying to move Chrome beyond. But there's no question such a movie will have an impact, and here are five of the biggest points to keep in mind.

1. The number of plug-ins affected is small, but significant

Chief among them are Java, Silverlight, Facebook's Unity game-playback plug-in, and two of Google's own creations: Google Earth and Google Talk. There's been less emphasis over time on Java apps in the browser in enterprise settings, but those still delivering critical applications via Java to endpoints running Chrome must look for another solution pronto.

Losing Silverlight isn't a major setback. Microsoft has been deprecating use of the framework for some time now, and its biggest real-world implementation, the Netflix in-browser player, now has an HTML5-powered substitute. Google will likely come up with replacements for its own plug-ins in short order as well.

2. If you're not happy about this, you're not alone

Not everyone is thrilled about the idea of killing off NPAPI -- not even across the course of almost two years. FireBreath, creators of a browser plug-in creation framework, gave the idea the thumbs-down. In FireBreath's eyes, there is no good replacement for what NPAPI has provided, and its rundown of the available replacement technologies found that the suggested replacements were either in their infancy, too manufacturer-centric (such as Google Native Client or Mozilla js-ctypes extensions), or lack direct access to hardware.

If you're upset that Google is going to jerk your chair out from under you, you're far from alone, and some of the criticisms mounted have merit. If Google (and Mozilla) can't offer better short-term solutions for the problems described above, they may have to allow a NPAPI compatibility system to grandfather in the last of those stuck with such plug-ins.

3. Flash isn't going anywhere

If you're expecting the death of NPAPI in the browser to mean the death of Adobe Flash, think again. It's still too important. Flash is easily the most widely used third-party plug-in apart from Oracle's Java, and a great deal of Web infrastructure -- gaming, ads, video playback -- is built on top of it.

But Chrome deals with Flash in a sly way. Rather than include Flash as a third-party add-on via the NPAPI architecture, Chrome has Flash support integrated directly into the program, with updates to Flash provided along with updates to Chrome.

That said, Flash usage is on the decline, with only 12 percent of all websites employing it, down from around 17 percent at this time last year. But it's the growth of HTML5, rather than the imminent death of Flash plug-ins, that will likely drive this.

4. It's still possible to override Google, but not forever

Starting in January 2015, all NPAPI plug-ins will be blocked by default, but Google has left die-hard plug-in users a way to re-enable NPAPI support via the Enterprise Policy system in Chrome.

But don't count on it being around for too long, as Google plans to remove support for the override -- and support for NPAPI once and for all -- as of September 2015. That gives you a little less than a year to get cracking on landing a permanent solution.

5. Now is the time to look into HTML5 and JavaScript

What would constitute a permanent solution? The best and most universal options: HTML5 and JavaScript. The former has finally reached the official Recommendation stage, thus making it a W3C-endorsed standard. The latter has become ubiquitous across both client and server environments. You could scarcely find a better time to migrate away from a dependence proprietary plug-ins.

Google has its own guide about how to make do without NPAPI, although be warned that some of the suggestions involve proprietary products like Google's own Native Client, not only cross-platform HTML5.

Early this year, InfoWorld's Woody Leonhard did a solid comparison of Microsoft Office 365 vs. Google Apps wherein he likened Office 365 to a cruise ship and Google Apps to a sailboat in terms of their strengths and weaknesses. Likewise, InfoWorld's Galen Gruman's review of mobile office productivity suites strongly criticize Google's mobile versions of Apps for being very weak compared to Microsoft Office (and Apple iWork). Although they offered interesting reads, I felt the discussions were moot, because it was obvious that Office 365 had completely cornered the productivity market.
Or has it?
This week, I was conversing with the IT admin for a company with 3,000 users. The company was considering moving its on-premises email environment to Google Apps. I was surprised initially, especially because the company is not a school system or nonprofit, which are the most common Google Apps adopters due to cost reasons and lack of IT. Thus, I decided to take a fresh look at what Google is offering.
The Google Apps for Work (aka Business) product suite offers a variety of browser-based tools geared toward communication and collaboration for the user, plus administrative elements for IT management. Google breaks the suite into four categories:

• Communicate: Gmail for email, Hangouts for voice and video calls, Calendar for personal and team scheduling, and Google+ for social networking
• Store: Drive for online cloud storage to store, share, and sync across devices
• Collaborate: Docs for word processing, Sheets for spreadsheets, Forms for online surveys and forms, Slides for presentations, and Sites for team website creation
• Manage: Admin for business controls and security and Vault for archiving and e-discovery

On the surface, it looks like Google has all the bases covered, although from a usability perspective I find the collaborative tools to be clunky. However, that’s my impression of all online applications (Microsoft's Office Online apps included) -- I prefer to work on an installed application if available.

Many Google Apps offerings have “good enough” features, but they may not have exactly what you’re looking for compared to Office 365, especially on the admin side (that is, the control over these features). Granted, administering Office 365 gets very complex if you plan on jumping into the Exchange Admin Center or SharePoint Admin Center, even if the initial setup is easy in the Office 365 admin dashboard.

Also, Google's pricing has none of the complexity of Microsoft's: You pay $5 per user per month for the basic package and $10 per user per month for all the bells and whistles (including Vault archiving and unlimited storage).

For some, the best part of Google's suite is user experience. As one person told me, "The Gmail interface is far more user-friendly and less corporate for end-users, who after all are the real consumers of the technology.” Maybe -- if you’re an enterprise user who has been working with the Office suite through the years, there is zero learning curve in moving to Office 365.
It used to be privacy concerns offered a strong argument against Google Apps adoption. Google scanned all emails in Gmail accounts to determine what paid ads to present to users. In its ads, Microsoft used to crow it didn't do that, but Microsoft overstated the case -- at least for business users. Google Apps provided an admin tool to turn off this scanning for ad delivery, and earlier this year Google said it no longer scanned business email at all and that ads would be removed.

For me, what matters above all is functionality. Office 365 provides a cornucopia of features for both users and admins, a selection unmatched by Google Apps. Microsoft's tools are also more polished.

If you’re already running a Microsoft shop, a move to Office 365 is the logical progression. But for some organizations, the simplicity (both visually and administratively) of Google Apps, combined with the simple, inexpensive licenses, adds up to a legitimate draw for smaller organizations.

Even those legitimately tempted by Google Apps should make sure it does what you need it to do. Give it a real test first.

Developers often complain that in Web UI frameworks, the labeling used for elements and styling are both hard to parse and hard to work with. Semantic, a new Web framework now in its 1.0 incarnation, is attempting to change that, provided the next generation of Bootstrap itself doesn't get there first.

Semantic follows in roughly the same tradition as Bootstrap, but with a philosophy meant to make the framework more immediately useful to design-oriented developers. "Writing front-end code shouldn't require learning the naming or programming conventions of a particular developer," state its creators.

To that end, Semantic employs what is described as "simple, common language for parts of interface elements, and familiar patterns found in natural languages for describing elements." For example, there's the class syntax used to describe one of the elements on Semantic-ui.com's home page: "ui stackable center aligned very relaxed page grid."

All the components in the framework, according to the guide at LearnSematic.com, use the em and rem measurements for their sizes, so the element sizes are multiples of the metrics for the base font used on a given page. This makes it easier to resize elements for mobile use. Common Interface definitions, like "article" or "section" don't affect the way elements render for display.

The CSS used for the framework is variable-controlled via LESS, and a UI API allows for the management of element state, among other controls. Also included is a way to have the URLs for submissions defined using variables and substituted automatically, so those URLs and their parameters don't have to be hand-coded. Angular, Meteor, and other JavaScript frameworks are also supported.

Semantic UI's approach to layout can be both more flexible and more verbose than Bootstrap's. For instance, according to the examples provided for each framework, a breadcrumb navigation element in Bootstrap is implemented using an unordered list or ul HTML tag. In Semantic, it's created with a div, with "section" and "divider" classes marking up the individual links in the breadcrumb list and the dividers between them. The plus side of Semantic's approach is that it allows for more detailed inline customizations, but Bootstrap needs far less boilerplate to accomplish the same goal.

Semantic may be at a 1.0 release, but the site that provides documentation and examples for the framework is still raw. Usage examples for the API aren't available yet, nor have the "themes" and "layouts" sections of the Semantic-ui.com been implemented. Bootstrap, by contrast, already has a full set of documentation and a slew of existing themes, for both its current 3.x and previous 2.0 incarnations.

Plus, some of the innovations touted in Semantic are already being rolled into the next generation of Bootstrap. Bootstrap's 3.x incarnation doesn't use em measurements, for instance, but the next version promises to be em-centric, to feature "a new approach to configuring global theming options," a unified replacement for several existing display components such as panels and wells, and "hundreds more changes across the board." Many of those changes are still in flux, so an alpha release hasn't yet been offered, although it's being promised "in the coming months."

The rapid growth of cloud computing continues. As we implement systems, migrate applications, and move infrastructure to the cloud, proceedings seem to be going better than most people expected.

I’m certainly thankful for that, but I'm particularly grateful for four developments this year.

First, I’m thankful that, for the most part, public cloud-based systems have done a good job of keeping outages to a minimum and avoiding data breaches. Despite the Microsoft Azure outage last week and a few other minor outages, public cloud providers have done a much better job at staying up and running than IT does with most internal enterprise systems.

Many commentators predicted widespread panic when massive cloud outages occurred. It hasn’t happened yet. However, according to most analysts, only 1 percent of our workloads are now in the cloud — so the effects of outages are still small.

Second, I’m thankful that large data breaches have not occurred at public cloud providers — knock on wood. Data breaches, such as recent issues within Target, Home Depot, and even the U.S. Postal Service, did not have a cloud anywhere near them; rather, traditional systems and traditional approaches to security caused the problems.

Cloud security, although not perfect, has not disappointed us so far. However, you have the specter of the NSA scandal and fear that data in the cloud is data the government will cull through.

Third, I’m thankful for Amazon Web Services, a company that set the standard and made many other public cloud providers step up their game. AWS has led the public IaaS market, and I suspect other public cloud providers would not have spent as much money on their clouds if AWS had not set the pace for them to follow. AWS’s success has led to followers who emulate it, and that in turn has led to a market that provides much better cloud technology as a whole.

Fourth, I’m thankful that private clouds do not have as many deployments as originally predicted. In using private clouds, you must still maintain your own hardware and software. Although it’s a good solution in some very specific cases, a private cloud does not provide the value that public cloud provides. Perhaps having figured that out, most enterprises now bypass private clouds to move to public cloud or at least to implement hybrid clouds.

What are you thankful for?

I live in a fairly safe area. I haven’t heard about any crimes in my neighborhood since I’ve lived here. But like you, I read about crime every day online, and it seems that about half the time a security camera is used to identify and arrest the suspect. To be safe, I decided to select a security camera for my home.

I spent months researching security cameras online. I bought and tried several models, all designed to be accessed over the Internet, ranging from the cheap ones you can buy at Target to the high-end variety.
I learned a lot from my little adventure. First of all, you maybe surprised to discover that security cameras can be hacked. Monitoring your surroundings sounds like a fine idea, but be forewarned that you’ll also open the possibility that a motivated hacker could see what your cameras see. That may be a showstopper, depending on who you are, which is why I’ve detailed those concerns up front. If not, read this entire post for my advice on how to choose and set up a security camera system.

Security cameras aren’t all that secure

Most security cameras and their software aren’t built with computer security in mind. None of the vendors could provide me with a clear understanding of code reviews and penetration testing. In fact, most of my security inquiries were met with befuddlement. Often I was called back by someone days later who either did not know the answers to my questions or said yes to everything I asked so often, you knew they were not telling the truth.

I’m going to go out on a limb and say that most security cameras and their software are probably easily hackable. Your security device could be an ingress point for external hackers into your physical life.

Google-hack your camera

Do some Google searches on the system you’re considering. You might be surprised by what you find. Most security cameras run on nondefault ports that are well documented and known by attackers. It allows them to scan the Internet, look for those ports to find the cameras, then use their tricks to exploit your devices.

Change your password

Make sure you change the password needed to access and/or configure your security cameras or administrative console. Google-hacking security cameras that failed to change the default password are easy to spot. In fact, entire websites are dedicated to helping would-be intruders access security cameras using default passwords.

Ensure your management console uses an encrypted connection

Most security camera consoles allowed me to connect using insecure connection methods. Ask if your camera supports TLS-enabled or other secure connection methods. If not, consider another brand.

It’s all about the glass

Many low-end cameras work great up to distances of 10 to 20 feet, but fail miserably at distances beyond 30 to 40 feet. By contrast, most high-end cameras are able to accurately capture people at 75 to 100 feet, often in HD or near HD. Video clarity will cost you, but when you’re showing your video or pictures to law enforcement, the clearer the better.

Features to look for

Not surprisingly, the more you spend, the better the quality and the more features you get. Of the higher-end features, I’d put night vision at the top – after all, crimes have a tendency to occur after dark. Motion detection is also desirable, but make sure you can adjust the sensitivity and narrow the range of the scan. You don’t want legitimate moving objects such as windblown plants generating false positives. If you can properly tune the system, you may also want it to send a text message to your phone when motion is detected.

You'll also want the ability to save video and/or pictures externally (great for law enforcement purposes). Also, if a crime is caught on camera, the ability to play back video at high speed will help you find the event, and slo-mo will help you determine exactly what happened. Finally, higher-end models come with a separate DVR to record video, which is a good idea if you plan to keep your cameras running all the time.

Placing your cameras

I’m not a physical security expert, but in a multicamera scenario you’ll want to place cameras at all your ingress points (front door, back door, gate, and so on) at the very least. I was able to place cameras outside and inside each ingress point.

I should note that my wife wasn’t happy when I placed a camera in our bedroom. I figured she’d appreciate the extra security, but she was far more worried about my ability to prevent unauthorized viewers from accessing our cameras. Truth be told, I couldn’t promise her that would never happen.

Price doesn't determine lag time

All security cameras have some delay versus real time, and the cost or quality of the camera doesn't determine the severity of the lag. On the most expensive cameras I tested, the lag could be 5 to 10 seconds or more. I could walk into the field of video, then back to my computer and see myself on screen.

Lag can be especially tricky when paired with motion detection. Many of the cameras would correctly send me motion detection alerts, but the images they sent or captured often didn’t include whatever caused it.

Use wired cameras when possible

I needed wireless cameras for my home, but I couldn’t drag cable between my security camera DVR and some of my outside ingress points. Sadly, the wireless cameras rarely met their published maximum wireless distances; often it was less than half the stated lengths. Also, even with wireless, you’ll need power connections.

Wireless cameras can kill your wireless Internet

When I turned on my wireless security cameras, my wireless Internet access plummeted from 100Mbps download speeds to 0.40Mbps, essentially rendering it useless. As it happened, the wireless security cameras and their receivers run on the same 2.4GHz frequency as many wireless Internet connections.

Ultimately, I had to buy a new home wireless Internet access point that supported the newer 5GHz frequencies and replace any Internet devices stuck at 2.4GHz. The wireless cameras did not have any settings that allowed to hard-code wireless channels or change frequencies.

"Weather resistant" cameras are rarely waterproof

Many of the “outdoor” or “weather resistant” cameras failed or were ruined by moderate rain. You'll either need to buy cameras that are explicitly waterproof or work out some sort of durable protection for outdoor cameras.

Get dynamic DNS to access your cameras while traveling

Unless your home Internet connection has a static IP address, you’ll need to subscribe to a dynamic DNS service and configure your Internet routers to report any IP address changes to that service. Plus, you’ll need to configure your routers to advertise your camera’s remote access port(s) to get that feature to work.

Technical support

To end on a good note, all the cameras I reviewed had acceptable technical support. Most technical support was via the website or email, but I always received a response back in a day or two, which I felt was reasonable.

I feel more secure with my new security cameras installed. I already caught some neighborhood critters causing damage in my yard and have worked out a preventative measure. But I also live with the fact that any Internet-accessible security cameras can probably be exploited and used to invade my privacy. Like most security-related matters, a security camera can be a double-edged sword.

It may be cliché to highlight turkeys at Thanksgiving, but it's a good time of year to look back at what to give thanks for — and what to learn from as a new year approaches.

With that in mind, it's been an extraordinary year for failed mobile products, smartphones, tablets, and more. I can't recall a larger gaggle of mobile turkeys. Let me carve them up for you!

Amazon Fire Phone

 

The biggest flameout was Amazon.com's Fire Phone, the poster child of how not to develop a product. The Fire Phone was all about serving Amazon's greed, not at all about its customers. When a company forgets that customers keep it in business, you get products like the Fire Phone — and executives who can't believe customers aren't as sheeplike as they would prefer.

The Fire Phone isn't so much a smartphone but a portable product scanner and ordering device tied to a single vendor that also happens to make phone calls. Who on earth would want that? I'm all for mobile shopping, but I want to do it at more than one store. Any iPhone, Android, or Windows Phone can do that, thanks to store apps and QR code readers.

Real technology chops were required to create the Fire Phone's ability to take a picture of a product and find it on the Amazon store, but the advancements were ultimately wasted. It's like sequencing the human DNA to be able to create only blond children. Surely, there are more useful benefits than photographing objects in the world to order them from Amazon.

The Fire Phone also has all the shortcomings of Amazon's other Fire devices, its Kindle Fire tablet series, which are designed to conquer only Amazon content and provide a stripped-down, poor Android fork to ensure you can't do anything else on them. Worse, the Fire Phone requires you to buy a monthly data plan to essentially only shop with it. Even cutting its price to 99 cents with contract couldn't fool enough people to move the needle.

Samsung Galaxy S5

The Galaxy line has been Samsung's star attraction and the powerhouse behind its Android dominance in the West. But cracks began to appear in 2013's Galaxy S 4 and its uneven software. This year's Galaxy S5 had software that was as unbaked as the S 4's and a cheaper-feeling casing.

Soon after its launch came rumors that sales were dismal, and multiple market analysts said Apple's "failed" iPhone 5c was outselling it, as was the then-six-month-old iPhone 5s and, for a time, even Samsung's own S 4. (True numbers are impossible to come by, as Samsung does not report them, and its statements of what sells well don't always match what actually happens in the market.)

This fall, Samsung revealed its smartphone profits had dropped precipitously, before the iPhone 6 debuted to huge sales. Samsung managed to sink its flagship by neglecting it and assuming buyers wouldn't notice. They did, and they bought devices from Apple, HTC, and LG instead.

iPad Mini 3 and iPad Air 2

 

I'll say it bluntly: This year's new iPads are the equivalents of last year's iPhone 5s: the last iteration of an old design. Adding the Touch ID sensor is welcome but an obvious change given that it debuted a year ago in the iPhone 5s. In a year when Apple reinvented the iPhone, remade mobile payments with Apple Pay, and invented the Apple Watch, maybe it is too much to expect it to reinvent the iPad.

But it's time to take the iPad to a higher level, and Apple's hype-heavy iPad debut event — it spent more time on them than it had on the iPhone 6's debut — couldn't hide that fact. Apple shouldn't have pretended the new iPads were a big deal.

Android and Tizen smartwatches

 

The failure to move the iPad to the next level while pretending to is a minor transgression, though, compared to the series of disasters that has been the smartwatch market this year, powered by Android and Tizen OSes.

Responding to rumors in the last couple years that Apple might have a smartwatch in the works, Samsung has delivered three failed incarnations of its Gear, an ugly, bulky watch that does very little useful. (Samsung should stop worrying about what Apple might do and figure out instead what it can be good at itself.)

LG and Motorola Mobility came up with their own. LG's G Watch R was clunky but more watchlike, and Motorola's Moto 360 was cool to look at but not very functional — its circular face is quite attractive, but the square display rendered by the underlying Android Wear OS exceeds the screen's boundaries, so only the middle line of alerts and so on are complete. Clearly, no one tested this before shipping it.

The reviews of the Moto 360 have been the kindest — but hardly kind. I'm reminded of those horrible early Android tablets such as the original Galaxy Tab 7. Let's hope it doesn't take the Android watch community as long to come up with decent devices once the Apple Watch ships this coming spring as it did for the Android tablet community after the iPad's debut.

If you want a smartwatch today, get the one that is actually good: the Pebble. It may come from an upstart company and use an OS you never heard of, but unlike the Android and Tizen competitors, it works well.
There's a poult (look it up) in this category too: The new Microsoft Band fitness monitor that smartly runs with Android, iOS, and Windows Phone devices but is uncomfortable to wear — which it needs you to do all day, every day.

Samsung Galaxy Note Pro 12.2

Chasing another rumor about Apple's potential moves, Samsung unveiled its 12-inch Galaxy Note Pro 12.2 this winter, showing clearly that bigger is not always better. The Note Pro 12.2 is awkward to hold and awkward to use, with insufficient accommodation in its interface for its outsize scale. Again, you have to wonder if anyone used this thing before manufacturing it. No wonder Samsung is in trouble.

Samsung Knox

The trouble continues at Samsung. In spring 2012, Samsung debuted its Knox security technology that creates a separate workspace for personal and business usage, in the same vein as BlackBerry's Balance technology. It even won Defense Dept. approval.

But reports soon surfaced that the Knox technology didn't work as promised on the few Galaxy smartphones that supported it, and the product release date kept slipping. Although several mobile management vendors promised support for Knox, that backing didn't go much beyond press releases. Worse, potential customers balked at paying another $3 per user per month for Knox on top of the MDM fees for Galaxy users.

By the time Knox 2 — the real Knox — became available in spring 2014, Google decided to buy a competitor called Divide and incorporate it in Android 5.0 Lollipop. Samsung and Google made noises about some aspects of Knox being incorporated into Lollipop, but to this day they won't say what, if any, of Knox is in Lollipop.

Tellingly, when Google bought Divide, Samsung began discussions with BlackBerry to have BlackBerry's BES12 support Knox, which Samsung continues to make available for some of its Android devices. When I asked them, both Samsung and BlackBerry execs were vague about what specific capabilities the Knox tie-in with BES12 would bring, promising merely a strong partnership on future efforts. I can only wonder how much Samsung paid BlackBerry for this fig-leaf deal.

Tizen, Firefox OS, and Ubuntu Touch

For us tech pundits, a world that has essentially consolidated to Android and iOS is a bit boring, and we all root for BlackBerry and Windows Phone to matter somewhere, somehow. We sometimes get excited by puppy mobile OSes like Tizen, Firefox OS, and Ubuntu Touch, which despite their open source pedigree are creatures of Samsung and Intel, Mozilla, and Canonical, respectively.

None is new, but 2014 was supposed to be the year each got real, coming to market in multiple products. It didn't happen, and it likely won't ever at this point. (Remember the Tizen-powered Samsung Z that was supposed to ship first in Russia? It didn't.) Although they have intriguing aspects, the fact is they're all hugely inferior to Android and iOS, even to BlackBerry and Windows Phone. Why bother?

Tizen has no real mission other than to be a paper tiger Samsung can wave at Google when they fight over Android's direction. Firefox OS and Ubuntu Touch come from open source dreamers who believe that all a smartphone needs to be is a glorified Web browser. Google's been trying that for five years with Chrome OS, to marginal uptake at best (it might finally have cracked the 1 percent new-sales threshold this year).

Android's AOSP version and Microsoft's free phone licenses have taken away most of the cost factor advantage of a free open source mobile OS. You can still build cheaper Firefox OS and Ubuntu Touch phones than AOSP or Windows Phone devices, but not much cheaper — and you get phones that can do very little. People in poor countries may not have much money, but if they spend it on a smartphone, it has to handle sufficiently useful tasks to justify any price.

Google Docs for iOS and Android

 

For years, Apple's iWork suite was the undisputed king of the mobile office suites, though the now-defunct Quickoffice had long been a strong second choice, and for many a superior one for Word and Excel file usage. This winter, Microsoft debuted Office for iPad and a couple weeks ago made it available for the iPhone. The first Office for iPad was good, not great. But with several revisions since that debut, Office for iOS is now very good, a strong rival to iWork.

The same can't be said for the sad suite that is Google Docs, a marginally capable office-productivity trio that will quickly convince you to save your work for when you get back to your desk and have a real word processor — or switch to Office or iWork on an iOS device. The Android version of Google Docs is slightly more capable than the iOS version, but not enough to prevent you from jumping to Office for Android when that finally ships, probably in early 2015.

Google keeps pushing its Docs suite on mobile devices and Apps suite (aka Google for Work) for the desktop Web as alternatives to Microsoft Office, but it keeps failing miserably on the mobile side of the equation — where all the computing growth is. It makes no sense.

Apple CarPlay

Enough of the promises, already! Apple's been talking about CarPlay for more than two years, and it's still MIA. Those 2014 models from 29 marques that were supposed to have it on "select models"? Crickets. Apart from a $300,000 Ferrari vehicle, Pioneer is the only company that seems to have CarPlay gear, in the form of aftermarket stereos.

Sure, part of that is the slow pace of the automakers, most of whom still can't believe that people hate their horrible attempts at infotainment systems. (Ford, I'm talking to you!) Part of that is waiting for one of the kings of waitware, Google, to debut its CarPlay clone called Android Auto, so they're not beholden to only Apple.

But CarPlay's long hello is starting to feel like "Waiting for Godot" — without the intention to be so.

Turkeys that lived to see another year

You don't see BlackBerry or Windows Phone on my list of 2014's mobile turkeys — because they were 2013 turkeys that lived another year. Both are still struggling to hold onto their dismal market shares, but both are in the middle of plausible turnaround efforts that won't bear fruit for a good year.

BlackBerry has its back-to-the-past BlackBerry Classic (basically, a BlackBerry Q10 in a BlackBerry Bold case) debuting in a couple weeks, but its real hopes are on its expanded set of management capabilities and apps powered by its new BES12 management server.

The perpetually pretty but dumb Windows Phone got a serious update this year — Windows Phone 8.1 — plus the Siri clone called Cortana, but the real make-or-break point for Windows Phone is at least a year away, after the debut of the unified Windows 10. If that fifth version of the Windows Phone fails to turn on customers, Windows Phone will head to the carving table.

Like many cloud services, IBM's Bluemix PaaS has nominally been a multitenanted system -- a boon for sharing resources, but not so great if you worry about performance or security issues. The newest version of Bluemix, though, aims to win over those who want their cloud to be their cloud.

The new offering, called Bluemix Dedicated, is built using "dedicated hardware from within a SoftLayer cloud center and direct network connectivity to the enterprise," as IBM states in its press release.

The big drawback is that it's initially designed to provide only a curated subset of Bluemix services, running on dedicated metal without the need for the user to manage said metal. The services include Cloudant's NoSQL product, based on Apache CouchDB; a set of runtimes for various languages (to be named later); data caching services; and the MQ Light messaging service. Other services will be added, but no details have been provided as to when or which.

None of this is to say that Bluemix Dedicated runs in a vacuum -- services from Bluemix's public catalog and from IBM's Watson machine learning services are also available. But the actual customer apps run in an isolated environment built on Softlayer's architecture, which IBM has pushed as another selling point (especially with Softlayer's data centers available in multiple geographic regions). Softlayer has existing bare-metal offerings, although it's unclear if Bluemix Dedicated builds directly on top of that or is an entirely new creation that uses many of the same concepts.

Another Bluemix addition that goes hand-in-hand with Dedicated is what IBM called a Private API catalog, a collection of APIs that allow developers to connect their existing on-premise systems with IBM's Bluemix. An organization can in effect republish its data through Bluemix and make it available as a service, either to other internal developers or external third parties. A company that can't or doesn't want to move its data into the cloud at all, even to an isolated instance like Bluemix Dedicated, could use this as a halfway-house solution.

Aside from the usual questions about how large an audience IBM can find for Bluemix Dedicated, other competition may arise in terms of how -- or whether -- rival clouds can provide true single tenancy, either for VMs or for application stacks. Google, Amazon, and Microsoft don't offer bare metal as an option (yet). Rather, they're pinning their hopes on the idea that application-level containers and other technologies can provide performance as good as dedicated iron.

IBM's Bluemix PaaS has evolved from simply another PaaS offering to becoming an arena in which IBM is hoping to reinvent itself from the inside out. By moving its disparate offerings under a single API-connected roof, IBM has clarified both what it has to offer enterprises and how it can be used. This has also given IBM a fresh way to stay current -- by integrating more closely with new technologies like Docker.

IBM's earlier talk of leveraging Softlayer's single-tenanted, highly granular systems is now taking a specific form. Rather than resell existing Softlayer offerings, IBM is using that infrastructure to build entirely new products aimed at itches the rest of the cloud hasn't completely scratched.

Battery power consumption remains a lingering problem on smartphones -- and is getting worse with the latest advances in the devices. But developers can take steps to tackle the issue.

Carriers and consumers realize the importance of battery life, said Rick Schwartz, senior product manager at Qualcomm Technologies, during the recent AnDevCon Android technical conference. “Recent surveys have shown it’s actually the No. 1 [issue] to consumers. It’s more important than screen quality” and other factors, he said.

Complicating the problem is a trend in which battery power increases have not kept pace with faster processors and a growing number of CPU cores. Also, displays are achieving higher resolution and getting bigger, while phones are running 24 hours a day. Thinner phones further complicate the issue. “Of course, the thinner the phone, the thinner the battery,” Schwartz said.

It's hard to say how much battery preservation is about coding and testing, Schwartz said. Applications can have problems with the likes of radio usage because most developers do know how to see what is happening, he said. Simple solutions like closing connections or grouping of packets can help with power consumption, he said. “The amount of power consumed by the radio is significant.”

Application power consumption can be measured, Schwartz said. “One of the most popular ways to do that is using the Monsoon power meter.” However, Monsoon is a pricey approach, costing $770, he said. There are other free options, such as Qualcomm’s Trepn diagnostic tool, which can be used with the Eclipse IDE.
Inserting application states into code, meanwhile, can help identify the cause of power spikes, according to Schwartz. Application state markers are placed into code and tracked with software such as Trepn.

Most applications do no use system resources efficiently, according to one study, said Schwartz. The most common causes of power consumption issues include inefficient use of the cellular radio and Wi-Fi network, preventing the processor from going to sleep, keeping the display lit too long, and taking too many GPS location fixes. These small amounts of wasted power add up, Schwartz said.

He cited AT&T Resource Optimizer, also a free tool, as a mechanism for determining if an application uses the cellular radio efficiently. It also tests for file download problems, HTML issues, and peripheral usage, then recommends fixes. The Battery Historian tool in Android 5.0 Lollipop is useful for diagnostics too, Schwartz said.

Meanwhile, connecting less often to networks can increase power efficiency.
Continual streaming can be another issue with power consumption. Applications should use wake locks, which keep the screen from turning off, at minimum levels. Also, TCP sockets should be closed when no longer in use.

When it comes to which applications use excessive data or CPU cycles, Google’s search application has been a heavy consumer of power resources, Schwartz noted.

Nobody loves a reboot, especially not if it involves a late-breaking patch for a kernel-level issue that has to be applied stat.

To that end, three projects are in the works to provide a mechanism for upgrading the kernel in a running Linux instance without having to reboot anything.

Ksplice

The first and original contender is Ksplice, courtesy of a company of the same name founded in 2008. The kernel being replaced does not have to be pre-modified; all it needs is a diff file listing the changes to be made to the kernel source. Ksplice, Inc. offered support for the (free) software as a paid service and supported most common Linux distributions used in production.

All that changed in 2011, when Oracle purchased the company, rolled the feature into its own Linux distribution, and kept updates for the technology to itself. As a result, other intrepid kernel hackers have been looking for ways to pick up where Ksplice left off, without having to pay the associated Oracle tax.

Kgraft

Kgraft works roughly like Ksplice by using a set of diffs to figure out what parts of the kernel to replace. But unlike Ksplice, Kgraft doesn't need to stop the kernel entirely to replace it. Any running functions can be directed to their old or new kernel-level counterparts until the patching process is finished.

Kpatch

Red Hat came up with its own no-reboot kernel-patch mechanism, too. Also introduced earlier this year -- right after Suse's work in that vein, no less -- Kpatch works in roughly the same manner as Kgraft.
The main difference, as outlined by Josh Poimboeuf of Red Hat, is that Kpatch doesn't redirect calls to old kernel functions. Rather, it waits until all function calls have stopped, then swaps in the new kernel. Red Hat's engineers consider this approach safer, with less code to maintain, albeit at the cost of more latency during the patch process.

Like Kgraft, Kpatch has been submitted for consideration as a possible kernel inclusion and can be used with Linux kernels other than Red Hat's. The bad news is that Kpatch isn't yet considered production-ready by Red Hat. It's included as part of Red Hat Enterprise Linux 7, but only in the form of a technology preview.

...or Kgraft + Kpatch?

A fourth solution proposed by Red Hat developer Seth Jennings early in November 2014 is a mix of both the Kgraft and Kpatch approaches, using patches built for either one of those solutions. This new approach, Jennings explained, "consists of a live patching 'core' that provides an interface for other 'patch' kernel modules to register patches with the core." This way, the patching process -- specifically, how to deal with any running kernel functions -- can be handled in a more orderly fashion.

The sheer newness of these proposals means it'll be a while before any of them are officially part of the Linux kernel, although Suse's chosen to move fast and made it a part of its latest enterprise offering. Let's see if Red Hat and Canonical choose to follow suit in the short run as well.

It used to be that open source software was released only as source code and had to be compiled wherever it was needed. Obviously, that's changed. Today, some will even tell you that compiling source is an improper and problematic way to install software. Tomorrow, it may become more standard than they think.
While compiling source is still the basis of many BSDs (though you can get binary packages easily enough), package management came to Linux early on with RPM and branched out everywhere ever since. Package support on Debian and Ubuntu is simply massive. Fedora has a huge number of packages, as do RHEL and CentOS, though the packages available for the latter are generally far older for legacy and stability reasons.

This reliance on older packages has led to a situation where far too many admins find themselves in unfamiliar territory when confronted with the problem of needing a software release newer than what's available in the various package repositories. If your new app needs foo >= 1.45 and all you can find are RPM packages for 1.42, you're out of luck.

This was never an issue in the old days. You'd grab the 1.45 source, toss it in /usr/local/src, check whatever configure and compile flags you might need, then build and install it under /usr/local. Problem resolved, time for happy hour.

Why do some think this is a nonstandard and problematic way to install software? The drawback is that the package will not show up in the installed packages list, and there could be issues down the line with library installation locations. But the goal is to get the software installed and running, and that goal has been achieved. Ideally, this is documented and life moves on.

However, there's also an alternative: build your own package from the newer source. You can even contribute back to the project if you like! Again, though, I've seen puzzled looks from those who have never gone beyond apt-get or yum to install software. Yes, Francis, you can build your own packages. It's even easy most of the time.

In the RPM world, a fast way to do this is to download the source RPM for the package you need and the source for the version you need, and marry them together, adjusting for whatever differences there may be. This might be a new configure flag or similar, but apart from a little trial and error, it's usually not a big deal. Then build your new RPM with your new version, install it, and you're in the clear -- the right version installed via the "proper" methods. Perhaps you then complete the OSS cycle and send that package back to the maintainer. Everyone wins.

This sounds great -- many times it is -- but it's not always that easy. Many times, there isn't an available RPM because software inconsistencies, bugs, or other issues have prevented the developers from creating one. In those cases, you may have to abandon the package game for the time being.

Also, things have become much more slippery these days with systemd in play. Because packages now need to contend with systemd dependencies and unit files, modifying newer source RPMs to build on a non-systemd distribution can be a nightmare. In cases where a newer package version was available for Fedora but not CentOS, you used to be able to grab the source RPM and make only minor adjustments (if any) to install on a CentOS 5 or 6 system. Those days are gone.

I think this may become a bigger issue in the short term. With the adoption of systemd in several distributions, we're likely to see much longer use of the current, non-systemd releases. CentOS and RHEL will support version 6 until 2020, and I'd bet there will be more CentOS 6 boxes still running in 2020 than there are CentOS 5 boxes running right now. The same might be true for Debian Stable and Ubuntu LTS releases.
This has nothing to do with a like or dislike of systemd. It has everything to do with the decision whether to invest the time, energy, and risk into upgrading otherwise fully functional systems to a newer version due to the need for a single package unrelated to systemd.

For instance, you might have a bunch of production systems that need an application upgrade. As part of that upgrade, you need libraries that are of a version only available as a package on CentOS 7. However, that means you need to upgrade all of those systems to CentOS 7 and thus systemd. You run a few tests and determine that systemd will cause problems with other existing infrastructure components.

Now you have a choice: Do you invest all of the time and energy to develop an infrastructure-wide systemd migration plan, and delay the application upgrade for months, or do you build your own package containing the required library versions and leave everything else alone? Dollars to doughnuts, whoever needs the upgraded app will not give a rat's tuckus about systemd, and delaying decisions by several months will not be an option.

The good news is we're all in the same boat, more or less. Once these pain points become big enough, packages will become available on the more adventurous repos like EPEL and RepoForge that will get us through. But don't think it'll be smooth sailing. If you can say anything about systemd, it sure tends to lead to unanticipated choppy waters.