Firstly, he thinks that consumers are stupid: "They don’t know what they hate. All they know is they buy phone service from mobile carriers and/or buy a phone from a carrier. They love speeds & feeds and will generally buy anything they are told to by television ads and RSPs (Retail Sales Professionals)."

No: consumers ask their friends. Their friends are Slashdot readers. They know full-well what a phone Market dominated by Microsoft would look like, they know how Microsoft has behaved. Repeatedly. And they are not going to recommend a MS phone to anyone: friends don't screw friends. They all know it's just about protecting the desktop market, and the moment that MS has achieved that objective they'll screw the user. The clue is in the name: 'Windows Phone'.

Secondly: "My hypothesis is that it also enables too much fragmentation that will eventually drive end users nuts." I guess that's how it's worked out for x86 choice in the face of the Apple desktop monoculture. Nope? It turns out that we value openness. It's one of the variables we play with when making a choice between systems: given all else equal, we'll choose the system that's more open. Advantages of openness far outweigh the disadvantages like fragmentation. So all that Google has to do is keep Android at rough parity with Apple in terms of UI/features. But they are doing better than parity - it's cheaper for better.

Thirdly: Carriers know full well what happens to companies who partner with Microsoft. And so do device manufacturers. I guess some companies (cough, Nokia, cough), like the idea of handing their future to Microsoft, but it turns out that most think that's a bad idea. Sendo, anyone?

Then I'm sure we can find a bunch of people who will dispute that WP is the best technically. Form an orderly queue in the replies please.

But finally, even if you were to consider that WP was technically the best, the idea that the best tech is the winner has been roundly disproved again and again. Everyone, including Charlie Kindel, knows it's about the whole package. We all know that MS on the desktop isn't the best technically (it can't be - it has to satisfy everyone) but it is the best at the whole package.

If this research is validated, then there may be implications for UI design...

Gnome 3, for example, works using an application space focus, rather than a window focus. In one way that's quite appealing - it gives you full focus on the task at hand without the distraction of the 12 other programs you are running at the same time. The problem that lots of people have reported/commented on is that it makes it very difficult to be task focused when a task involves more than one program. Part of this may be to do with the doorway context switch impeding short term memory retention on the task at hand.

I've used Gnome 3 as an example, but it's far from alone; Metro & Apple full-screen apps spring to mind, though there's a mitigation with Apple full-screen in that it's not forced upon you.

I wonder if there's a way to enjoy the focus of application-centricity without the disadvantages? For instance, I can imagine keeping a map of the other applications visible, or a representation of the overall desktop/workspace, as you move th'rough the doorway between applications, and/or as you work in an application space. (Slashdot, you may want to vote this up so that it isn't deleted when this item is archived, so that there's some evidence of prior art when large megacorp tries to patent this UI idea.)

Something like that might be enough to jog short term memory and stop the context loss.

Or of course, we could decide that window centric works best, but work on ways to easily group windows into tasks.

Workspaces/Desktops are one way to accomplish this. The problem that I find with workspaces is that they are a clumsy way to manage tasks when I have an application that spans different tasks. But on the other hand, actively managing windows by marking and grouping them introduces unwelcome management overhead.

I would welcome a system whereby windows and applications were grouped together, either automatically or on the cue of the user, by virtue of the fact that they had been used together. (Again - oh no megacorp! - more prior art! ) For instance, one embodiment of this might be to group windows or applications based on the transfer of info between them. Cut and paste for example shows a transfer of info, and could be used as an indicator of affinity.

As ever, it depends:

Firstly, the landscape is constantly evolving, and some of what I say below reflects the current situation for Drupal 7. It may not be the same in six months time.

You need to decide:
Do you want very clean, targeted HTML and CSS? Or do you want as many options as possible in the CSS, and don't mind the cost of many wrapping divs and CSS with many overrides?

If it's the latter, then you will likely want to work from one of the starter themes, sculpting the CSS and templates to suit your design. Try the Stark (shipped with Drupal 7), Clean, Boron and Basic themes.

Or if it's the former then you will likely want to either build the theme from scratch or work from one of the minimal themes, and build up to cater for your exact requirements. Omega, Zen, Adaptive, Genesis and Fusion are all good bets.

You need to decide whether your design is grid-based or not. If it is grid-based, then it's easier to use a theme with built-in grid support. (Or you can add grid support to a theme which doesn't have it.) If your design is not gridded, then you are probably best-off not using a gridded theme (though of course you could override the grid classes to remove the grid.)

