I think you failed to notice the shill posting that I was responding to. I didn't bring up .NET to bash it, rather to respond to someone who was trying to compare it to RedHat which is a system that .NET clearly doesn't approach in any of maturity, flexibility or stability.

That's hardly a recommendation. There are hundreds of thousands of projects that have been based on PHP. There are probably millions of such projects which are based on excels. The fact is that almost every problem system has lots of "success" stories. Many of those would have been much more successful if they chose a less problematic system but that doesn't mean that they aren't in their own terms successful.

Look at some key criteria for choosing a good system

• Multiple competing suppliers each of which are approximately equivalent in ability.
• Open active support market without specific vendor bias
• Long record of successful projects
• Full source code availablility
• Open standards and standardization
• Lack of proprietary interests able to close down development on a whim
• interoperability and ability to migrate solutions both out and in of the chosen system
• Supported by organisations with a reputation for honesty and reliability

When people choose .NET, they are choosing a system which is locked into one vendor. They are choosing a system which has a record of a number of serious disasters and lack of performance at higher system demand levels. Most of all, they are choosing a system from a vendor which is more willing to pay shills to turn up on forums astroturfing their success than they are willing to solve the underlying problems of their system. This doesn't guarantee failure any more than choosing a solid system guarantees success. However, it can be a single decision point which causes some given project to fail.

Compare the decision to choose .NET to the decision to choose SQL or C or even Java. Even though they have their problems, each of those systems has multiple suppliers and it will be possible, if for example your Java supplier has a bad security record, to migrate to a different one which is more responsive. That gives a more solid environment and a better chance of long term success.

Failing to read the article is one thing. Failing to read the summary another. Failing to read the comment you are responding to is worse, but somewhat traditional. However, failing to read the quote you yourself choose from the comment you are responing to is... is ... uh special.

I'm not saying that agile can't fail. I'm saying that repeated early regular failure is a key part of agile. You are supposed to deliver "working" software all the time. Early on in the project that software may have very limited features and value, however it is supposed to always add something of value to the users life. If you fail to do that for a period of several months then your project has already failed and should be cancelled for a cost which cannot be more than a few tens of kilo pounds.

In order to fail and cost Billions they must have been a very long way from doing agile development.

The agile word they say is "Working software". "Runs and passes some tests" does not match my meaning of working software.

I see this a bit differently. I take the "working software" bit as it is. I think this means that agile projects are mostly impossible for most things other than incremental software development of changes to pre-existing useful systems and that 90% of projects claiming to be "agile" actually aren't. However, more or less it seems to me we agree. The idea of delivering something that "runs and passes some tests" does not represent "inherent value" as you call it. I don't believe that software is working unless it delivers what you call "inherent value".

This is not an area where it is possible to give "a cite" since there are whole genres of literature covering this topic alone. If you haven't read ."The Mythical Man Month" (please note; the book has a Wikipedia page; this is not an Amazon link) then that is where you should start. Not because it is complete, not because it is up to date, but because it will make you realise that the problems of today's IT were already fully described in the '70s and that our advances in the last decades have been incremental and mostly small.

Bridges do not work the same as software development. Whilst each individual bridge has some differences in environment and location, in general you are just repeating a structure which has already been build long ago. In sofware the equivalent of building a new bridge is the "cp -ar" command. Agile is mostly designed to address development of new features on pre-existing software which is completely different.

There are many possible reasons for failure.

• you are stupid
• you base your product on .NET
• you fail to start a testing program
• you are the British government
• bad luck.

Just because the failure of one project is caused by .NET does not mean that a project not based on .NET is going to succeed. In fact, traditionally 80% of software projects fail.

This project is clearly failing for the second from last reason. It is also failing because it is not an "agile project". An "agile" project cannot fail and cost Billions because it must always deliver runnable software with a maximum of a few weeks delay if you use some "semi agile" process like scrum or immediately any point if you use some true agile process.

Once you deviate from "Working software" for more than a couple of sprints (everybody can make a mistake) then you are no longer doing agile. I have seen so many "agile" projects which seem to define "Working" as meaning something like "a prototype which would never work at full scale" and so they have never addressed the major problems of their class of system.

If they are "billions" of pounds down whilst doing agile, then they should have already delivered plenty of working systems and have hundreds of happy users. In this case they are a "success" even if they were a bit slower and more expensive than some other projects. If, however, they really haven't delivered anything then what they were doing was an unplanned disaster using "agile" as an excuse for not having a proper plan.

