MacRumors: ‘iOS 8 Adoption Stagnates Just Two and a Half Weeks After Launch’

MacRumors: ‘iOS 8 Adoption Stagnates Just Two and a Half Weeks After Launch’:

Very worrisome — a canary-in-the-coal-mine indicator that casual users no longer trust Apple with major iOS updates. Last year the number for iOS 7 adoption was in the 70s in October, which was a faster adoption rate than iOS 6 the year prior.

[Here’s my take. Lots of devices don’t have the room necessary to complete the update, and folks haven’t made time to do anything about it yet. My son’s device is a perfect example, 16G, totally maxed out. I haven’t had time to check that it’s backed up, wipe it, update, and then reload. It’s gonna wait…]

20 years of blogging

20 years of blogging:

Every day I try to do some development work on my projects, but I see the end coming, not too far away. I don’t think I’ll be digging any great new holes in the future, but I do want to wrap up all the stuff I’ve started. That’s what the last few years have been about. I want to have great open publishing tools, that don’t require you to give everything you have to a billionaire in the hopes of getting a little attention.

[It does all come to end, and in technology it is harder to sustain a legacy I think. If you build a great building, it could easily be standing hundreds of years later. Software rarely lasts for 10 of years, although some stuff does. I have no problem with that. What I did/do is mostly work for hire. I love doing it, and it’s been kind to me, but most of programming I’ve done is already long gone from an executable standpoint. Some of it lives on as lessons applied to current work, and some of it lives on in the work of people I’ve taught. So when Dave says “Maybe it won’t go anywhere. Maybe it’ll all be swept aside, forgotten, along with so many other dreams of so many other people who thought they could make a difference.” I hear him, but I feel like all the folks who learned something about software from using his stuff, or writing their own software in his, or simply taking ideas and running with them in their own direction… that’s what makes a lasting difference. There is no way to sweep that aside. It just is.]

In an Uber all graphite and glitter

In an Uber all graphite and glitter:

Sure, maybe O’Reilly’s post bugged me because he’s playing the familiar game of using recent Apple product news as a strawman to compare to an utterly different kind of technology, while throwing in coded phrases like “Apple hype machine.” (Replying to a comment on his own article, O’Reilly declares, “What I wrote wasn’t really about Apple Pay.” Of course it wasn’t.)

But I think what really rankles is that Tim O’Reilly is applying his vision to a Silicon Valley utopia where people take Ubers to their Cover-booked restaurants, always operating on their own recognizance and never, ever waiting for the check. There’ll be spandex jackets, one for everyone.

Apparently these people never go to the supermarket.

[Common problem… Apple is used for so many things unrelated to Apple. OTOH, people are now making pants with larger pockets because of Apple. So if that matters to you, regardless of what phone you carry, thank Apple.]

Microsoft, IBM, & Docker jump on Google’s Kubernetes project for managing app containers anywhere

Microsoft, IBM, & Docker jump on Google’s Kubernetes project for managing app containers anywhere:

Now several companies that deal in managing infrastructure at scale have stepped up as contributors to the Kubernetes project, namely IBM, Microsoft, Red Hat, Docker, CoreOS, Mesosphere, and SaltStack.

Take the development as more proof that technology can now span a very wide variety of computing environments. Docker and its container technology have grown popular based on the notion that containers could be the basic unit of computing, and Kubernetes could be the tool to orchestrate all containers at the same time.

The new backing of Kubernetes could also be a turn away from more segmented and often proprietary hypervisor technology that sits on top of server operating systems and creates many virtual slices for running applications within each physical server. As developers and companies begin to try it, companies that sell hypervisor software, including VMware, could start to wonder how they should participate in the containerization movement.

[Like wildfire…]

Mesosphere to Bring Google’s Kubernetes to Mesos

Mesosphere · Mesosphere to Bring Google’s Kubernetes to Mesos:

The big trend driving containerization is a fundamental shift in the way apps are built. Today’s apps need to ingest big data. They need to connect to millions of devices. They need to scale out, elastically, in real time to handle surges in usage. They need to be highly automated, with no human operators. And they need to be fault tolerant and self-healing, so that zero downtime is the new normal. In this world, the old way of doing things simply—building ever bigger monolithic apps that run on ever bigger machines—simply does not work.

Building apps today means building them like Google does—or like Twitter, Facebook, and Airbnb for that matter. As the early pioneers of the “always on, always connected” world, these companies had to invent new ways to build apps. An “app” at one of these companies is not a single “binary” running on a giant server; it’s comprised of dozens (or hundreds or even thousands) of composable services running on fleets of servers, distributed across entire datacenters and clouds.

Building an app out of many composable services, distributed across just as many machines in a cloud or datacenter—stitched together using technologies like Mesos—is how apps are being built today. If you are not yet building apps like this, you will be. This is the new way to build apps. This is the new way to deploy apps. And this is what is truly driving the container revolution.

[I was wondering if there would be contention between these products. This is a good sign. And I agree that while one will probably bleed all over this stack for a while, it would indeed seem to be the way of the future. If you disagree, I’d love to here why.]

Jonathan Ive on Apple’s Design Process and Product Philosophy

Jonathan Ive on Apple’s Design Process and Product Philosophy –

The benefit of hindsight is we only really talk about those things that did work out. You have this sense that you’re working on something incredibly hard. When working on projects, you have this determination. You just keep going. If doing anything new, you’re very used to having insurmountable obstacles. At some point you have to make a call — at some point you have to say, “We’ve stretched this and we’ve come up against laws of physics, which we cannot change.”

[The first sentence is what caught me. in my daily life my company works on a lot of things and many don’t work out. And at times we get a bit unsettled about that. As if we were “better” more things would work out. But I doubt that’s the case when you’re doing things that are new, hard, and with incredible challenges. We’re probably have a really excellent ratio… but it’s easy to lose sight of that. Allez!]