If it's grid-based, then the best is probably Omega, but 960 is worth a look. For non-gridded, Stark, Clean, Basic, Zen, Adaptive, Genesis and Fusion are all still ok.

You need to decide whether mobile support, HTML5, and adaptive theming are critical or not. Of course you can override the templates a theme provides, to include any of these, but starting off with a theme with them built-in will be easier for most people.

If any of these are critical, and you aren't interested in building in support yourself, then Omega, Adaptive, Genesis, Boron and Fusion have support for some or all of these features.

At the moment, if a maximal theme, with grid support is what interests you most, Omega is the best imo. The cost is that it's big, and complex.

There are several good resources:
http://drupal.org/node/323993 contains a list of starter themes.
http://www.chapterthree.com/blog/squiggy_rubio/review_drupal_6_starter_themes - is about Drupal 6, but much of it remains relevant for Drupal 7.
And in some blatant promotion, sometime in the next week we'll post an article at http://www.tanasity.com/ comparing and contrasting the best starter themes for Drupal 7, the work on which this note is based.

Before doing this you may want to check what the local laws are. Police States do not like privacy. Encryption is not always legal. If you find it's illegal you will probably also want to check what the penalties are.

As any veteran of website Content Management Systems (CMS) will tell you, the problem is that custom coded sites are a nightmare in waiting for most customers. Unless you have a mega budget, and a team of developers, and the guarantee of the ongoing budget and team, you are much better off using a existing CMS. The security is likely to be better than with a custom CMS especially if there are lots of people contributing, the opportunities to grow the site through new functionality will be better, especially if it's open source, and the cost is likely to be less for more.

Behind the scenes most of CMS there is a database. Often, but not always, it's coupled to a scripting language, and usually it's organized in such a way that it's modular. This modularity is what gives non-custom CMSs their teeth, but compared to custom CMSs, the cost is that the queries on the database are non-optimal. Often data is read twice or more by different parts of the CMS because they aren't able to directly work together to retrieve the data in the way that a custom CMS can. It's this explosion of database queries which is usually responsible for any drop in comparative speed, and not the cost of executing scripts.

The revolutionary approach is not to waste time redeveloping stuff that other people have already built, but to reuse at low or no cost through the power of open source. It's almost always quicker, easier and cheaper to buy faster hardware and use a scripting language than it is to develop software in C++.

Some games and operating systems may be written in C++, but they have different needs and requirements, and operate in different environments; a formula 1 car is optimized for traveling around a race circuit, but it is useless when there are speed bumps.

Drupal represents tens of millions of dollars investment and is built by some of the world's best CMS developers. It takes a lot for a custom CMS to compete with that.

Disclosure: I'm involved in the Drupal project. I develop for Drupal. I've been developing for Drupal for 6 years. I have programmed in C++ and scripting languages. I have built custom CMSs. I've built sites in other CMSs. I threw away my CMS framework when I discovered Drupal, not because it was better, but because, even where it wasn't, the rate of growth of Drupal meant that it soon would be. The rate at which Drupal is developed far outstrips anything that all but the very largest companies can sustain. I would say that I'm a CMS veteran of contemporary CMSs. Whatever that means.

The issues are critical because they are blockers to releasing a polished product. There will be no fundamental API changes. And chances are that most of these won't affect you in any way if you build a site using Drupal. Drupal 7 is already being used on production sites - some of them quite major - but we can't yet recommend you use it. The list of issues at the moment is:

