Computed·Blg

Via AnandTech

-----

Today Intel made a sobering, but not entirely unexpected announcement: over the next 3 years Intel will be ramping down its own desktop motherboard business. Intel will continue to supply desktop chipsets for use by 3rd party motherboard manufacturers like ASUS, ASRock and Gigabyte, but after 2013 it will no longer produce and sell its own desktop mITX/mATX/ATX designs in the channel. We will see Haswell motherboards from the group, but that will be the last official hurrah. Intel will stop developing desktop motherboards once the Haswell launch is completed. All Intel boards, including upcoming Haswell motherboards, will carry a full warranty and will be supported by Intel during that period.

This isn't a workforce reduction. Most of the folks who worked in Intel's surprisingly small desktop motherboard division will move on to other groups within Intel that can use their talents. Intel's recently announced NUC will have a roadmap going forward, and some of the desktop board folks will move over there. Intel will continue to produce barebones motherboards for its NUC and future versions of the platform.

Intel will also continue to produce its own form factor reference designs (FFRDs) for Ultrabooks and tablets, which will be where many of these employees will end up as well. As of late Intel has grown quite fond of its FFRD programs, allowing it a small taste of vertical integration (and the benefits that go along with it) without completely alienating its partners. This won't be a transfer of talent to work on smartphone FFRDs at this time however.

The group within Intel responsible for building reference designs that are used internally for testing as well as end up as the base for many 3rd party motherboards will not be impacted by this decision either. The reference board group will continue to operate and supply reference designs to Intel partners. This is good news as it means that you shouldn't see a reduction in quality of what's out there.

It's not too tough to understand why Intel would want to wind down its desktop motherboard business. Intel has two options to keep Wall Street happy: ship tons of product with huge margins and/or generate additional profit (at forgiveably lower margins) that's not directly tied to the PC industry. The overwhelming majority of Intel's business is in the former group. The desktop motherboards division doesn't exactly fit within that category. Motherboards aren't good high margin products, which makes the fact that Intel kept its desktop board business around this long very impressive. Intel doesn't usually keep drains on margins around for too long (look how quickly Intel exited the de-emphasized its consumer SSD business).