Whilst I know that the "waterfall" method of development is famed for it's failures. Whilst I know that those failures are spectacular and huge. I really don't see how you deliver, for example, 5% of a working mobile phone network. You just have to have a big interlocked plan with a working phone, transmitter, backend, management and interconnection all planned together. I don't believe that such a thing can be done in a true "agile" way and pretending that you are doing it in an agile way is a dangerous fantasy. Only once you have a working network can you start to improve it in Agile increments.

Profit. This is the most profitable way to put the news.

Actually, as a person who has previously slammed you for your trolling, can I just say that this is about the most insightful criticism you have made of Linux and you are very largely right. Let me also give you the hint you need to pass your test.

1. The hardware is Red Hat certified (from five years ago)
2. The OS you use is the latest stable Red Hat from five years ago.
3. You are only allowed to change to a more recent major release if the hardware is also certified on the new release (though in real life this will almost always work too - Red Hat keep old hardware in their test suites)

This is a real practical problem for users. The correct solution is properly supported dedicated Linux hardware.

Ah thanks; it seems limited means "no longer breaks OSM, so you can use it safely without breaking things". That's exactly the minimum needed. I guess I have to download and try it....

Lack of Android offline support is one of the biggest barriers I have to editing.

What is the biggest shame is that the most functional Android OSM editor seems to break relations so apparently isn't good to use. Does anyone know more about this? Any idea how to fix it?

you what?

Installers for GIMP for Windows

You say that; and I do believe you that that is what they will say too. However, their actions speak louder than their words, and when they broadcast their every little move and argument to the world, I think that you can see that in fact these people secretly like these applications.

No; just as an example to show that the design doesn't have to emphasise the camera bit. This is a Google choice for now and I expect that they would change it for the next generation allowing in anyone else who made glasses.

Right, but those don't have any applications. Think:

• Head up display for runers; tells you how well you are doing; integrates with your heart monitoring; plans a route that will stretch you today.
• can't remember that cute girl's name. Google can. Plus, if you link into her facebook profile you will get to know whether she's dating or not. And who. And whether this is a good moment when they might just have had an argument.
• bargain/no bargain. about to buy something? Get a warning if you can get it 5% cheaper within 100 metres.

Most of these are scary/downright creepy for me. But then I'm not a great facebook lover either. In any case you can't claim they wouldn't add to most people's lives. In fact I think I'm no a roll here.

• wanna buy a girl some underwear? Have google glasses size her up. Check whether anyone else has registered her sizes
• standard; boring; watch porn videos sure nobody else can see you doing it.
• ultra creepy: most naked picture available of anyone you see off the internet
• friend's reviews of anyone you meet; judge people before they judge you

My only hope is that Google has some patents on this because "facebook glasses" would be terrible.

And yet this is more or less the same thing they said about mobile phones in the early 80's. No more than a few k needed in the world or something similarly stupid.

Someone explain to me why you can't do the same technology on mirrored glasses in a way that nobody will notice the camera? If I look on Google for "camera sunglasses" most of the results are dorky, but some begin to look quite cool (second photo; warning there may be some flash media my browser ignored).

There also seem to be a bunch of ideas for holographic contact lenses. Google glass is more of a technology demonstrator and beginning of something bigger. I don't see why it can't take off long term if they can do something useful with it.

Now if only someone could come up with a version where we could control the privacy a bit.

I think for startups/small companies, this may well still be true. iOS users still tend to have more apps and pay more for them than Android users. In the large corporate world, though, that's already changed long ago. There are two fundamental applications here:

• provide easier access to something I already had (e.g. BBC android app makes access to their site better)
• interlink with a product idea (e.g. barcode-scan -> product-id -> you already know the history of the wing component).

Sometimes of course a combination of the two (provide a more secure access to my customer's bank accounts). In both cases the question is not "where will I get the most money from selling the app". The questions are "where can I get the largest audience to access my system", "which BYOD devices will my users insist on using" and occasionally "how can I avoid having to distribute special client hardware just for my app". In this case the order is Android, then iOS then, in certain special corporate environments possibly even Blackberry.

In these cases the mobile devices are typically supplementing web pages or replacing legacy Windows clients where something more available, more modern or more secure is needed.

As long as exactly the same thing happens to each biologically, then it would be discrimination. If there were some difference; say the man actually gave birth to the child and had to recover whilst the woman just supported him afterwards; then you might expect a difference. However I would have thought that the man would need more time in that case.