• "Do not enable the management menu by default". This is about removing some on-screen duplication that wastes pixels.
• "Cannot install on PHP 5.3.2". I have a working version on 5.3.2. This is a false positive - something to do with the reporters set up. D7 needs PHP PDO extension, which is part of the default PHP. Most likely not enabled for the person who reported the bug.
• "Links are needlessly unable to fully participate in D7 AJAX framework" Making sure that the Ajax framework is orthogonal with respect to content types, I think.
• "Security harden stream wrappers by defaulting them as remote" We worry about security. This would subject streams to the level of scrutiny that remote data is subject to. If allow_url_include in php.ini is false, then Drupal should not allow remote streams as content.
• "Skip to main content" link doesn't work correctly in the overlay" We are screen-reader friendly by default. We also have a new mode of operation - overlaying a screen with things that need to be done before you can continue with your original task. This should work for screen readers too, so the link needs to point to the 'topmost' content.
• "All fields are hidden after the administrator newly configures a view mode to not use 'default' display" Oops! It shouldn't be possible to get into a state where critical stuff seemingly disappears. A feature that's central to D7 is fields - that is, all content is extensible with new fields. It should always be possible to set fields to display correctly.
• "Some schema code incorrectly rely on the generic type instead of the engine-specific type" D7 supports storing data in different storage formats, including several database engines. There's some small inconsistency; the schema (and things that manipulate it) should use the column types specific to a particular engine - for instance it's AUTO_INCREMENT in MySQL, but Serial in PostgreSQL, and different rules apply to how each is used.
• "Clean-up the upgrade path: UPGRADE.txt" If you are upgrading from Drupal 6, we'd like it to be a smooth ride.
• "Screen reader users need a clear, quick way to disable the overlay". Not all the screen readers will like the overlay system, so there should be a ridiculously easy way to stop using overlays, which is immediately accessible from a screen reader. "Allow dashboard to limit available blocks" Users can configure their own dashboard, but not everything that is displayable makes sense on the dashboard page, so it would be sensible to limit what can be displayed. The User Interface for this is being tested.

And I'd like to take this opportunity to advertise - Drupalcon Chicago will be in March 2011. And if you are in Europe, I have it on reasonably good authority that you can look forward to the announcement of the location of the Autumn conference either later this week or next week. And this week we moved the Drupal.org site redesign live.

I think I can claim to be a real programmer having designed & written shrinkwrap software, built in-house corporate software, developed embedded control software, made web apps used by thousands of users daily, written several frameworks, all for software running on a diverse range of hardware, from microcontrollers through to mainframes and most things in between, in a pretty wide variety of languages, from systems languages like C, through to dynamic languages like PHP and Ruby, and all the usual suspects in between.

In my opinion Drupal core is well written. Tons of thought goes into it, with lots of smart, experienced people weighing in on the architectures and reviewing the code. It's (far) better than most closed source apps I've had the pleasure of working with.

This is also true of the top, say 10 to 20% of non-core modules. The ones that no serious site is without. The quality of the rest varies hugely, from bad, through to awesomely good.

Drupal is not alone here. This is a problem with almost all except the simplest CMSs.

The problem is one of complexity: when you are doing one thing, it's easy to optimize it into one SQL query. But when you have a modular system, you want each module to work independently as much as possible because you want to avoid dependency hell, and you want to minimize module interaction because that will lead to side-effect bugs which are difficult to track down. The architecture choice that most CMSs make in order to foster sustainable growth is that each module gets to handle its own data. But that means that you don't get optmized database queries - in fact you are almost certainly guaranteed that you will have multiple reads of the same data, as different modules work on that data.

Which is why all mature CMSs also have caching strategies. They typically cache the output of whole pages if pages do not differ by user, and partial pages where they do, constructing the page from the appropriate parts. They also usually have in-memory caching strategies to avoid repeated db reads.

Better CMS's have variable caching strategies, allowing you to store pages in memory, in files and in database as appropriate. Drupal has modules for all of these strategies and also works well with Varnish, a caching proxy/accelerator.

My 4.5 modules worked with 4.6 with no changes. My 4.6 modules worked with 4.7 with no changes. My 4.7 modules worked with 5 with very minor changes. My 5 modules worked with 6 with very small changes. I haven't tried porting any 6 modules to 7 yet, but looking at the list of modules that already support 7, I'm not quivering with fright at the prospect.

