"United Kingdom: 5% (2003 est.)"
Now down to approx 3% officially, AFAIK.
Also officially Germany is up to 11.6%, but it changed its reporting methods, and by the old methods is would be still be nearer 10%.
In any case the ILO would be a better source of figures as the ILO calculates them on a more consistent set of criteria.
Also high unemployment, whilst bad in some ways for a country, is potentially good for business as it tends to depress increases in wages. So currently we see labour costs rising in the USA but in Germany they are essentially static. In terms of GDP PPP production per capita per hour worked Germany outstrips the USA, but there are more hours worked in the USA due to longer worker hours and lower unemployment. In both countries productivity is improving. What the longer term trend will be (will US productivity gains outstrip increasing producer prices?) I don't know. Currently Germany is the world's largest exporter, although the relatively low value of the dollar may mean that the USA and Germany may swap places yet again before the end of the year.
A better analogy, based on the things that socialists were actually complaining about in the 19th century would be this:
There are some members of the class that have some sort of power over the others. They make the weaker members of the class work on their behalf so that they get 100%. Other members of the class get 100% on their own merits. Socialism then seeks to redistribute the marks from those that got 100% (whether or not it was on their own merits or not) to those who got a low mark (whether or not it is because of their own deficiencies, or because they were having to work for some of those that got 100%). So in this sense socialism attempts to deal with an inequity based on power relationships, but does it in a way that doesn't reward effort correctly either. So a noble sentiment, badly applied.
The first is at the low level - containers in which to run an operating system. This allows the system to be provisioned with the required OS that the user requires, no matter what the hardware layer. This allows the user more options of where their jobs might run rather than scouring the world for the one server that has the right OS, is cheap enough, and can have the job done by next Tuesday.
At the higher level there is the virtualisation of collections of resources into a computing infrastructure at which you can throw your job (along with some policies, such as what your job does, how much you are prepared to pay to have it done, and the fact you want it done by next Tuesday). Ultimately this virtualisation is into the 'Grid' - just one virtual computer that gets your stuff done.
There are a whole series of underlying tools and technolgies that make this possible, and the likes of Sun Grid Engine, Condor, Globus, Web services, BPEL, etc., are tools to construct such a grid, that all run on the lower level tools (TCP/IP and the like).
Failing to make the tools interoperable damages the market for Grid as a whole and does neither Sun nor IBM any good, given that most companies have mixed hardware. Standardisation has taken place over a whole series of networking layers: first TCP/IP, then services on top such as http, and Grid services will follow.
Grid is a form of distributed computing. Currently what Grid actually means (Foster's book not withstanding) isn't entirely clear. To me Grid is an aspiration, and there a host of technologies that can be used to create a Grid or Grids. Condor is one useful way to virtualise a set of machines based on a CPU-scavenging model (others include Entropia, Inferno, etc). Grids also do not need to be based on Globus (e.g. Inferno, Unicore) although standards make life a lot easier. The standards are still in a process of emerging, however.
Also still emerging is the convergence of data grids (cf Oracle 10g, OGSA-DAI, SRB, GridFTP) and compute grids (Globus job submission, GASS).
There are also a number of issues to solve, not least security, billing, HCI, and ensuring that there is a suitable environment to run your compute job in (automatic provisioning, containers and so on). Some of the partial solutions to these issues have been floating around for a couple of days since the earlier days of distributed and thin client computing. Assembling everything into a coherent whole that is interoperable and robust and extensible is no small task, however.
To add to confusion there seem to be a number of definitions of Grid, some distinct varieties of Grid, some misuse of the term Grid, and a series of distributed computing and dynamic resource management systems that are near-Grid to which the name Grid is attached.
Often I think there is too much concentration on the technologies (don't get me wrong, the technology is important) since it has been technology-led when the real focus should be on the business process, or business or user advantage in using Grid. Here I think the likes of CERN or T-Systems are doing good work: they have their technologists but the important thing is to get the work done with minimum fuss. The aspiration should be for this to be more widely possible, irrespective of whatever underlying technology or standards become the most prevalent. The ideal is (much like Foster's vision) is the electricty grid model. We are a way off from that vision, but Grid (in a pure or true sense of the term) can be used to business advantage today.
Trivially parallelisable codes will, by their very nature, be the easiest to parallelise on an arbitrary computing infrastructure. However, even then Grid (which is an aspiration and collection of technolgies rather than a single technology currently) can offer benefits, with regards to resource discovery, and submission of work to a remote resource.
Grid is not just for parallelisable codes, but also for the ability to find a resource to run some code on, collecting and virtualising resources, and creating workflows (pipelines).
Grid computing has a number of aspects: * Offering services (web services, OGSA, etc) * Creation of workflow from services (BPEL, etc) * Service orientation (SOA) * Cluster computing (Sun, PBS, LSF, Beowulf) * Virtualisation (VMWare, containers, etc) * CPU cycle scavenging (Condor, Entropia, etc) * Remote job submission (Globus, CFS, Condor, etc) * Remote resource discovery (Globus) * Data replication and management (SRB, etc) * Database federation (DB2, Oracle 10g) * Collaboration (virtual organisations) * Visualisation
You CAN get them, then are simply a little too expensive for general use. You can get VR goggles (circa $600 for 800x600) and head motion trackers for around $100. To make playing an FPS workable you'd also need a wireless gamepad (to avoid getting wrapped up in the cables when in the virtual world) and voice activation software (e.g. Voice Buddy) for all those additional commands that you can't map to a gamepad.
Linux is becoming more popular yet it seems the time for an exposed Linux machine on the internet to get hacked seems to have increased, even with the same old distribution. Maybe all that means is that the script kidz simply aren't interested in hacking into Linux machines.
Increasingly it seems that companies are understanding Grid. I've certainly bumped into some companies selling software used in computationally-intensive applications at Grid conferences.
" They're simply the worst for scientific computing"
If you are talking about Sparc architectures a lot depends on how you optimise your code. You can take code that runs moderately well on a high-clocked x86 architecture and have it run like a dog on a Sparc. However if you have floating point mathematics and tune the code to dispatch work to each of the four floating point units and keep those pipelines full you can get massive speed ups. Lots of the techniques will also provide lesser speed ups on x86 architectures too, but the Sparc has the advantage of a lot of floating point horsepower, but you do have to do a bit of extra work to get the best out of it.
As part of the Forte compiler set (I can't remember the latest Sun ONE name for this) you get a combination of text-based and graphical tools (depending on what software set you have) that allow you to analyse the code performance in depth and tune it. Sun also runs some excellent training courses in this area.
This is certainly being done in academia already although generally without the strict QoS and other legal issues that would be required between commercial entities.
With regard to the scavenging there are a number of tools that can be used such as ones from Entropia, Condor, Mosix, Inferno and Sun Grid Engine to name a few, plus some stuff coming out of IBM's Alphaworks. With regard to virtual machines there is also work going on with regard to this, Solaris 10 virtual containers and VM Ware being two examples, and also the ability to run Linuxes within Linux. At Duke University there is a project to allow some form of automatic creation of such virtual servers to allow on demand provisioning of specific environments. I also wrote a paper for a Sun HPC conference covering aspects of this.
There is a lot of stuff happening in this area. We're not there quite yet, but I would expect to see some robust solutions to this emerge over the next three years. There will still be issues to solve in terms of the subtleties of balancing policies and making the best possible scheduling decisions plus the rather complex issue of legal and QoS agreements.
I think we will see more of 'trading grids' in the future. The White Rose Grid (Yorkshire, UK) is a form of such a grid in an academic environment.
In addition there are the usual array of volunteer CPU cycle scavenging Grids for good purposes : protein folding @ home, set @home, IBM's Community Grid and so on.
One of the advantages of Grid is to defray those capital costs by allowing researchers to gain easier access to existing resources. Traditionally academic HPC has either been isolated islands in various departments on various campuses augmented by a few supercomputing centres offering relatively centralised facilities. In theory Grid offers a way to make access to resources scattered across a campus seamless so those dusty old machines almost everyone has forgotten about can be used. There are challenges in making this scalable and robust and easy to use from an end user perspective but great strides are being made.
Ultimately, though, machines still have a limited lifecycle as user requirements for memory and turnaround will mean that older machines will reduce in usefullness and the power drain will mean that it is not economical or ecological to keen them running for the amount of use they are getting. Some are still more useful than it would appear as part of the problem is a lack of tools to automatically parallelise or otherwise subdivide computation algorithms into logical units suitable for a variety of different underlying architectures. Software engineers can create these parallelisations but with a variety of possible architectures available some automation of the process would be advantageous. However the relatively low level programming languages used for most scientific code makes it hard to automate this. I know Sun was looking at a higher level language for HPC and this would be a good development for future code as a higher level description of the algorithm could be more amenable to automatic processing. In addition something that is closer to the mathematics involved than C or Fortran might make the code less prone to bugs (compilers and translators permitting).
Features such as containers in Solaris 10 allow you to address some of those security concerns, along with encryption at rest and in flight. Pharmas are likely to be unhappy about those security issues for some time to come all the same.
A practical concern, however, is the cost of shipping data to the compute. If your jobs are compute intensive rather than data intensive then this is great. If your jobs are data intensive then shipping the data for peak compute demands may not be feasible.
If the business requirement for that peak is strong, though, $1 an hour for the peak compute but with an associated transport cost may be cheaper overall than maintaining a large compute facility large enough to meet that peak compute demand adjacent to the data storage. However there is always the option for a business to sell the spare compute cycles themselves in the way Sun are suggesting.
Basically the big determinants here are how much data you have and how much you are prepared to pay and/or how long you are prepared to wait for it to be moved about and how much compute you can do on that same set of data once it has been transported. Ultimately we will see intelligent brokers that will allow companies to set policies for these and for provision companies and automatic agents driven by those policies go through a bidding process. There are projects such as ICL's ICENI looking at mechanisms for this on top of existing grid middleware.
" GNU tools aren't part of the default Solaris Distro"
It installs gzip by default, so there is at least one GNU tool on there by default without the supplemental CD. I am not aware of any other GNU tools installed by default, though.
These says it seems the kids are checking their email and playing games on their 3G phones as much as anything else.
To be honest I think that an ultimately more useful model than the monolithic PC might be a series of single-purpose devices connected with high speed wireless connectivity and completely transparent communication set up, each streaming the appropriate type of content potentially to a number of presentation devices (hi fi, wireless TV, 3G phones, PCs).
There are issues to be solved here with regard to contention and performance both of devices and network. But in theory if you want to record TV you buy a PVR 'brick' and any of the presentation devices (e.g. your TV) could request a stream of content from it.
Maybe poorly written applications is what I have been experiencing in trying to run multiple applications of that type on my single PC at home (AMD XP 2000, 1GB RAM). Actually the major issue I was experiencing when doing several things including recording analogue TV signals was audio and video from the TV recording going out of sync.
What I was really alluding to is the ability to sandbox the applications. You can sandbox now with single cores but multiple cores will likely make this easier. There have been suggestions that some multicore desktop chips will support the ability to run a separate OS on one of the cores. If you could run a separate set of applications on that separate core, sandboxed as much as possible, then it might insultate the other functionality against problems. But you are right, applications written correctly in the first place would solve the problem.
The downside to having the PC in your living room handling your audio (CD, radio) video (DVDs) and TV and recording (PVR) is that you have all your eggs in one basket.
Another potential downside is that resoruce demands for each task are not necessarily insulated from each other. If I wanted to record a TV show, record from the radio and watch a DVD at the same time a PC would still be pushed to achieve this at the moment. It would be annoying for the radio recording be choppy because of the DVD playback, for example. So until a PC can do the sort of things that a home user with a typical set of separates can achieve (with a video recorder, radio, tape deck and a DVD player the above scenario is very possible) there is a problem. Luckily upcoming dual core processors should help with some of the insulation between tasks. In theory a well designed suite of tools should be able to achieve this gracefully now, given a fairly beefy PC, but I doubt testing always involves these scenarios.
A further issue is tolerance to faults. Currently a video recorder ends up creating a number of tapes. If one fails you still have a series of others that are likely to work. If everything is on a single hard drive, however, you are vulnerable. Backup systems exist but they can be expensive extras. Also they can take quite a while to create a version of a piece of media that can be removed for safe keeping. It takes a long time to replicate a video cassette too, but the recordings are separate and not likely to be lost in one fell swoop unless your house burns down or something. At the very least I think media centre PCs should ship with two drives, either mirrored or performing disk-to-disk backups at quiet periods. Ideally the second drive should be accessible via the front panel, held in by a lock. If you have a series of treasured memories held on your machine you want to be able to remove it and take it with you if your house is in danger of destruction.
The final issue is interfaces. If the interface doesn't allow me to easily achieve the scenario above, then this is also a problem. Ok, it isn't necessarily a scenario that turns up very often, but if a PC can't do it then it is a step backwards on some levels in terms of the total functionality available. One of the advantages of separates is that they typically have pretty simple interfaces for simple tasks. The disadvantage is the lack of integration and the sometimes bewildering quanity of wiring spaghetti and remote controls you can end up with!
I think we will see the PC dominate, but I think it will be a 3 or more years before all the above issues are solved in terms of high street plug-in-and-forget products. What is on offer now is fine for early adopters, though.
"No, your elaborate theory of bandwidth distribution leading to lower perceived switching costs among consumers is not anything close to an economic principle. It's a theory, and one you haven't supported."
Sorry, it wasn't clear to what you were referring to so I presumed you were referring to barriers to entry into a market.
" That doesn't mean you're wrong, but we should realize that these are theories."
It is a well established economic principle.
" why did Netscape have 70+% browser share for the next 4 years?"
Initially the internet was something not available at home so the users were people in various companies, academia etc. The browser of choice was initially Mosaic and then Netscape. This established mindshare. Often these people were using UNIX clients which automatically established netscape in a dominant position. As browsing shifted to home users the first home users were those same academics etc. For those users at home using the same client, but on windows, was a natural choice. However as time marched on towards 2000 and beyond there was an influx of users who were not from that community. The correlation between this set of new users and the increase in share of internet explorer isn't perfect, but there is some correlation.
Over the period of 1997-2001 internet use at home in the USA close to doubled. In any case netscape market share was not as high as you suggest. In 1997 it was under 60%, with IE's share doubling through 1997, down to 12% in 2001. If we assume (big assumption, of course) that all new users in this period decided to use IE and not netscape then this would lead to netscape's share reducing by half. So there must be other factors involved other than simply bundling. One of these might be that netscape became less able to open web pages properly as some pages broke HTML compliance (not that netscape was totally compliant either) and would work only with internet explorer. This is likely to drive those who have bought windows PCs with IE on to use this, even if they have to use netscape at work. IE simply became the tool you needed to work with some applications. For example I used to use netscape for online banking and then my bank changed to supporting only internet explorer. Thus I had to use IE at least some of the time.
Also, increasingly through this period networked computers with internet access at work became windows boxes rather than expensive UNIX workstations and the like as common in academia. So the netscape mindshare was also eroded in the workplace.
I suspect it sat unchanged becase behind the scenes it was indeed being changed but it just took a while to sort things out. Essentially this is the same rendering engine as being used by the netscape forks and others (such as Galeon) even now. So it seems to have been a good choice of engine, but just took a while to appear. In many ways that is better than it having been released, half-cocked, 18 months previously as then it might have killed off the nascent Gecko engine leaving us without firefox.
Back in the 1990s dial up was the connection type for most people. This meant that it was a fair effort to download several MB of new program. It was a hassle to order it on CD (which cost money).
In the 21st century large numbers of people have broadband. Downloading 20MB of firefox is no big deal.
So basically Netscape needed to be far superior to the tool packaged with the OS to make it worth the while of people with a dialup connection to download. If Netscape was as good as IE then it would have lost share. It needed to be significantly better (and have sufficient advertising to make new users even aware that it existed)
4.0 was released in 1997 but 6.0 (the first major change of rendering engine) didn't hit the download sites until 6.0. This was aimed to be the major change which would make it worth dialup users downloading it. But by this time IE had significant mindshare based on the fact that it was there, ready to be used, no lengthy download wait required.
"I said that Netscape killed itself by not releasing an update of its software from 1997 until 2000."
Here's a list of versions between those dates:
4.0, Jun 1997 4.5, Mar 1998 4.6, May 1999 4.7, Sep 1999
There was no major revision change between 1997 and 2000, but there was certainly development.
If only a major version number counts for development then there was no Internet Explorer development from version 5.0 (March 2000) and version 6.0 (August 2002) and no Internet Explorer development from August 2002 to January 2005.
" After all, since China is not going to become a research and development hub"
There's a lot of research (and increasingly so) going on there already. A long way to go, though.
Slashdot Mirror
"United Kingdom: 5% (2003 est.)" Now down to approx 3% officially, AFAIK. Also officially Germany is up to 11.6%, but it changed its reporting methods, and by the old methods is would be still be nearer 10%. In any case the ILO would be a better source of figures as the ILO calculates them on a more consistent set of criteria. Also high unemployment, whilst bad in some ways for a country, is potentially good for business as it tends to depress increases in wages. So currently we see labour costs rising in the USA but in Germany they are essentially static. In terms of GDP PPP production per capita per hour worked Germany outstrips the USA, but there are more hours worked in the USA due to longer worker hours and lower unemployment. In both countries productivity is improving. What the longer term trend will be (will US productivity gains outstrip increasing producer prices?) I don't know. Currently Germany is the world's largest exporter, although the relatively low value of the dollar may mean that the USA and Germany may swap places yet again before the end of the year.
A better analogy, based on the things that socialists were actually complaining about in the 19th century would be this: There are some members of the class that have some sort of power over the others. They make the weaker members of the class work on their behalf so that they get 100%. Other members of the class get 100% on their own merits. Socialism then seeks to redistribute the marks from those that got 100% (whether or not it was on their own merits or not) to those who got a low mark (whether or not it is because of their own deficiencies, or because they were having to work for some of those that got 100%). So in this sense socialism attempts to deal with an inequity based on power relationships, but does it in a way that doesn't reward effort correctly either. So a noble sentiment, badly applied.
That's a very warped idea of socialism. It might work for a Rush song, but not for much else.
The first is at the low level - containers in which to run an operating system. This allows the system to be provisioned with the required OS that the user requires, no matter what the hardware layer. This allows the user more options of where their jobs might run rather than scouring the world for the one server that has the right OS, is cheap enough, and can have the job done by next Tuesday.
At the higher level there is the virtualisation of collections of resources into a computing infrastructure at which you can throw your job (along with some policies, such as what your job does, how much you are prepared to pay to have it done, and the fact you want it done by next Tuesday). Ultimately this virtualisation is into the 'Grid' - just one virtual computer that gets your stuff done.
There are a whole series of underlying tools and technolgies that make this possible, and the likes of Sun Grid Engine, Condor, Globus, Web services, BPEL, etc., are tools to construct such a grid, that all run on the lower level tools (TCP/IP and the like).
Failing to make the tools interoperable damages the market for Grid as a whole and does neither Sun nor IBM any good, given that most companies have mixed hardware. Standardisation has taken place over a whole series of networking layers: first TCP/IP, then services on top such as http, and Grid services will follow.
Also still emerging is the convergence of data grids (cf Oracle 10g, OGSA-DAI, SRB, GridFTP) and compute grids (Globus job submission, GASS).
There are also a number of issues to solve, not least security, billing, HCI, and ensuring that there is a suitable environment to run your compute job in (automatic provisioning, containers and so on). Some of the partial solutions to these issues have been floating around for a couple of days since the earlier days of distributed and thin client computing. Assembling everything into a coherent whole that is interoperable and robust and extensible is no small task, however.
To add to confusion there seem to be a number of definitions of Grid, some distinct varieties of Grid, some misuse of the term Grid, and a series of distributed computing and dynamic resource management systems that are near-Grid to which the name Grid is attached.
Often I think there is too much concentration on the technologies (don't get me wrong, the technology is important) since it has been technology-led when the real focus should be on the business process, or business or user advantage in using Grid. Here I think the likes of CERN or T-Systems are doing good work: they have their technologists but the important thing is to get the work done with minimum fuss. The aspiration should be for this to be more widely possible, irrespective of whatever underlying technology or standards become the most prevalent. The ideal is (much like Foster's vision) is the electricty grid model. We are a way off from that vision, but Grid (in a pure or true sense of the term) can be used to business advantage today.
Trivially parallelisable codes will, by their very nature, be the easiest to parallelise on an arbitrary computing infrastructure. However, even then Grid (which is an aspiration and collection of technolgies rather than a single technology currently) can offer benefits, with regards to resource discovery, and submission of work to a remote resource.
Grid is not just for parallelisable codes, but also for the ability to find a resource to run some code on, collecting and virtualising resources, and creating workflows (pipelines).
Grid computing has a number of aspects:
* Offering services (web services, OGSA, etc)
* Creation of workflow from services (BPEL, etc)
* Service orientation (SOA)
* Cluster computing (Sun, PBS, LSF, Beowulf)
* Virtualisation (VMWare, containers, etc)
* CPU cycle scavenging (Condor, Entropia, etc)
* Remote job submission (Globus, CFS, Condor, etc)
* Remote resource discovery (Globus)
* Data replication and management (SRB, etc)
* Database federation (DB2, Oracle 10g)
* Collaboration (virtual organisations)
* Visualisation
You CAN get them, then are simply a little too expensive for general use. You can get VR goggles (circa $600 for 800x600) and head motion trackers for around $100. To make playing an FPS workable you'd also need a wireless gamepad (to avoid getting wrapped up in the cables when in the virtual world) and voice activation software (e.g. Voice Buddy) for all those additional commands that you can't map to a gamepad.
Linux is becoming more popular yet it seems the time for an exposed Linux machine on the internet to get hacked seems to have increased, even with the same old distribution. Maybe all that means is that the script kidz simply aren't interested in hacking into Linux machines.
Increasingly it seems that companies are understanding Grid. I've certainly bumped into some companies selling software used in computationally-intensive applications at Grid conferences.
If you are talking about Sparc architectures a lot depends on how you optimise your code. You can take code that runs moderately well on a high-clocked x86 architecture and have it run like a dog on a Sparc. However if you have floating point mathematics and tune the code to dispatch work to each of the four floating point units and keep those pipelines full you can get massive speed ups. Lots of the techniques will also provide lesser speed ups on x86 architectures too, but the Sparc has the advantage of a lot of floating point horsepower, but you do have to do a bit of extra work to get the best out of it.
As part of the Forte compiler set (I can't remember the latest Sun ONE name for this) you get a combination of text-based and graphical tools (depending on what software set you have) that allow you to analyse the code performance in depth and tune it. Sun also runs some excellent training courses in this area.
With regard to the scavenging there are a number of tools that can be used such as ones from Entropia, Condor, Mosix, Inferno and Sun Grid Engine to name a few, plus some stuff coming out of IBM's Alphaworks. With regard to virtual machines there is also work going on with regard to this, Solaris 10 virtual containers and VM Ware being two examples, and also the ability to run Linuxes within Linux. At Duke University there is a project to allow some form of automatic creation of such virtual servers to allow on demand provisioning of specific environments. I also wrote a paper for a Sun HPC conference covering aspects of this.
There is a lot of stuff happening in this area. We're not there quite yet, but I would expect to see some robust solutions to this emerge over the next three years. There will still be issues to solve in terms of the subtleties of balancing policies and making the best possible scheduling decisions plus the rather complex issue of legal and QoS agreements.
In addition there are the usual array of volunteer CPU cycle scavenging Grids for good purposes : protein folding @ home, set @home, IBM's Community Grid and so on.
Ultimately, though, machines still have a limited lifecycle as user requirements for memory and turnaround will mean that older machines will reduce in usefullness and the power drain will mean that it is not economical or ecological to keen them running for the amount of use they are getting. Some are still more useful than it would appear as part of the problem is a lack of tools to automatically parallelise or otherwise subdivide computation algorithms into logical units suitable for a variety of different underlying architectures. Software engineers can create these parallelisations but with a variety of possible architectures available some automation of the process would be advantageous. However the relatively low level programming languages used for most scientific code makes it hard to automate this. I know Sun was looking at a higher level language for HPC and this would be a good development for future code as a higher level description of the algorithm could be more amenable to automatic processing. In addition something that is closer to the mathematics involved than C or Fortran might make the code less prone to bugs (compilers and translators permitting).
Features such as containers in Solaris 10 allow you to address some of those security concerns, along with encryption at rest and in flight. Pharmas are likely to be unhappy about those security issues for some time to come all the same.
A practical concern, however, is the cost of shipping data to the compute. If your jobs are compute intensive rather than data intensive then this is great. If your jobs are data intensive then shipping the data for peak compute demands may not be feasible.
If the business requirement for that peak is strong, though, $1 an hour for the peak compute but with an associated transport cost may be cheaper overall than maintaining a large compute facility large enough to meet that peak compute demand adjacent to the data storage. However there is always the option for a business to sell the spare compute cycles themselves in the way Sun are suggesting.
Basically the big determinants here are how much data you have and how much you are prepared to pay and/or how long you are prepared to wait for it to be moved about and how much compute you can do on that same set of data once it has been transported. Ultimately we will see intelligent brokers that will allow companies to set policies for these and for provision companies and automatic agents driven by those policies go through a bidding process. There are projects such as ICL's ICENI looking at mechanisms for this on top of existing grid middleware.
" GNU tools aren't part of the default Solaris Distro" It installs gzip by default, so there is at least one GNU tool on there by default without the supplemental CD. I am not aware of any other GNU tools installed by default, though.
These says it seems the kids are checking their email and playing games on their 3G phones as much as anything else. To be honest I think that an ultimately more useful model than the monolithic PC might be a series of single-purpose devices connected with high speed wireless connectivity and completely transparent communication set up, each streaming the appropriate type of content potentially to a number of presentation devices (hi fi, wireless TV, 3G phones, PCs). There are issues to be solved here with regard to contention and performance both of devices and network. But in theory if you want to record TV you buy a PVR 'brick' and any of the presentation devices (e.g. your TV) could request a stream of content from it.
Maybe poorly written applications is what I have been experiencing in trying to run multiple applications of that type on my single PC at home (AMD XP 2000, 1GB RAM). Actually the major issue I was experiencing when doing several things including recording analogue TV signals was audio and video from the TV recording going out of sync.
What I was really alluding to is the ability to sandbox the applications. You can sandbox now with single cores but multiple cores will likely make this easier. There have been suggestions that some multicore desktop chips will support the ability to run a separate OS on one of the cores. If you could run a separate set of applications on that separate core, sandboxed as much as possible, then it might insultate the other functionality against problems. But you are right, applications written correctly in the first place would solve the problem.
The downside to having the PC in your living room handling your audio (CD, radio) video (DVDs) and TV and recording (PVR) is that you have all your eggs in one basket.
Another potential downside is that resoruce demands for each task are not necessarily insulated from each other. If I wanted to record a TV show, record from the radio and watch a DVD at the same time a PC would still be pushed to achieve this at the moment. It would be annoying for the radio recording be choppy because of the DVD playback, for example. So until a PC can do the sort of things that a home user with a typical set of separates can achieve (with a video recorder, radio, tape deck and a DVD player the above scenario is very possible) there is a problem. Luckily upcoming dual core processors should help with some of the insulation
between tasks. In theory a well designed suite of tools should be able to achieve this gracefully now, given a fairly beefy PC, but I doubt testing always involves these scenarios.
A further issue is tolerance to faults. Currently a video recorder ends up creating a number of tapes. If one fails you still have a series of others that are likely to work. If everything is on a single hard drive, however, you are vulnerable. Backup systems exist but they can be expensive extras. Also they can take quite a while to create a version of a piece of media that can be removed for safe keeping. It takes a long time to replicate a video cassette too, but the recordings are separate and not likely to be lost in one fell swoop unless your house burns down or something. At the very least I think media centre PCs should ship with two drives, either mirrored or performing disk-to-disk backups at quiet periods. Ideally the second drive should be accessible via the front panel, held in by a lock. If you have a series of treasured memories held on your machine you want to be able to remove it and take it with you if your house is in danger of destruction.
The final issue is interfaces. If the interface doesn't allow me to easily achieve the scenario above, then this is also a problem. Ok, it isn't necessarily a scenario that turns up very often, but if a PC can't do it then it is a step backwards on some levels in terms of the total functionality available. One of the advantages of separates is that they typically have pretty simple interfaces for simple tasks. The disadvantage is the lack of integration and the sometimes bewildering quanity of wiring spaghetti and remote controls you can end up with!
I think we will see the PC dominate, but I think it will be a 3 or more years before all the above issues are solved in terms of high street plug-in-and-forget products. What is on offer now is fine for early adopters, though.
"No, your elaborate theory of bandwidth distribution leading to lower perceived switching costs among consumers is not anything close to an economic principle. It's a theory, and one you haven't supported." Sorry, it wasn't clear to what you were referring to so I presumed you were referring to barriers to entry into a market.
It is a well established economic principle.
" why did Netscape have 70+% browser share for the next 4 years?"
Initially the internet was something not available at home so the users were people in various companies, academia etc. The browser of choice was initially Mosaic and then Netscape. This established mindshare. Often these people were using UNIX clients which automatically established netscape in a dominant position. As browsing shifted to home users the first home users were those same academics etc. For those users at home using the same client, but on windows, was a natural choice. However as time marched on towards 2000 and beyond there was an influx of users who were not from that community. The correlation between this set of new users and the increase in share of internet explorer isn't perfect, but there is some correlation.
Over the period of 1997-2001 internet use at home in the USA close to doubled. In any case netscape market share was not as high as you suggest. In 1997 it was under 60%, with IE's share doubling through 1997, down to 12% in 2001. If we assume (big assumption, of course) that all new users in this period decided to use IE and not netscape then this would lead to netscape's share reducing by half. So there must be other factors involved other than simply bundling. One of these might be that netscape became less able to open web pages properly as some pages broke HTML compliance (not that netscape was totally compliant either) and would work only with internet explorer. This is likely to drive those who have bought windows PCs with IE on to use this, even if they have to use netscape at work. IE simply became the tool you needed to work with some applications. For example I used to use netscape for online banking and then my bank changed to supporting only internet explorer. Thus I had to use IE at least some of the time.
Also, increasingly through this period networked computers with internet access at work became windows boxes rather than expensive UNIX workstations and the like as common in academia. So the netscape mindshare was also eroded in the workplace.
I suspect it sat unchanged becase behind the scenes it was indeed being changed but it just took a while to sort things out. Essentially this is the same rendering engine as being used by the netscape forks and others (such as Galeon) even now. So it seems to have been a good choice of engine, but just took a while to appear. In many ways that is better than it having been released, half-cocked, 18 months previously as then it might have killed off the nascent Gecko engine leaving us without firefox.
Back in the 1990s dial up was the connection type for most people. This meant that it was a fair effort to download several MB of new program. It was a hassle to order it on CD (which cost money). In the 21st century large numbers of people have broadband. Downloading 20MB of firefox is no big deal. So basically Netscape needed to be far superior to the tool packaged with the OS to make it worth the while of people with a dialup connection to download. If Netscape was as good as IE then it would have lost share. It needed to be significantly better (and have sufficient advertising to make new users even aware that it existed) 4.0 was released in 1997 but 6.0 (the first major change of rendering engine) didn't hit the download sites until 6.0. This was aimed to be the major change which would make it worth dialup users downloading it. But by this time IE had significant mindshare based on the fact that it was there, ready to be used, no lengthy download wait required.
"I said that Netscape killed itself by not releasing an update of its software from 1997 until 2000."
Here's a list of versions between those dates:
4.0, Jun 1997
4.5, Mar 1998
4.6, May 1999
4.7, Sep 1999
There was no major revision change between 1997 and 2000, but there was certainly development.
If only a major version number counts for development then there was no Internet Explorer development from version 5.0 (March 2000) and version 6.0 (August 2002) and no Internet Explorer development from August 2002 to January 2005.
" After all, since China is not going to become a research and development hub" There's a lot of research (and increasingly so) going on there already. A long way to go, though.