Here's one counter argument: the Blackberry. It's basically a smartphone. The missing piece was not networks, price, features, etc. It was focus. The Blackberry demonstrates how to make a successful smartphone: you package useful technology in a usable and simple form. It does not have to be cheap.
I'm also using a Nokia E70, my third 'seagull' Nokia. And to my own surprise, I'm surfing the net with it. I bought it because I like writing notes on the fly. But it has built-in wifi, so gets connected whenever I can find a hotspot. And I've gotten it working with Orange UK's 1UKP/day unlimited GPRS internet. It's slow but acceptable. Gmail provides a really efficient mobile mail interface and a mobile map application that works well enough to let me find my way around big cities like London.
What's happening is that the "smartphone" market, pushed by telcos and self-styled gurus like Rheingold, is in fact coming to life, because after the hype and the WAP and the other technology-driven failures, we are entering the period of demand-driven innovation. I can see the smartphone market fragmenting into several clear niches, which is a sign that it's maturing:
- portable text/email (Blackberry)
- mobile Microsoft (that's a niche all in itself)
- general-purpose mobile computers (wifi, voip, Symbian)
- dumb media phones (camera, MP3)
Telco's are particularly bad for trying to push technology-driven products that they believe will make them money but which no-one wants because they're too complex. It takes other manufacturers to build products on top of those technologies, and since only a minority of products ever make it to market, this is why we have such a gap between new communications technologies being announced, and people actually using them.
In simple terms: I don't want GPRS, I want mobile gmail and google maps.
I never liked reading Rheingold because he always said the most obvious things using the most buzzwords possible. Very tiring, like one long endless Wired article.
The future is always easy to predict, only the details seems to go wrong.
Yes, people will continue to get more and more interconnected, as every phone turns into a full-on mobile computer/camera complete with infinite memory, as social life moves more and more into the virtual world. Yes, the old patterns of mass movement to work will end as oil continues to cost more and more. No, electric cars won't solve anything. Yes, Japan will produce life-like robots but it'll be small firms in the US and France that produce the bots that finally make it into every home, and they'll be toys, tools, avatars, and for some people, friends. Yes, nuclear power will make a big comeback. No, it won't power our cars. Yes, China and India are going to become information superpowers. No, they won't toppled the US from its throne. Yes, there will be a lot of war in the future, and a lot of it will be fragmented, because just as mobile phones disrupt the traditional social forms, they also disrupt fighting. "Smart armies"? Give them all Blackberries. Yes, there will be a nuclear terrorist attack. No, it won't be in New York or Washington, but probably in Delhi or Tehran. Yes, Linux will take Windows off the desktop, but really not in the way you'd expect. No, no-one will care when it happens. Yes, there will be a black US president one day. No, she won't be a republican.
The future is not so hard to predict - just look at all the domains where people are competing hardest to innovate, then assume ten years of progress, slower than you'd expect but more profound than you'd believe possible, and then see how people would use those changes to improve and simplify their lives.
To be very clear, "he would like the Christian ideals further forced upon all in the US, even non-Christians" for the simple reason that each of these issues has been carefully selected to act as a wedge issue, dividing the population into polarised for-and-against camps that are incapable of compromise, because such a divided country is unable to get enough unity to act on the real issues.
It's quite remarkable how so many issues trumpted by the administration actually have nothing to do with Christian beliefs at all. Immigrant rights, for instance. It's a classic case of a situation that can be tolerated without too much discussion, but by forcing the discussion on the nation, the administration splits the American people into, what was it, FOUR? camps of opinion.
The US is not a Christian-run state. It is not a theocracy but a kleptocracy. It is a state run by gangsters. They are well-dressed, well-educated, well-connected, modern, slick, and very powerful gangsters, but they are gangsters nonetheless, and they use the instruments of the state for personal and collective profit just like any tin-pot dictator.
Congress will never impeach Bush because Congress was corrupted and castrated a long time ago. Gerrymandering has turned Congress into a cartel of power that removes competition and the need to deliver value to the citizen.
A tomato seed is, as astute readers of the last embodiment of this story will remember, almost exactly the same size as a grain of rice.
Presumably HP is now using the "use food as units of measurement and the hungry masses will lap up your products" theory of mass marketing.
Coming soon:
- a laptop the size of a pizza calzone!
- a new PDA the size of a 8-oz packet of California sun-dried raisins!
- ink cartridges the size of a small tin of caviar (and more expensive!)
- a secure USB drive the size of a sun-dried tomato!...
It's difficult to see what these chips can do that smartcards, mini flash chips, and so on can't do... I think the main drivers are going to be cost and size and accessibility to ordinary developers.
But it could be fun to build memory into ordinary objects. You would not need any electrical contacts. All you need is a universal reader that can presumably be cheaply added to PDA, notebooks, etc. On top of that it'd be easy to write software that reads and writes these to do interesting things:
- smart business cards and ID cards
- smart locks and other innovative security systems
- data collection systems (e.g. cardiac monitors, sensors, etc.)
- contactless public data sources: smart signposts in cities (touch your mobile phone to get a map), etc.
It may be that the wireless aspects eventually become much more useful than the memory itself.
But on the whole I think this technology will not have any market traction until it can be exploited by the adult entertainment industry.
Yes, the problem of "send this document to random people" is a real issue.
However, since OpenOffice has had a "create PDF" feature for ages, and since it produces really elegant PDFs, this is a solved problem.
I much prefer sending PDFs to editable documents because it prevents random modifications. When people do have to collaborate on writing a document, they can install OOo without much effort, and it is easy to learn, despite not being MS Office.
I've seen many people learn to use OpenOffice and the suggestion that its interface is hard to use is untrue. I've literally given non-technical people (office admins, sales and marketing people) a Linux box with OpenOffice and said, "go for it", and they've produced documents and spreadsheets and presentations without asking anything after, "what printer do I use".
PDFs are the answer to distributing prepared documents. PDF or HTML works fine for presentations. And if you *really* need to send someone an MS-Office format document, you use the "Save as" function to create it.
And this model has let us use OO for 4-5 years in a world where almost all of our clients use MS-Office. It works.
I'm speculating that bacteria, in colonies, may be responsible for gold nuggets, at least in some cases. There are other cases of bacteria creating mineral concentrations (like stromatolites). Bacterial activity in hot rocks and hot springs is well known; gold is often found with other elements that some bacteria like, such as sulphur. Concentrations of gold don't seem to fit a natural process, I'd expect to see minerals dispersed within strata, not concentrated into pure blobs.
OK, bizarre theory, I know. Anyhow, I just did some googling and found this.
"Biogenicity of gold- and silver-bearing siliceous sinters forming in hot (75C) anaerobic spring-waters..."
The question people need to ask is not, "why should I switch to OpenOffice", but "what is the killer feature in MS Office that I absolutely need?" Do you really need to be able to run Word on a PDA? Do you need a smooth integration between Office and Exchange? Perhaps, but it's worth reevaluating.
If the cost-benefit ratio is not strong enough to make the cost and insecurity worthwhile, abandon MS Office and use OOo. For most people it's a lot less painful than it sounds. I've even seen OOo spread like a fashion in some teams that were 100% Microsoft, as they discovered that OOo does actually work very nicely, and as they started using ODF as a standard in place of Microsoft's own formats. We did this a long time ago... we get a consistent set of tools on Windows and Linux, and documents that now conform to a global standard and which I know will still be readable in 20 years' time, whatever software or platform I'm using.
There are many alternative office suites and OOo has its flaws, mainly it's a bit slow, but it has a feature set that hits 100% of what we've used - for documents, spreadsheets, simple graphics, and presentations - for years. And I don't get the feeling, when I run it, that I'm running a code base that has hundreds of undocumented backdoors, caused deliberately, or accidentally.
There's no obvious mechanism by which gold should spontaneously form into nuggets in the wild; I don't really believe that gold particles in the soil magically find their way together by some mystical process of attraction.
Is it not more likely that these bacteria have been excreting gold as a matter of habit for hundreds of millions of years, and that gold nuggets are in fact the toilet pits of huge bacterial colonies from ages past? Perhaps the bacteria feed off sulphur or some other element that's mixed with the gold...
It does not matter how much these processors cost today, nor whether AMD's 4x4 is real or a maketing ploy.
What matters is that AMD has captured sufficient marketshare over the last years to become a real competitor to Intel. Opterons have become the CPU of choice for large servers, the niche that Itanium was meant to capture.
Now Intel's comeback means we're seeing the start of a new growth of CPU power, this time into multi-core land, a nice solid metric on which to compete. You can fudge the Ghz but you can't really fudge the number of cores. This means we have the perfect conditions for an explosion of growth, until the numbers get into meaningless territory. Within 3-4 years, common desktops will have 8 to 16 cores, and high-end workstations will have 128 or more.
I'm just very glad my company made the move to writing multithreaded code so we can get the best from this new landscape.
My company designed high-performance mono-process servers (portable ones too) starting in 1995, using event-driven virtual threads and state-machine frameworks. Very elegant, very fast, and really easy programming. The Xitami web server was one example - I remember seeing a Win95 system with Xitami survive a slashdotting (it was serving static pages but that was still impressive.)
We worked in C, because we needed guaranteed low latencies.
In 2004 we decided to rebuild these frameworks to handle OS multithreading. The reason was that on a single CPU we could not get the performance we needed, and the choice was either to use clusters, or multithreading.
We continued to work in C. C, and C++ are really nasty for multithreading because the languages have zero support for concurrency. You need to handle everything yourself, and most threading errors are extremely hard to detect.
It cost us about 10 times more to write our software as multithreaded code than using virtualised threads and we had to build whole reference management frameworks to ensure that threads could share data safely.
We did keep virtual threading, in fact, but virtual threads get handled by a pool of OS threads. Using 1 OS thread per connection is not scalable beyond a few hundred threads. Modern Linux kernels handle lots of threads but we also target Solaris, and Windows with the same code. So we use two virtual threads per connection, for full-duplex traffic, and we design most of the major server components as threaded objects, which are asynchronous event-driven objects.
Doing multithreading in C is a *huge* work. C++ has frameworks like ACE that help a lot.
But there is a performance gain. Our software is a messaging server (implementing the AMQP draft standard). We maxed out at around 55,000 messages per second using a pure virtual-threaded model. Very efficient code. On a single CPU the multithreaded code hits 35,000 messages per second. With two CPUs we're back at 55k, and with 4 dual-core Opterons we're at 120k-150k and higher. (Our software runs a massive trading application that processes 1.5bn messages per day). We still need to improve some of the low-level locking functions to use lock-free mechanisms, and we max out a gigabit network. It is difficult to find machines powerful enough to really stress test the software.
Without very robust frameworks, I'd never attempt such a project. As it was, we paid a lot for the extra performance. Our frameworks will eventually be released as free software, along with the middleware server.
Interestingly, a very similar application written in Java 1.5 and using the BEA runtime gets similar performance to ours. Java's threading is so good that I'd be hesitant to chose C on the basis of performance again. I'm not sure whether ACE can reach the levels of performance we need; 100k messages per second is extreme.
Other questions that are very important to ask:
- The number of clients you expect to connect at once. If it's less than 500 you can probably use one or two OS threads per connection. If it's more you need to virtualise connections or share your OS threads.
- The footprint. If you don't care, then I'd advise using Java. If you want a native Linux service, consider C++ and ACE. If you really want to write multithreaded C code, and don't have a full toolkit, consider seeing a doctor.
When it comes to the future, clearly multiple cores are the way we're heading. This was clear two years ago, and was the main reason we bit the bullet and chose to write our software multithreaded rather than using a clustering model. It seemed clear to me that within a decade, systems would have 32, 64, 128 cores, and software that could take advantage of this would survive for longer. Clustering is not as powerful an abstraction as multithreading.
Well, obviously after the War on Terrr, we can expect a War on Witches (with televised burnings on Fox News), followed by a War on Evil (and I know my neighbour must be a devil worshipper), followed by a War on Youth, after which there will be no-one left to consume drugs, giving us a neat conclusion to the War on Drugs.
When all those wars are complete, we can expect a War on Wars, which will involve the peaceful use of tactical nuclear weaponry on all those who remain after the subcultures have been eliminated.
When it comes down to basics, humanity is just too unreliable and messy to be trusted with its own fate.
Very good indeed. Did you collect these yourself? If so, do you want a job?
I'll add a few more of my own rules:
- Make sure you're in total control of your toolset and improve it systematically
- Do not take the clients' deadlines literally - first accept the project, then renegotiate the deadline.
- Don't implement anything that is not going to be used immediately.
- Design your software around interfaces so you can make massive changes cheaply.
- Document the interfaces perfectly, but don't document code (see next point).
- Be fanatical about the readability of code.
- Push all QC, packaging, and issue management through a single person.
- Build regression testing into the build process.
- When debugging a problem, never ask, "how come it works on my box?"
- If some code is too complex to understand on a Monday morning before coffee, redesign it.
- Never add new code while there are still bugs in the existing code.
It does not work. What's obvious today was often not obvious when the patent was filed, and this fact means most courts ignore the test of obviousness altogether.
The only real way to exclude software patents is, stunningly, to ban patents on software. No exceptions, no ifs, no buts. This is what the European Patent Convention does, in its so-called "subject matter" rule.
Software patents represent a hijacking of the IT industry by lawyers and patent specialists. It's a profitable short-term extraction of value, much like chopping down old timber. And it has only one conclusion, the end of innovation for about two decades, while the world scratches its head and finally realises, "boy that was a *stupid* idea".
To a large extent you can see software patents as a kind of disease, spreading out from IBM's original sinister legal virus labs, across weaker nations first and now into the EU and Asia, and eventually it will infect everyone, kill off a large part of the ecology, and leave a little bit behind to regrow.
The future of IT is lots of lawsuits, with diminishing returns. No new standards, and fewer and fewer new markets, as the technology of patents gets sharper. Within ten years you won't be able to do business without paying a patent fee and small independent inventors (99% of inventors) will be excluded. The state will eventually take over all patents to enable some kind of work to go ahead, and existing patent holders will receive part of the patent tax.
Or, alternatively, we will stop software patents dead in their tracks in Europe, this year, and then start the process of killing off these monsters in the USA as well.
It's probably a good time to support a group like the FFII which is fighting these battles.
Software patents are granted by the tens of thousands in Europe by the EPO and it's just national courts that tend (but not always) to reject them. Telecoms patents have tended to be upheld by courts much more often because they have (superficially) a industrial character that makes them different from 'pure software' patents. This is the rationale. Of course GSM is pure software.
Simply do a Google search for "gsm patent", it's pretty clear the impact these patents have, which is mainly lawsuits.
The GSM standard is owned much the same way the MPEG standard is owned, and licensed under the same kind of 'reasonable and non-discriminatory' terms. It is a very heavily patented standard and (IMO) for this reason has been very slow to evolve once it was defined.
Of course the people are key to any business, not just software, and not just open source. A large part of building a sustainable business is to solve this problem and build structures that survive change. Sustainable software is built in layers so that no single team determines the life of the whole. Individual projects will die if their key developers leave but the whole can keep running.
The article seems mainly aimed at VCs involved in the new boom in Silicon Valley - open source - and is warning them, "buy the developers, not the software".
There are a number of inescapable flaws in the software patent 'system'; this is one of them...
1. Owning patents does not protect you from a non-producing entity (NPE, a firm that owns patents but makes nothing, so infringes nothing and cannot be sued).
2. It is impossible to define new software standards that cannot be undercut and held hostage by NPEs.
3. It is impossible to build new software products that cannot be undercut and held hostage by NPEs.
4. It is impossible to define software patents that cannot be undercut by other software patents. I.e. if Microsoft had filed and owned this particular patent, it'd not stop an NPE making another claim that undercut this claim.
The irony (sweet or not) is that it is those firms lobbying hardest for wider and stronger software patents (IBM, Microsoft, Nokia, Sony, Siemens, SAP) which end up paying the biggest bills. It's true that software patents provide temporary and lucrative monopolies - see the GSM market, based on some of the heaviest-patented standards ever - but in the end the patent trolls will always find a way to turn it around.
Sadly large IT firms are deeply schizophrenic about software patents, with patent policy firmly in the hands of the lawyers, not the engineers, and it will take more than a few lawsuits to change this. (A lawsuit that does not kill a firm just makes its lawyers stronger.)
If you took a look at the BDB source code, you're understand immediately why forking this is not an option unless you happen to have hired the developers.
The software itself, is simply an expression. The user of the patented idea is the person using the software. Today, most litigation is aimed at product producers because these have the money. But if one was to exclude (e.g.) FOSS from patent claims, then the patent ambush would simply shift onto large-scale software users.
It is difficult to see how the fact that one is using FOSS as compared to commercial software, to do the infringing, would change anything. If you are using someone's patented idea, they own you.
And BTW, Paul Graham is wrong when he says, "if you are against software patents, you are against all patents".
All patents have the potential for evil. But software patents are guaranteed to do evil.
Question: why are there so few new software standards coming out and why do they take so much longer to produce? Answer: because every new software standard is a recipe for patent ambush. Implemented, use it, or use products based on it, and you will, if you make money, be sued.
Yes, software patents are evil because in the name of promoting innovation in a field, they actively destroy it.
Hmmm, if I claim a method (which is the basis for software patents), then I can sue anyone who uses this method without my permission.
Yes, I can sue someone who uses software that implements that method, because the user is using my method. Yes, I can also sue the people who distributed or wrote the software, because they contributed to the infringement.
This is one of the things that makes patents on methods/algorithms/language special. They do not simply cover the production of products, they cover their actual use.
I've never heard of a patent lawsuit where the defendant was allowed to inspect the plaintiff's source code for other random violations. It probably made sense when you made this up but it's not the way the world works.
Take random huge Linux user, e.g. a large bank that runs 70% of its servers on Linux and is migrating the other 30% as fast as it can. Now produce a patent with 17 claims. Now if large bank cannot disprove each and every one of these 17 claims, they must stop using Linux immediately, or pay whatever the patent holder asks. It is up to the defendant to break the patent claims.
Microsoft will not enforce their patents, if they have any that they think undercut Linux, not because there is any real defense (there is not) but because they will wait until Linux is well-enough established that the patent negotations will go smoothly.
Patent licenses are a large planned revenue stream for Microsoft, and they are only possible when there is a large captive public of infringers who keep infringing. Thus, Linux growth is actually good for Microsoft, seen from this point of view.
Where the whole lovely effice collapses is when we see that for ever dollar MSFT can hope to earn from licensing "their" IP in this way, they will spend ten times that fighting and settling patent ambushes.
Patent holders have a huge power. Look at NTP's extortion of RIM. Microsoft think they can use this power to extort future Linux users. But it's a very risky gamble because MSFT are a lovely target for extortion themselves.
I'm glad to see that the Microsoft astroturfers are out in force here.
Let's review the game plan. The EU has (rightly) condemned Microsoft of illegal monopoly practices and is attempting to force Microsoft to behave in a way that creates a more level playing field. This is not about EU vs. US; Microsoft has also been convicted of monopolist behaviour in the US, only it's managed to avoid any penalties for that.
Now, the EU is asking for Microsoft to stop working to create barriers to interoperability. This is a valid approach. Microsoft can make whatever software it likes but it cannot deliberately break interoperability. In case you're wondering why this matters, it's thanks to interoperability that the Internet even exists. Microsoft would like to make products like Samba useless.
It is trying to inject software patents into the picture, by claiming that its standards are "patented". Thus, any open source implementation would infringe.
As an alternative, Microsoft suggests that people can license its source code. Note that this is something MS has been offering to random partners for years, so it's hardly a new step. When asked what the price and conditions for such a license would be, Microsoft said, "we are willing to negotiate".
In other words, Microsoft has not budged an inch and is instead preparing the ground for patenting its interfaces in the EU.
Now we come to the crux of the matter: Microsoft, far from making any concession with respect to the anti-trust accusations, is instead laying the groundwork for an attack on open source competition! This is so blatant and so hostile to the interests of the market that it's quite amazing the Commission is still talking to them, instead of simply levying an appropriate fine.
Open standards are vital to competition, and Microsoft's attempts to quash competition by placing patent bombs into its interfaces, while happily exploiting every other standard on the market, deserve all the abuse they get.
So long as the USPTO has not ruled, they can blackmail RIM. They just need to get the court to agree to shutdown RIM for one day, to win the huge amounts of money they are seeking. The USPTO can invalidate whatever patents they like after that, it's not going to affect the deal they strike.
This is a perfect case of patent agression. Experts in the legal process extorting huge amounts from innovators. Welcome to the way business is going to be run for the next decades.
Slashdot Mirror
Very good article from the Reg.
Here's one counter argument: the Blackberry. It's basically a smartphone. The missing piece was not networks, price, features, etc. It was focus. The Blackberry demonstrates how to make a successful smartphone: you package useful technology in a usable and simple form. It does not have to be cheap.
I'm also using a Nokia E70, my third 'seagull' Nokia. And to my own surprise, I'm surfing the net with it. I bought it because I like writing notes on the fly. But it has built-in wifi, so gets connected whenever I can find a hotspot. And I've gotten it working with Orange UK's 1UKP/day unlimited GPRS internet. It's slow but acceptable. Gmail provides a really efficient mobile mail interface and a mobile map application that works well enough to let me find my way around big cities like London.
What's happening is that the "smartphone" market, pushed by telcos and self-styled gurus like Rheingold, is in fact coming to life, because after the hype and the WAP and the other technology-driven failures, we are entering the period of demand-driven innovation. I can see the smartphone market fragmenting into several clear niches, which is a sign that it's maturing:
- portable text/email (Blackberry)
- mobile Microsoft (that's a niche all in itself)
- general-purpose mobile computers (wifi, voip, Symbian)
- dumb media phones (camera, MP3)
Telco's are particularly bad for trying to push technology-driven products that they believe will make them money but which no-one wants because they're too complex. It takes other manufacturers to build products on top of those technologies, and since only a minority of products ever make it to market, this is why we have such a gap between new communications technologies being announced, and people actually using them.
In simple terms: I don't want GPRS, I want mobile gmail and google maps.
I never liked reading Rheingold because he always said the most obvious things using the most buzzwords possible. Very tiring, like one long endless Wired article.
The future is always easy to predict, only the details seems to go wrong.
Yes, people will continue to get more and more interconnected, as every phone turns into a full-on mobile computer/camera complete with infinite memory, as social life moves more and more into the virtual world. Yes, the old patterns of mass movement to work will end as oil continues to cost more and more. No, electric cars won't solve anything. Yes, Japan will produce life-like robots but it'll be small firms in the US and France that produce the bots that finally make it into every home, and they'll be toys, tools, avatars, and for some people, friends. Yes, nuclear power will make a big comeback. No, it won't power our cars. Yes, China and India are going to become information superpowers. No, they won't toppled the US from its throne. Yes, there will be a lot of war in the future, and a lot of it will be fragmented, because just as mobile phones disrupt the traditional social forms, they also disrupt fighting. "Smart armies"? Give them all Blackberries. Yes, there will be a nuclear terrorist attack. No, it won't be in New York or Washington, but probably in Delhi or Tehran. Yes, Linux will take Windows off the desktop, but really not in the way you'd expect. No, no-one will care when it happens. Yes, there will be a black US president one day. No, she won't be a republican.
The future is not so hard to predict - just look at all the domains where people are competing hardest to innovate, then assume ten years of progress, slower than you'd expect but more profound than you'd believe possible, and then see how people would use those changes to improve and simplify their lives.
It does not take buzzwords.
To be very clear, "he would like the Christian ideals further forced upon all in the US, even non-Christians" for the simple reason that each of these issues has been carefully selected to act as a wedge issue, dividing the population into polarised for-and-against camps that are incapable of compromise, because such a divided country is unable to get enough unity to act on the real issues.
It's quite remarkable how so many issues trumpted by the administration actually have nothing to do with Christian beliefs at all. Immigrant rights, for instance. It's a classic case of a situation that can be tolerated without too much discussion, but by forcing the discussion on the nation, the administration splits the American people into, what was it, FOUR? camps of opinion.
The US is not a Christian-run state. It is not a theocracy but a kleptocracy. It is a state run by gangsters. They are well-dressed, well-educated, well-connected, modern, slick, and very powerful gangsters, but they are gangsters nonetheless, and they use the instruments of the state for personal and collective profit just like any tin-pot dictator.
Congress will never impeach Bush because Congress was corrupted and castrated a long time ago. Gerrymandering has turned Congress into a cartel of power that removes competition and the need to deliver value to the citizen.
A tomato seed is, as astute readers of the last embodiment of this story will remember, almost exactly the same size as a grain of rice.
...
Presumably HP is now using the "use food as units of measurement and the hungry masses will lap up your products" theory of mass marketing.
Coming soon:
- a laptop the size of a pizza calzone!
- a new PDA the size of a 8-oz packet of California sun-dried raisins!
- ink cartridges the size of a small tin of caviar (and more expensive!)
- a secure USB drive the size of a sun-dried tomato!
It's difficult to see what these chips can do that smartcards, mini flash chips, and so on can't do... I think the main drivers are going to be cost and size and accessibility to ordinary developers.
But it could be fun to build memory into ordinary objects. You would not need any electrical contacts. All you need is a universal reader that can presumably be cheaply added to PDA, notebooks, etc. On top of that it'd be easy to write software that reads and writes these to do interesting things:
- smart business cards and ID cards
- smart locks and other innovative security systems
- data collection systems (e.g. cardiac monitors, sensors, etc.)
- contactless public data sources: smart signposts in cities (touch your mobile phone to get a map), etc.
It may be that the wireless aspects eventually become much more useful than the memory itself.
But on the whole I think this technology will not have any market traction until it can be exploited by the adult entertainment industry.
Yes, the problem of "send this document to random people" is a real issue.
However, since OpenOffice has had a "create PDF" feature for ages, and since it produces really elegant PDFs, this is a solved problem.
I much prefer sending PDFs to editable documents because it prevents random modifications. When people do have to collaborate on writing a document, they can install OOo without much effort, and it is easy to learn, despite not being MS Office.
I've seen many people learn to use OpenOffice and the suggestion that its interface is hard to use is untrue. I've literally given non-technical people (office admins, sales and marketing people) a Linux box with OpenOffice and said, "go for it", and they've produced documents and spreadsheets and presentations without asking anything after, "what printer do I use".
PDFs are the answer to distributing prepared documents. PDF or HTML works fine for presentations. And if you *really* need to send someone an MS-Office format document, you use the "Save as" function to create it.
And this model has let us use OO for 4-5 years in a world where almost all of our clients use MS-Office. It works.
Yes, exactly! :-)
I'm speculating that bacteria, in colonies, may be responsible for gold nuggets, at least in some cases. There are other cases of bacteria creating mineral concentrations (like stromatolites). Bacterial activity in hot rocks and hot springs is well known; gold is often found with other elements that some bacteria like, such as sulphur. Concentrations of gold don't seem to fit a natural process, I'd expect to see minerals dispersed within strata, not concentrated into pure blobs.
OK, bizarre theory, I know. Anyhow, I just did some googling and found this.
"Biogenicity of gold- and silver-bearing siliceous sinters forming in hot (75C) anaerobic spring-waters..."
The question people need to ask is not, "why should I switch to OpenOffice", but "what is the killer feature in MS Office that I absolutely need?" Do you really need to be able to run Word on a PDA? Do you need a smooth integration between Office and Exchange? Perhaps, but it's worth reevaluating.
If the cost-benefit ratio is not strong enough to make the cost and insecurity worthwhile, abandon MS Office and use OOo. For most people it's a lot less painful than it sounds. I've even seen OOo spread like a fashion in some teams that were 100% Microsoft, as they discovered that OOo does actually work very nicely, and as they started using ODF as a standard in place of Microsoft's own formats. We did this a long time ago... we get a consistent set of tools on Windows and Linux, and documents that now conform to a global standard and which I know will still be readable in 20 years' time, whatever software or platform I'm using.
There are many alternative office suites and OOo has its flaws, mainly it's a bit slow, but it has a feature set that hits 100% of what we've used - for documents, spreadsheets, simple graphics, and presentations - for years. And I don't get the feeling, when I run it, that I'm running a code base that has hundreds of undocumented backdoors, caused deliberately, or accidentally.
There's no obvious mechanism by which gold should spontaneously form into nuggets in the wild; I don't really believe that gold particles in the soil magically find their way together by some mystical process of attraction.
Is it not more likely that these bacteria have been excreting gold as a matter of habit for hundreds of millions of years, and that gold nuggets are in fact the toilet pits of huge bacterial colonies from ages past? Perhaps the bacteria feed off sulphur or some other element that's mixed with the gold...
It does not matter how much these processors cost today, nor whether AMD's 4x4 is real or a maketing ploy.
What matters is that AMD has captured sufficient marketshare over the last years to become a real competitor to Intel. Opterons have become the CPU of choice for large servers, the niche that Itanium was meant to capture.
Now Intel's comeback means we're seeing the start of a new growth of CPU power, this time into multi-core land, a nice solid metric on which to compete. You can fudge the Ghz but you can't really fudge the number of cores. This means we have the perfect conditions for an explosion of growth, until the numbers get into meaningless territory. Within 3-4 years, common desktops will have 8 to 16 cores, and high-end workstations will have 128 or more.
I'm just very glad my company made the move to writing multithreaded code so we can get the best from this new landscape.
My company designed high-performance mono-process servers (portable ones too) starting in 1995, using event-driven virtual threads and state-machine frameworks. Very elegant, very fast, and really easy programming. The Xitami web server was one example - I remember seeing a Win95 system with Xitami survive a slashdotting (it was serving static pages but that was still impressive.)
We worked in C, because we needed guaranteed low latencies.
In 2004 we decided to rebuild these frameworks to handle OS multithreading. The reason was that on a single CPU we could not get the performance we needed, and the choice was either to use clusters, or multithreading.
We continued to work in C. C, and C++ are really nasty for multithreading because the languages have zero support for concurrency. You need to handle everything yourself, and most threading errors are extremely hard to detect.
It cost us about 10 times more to write our software as multithreaded code than using virtualised threads and we had to build whole reference management frameworks to ensure that threads could share data safely.
We did keep virtual threading, in fact, but virtual threads get handled by a pool of OS threads. Using 1 OS thread per connection is not scalable beyond a few hundred threads. Modern Linux kernels handle lots of threads but we also target Solaris, and Windows with the same code. So we use two virtual threads per connection, for full-duplex traffic, and we design most of the major server components as threaded objects, which are asynchronous event-driven objects.
Doing multithreading in C is a *huge* work. C++ has frameworks like ACE that help a lot.
But there is a performance gain. Our software is a messaging server (implementing the AMQP draft standard). We maxed out at around 55,000 messages per second using a pure virtual-threaded model. Very efficient code. On a single CPU the multithreaded code hits 35,000 messages per second. With two CPUs we're back at 55k, and with 4 dual-core Opterons we're at 120k-150k and higher. (Our software runs a massive trading application that processes 1.5bn messages per day). We still need to improve some of the low-level locking functions to use lock-free mechanisms, and we max out a gigabit network. It is difficult to find machines powerful enough to really stress test the software.
Without very robust frameworks, I'd never attempt such a project. As it was, we paid a lot for the extra performance. Our frameworks will eventually be released as free software, along with the middleware server.
Interestingly, a very similar application written in Java 1.5 and using the BEA runtime gets similar performance to ours. Java's threading is so good that I'd be hesitant to chose C on the basis of performance again. I'm not sure whether ACE can reach the levels of performance we need; 100k messages per second is extreme.
Other questions that are very important to ask:
- The number of clients you expect to connect at once. If it's less than 500 you can probably use one or two OS threads per connection. If it's more you need to virtualise connections or share your OS threads.
- The footprint. If you don't care, then I'd advise using Java. If you want a native Linux service, consider C++ and ACE. If you really want to write multithreaded C code, and don't have a full toolkit, consider seeing a doctor.
When it comes to the future, clearly multiple cores are the way we're heading. This was clear two years ago, and was the main reason we bit the bullet and chose to write our software multithreaded rather than using a clustering model. It seemed clear to me that within a decade, systems would have 32, 64, 128 cores, and software that could take advantage of this would survive for longer. Clustering is not as powerful an abstraction as multithreading.
Well, obviously after the War on Terrr, we can expect a War on Witches (with televised burnings on Fox News), followed by a War on Evil (and I know my neighbour must be a devil worshipper), followed by a War on Youth, after which there will be no-one left to consume drugs, giving us a neat conclusion to the War on Drugs.
When all those wars are complete, we can expect a War on Wars, which will involve the peaceful use of tactical nuclear weaponry on all those who remain after the subcultures have been eliminated.
When it comes down to basics, humanity is just too unreliable and messy to be trusted with its own fate.
Those are very good rules.
Very good indeed. Did you collect these yourself? If so, do you want a job?
I'll add a few more of my own rules:
- Make sure you're in total control of your toolset and improve it systematically
- Do not take the clients' deadlines literally - first accept the project, then renegotiate the deadline.
- Don't implement anything that is not going to be used immediately.
- Design your software around interfaces so you can make massive changes cheaply.
- Document the interfaces perfectly, but don't document code (see next point).
- Be fanatical about the readability of code.
- Push all QC, packaging, and issue management through a single person.
- Build regression testing into the build process.
- When debugging a problem, never ask, "how come it works on my box?"
- If some code is too complex to understand on a Monday morning before coffee, redesign it.
- Never add new code while there are still bugs in the existing code.
It does not work. What's obvious today was often not obvious when the patent was filed, and this fact means most courts ignore the test of obviousness altogether.
The only real way to exclude software patents is, stunningly, to ban patents on software. No exceptions, no ifs, no buts. This is what the European Patent Convention does, in its so-called "subject matter" rule.
Software patents represent a hijacking of the IT industry by lawyers and patent specialists. It's a profitable short-term extraction of value, much like chopping down old timber. And it has only one conclusion, the end of innovation for about two decades, while the world scratches its head and finally realises, "boy that was a *stupid* idea".
To a large extent you can see software patents as a kind of disease, spreading out from IBM's original sinister legal virus labs, across weaker nations first and now into the EU and Asia, and eventually it will infect everyone, kill off a large part of the ecology, and leave a little bit behind to regrow.
The future of IT is lots of lawsuits, with diminishing returns. No new standards, and fewer and fewer new markets, as the technology of patents gets sharper. Within ten years you won't be able to do business without paying a patent fee and small independent inventors (99% of inventors) will be excluded. The state will eventually take over all patents to enable some kind of work to go ahead, and existing patent holders will receive part of the patent tax.
Or, alternatively, we will stop software patents dead in their tracks in Europe, this year, and then start the process of killing off these monsters in the USA as well.
It's probably a good time to support a group like the FFII which is fighting these battles.
Software patents are granted by the tens of thousands in Europe by the EPO and it's just national courts that tend (but not always) to reject them. Telecoms patents have tended to be upheld by courts much more often because they have (superficially) a industrial character that makes them different from 'pure software' patents. This is the rationale. Of course GSM is pure software.
Simply do a Google search for "gsm patent", it's pretty clear the impact these patents have, which is mainly lawsuits.
The GSM standard is owned much the same way the MPEG standard is owned, and licensed under the same kind of 'reasonable and non-discriminatory' terms. It is a very heavily patented standard and (IMO) for this reason has been very slow to evolve once it was defined.
Of course the people are key to any business, not just software, and not just open source. A large part of building a sustainable business is to solve this problem and build structures that survive change. Sustainable software is built in layers so that no single team determines the life of the whole. Individual projects will die if their key developers leave but the whole can keep running.
The article seems mainly aimed at VCs involved in the new boom in Silicon Valley - open source - and is warning them, "buy the developers, not the software".
Good advice but hardly profound.
There are a number of inescapable flaws in the software patent 'system'; this is one of them...
1. Owning patents does not protect you from a non-producing entity (NPE, a firm that owns patents but makes nothing, so infringes nothing and cannot be sued).
2. It is impossible to define new software standards that cannot be undercut and held hostage by NPEs.
3. It is impossible to build new software products that cannot be undercut and held hostage by NPEs.
4. It is impossible to define software patents that cannot be undercut by other software patents. I.e. if Microsoft had filed and owned this particular patent, it'd not stop an NPE making another claim that undercut this claim.
The irony (sweet or not) is that it is those firms lobbying hardest for wider and stronger software patents (IBM, Microsoft, Nokia, Sony, Siemens, SAP) which end up paying the biggest bills. It's true that software patents provide temporary and lucrative monopolies - see the GSM market, based on some of the heaviest-patented standards ever - but in the end the patent trolls will always find a way to turn it around.
Sadly large IT firms are deeply schizophrenic about software patents, with patent policy firmly in the hands of the lawyers, not the engineers, and it will take more than a few lawsuits to change this. (A lawsuit that does not kill a firm just makes its lawyers stronger.)
"Rain Drops Signal Cell Phones" really means:
"I'm zonked, it's late, and I'm going to copy and paste
If you took a look at the BDB source code, you're understand immediately why forking this is not an option unless you happen to have hired the developers.
The patent covers the use of an idea.
The software itself, is simply an expression. The user of the patented idea is the person using the software. Today, most litigation is aimed at product producers because these have the money. But if one was to exclude (e.g.) FOSS from patent claims, then the patent ambush would simply shift onto large-scale software users.
It is difficult to see how the fact that one is using FOSS as compared to commercial software, to do the infringing, would change anything. If you are using someone's patented idea, they own you.
They are.
It does not take a long essay to answer this.
And BTW, Paul Graham is wrong when he says, "if you are against software patents, you are against all patents".
All patents have the potential for evil. But software patents are guaranteed to do evil.
Question: why are there so few new software standards coming out and why do they take so much longer to produce? Answer: because every new software standard is a recipe for patent ambush. Implemented, use it, or use products based on it, and you will, if you make money, be sued.
Yes, software patents are evil because in the name of promoting innovation in a field, they actively destroy it.
Hmmm, if I claim a method (which is the basis for software patents), then I can sue anyone who uses this method without my permission.
Yes, I can sue someone who uses software that implements that method, because the user is using my method. Yes, I can also sue the people who distributed or wrote the software, because they contributed to the infringement.
This is one of the things that makes patents on methods/algorithms/language special. They do not simply cover the production of products, they cover their actual use.
Bzzzt. Wrong.
I've never heard of a patent lawsuit where the defendant was allowed to inspect the plaintiff's source code for other random violations. It probably made sense when you made this up but it's not the way the world works.
Take random huge Linux user, e.g. a large bank that runs 70% of its servers on Linux and is migrating the other 30% as fast as it can. Now produce a patent with 17 claims. Now if large bank cannot disprove each and every one of these 17 claims, they must stop using Linux immediately, or pay whatever the patent holder asks. It is up to the defendant to break the patent claims.
Microsoft will not enforce their patents, if they have any that they think undercut Linux, not because there is any real defense (there is not) but because they will wait until Linux is well-enough established that the patent negotations will go smoothly.
Patent licenses are a large planned revenue stream for Microsoft, and they are only possible when there is a large captive public of infringers who keep infringing. Thus, Linux growth is actually good for Microsoft, seen from this point of view.
Where the whole lovely effice collapses is when we see that for ever dollar MSFT can hope to earn from licensing "their" IP in this way, they will spend ten times that fighting and settling patent ambushes.
Patent holders have a huge power. Look at NTP's extortion of RIM. Microsoft think they can use this power to extort future Linux users. But it's a very risky gamble because MSFT are a lovely target for extortion themselves.
I'm glad to see that the Microsoft astroturfers are out in force here.
Let's review the game plan. The EU has (rightly) condemned Microsoft of illegal monopoly practices and is attempting to force Microsoft to behave in a way that creates a more level playing field. This is not about EU vs. US; Microsoft has also been convicted of monopolist behaviour in the US, only it's managed to avoid any penalties for that.
Now, the EU is asking for Microsoft to stop working to create barriers to interoperability. This is a valid approach. Microsoft can make whatever software it likes but it cannot deliberately break interoperability. In case you're wondering why this matters, it's thanks to interoperability that the Internet even exists. Microsoft would like to make products like Samba useless.
It is trying to inject software patents into the picture, by claiming that its standards are "patented". Thus, any open source implementation would infringe.
As an alternative, Microsoft suggests that people can license its source code. Note that this is something MS has been offering to random partners for years, so it's hardly a new step. When asked what the price and conditions for such a license would be, Microsoft said, "we are willing to negotiate".
In other words, Microsoft has not budged an inch and is instead preparing the ground for patenting its interfaces in the EU.
Now we come to the crux of the matter: Microsoft, far from making any concession with respect to the anti-trust accusations, is instead laying the groundwork for an attack on open source competition! This is so blatant and so hostile to the interests of the market that it's quite amazing the Commission is still talking to them, instead of simply levying an appropriate fine.
Open standards are vital to competition, and Microsoft's attempts to quash competition by placing patent bombs into its interfaces, while happily exploiting every other standard on the market, deserve all the abuse they get.
NTP are exploiting weaknesses in the system.
So long as the USPTO has not ruled, they can blackmail RIM. They just need to get the court to agree to shutdown RIM for one day, to win the huge amounts of money they are seeking. The USPTO can invalidate whatever patents they like after that, it's not going to affect the deal they strike.
This is a perfect case of patent agression. Experts in the legal process extorting huge amounts from innovators. Welcome to the way business is going to be run for the next decades.