The desktop motherboard business lasted so long as a way to ensure that Intel CPUs had a good, stable home (you can't sell CPUs if motherboard quality is questionable). While there was a need for Intel to build motherboards and reference designs 15 years ago, today what comes out of Taiwan is really quite good. Intel's constant integration of components onto the CPU and the resulting consolidation in the motherboard industry has helped ensure that board quality went up.

There's also the obvious motivation: the desktop PC business isn't exactly booming. Late last year word spread of Intel's plans for making Broadwell (14nm Core microprocessor in 2014) BGA-only. While we'll continue to see socketed CPUs beyond that, the cadence will be slower than what we're used to. The focus going forward will be on highly integrated designs, even for the desktop (think all-in-ones, thin mini-ITX, NUC, etc...). Couple that reality with low board margins and exiting the desktop motherboard business  all of the sudden doesn't sound like a bad idea for Intel. 

In the near term, this is probably good for the remaining Taiwanese motherboard manufacturers. They lose a very competent competitor, although not a particularly fierce one. In the long run, it does highlight the importance of having a business not completely tied to desktop PC motherboard sales.

Via DVICE

-----

No matter how many times you watch The Matrix, the creepiest part is seeing the whole of humanity hooked up to pods to act as living power generators for their robot masters. Now Germany-based designer Dennis Siegel has created a kind of mini version of this idea that he calls an Electromagnetic Harvester.

The tiny device allows him to draw redundant energy from household appliances, mobile devices, and even outside aerial electrical lines. An LED light indicates when power is effectively being drawn in, and that power is conveniently stored in what appears to be a common AA battery. According to Siegel, it takes the Electromagnetic Harvester about one day to fully charge one of the batteries, depending on the strength of the electromagnetic field being sourced.

You can see video of the Electromagnetic Harvester in action in the video below.

Via liliputing

-----

Always Innovating is working on a tiny flying video camera called the MeCam. The camera is designed to follow you around and stream live video to your smartphone, allowing you to upload videos to YouTube, Facebook, or other sites.

And Always Innovating thinks the MeCam could eventually sell for just $49.

The camera is docked in a nano copter with 4 spinning rotors to keep it aloft. There are 14 different sensors which help the copter detect objects around it so it won’t bump into walls, people. or anything else.

Always Innovating also includes stabilization technology so that videos shouldn’t look too shaky.

Interestingly, there’s no remote control. Instead, you can control the MeCam in one of two ways. You can speak voice commands to tell it, for instance, to move up or down. Or you can enable the “follow-me” feature which tells the camera to just follow you around while shooting paparazzi-style video.

The MeCam features an Always Innovating module with an ARM Cortex-A9 processor, 1GB of RAM, WiFI, and Bluetooth.

The company hopes to license the design so that products based on the MeCam will hit the streets in early 2014.

If Always Innovating sounds familiar, that’s because it’s the same company that brought us the modular Touch Book and Smart Book products a few years ago.

If the MeCam name sounds familiar, on the other hand, it’s probably worth pointing out that the Always Innovating flying camera is not related the wearable camera that failed to come close to meeting its fundraising goals last year.

Via c|net

-----

A rendering of the "Landscape House" by architect Janjaap Ruijssenaars.

(Credit: Universe Architecture)

Sure, we've heard of 3D-printed iPhone cases, dinosaur bones, and even a human fetus -- but something massive, like a building?

This is exactly what architect Janjaap Ruijssenaars has been working on. The Dutch native is planning to build what he calls a "Landscape House." This structure is two-stories and is laid out in a figure-eight shape. The idea is that this form can borrow from nature and also seamlessly fit into the outside world.

Ruijssenaars describes it on his Web site as "one surface folded in an endless mobius band," where "floors transform into ceilings, inside into outside."

The production of the building will be done on a 3D printer called the D-Shape, which was invented by Enrico Dini. The D-Shape uses a stereolithography printing process with sand and a binding agent -- letting builders create structures that are supposedly as strong as concrete.

According to the Los Angeles Times, the printer will lay down thousands of layers of sand to create 20 by 30-foot sections. These blocks will then be used to compile the building.

The "Landscape House" will be the first 3D-printed building and is estimated to cost between $5 million and $6 million, according to the BBC. Ruijssenaars plans to have it done sometime in 2014.

Via WebProNews

-----

Via ASYMCO

-----

As it did yesterday, on occasion Apple reports the cumulative total downloads and payments to developers. Since this is done in variable time intervals, it makes analysis of the value of the app store difficult.

But not impossible.

The provision of developer revenues means we can determine the pricing of apps. The pricing of apps and the download totals allows us to determine the revenue of the store. Using the time stamps of the reports allows us to determine these quantities over time.

I’ve combined the data we have so far into the following graph.

It shows three quantities (on three separate scales) at a monthly resolution:

1. Download rate (in millions/day, interpolated from download totals)
2. Payment rate to developers (reported change in payment to developers/reported time interval)
3. Resulting revenue per download (in red, trailing average over a 10 month period)

Having a price and quantity of app downloads allows for a complete picture of App Store revenues over time, shown below:

Note that I’ve separated the developer revenues from Apple’s own revenues. The blue area should total cumulative developer payments (to a degree of error.)

The green area above is what Apple includes in its financial reports as part of “Music” revenues. If we annualize these App Store revenues we can strip them out and show them separately from “other media” revenues.

Concentrating on the green areas which represent what Apple “keeps” we see the following split:

Considering that Apple reports the iTunes store to being “slightly above break-even” then we can summarize the chart above as the operating expenses for the store.

Finally, taking into account all the information above we can draw a complete picture of how revenues flow through the App Store:

Here are some conclusions:

• The iTunes economy defined as gross revenues transacted through it is now about $12 billion/yr.
• Over the last five years content owners (media and app) received a total of $24 billion while Apple spent about $10 billion to create those sales
• Seen as a retail business, iTunes costs about $3.5 billion/yr to operate. This includes merchandising, payment processing and “shipping & handling”.
• Total revenues have risen steadily in a range of 32 to 38% compounded over the last 4 years.
• Apps are now a third of all iTunes revenues, (about $4 billion/yr) having taken that share in only 4.5 years.
• Non-app media still make up 2/3 of iTunes in terms of sales value but their growth is now 28% vs. about 50% for apps.

Via prote.in

-----

Bearing similarities to the Emoto project we looked at over the Summer, Mithru Vigneshwara's Aleph of Emotions uses location-based Twitter information to measure the 'mood' in various cities around the world.

Looking like a traditional camera, the user points the device in any direction and, combining the technology of a GPS, a smart phone and openFrameworks, the Aleph of Emotions captures and displays the emotional state people in major geographical locations.

This is another example of technology merging with intuitive design to measure or record concepts previously considered too abstract and intangible to be turned into meaningful data.

Via webmonkey

-----

Amiga pinball wizard.

Miss your Amiga? Now you can play Prince of Persia, Pinball Dreams and other Amiga hits right in your web browser thanks to the Scripted Amiga Emulator, an Amiga emulator written entirely in JavaScript and HTML5.

To view the emulator, which was written by developer Rupert Hausberger, you’ll need a browser with support for WebGL and WebAudio, as well as a few other HTML5 APIs. I tested the emulator in the latest version of both Chrome and Firefox and it worked just fine.

If you’d like to see the code behind the Scripted Amiga Emulator, head on over to GitHub.

Via Smashing Magazine

-----

At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.

After some initial missteps, the project finally hit a groove, and it now regularly get compliments from people using and contributing to CSS Lint. It’s actually not that hard to create a successful open-source project when you stop to think about your goals.

(Smashing’s note: Subscribe to the Smashing eBook Library and get immediate unlimited access to all Smashing eBooks, released in the past and in the future, including digital versions of our printed books. At least 24 quality eBooks a year, 60 eBooks during the first year. Subscribe today!)

What Are Your Goals?

These days, it seems that anybody who writes a piece of code ends up pushing it to GitHub with an open-source license and says, “I’ve open-sourced it.” Creating an open-source project isn’t just about making your code freely available to others. So, before announcing to the world that you have open-sourced something that hasn’t been used by anyone other than you in your spare time, stop to ask yourself what your goals are for the project.

The first goal is always to create something useful. For CSS Lint, our goal was to create an extensible tool for CSS code quality that could easily fit into a developer’s workflow, whether the workflow is automated or not. Make sure that what you’re offering is useful by looking for others who are doing similar projects and figuring out how large of a user base you’re looking at.

After that, decide why you are open-sourcing the project in the first place. Is it because you just want to share what you’ve done? Do you intend to continue developing the code, or is this just a snapshot that you’re putting out into the world? If you have no intention of continuing to develop the code, then the rest of this article doesn’t apply to you. Make sure that the readme file in your repository states this clearly so that anyone who finds your project isn’t confused.

If you are going to continue developing the code, do you want to accept contributions from others? If not, then, once again, this article doesn’t apply to you. If yes, then you have some work to do. Creating an open-source project that’s conducive to outside contributions is more work than it seems. You have to create environments in which those who are unfamiliar with the project can get up to speed and be productive reasonably quickly, and that takes some planning.

This article is about starting an open-source project with these goals:

1. Create something useful for the world.
2. Continue to develop the code for the foreseeable future.
3. Accept outside contributions.

Choosing A License

Before you share your code, the most important decision to make is what license to apply. The open-source license that you choose could greatly help or hurt your chances of attracting contributors. All licenses allow you to retain the copyright of the code you produce. While the concept of licensing is quite complex, there are a few common licenses and a few basic things you should know about each. (If you are open-sourcing a project on behalf of a company, please speak to your legal counsel before choosing a license.)

• GPL
  The GNU Public License was created for the GNU project and has been credited with the rise of Linux as a viable operating system. The GPL license requires that any project using a GPL-licensed component must also be made available under the GPL. To put it simply, any project using a GPL-licensed component in any way must also be open-sourced under the GPL. There is no restriction on the use of GPL-licensed applications; the restriction only has to do with the modification and distribution of derived works.
• LGPL
  The Lesser GPL is a slightly more permissive version of GPL. An LGPL-licensed component may be linked to from an application without the application itself needing to be open-sourced under GPL or LGPL. In all other ways, LGPL is the same as GPL, so any derived works must also be open-sourced under GPL or LGPL.
• MIT
  Also called X11, this licence is permissive, allowing for the use and redistribution of code so long as the license and copyright are included along with it. MIT-licensed code may be included in proprietary code without any additional restrictions. Additionally, MIT-licensed code is GPL-compatible and can be combined with such code to create new GPL-licensed applications.
• BSD3
  This is also a permissive license that allows for the use and redistribution of code as long as the license and copyright are included with it. In addition, any redistribution of the code in binary form must include a license and copyright in its available documentation. The clause that sets BSD3 apart from MIT is the prohibition of using the copyright holder’s name to promote a product that uses the code. For example, if I wrote some code and licensed it under BSD3, then an application that uses that code couldn’t use my name to promote the product without my permission. BSD3-licensed code is also compatible with GPL.

There are many other open-source licenses, but these tend to be the most commonly discussed and used.

One thing to keep in mind is that Creative Commons licenses are not designed to be used with software. All of the Creative Commons licenses are intended for “creative work,” including audio, images, video and text. The Creative Commons organization itself recommends not using Creative Commons licenses for software and instead to use licenses that have been specifically formulated to cover software, as is the case with the four options discussed above.

So, which license should you choose? It largely depends on how you intend your code to be used. Because LGPL, MIT and BSD3 are all compatible with GPL, that’s not a major concern. If you want any modified versions of your code to be used only in open-source software, then GPL is the way to go. If your code is designed to be a standalone component that may be included in other applications without modification, then you might want to consider LGPL. Otherwise, the MIT or BSD3 licenses are popular choices. Individuals tend to favor the MIT license, while businesses tend to favor BSD3 to ensure that their company name can’t be used without permission.

To help you decide, look at how some popular open-source projects are licensed:

• jQuery: MIT license
• YUI: BSD3 license
• Dojo Toolkit: dual-licenced under BSD3 and Academic Free License
• Backbone: MIT license

Another option is to release your code into the public domain. Public-domain code has no copyright owner and may be used in absolutely any way. If you have no intention of maintaining control over your code or you just want to share your code with the world and not continue to develop it, then consider releasing it into the public domain.

To learn more about licenses, their associated legal issues and how licensing actually works, please read David Bushell’s “Understanding Copyright and Licenses.”

Code Organization

After deciding how to license your open-source project, it’s almost time to push your code out into the world. But before doing that, look at how the code is organized. Not all code invites contributions. If a potential contributor can’t figure out how to read through the code, then it’s highly unlikely any contribution will emerge. The way you lay out the code, in terms of file and directory structure as well as coding style, is a key aspect to consider before sharing it publicly. Don’t just throw out whatever code you have been writing into the wild; spend some time figuring out how others will view your code and what questions they might have.

For CSS Lint, we decided on a basic top-level directory structure of src for source code, lib for external dependencies, and tests for all test code. The src directory is further subdivided into directories that group together related files. All CSS Lint rules are in the rules subdirectory; all output formatters are in the formatters directory; etc. The tests directory is split up into the same subdirectories as src, thereby indicating the relationship between the test code and the source code. Over time, we’ve added top-level directories as needed, but the same basic structure has been in place since the beginning.

Documentation

One of the biggest complaints about open-source projects is the lack of documentation. Documentation isn’t as fun or exciting as writing executable code, but it is critical to the success of an open-source project. The best way to discourage use of and contributions to your software is to have no documentation. This was an early mistake we made with CSS Lint. When the project launched, we had no documentation, and everyone was confused about how to use it. Don’t make the same mistake: get some documentation ready before pushing the project live.

The documentation should be easy to update and shouldn’t require a code push, because it will need to be changed very quickly in response to user feedback. This means that the best place for documentation isn’t in the same repository as the code. If your code is hosted on GitHub, then make use of the built-in wiki for each project. All of the CSS Lint documentation is in a GitHub wiki. If your code is hosted elsewhere, consider setting up your own wiki or a similar system that enables you to update the documentation in real time. A good documentation system must be easy to update, or else you will never update it.

End-User Documentation

Whether you’re creating a command-line program, an application framework, a utility library or anything else, keep the end user in mind. The end user is not the person who will be modifying the code; it’s the one who will be using the code. People were initially confused about CSS Lint’s purpose and how to use it effectively because of the lack of documentation. Your project will never gain contributors without first gaining end users. Satisfied end users are the ones who will end up becoming contributors because they see the value in what you’ve created.

Developer Guide

Even if you’ve laid out the code in a logical manner and have decent end-user documentation, contributions are not guaranteed to start flowing. You’ll need a developer guide to help get contributors up and running as quickly as possible. A good developer guide covers the following:

1. How to get the source code
   Yes, you would hope that contributors would be familiar with how to check out and clone a repository, but that’s not always the case. A gentle introduction to getting the source code is always appreciated.
2. How the code is laid out
   Even though the code and directory structures should be fairly self-explanatory, writing down a description for posterity always helps.
3. How to set up the build system
   If you are using a build system, then you’ll need to include instructions on how to set it up. These instructions should include where to get build-time dependencies that aren’t already included in the repository.
4. How to run a build
   These are the steps necessary to run a development build and to execute unit tests.
5. How to contribute
   Spell out the criteria for contributing to the project. If you require unit tests, then state that. If you require documentation, mention that as well. Give people a checklist of things to go over before submitting a contribution.

I spent a lot of time refining the “CSS Lint Developer Guide” based on conversations I had had with contributors and questions that others would ask. As with all documentation, the developer guide should be a living document that continues to grow as the project grows.

Use A Mailing List

All good open-source projects give people a place to go to ask questions, and the easiest way to achieve that is by setting up a mailing list. When we first launched CSS Lint, Nicole and I were inundated with questions. The problem is that those questions were coming in through many different channels. People were asking questions on Twitter as well as emailing each of us directly. That’s exactly the situation you don’t want.

Setting up a mailing list with Yahoo Groups or Google Groups is easy and free. Make sure to do that before announcing the project’s availability, and actively encourage people to use the mailing list to ask questions. Link to the mailing list prominently on the website (if you have one) or in the documentation.

The other important part of running a mailing list is to actively monitor it. Nothing is more frustrating for end users or contributors than being ignored. If you’ve set up a mailing list, take the time to monitor it and respond to people who ask questions. This is the best way to foster a community of developers around the project. Getting a decent amount of traffic onto the mailing list can take some time, but it’s worth the effort. Offer advice to people who want to contribute; suggest to people to file tickets when appropriate (don’t let the mailing list turn into a bug tracker!); and use the feedback you get from the mailing list to improve documentation.

Use Version Numbers

One common mistake made with open-source projects is neglecting to use version numbers. Version numbers are incredibly important for the long-term stability and maintenance of your project. CSS Lint didn’t use version numbers when it was first released, and I quickly realized the mistake. When bugs came in, I had no idea whether people were using the most recent version because there was no way for them to tell when the code was released. Bugs were being reported that had already been fixed, but there was no way for the end user to figure that out.

Stamping each release with an official version number puts a stake in the ground. When somebody files a bug, you can ask what version they are using and then check whether that bug has already been fixed. This greatly reduced the amount of time I spent with bug reports because I was able to quickly determine whether someone was using the most recent version.

Unless your project has been previously used and vetted, start the version number at 0.1.0 and go up incrementally with each release. With CSS Lint, we increased the second number for planned releases; so, 0.2.0 was the second planned release, 0.3.0 was the third and so on. If we needed to release a version in between planned releases in order to fix bugs, then we increased the third number. So, the second unplanned release after 0.2.0 was 0.2.2. Don’t get me wrong: there are no set rules on how to increase version numbers in a project, though there are a couple of resources worth looking at: Apache APR Versioning and Semantic Versioning. Just pick something and stick with it.

In addition to helping with tracking, version numbers do a number of other great things for your project.

Tag Versions in Source Control

When you decide on a new release, use a source-control tag to mark the state of the code for that release. I started doing this for CSS Lint as soon as we started using version numbers. I didn’t think much of it until the first time I forgot to tag a release and a bug was filed by someone looking for that tag. It turns out that developers like to check out particular versions of code.

Tie the tag obviously to the version number by including the version number directly in the tag’s name. With CSS Lint, our tags are in the format of “v0.9.9.” This will make it very easy for anyone looking through tags to figure out what those tags mean — including you, because you’ll be able to better keep track of what changes have been made in each release.

Change Logs

Another benefit of versioning is in producing change logs. Change logs are important for communicating version differences to both end users and contributors. The added benefit of tagging versions and source control is that you can automatically generate change logs based on those tags. CSS Lint’s build system automatically creates a change log for each release that includes not just the commit message but also the contributor. In this way, the change log becomes a record not only of code changes, but also of contributions from the community.

Availability Announcements

Whenever a new version of the project is available, announce its availability somewhere. Whether you do this on a blog or on the mailing list (or in both places), formally announcing that a new version is available is very important. The announcement should include any major changes made in the code, as well as who has contributed those changes. Contributors tend to contribute more if they get some recognition for their work, so reward the people who have taken the time to contribute to your project by acknowledging their contribution.

Managing Contributions

Once you have everything set up, the next step is to figure out how you will accept contributions. Your contribution model can be as informal or formal as you’d like, depending on your goals. For a personal project, you might not have any formal contribution process. The developer guide would lay out what is necessary in order for the code to be merged into the repository and would state that as long as a submission follows that format, then the contribution will be accepted. For a larger project, you might want to have a more formal policy.

The first thing to look into is whether you will require a contributor license agreement (CLA). CLAs are used in many large open-source projects to protect the legal rights of the project. Every person who submits code to the project would need to fill out a CLA certifying that any contributed code is original work and that the copyright for that work is being turned over to the project. CLAs also give the project owner license to use the contribution as part of the project, and it warrants that the contributor isn’t knowingly including code to which someone else has a copyright, patent or other right. jQuery, YUI and Dojo all require CLAs for code submissions. If you are considering requiring a CLA from contributors, then getting legal advice regarding it and your licensing structure would be worthwhile.

Next, you may want to establish a hierarchy of people working on the project. Open-source projects typically have three primary designations:

• Contributor
  Anyone who has had source code merged into the repository is considered a contributor. The contributor cannot access the repository directly but has submitted patches that have been accepted.
• Committer
  People who have direct access to the repository are committers. These people work on features and fix bugs regularly, and they submit code directly to the repository.
• Reviewer
  The highest level of contributor, reviewers are commanders who also have directional impact on the project. Reviewers fulfill their title by reviewing submissions from contributors and committers, approving or denying patches, promoting or demoting committers, and generally running the project.

If you’re going to have a formal hierarchy such as this, you’ll need to draft a document that describes the role of each type of contributor and how one may be promoted through the ranks. YUI has just created a formal “Contributor Model,” along with excellent documentation on roles and responsibilities.

At the moment, CSS Lint doesn’t require a CLA and doesn’t have a formal contribution model in place, but everyone should consider it as their open-source project grows.

The Proof

It probably took us about six months from its initial release to get CSS Lint to the point of being a fully functioning open-source project. Since then, over a dozen contributors have submitted code that is now included in the project. While that number might seem small by the standard of a large open-source project, we take great pride in it. Getting one external contribution is easy; getting contributions over an extended period of time is difficult.

And we know that we’ve been doing something right because of the feedback we receive. Jonathan Klein recently took to the mailing list to ask some questions and ended up submitting a pull request that was accepted into the project. He then emailed me this feedback:

I just wanted to say that I think CSS Lint is a model open-source project — great documentation, easy to extend, clean code, fast replies on the mailing list and to pull requests, and easily customizable to fit any environment. Starting to do development on CSS Lint was as easy as reading a couple of wiki pages, and the fact that you explicitly called out the typical workflow of a change made the barrier to entry extremely low. I wish more open-source projects would follow suit and make it easy to contribute.

Getting emails like this has become commonplace for CSS Lint, and it can become the norm for your project, too, if you take the time to set up a sustainable eco-system. We all want our projects to succeed, and we want people to want to contribute to them. As Jonathan said, make the barrier to entry as low as possible and developers will find ways to help out.

Via ZDNet

-----

Continuing our look in more detail at the 2013 predictions from analyst Mark Anderson, the question of processors and Intel vs ARM is an interesting proxy for the bigger question of "what do we want a computer to be?"

Despite the successes of three generations of Core processors, Intel has plenty of problems to tackle.

Anderson put it bluntly and raised questions about both the business and the technology of CPUs ('CarryAlong' is his term for tablets, phablets, netbooks and other devices that are portable enough to carry and use all day):

"Intel: Long Live the King, the King is Dead. The chip royalty ladder is flipped, as Intel becomes increasingly irrelevant in the world of general computing, while CarryAlong and mobile chipmakers (led by Qualcomm and ARM) are the new William and Kate. For most observers, Intel in 2013 is a component supplier for servers. The best way out of this cul de sac: a new CEO with tech chops."

Quantum barrier

Intel is unbeatable in the laptop space today, but the combination of the popularity of tablets and the laws of physics at 19nm scale and below makes you wonder where they will be in five to 10 years' time. I've wondered if Intel started favouring operations over chip technologists for leadership when they noticed that they were hitting the wall on Moore's Law and had run through Dennard Scaling so much faster than predicted.

(Moore's Law, of course, relates to the number of transistors on a wafer and the cost of the fab to put them there, while Dennard Scaling has to do with keeping the power efficiency of those transistors as good as the previous generation.)

The hi-K metal gates introduced in Sandy Bridge and the tri-gate derivative in Ivy Bridge are making a huge difference in today's Intel chips, but it took 10 years to get that into production. Moreover, a new material is needed to help deal with the fundamental issue of not having enough electrons to get a clean signal to switch the transistor between one and zero without quantum-level effects weirding out the transistor - and if there is such a material, it's still in the labs.

Intel needs to optimise the processes now to make enough time to do the next piece of fundamental science; however, as you hit the quantum level, that fundamental science is a lot harder.

In the meantime I see Intel deliberately continuing to cannibalise itself with Atom because that's preferable to being cannibalised by ARM - and at least uses those fabs that were so expensive when you built them a few years back when they were state of the art. I also see it missing out on LTE, still, which has to hurt its ability to compete in the smartphone market. And if rumours that Haswell chips don't launch until the middle of 2013 are true, Intel would be about six months behind on its usual tick-tock cadence of shrinking a die one year and rolling out a new architecture 12 months later.

Could Intel knock the internal politics on the head while it's at it? I don't understand why CloverTrail isn't yet available in large numbers, but the battle between the Silicon Valley and Israeli chip development teams on direction could be one reason why we don't yet have a Core chip that can support Connected Standby (CS) in Windows 8, even though the power levels should be low enough to make that work.

Connected Standby, Ultrabooks and GPUs

Look at the 17W TDP (thermal design point) of some Ivy Bridge Core models, the promised 15W TDP of Shark Bay Ultrabook processors and then forward to the 8-10W TDP of Haswell, when we might finally get on-package CMOS voltage regulators and support for S0ix active idle - and that's what you need for Connected Standby.

To be fair, it's possible that the reason we don't have Core chips with CS already is that it requires everything to go to a low power fast wake state, not just the CPU - and that's easiest to do when you control all the support components by building an SoC; System on Chip by definition means integration and less variation to deal with. (Qualcomm's huge success has been about not just building a good ARM chip but building it into an integrated platform that can be used to churn out dozens or hundreds of smartphones in a year.)

The Ultrabook programme also gives Intel a way to kick OEMs into line to make them use low-power components (maybe even screens with enough attached RAM to cache what you're looking at on screen when it's not changing fast enough for the GPU to need to be awake), although that's going to face the usual resistance from OEMs who want the choice to carry on with their race to the bottom on $200 tablets and $300 PCs.

Meanwhile, there's Intel's continuing inability to understand that producing graphics drivers that are robust enough to reliably do hardware acceleration is crucial. Notice how few Intel GPUs have been certified for hardware acceleration by Adobe or compare the hardware acceleration you can get in IE 9 and 10 with a 'real' GPU compared to Intel integrated graphics. Offload to GPU is one way to get around Moore's Law (a GPU has far more cores than even the most multi-core of CPUs and they're simplistic and only applicable to easily parallelised problems, but offloading to special purpose hardware is another way ARM systems punch above their weight).

Intel is stuck between the rock of physics, the hard place of mobile computing, the Scylla of expensive fabs and the Charybdis of business models.

Maybe that's why it's trying so hard to become a software company with services for developers. It's been adding NUI concepts like voice recognition and gestures as well as location services under the Computer Continuum umbrella to the language support and development tools it's long offered, and putting its own virtualisation layer under any operating system running on an Intel PC. And, yes, all that does put Intel into competition with an even wider range of industry players...

AMD takes ARMs against the sea of Intel

Inside ARM: The British success story taking the chip world by storm