The API is not guaranteed not to change, but a lot of people work hard to make sure that the change is evolutionary and the thousands of automated tests help to make sure that

I seriously object to my comments being marked as troll! This was not trolling. It's a serious point. It's hardly reasonable to say that there's one rule if it happens in the US, and another for everywhere else. Yes, I know that there were/are wars in both places, but there _have_ been deaths that were murder rather than battlefield deaths, and US citizens have not been held to account in courts of the countries where the actions took place.

http://www.huffingtonpost.com/2010/04/05/wikileaks-exposes-video-o_n_525569.html
http://edition.cnn.com/2009/WORLD/meast/05/12/iraq.soldiers.killed/
http://www.nytimes.com/2010/01/08/world/asia/08blackwater.html

Which is to say that there is no absolute rule that a person should be tried in the jurisdiction of the place under which the action had effect.

US citizens have been guilty of murder in Iraq and Afghanistan, and yet we do not see them on trial there. Why not?

The lesson I take from this is that it's not a rule that a crime is tried in the place in which it was committed.

You are absolutely right.

Except that there was a recent report that terahertz radiation was resonating DNA and partially unzipping it, creating 'bubbles' of unzipped regions. I haven't seen any corroboration of this, so it may not be proven, but it's certainly worth a pause because it's not an effect that had been predicted. Now mm waves are not sub-millimeter waves, but they are adjacent in the spectrum, and it's this sort of thing that we should worry about.

Probably there's no cause for concern, but again - when the potential impact is very high, though the risk is low, we should be taking great care.

The health effects of millimeter wave scanning are what we should be worried about - there's an unknown risk but a high possible impact: imagine if in 10 years time millions of people start developing melanomas as a result of being scanned.

The x-ray backscatter machines are much less worrying; we've had 100(?) years of experience with X-rays and we understand what x-rays can do to DNA.

But we have very little experience of mm level radiation.

What I've seen in the press is cheerleading. 'Experts say there is little cause to worry' with unknown experts talking in vague generalities. I've seen articles saying that the energy involved is less than the energy emitted by a cell-phone. That may well be the case, but it's not in the cell-phone spectrum, and even a little energy in the wrong place can do a lot of damage. Just see what a match can do to a pile of paper*.

Of course it's impossible to completely prove something is safe. But I don't think we don't have empirical evidence that it's safe. Or at least - I've not seen it.

I absolutely have not made an exhaustive search for literature on the health effects of mm radiation, and I'm not an expert. In the brief searches I have made I have seen that there's a lot of scare-noise based on what seems like only a few sources which imo are not applicable. What I don't see is a long list of studies. And even more striking is that that non-existent list of studies is not full of papers saying 'we found no observable effects'**.

But I have found that it's possible to cook bacteria with mm waves! Maybe this is a hint that there's a potential problem. And in the diagrams of atmospheric absorption of radiation that I've looked at, for example, it looks like mm waves are mostly absorbed, which suggests that we'd have little evolved defense to mm wave damage.

What I'd really like to see is a series of mm wave experts saying things like 'we've studied the health effects of mm wave scanners for 10 years now, and I'd have no qualms about subjecting my three month old baby to a scan because I'm confident that there's no health risk associated.'

* Pedants: yes, I know the energies involved are different orders of magnitude - it's a metaphor.

** It's quite possible I was looking in the wrong place. I'd be very pleased to see a detailed response with a link to this list.

Didn't American's fight a war of independence because of this? Maybe American politicians have forgotten, Someone seems to think that it's ok to make law without reference to the people it affect.

For the people who are helped by music when programming:

I listen to a pretty wide range of music, from classical through to current pop, with a lot of stuff inbetween. I find that some music that I like helps me to program, but other music, which I also like hinders me.

I work better with rhythmically strong music - a heavy beat without deep complexity. Music which encourages me to pay attention to lyrics is bad, but that might just be that familiarity is a requirement so as not to get sidetracked into _listening_ to the music.

The best music I know of for taking me to the zone is Talking Heads. And their best programming album of all for me is Stop Making Sense, which I must have listened to thousands of times.

It's starting to get repetitive. I would like some new programming music: what music helps you most?