Indeed: there's a very simple test - if it were wanted it would have been adopted by now!
There was a powerful driver to IPv6 - the shortage of IPv4 addresses - but the people working on it couldn't resist the urge to try and solve a bunch of other less pressing problems while they were at it. The practical experience of people who've been in this kind of "upgrade" situation before is that unless you have absolute central control over the network you have to do migrations in very simple, evolutionary steps which network operators across the globe are prepared to buy into as an adjunct to their main task which is keeping the current version of the network running. IPv6 just has too many new things in it for network operators to do it in one hit while they're doing their day jobs.
There were loud voices warning the IPv6 group of the practical migration problems, but the idea of joining the ranks of the IETF immortals by finding the "ultimate answer to networking and everything" was a powerful spur to ever greater complexity.
And we didn't run out of IPv4 addresses. Or, rather, most of us realised that whilst in theory having a unique network address for every bit of kit might be ideal, in practice we don't want to have to be continuously upgrading the anti-virus protection on our toasters. So, hello NAT and friends. What we actually need are some solutions higher up the protocol stack that make network-layer relays (such as NAT systems) more robust* (heck, you could even make a virtue out of protection at the network border) by separating the concepts of "end point" address and "network" address.
Unfortunately, the unique-address-for-everything zealots have been buggering up the application protocols in the meantime and passing raw IP addresses around: just when you thought passive mode in FTP had fixed that application, some idiot makes exactly the same mistake in SIP.
So: IPv6 isn't going to catch on and IPv4 is increasingly broken. And the Internet justs creaks along as usual...
Indeed, it might ultimately be advantageous to Microsoft to open up the protocols. All computer companies in history have had a time-limited opportunity to exploit a particular technical niche and most have disappeared when the time limit expired.
An appropriate comparison would be Digital Equipment. Some of the biggest networks in the world at one time were based on DECnet, which it kept for the most part proprietary. When TCP/IP came along it took away a significant market not because TCP/IP excluded DEC computers, but because DEC computers couldn't connect to machines for which there was no licensed implementation of DECnet unless they used TCP/IP - so everyone switched. DEC suddenly had a good plan: produce a new version of DECnet which was compliant with open standards, but it came along too late, had too many problems with backwards compatibility, so bye-bye DECnet and bye-bye DEC.
Microsoft might well lose short-term market share by opening up its networking protocols, but in the long term it's probably the only way to keep a proportion of the market for this type of product. It all depends how far ahead your shareholders will allow you to plan...
You can (usually) get a "normal" hotel in London from one of the budget chains for around the $70 mark (depending on area). The last time I checked "easyHotel" (http://www.easyhotel.com/), who pioneered the reduced-cost hotel concept, their prices were typically higher (up to $80 per night) than I could get in a number of conventional hotels that offered more space and a higher level of service. Accor (the French chain that operates Motel 6, Ibis, Novotel et al) already operates the Formule 1 brand (http://www.hotelformule1.com/) which provides automated checkin and basic rooms from around $50 in (the environs of) London and don't vary their prices according to demand the way easyHotel do.
The only thing that seems to distinguish the Yotel is "designer" styling - and it will be interesting to see how this stands up to the wear and tear of a small space with high occupancy levels...
Still, if they manage to deliver a hotel which meets the three basic requirements of a hotel - cleanliness, a working shower and a room quiet enough to sleep in - they'll be doing better than the majority of establishments out there!
I'm curious about the motives for electronic voting.
We seem to get on just fine with pencil and paper in the UK - in the case of a general (national) election, the results from most constituencies are available within a few hours of polls closing. The candidates can have observers in the polling stations and attend the count. That makes the whole process pretty transparent.
Even encouraging people to vote by post has led to a significant increase in electoral fraud (example) as it moves part of the process beyond direct observation.
Burying the entire process in software where it cannot be observed, except using unusual skill and effort, can only be justified if there is some manifest benefit that outweighs the cost of proper oversight. What could that possibly be?
HTML isn't ... very good ... for making Web pages
on
The Future of HTML
·
· Score: 1
I'd say that the real problem is that HTML isn't very good for anything else! By which I mean that in order to *display* a web page you really don't need much more than a set of tags pointing at appropriate bits of a CSS, so HTML is pretty much overkill since it gives you more tags than you really need for that purpose (now).
If you want usefully to store the information that's going to be rendered into a web page, you probably want to store some semantic information about the content of the text which you can later use to influence the way it's displayed (for example, distinguish which names in a court report refer to the accused, which to the victim and which to witnesses) but also the way in which the information can be navigated. The HTML spec makes a half-hearted stab at this by enabling you indicate which bits of the text are headings, but there's not a lot of other semantic information conveyed by tags (and where there was the tags were typically misused for their formatting side-effects).
XML is much more flexible about allowing the markup of semantic content - a browser could (under certain circumstances) use XML+CSS without having necessarily to understand any XML schema or XHTML, but even XML has problems with overlapping and discontiguous semantic blocks.
There's a big difference between putting a document on screen for someone to read and marking it up for semantic content: there's more cruft in HTML than is required for the former and nothing to assist with the latter.
If you use any AV system in a mode in which it checks every file on being opened then it's a drag on system resources: it's a second order issue as to whether one product is slower than another.
It's also a very bizarre concept to sell something that's inherently dangerous without an unrelated product. You'd never sell a toaster if you had to buy a 3rd party device to make sure the bread didn't burn...
Not true. By the 1980s every "serious" operating system had the kind of "protection" that had been around since Multics: protection of one user from another. That just doesn't cut it when it comes to protecting the user from himself (or worse, from the operating system itself).
Microprocessors moved things backwards with their total lack of memory protection or processor modes, but once this problem was eradicated it was simply a return to the status quo ante.
A client of mine recently bought some new, relatively-fast (albeit Celeron) laptops. They have Windows XP SP2 (with firewall) but came also with a Symantec anti-virus product which also has its own firewall. They have subsequently installed the Microsoft anti-spyware software. That's a lot of software which not only has to intercept and check the "useful" software on the machine but also find time and bandwidth to update itself.
The machines run like dogs, slower than the 300Mhz machine I have which happily runs Windows 2K - without virus scanners, firewalls and assorted software. And the firewall product (redundant with SP2) is active even when it's turned off, preventing filesharing from working.
A relative has a kiddie-safe product which acts as a web proxy as well as the antivirus and anti-spyware products: it takes about 20 minutes for his machine to become usable after it is rebooted because of the various startup activities of these "security" products. You can hardly coax Office into life once the 20 minutes have passed.
The malware/firewall approach to computer security is simply broken - it slows the machine down and stops things (like networking) working in ways that the average user will simply be at a loss to fix.
I wouldn't advise anyone with a clue about computers to use anti-virus software and for those without a clue, it's a heavy price to pay in resource terms.
Unfortunately, the science of Operating Systems has mainly stagnated since the 1960s and building computer systems for the networked world needs a radically different approach.
This is one of the arguments frequently lobbed at the licence-fee funding of the BBC by commercial broadcasters in the UK (and in particular Murdoch's Sky and its press affiliates). "Why should the public be forced to pay for channels they don't want to watch?", the argument goes. The US is then cited as an example of where a wealth of different interests are served by cable channels for which people choose to pay. Strangely, no-one ever mentions the must-carry provisions which appear to support this diversity.
Future funding of the BBC is still being discussed and it will be interesting to see if this change in US regulation goes ahead what effect it turns out to have.
If you happen to have a distribution that by default provides apt-get (I note you're a Debian user) and you happen to want the features compiled into the debian package then you might just have it easy. Not necessarily - you might have another multimedia application that has conflicting requirements on the version of ffmpeg, for example, but probably it might work.
If you look beyond the pretty coloured icons you'll find the availability of packages for many distributions is not what it appears. You'll find comments such as:
"We currently do not have an official VLC media player package for SUSE"
or
"To get the latest VLC media player version, please use one of the Unofficial Fedora Core packages"
The latter of which assumes a certain amount of expertise in configuring yum to include additional repositories, which the average user in search of a media player might not have.
And even if you do, I suspect you will find that, for example, that DVB support may not be provided. So if you want that, you might have to resort to the source, where you will find a list of dependencies marked:
"Warning, this package list is mostly outdated."
And when you start to sort that out, you might just find if (for example) you're running Fedora Core 4 that the version of gcc you have by default won't actually compile some of that stuff anyway.
All of which is fine if you have a computer because your hobby is software development and an infinite amount of spare time and patience. Most people, though, just want to install the software and have it work as described and telling them that they can't because "Linux" is a kernel is not really assisting them in that endeavour...
VLC manages to embody the essential dichotomy of the OSS vs Proprietary Software debate.
Get an installer for Windows or the Mac and you get a useful multi-purpose tool that has more flexibility and fewer restrictions than the equivalent commercial software.
Try to install it on Linux and you realise the advantages of a commercial platform onto which you simply install binary application packages. There are *some* packages available for VLC, provided you happen to have the right version of the right Linux distribution, but most have some important features configured out. Try to compile it yourself and get ready for a nightmare of dependencies on specific (sometimes elderly) versions of obscure libraries, header files that your Linux distribution didn't think to provide and a number of other little glitches that have you tearing your hair out. Or, more likely, giving up.
Now if only there were an open platform onto which you could simply copy an open application and just have it run...
I've had the dubious privilege of attempting to convert a web app that was originally designed to use Microsoft Access (don't laugh, it's a surprisingly capable performer for web applications provided you use the OLEDB driver) to both postgreSQL and MySQL. On the whole, the postgreSQL port was relatively painless (apart from the fact that the ODBC driver sometimes returns spurious null rows) and allowed some of the application logic to be simplified by making use of triggers and stored procedures. The MySQL port turned out not to be worth the effort at the time (MySQL version 4.1) since the lack of subqueries and views would have meant an inordinate amount of change to the application code.
The "new" additional features in MySQL don't make it "enterprise class" - they're nothing to do with scale - they simply make it possible to use MySQL for a wider range of real-world problems than has hitherto been possible.
If the British collection society should disappear, it would be the death of an old and venerable joke which goes back as least as far as Morecambe and Wise:
Are you from the Performing Rights Society?
Well, tell these musicians they aren't performing right.
I'd be interested to know what the performance impact of this is - exactly what counts as "too much of a slowdown".
Application heap allocation has "traditionally" been fairly inexpensive unless the heap has to be grown (update a couple of free block pointers/sizes) and the cost of growing the heap (which requires extending the virtual address space and therefore fiddling with page tables which would on a typical CPU require a mode change) is mitigated by allocating more virtual address space than is immediately needed.
If free space is always unmapped then each block allocation will require an alteration to the page tables, as will each unallocation. Not to mention that could cause the page-translation hardware to operate sub-optimally since the range of addresses comprising the working set will constantly change.
If most allocations are significantly less than a page size, then the performance impact may be minimal since whole pages will rarely become free, but if allocations typically exceed a page size, that would no longer be true. If the result is that some applications simply implement their own heap management to avoid the overhead, then you've simply increased the number of places that bugs can occur.
As far as I recall, journalists are explicitly excluded from the visa waiver programme. Journalists wishing to enter the United States have a wholly separate visa category.
In some ways this reminds me of the final death throes of Digital Equipment - the company had lost its way and multiple restructurings and board-level turmoil only made that worse.
On the other hand, when a company is producing products people want to buy, then the only thing management can really screw up is the financials. In the case of Microsoft, I see no sign that Windows or Office sales are going to plummet: the company is not exactly short of either revenue or cash.
What killed DEC was an environmental shift from minicomputers to PCs and betting against TCP/IP. I don't see any similar environmental shift threatening Microsoft in the short to medium term: OSS has pretty well missed the boat on that one and there's nothing similarly threatening on the horizon, yet. There will be of course: it's in the nature of technology companies to have their feet mired in legacy support and consequently to drown when the next wave of innovation eventually floods in.
A similar scheme (http://www.politics.co.uk/public-services/hodge-c hildrens-database-will-not-be-it-disaster-$7765060 .htm) is being planned for the UK. It follows the high-profile death of an abused child who was "known" to a variety of agencies who failed to communicate with each other. Whilst the motives appear to be virtuous, the possible implications of the scheme are serious and the benefits extremely dubious.
This is really about Microsoft staking its claim in an emerging market. It doesn't mean they're going to strike oil. WebTV hasn't really led to a rush to adopt a Microsoft-dominated media/PC convergence model. And neither has Windows MCE. Microsoft's ventures outside its traditional Windows and Office franchises have not been particularly successful.
Nobody would think of phoning people through their PC if there wasn't temporarily a tariff anomaly - that's simply not going to persist in the long term.
The kind of thing that will persist is a rather different kind of innovative integration that delivers services that can be used on familiar devices (phones, televisions, etc) as well as PCs - an example of which might be HomeChoice.
I really don't know. However, if I have VoIP service from Company A running over broadband from Company B using wires provided by Company C and wish to communicate with another party with services from D, E and F, then how do I identify which of (A, B, C, D, E, F) might be required to resolve the problem - and if the problem is with one or more of (D, E, F), with whom I have no contractual relationship, what incentive is there for them to fix it?
These are issues that have been addressed by fixed-line telephone companies by virtue of monopoly or regulation: VoIP will ultimately need one or the other if it's going to make it to granny territory. More likely, though, as telephone companies replace their circuit-switching kit with cheaper packet-switching kit, POTS costs will come down to a point at which granny can't see much of a saving(s) anyway.
Another reason the DVD case has its present size is so that it can occupy the retail shelving which previously held VHS tapes without the shelves looking bare...
As I understand it, the problem has not been so much in identifying people who may have been present, but in identifying the body parts relating to specific individuals so that the "correct" bits can be returned to relatives.
RFID tags would not help in this process, unless they were ubiquitous throughout the body. People already have deeply-embedded and widely-distributed tissue identification in the form of DNA. Given that it has apparently been necessary to resort to collecting maggots from the scene of the tube bombing(infested with rodents and with the temperature reaching 60C) to assist with the DNA identification of human fragments, the situation is far beyond one for which a simple technical fix is available.
Whilst I sympathise tremendously with the relative's desire for certain knowledge - and indeed their desire to be protected from the full horror - it does them a great disservice to pretend that there's an alternative. Not to mention the undervaluing of the forensic teams whose jobs must have been almost unbearable.
Slashdot Mirror
Indeed: there's a very simple test - if it were wanted it would have been adopted by now!
There was a powerful driver to IPv6 - the shortage of IPv4 addresses - but the people working on it couldn't resist the urge to try and solve a bunch of other less pressing problems while they were at it. The practical experience of people who've been in this kind of "upgrade" situation before is that unless you have absolute central control over the network you have to do migrations in very simple, evolutionary steps which network operators across the globe are prepared to buy into as an adjunct to their main task which is keeping the current version of the network running. IPv6 just has too many new things in it for network operators to do it in one hit while they're doing their day jobs.
There were loud voices warning the IPv6 group of the practical migration problems, but the idea of joining the ranks of the IETF immortals by finding the "ultimate answer to networking and everything" was a powerful spur to ever greater complexity.
And we didn't run out of IPv4 addresses. Or, rather, most of us realised that whilst in theory having a unique network address for every bit of kit might be ideal, in practice we don't want to have to be continuously upgrading the anti-virus protection on our toasters. So, hello NAT and friends. What we actually need are some solutions higher up the protocol stack that make network-layer relays (such as NAT systems) more robust* (heck, you could even make a virtue out of protection at the network border) by separating the concepts of "end point" address and "network" address.
Unfortunately, the unique-address-for-everything zealots have been buggering up the application protocols in the meantime and passing raw IP addresses around: just when you thought passive mode in FTP had fixed that application, some idiot makes exactly the same mistake in SIP.
So: IPv6 isn't going to catch on and IPv4 is increasingly broken. And the Internet justs creaks along as usual...
*No: I don't mean UPnP.
Indeed, it might ultimately be advantageous to Microsoft to open up the protocols. All computer companies in history have had a time-limited opportunity to exploit a particular technical niche and most have disappeared when the time limit expired.
An appropriate comparison would be Digital Equipment. Some of the biggest networks in the world at one time were based on DECnet, which it kept for the most part proprietary. When TCP/IP came along it took away a significant market not because TCP/IP excluded DEC computers, but because DEC computers couldn't connect to machines for which there was no licensed implementation of DECnet unless they used TCP/IP - so everyone switched. DEC suddenly had a good plan: produce a new version of DECnet which was compliant with open standards, but it came along too late, had too many problems with backwards compatibility, so bye-bye DECnet and bye-bye DEC.
Microsoft might well lose short-term market share by opening up its networking protocols, but in the long term it's probably the only way to keep a proportion of the market for this type of product. It all depends how far ahead your shareholders will allow you to plan...
You can (usually) get a "normal" hotel in London from one of the budget chains for around the $70 mark (depending on area). The last time I checked "easyHotel" (http://www.easyhotel.com/), who pioneered the reduced-cost hotel concept, their prices were typically higher (up to $80 per night) than I could get in a number of conventional hotels that offered more space and a higher level of service. Accor (the French chain that operates Motel 6, Ibis, Novotel et al) already operates the Formule 1 brand (http://www.hotelformule1.com/) which provides automated checkin and basic rooms from around $50 in (the environs of) London and don't vary their prices according to demand the way easyHotel do.
The only thing that seems to distinguish the Yotel is "designer" styling - and it will be interesting to see how this stands up to the wear and tear of a small space with high occupancy levels...
Still, if they manage to deliver a hotel which meets the three basic requirements of a hotel - cleanliness, a working shower and a room quiet enough to sleep in - they'll be doing better than the majority of establishments out there!
I'm curious about the motives for electronic voting.
We seem to get on just fine with pencil and paper in the UK - in the case of a general (national) election, the results from most constituencies are available within a few hours of polls closing. The candidates can have observers in the polling stations and attend the count. That makes the whole process pretty transparent.
Even encouraging people to vote by post has led to a significant increase in electoral fraud (example) as it moves part of the process beyond direct observation.
Burying the entire process in software where it cannot be observed, except using unusual skill and effort, can only be justified if there is some manifest benefit that outweighs the cost of proper oversight. What could that possibly be?
I'd say that the real problem is that HTML isn't very good for anything else! By which I mean that in order to *display* a web page you really don't need much more than a set of tags pointing at appropriate bits of a CSS, so HTML is pretty much overkill since it gives you more tags than you really need for that purpose (now).
If you want usefully to store the information that's going to be rendered into a web page, you probably want to store some semantic information about the content of the text which you can later use to influence the way it's displayed (for example, distinguish which names in a court report refer to the accused, which to the victim and which to witnesses) but also the way in which the information can be navigated. The HTML spec makes a half-hearted stab at this by enabling you indicate which bits of the text are headings, but there's not a lot of other semantic information conveyed by tags (and where there was the tags were typically misused for their formatting side-effects).
XML is much more flexible about allowing the markup of semantic content - a browser could (under certain circumstances) use XML+CSS without having necessarily to understand any XML schema or XHTML, but even XML has problems with overlapping and discontiguous semantic blocks.
There's a big difference between putting a document on screen for someone to read and marking it up for semantic content: there's more cruft in HTML than is required for the former and nothing to assist with the latter.
It ain't going away soon, though...
If you use any AV system in a mode in which it checks every file on being opened then it's a drag on system resources: it's a second order issue as to whether one product is slower than another.
It's also a very bizarre concept to sell something that's inherently dangerous without an unrelated product. You'd never sell a toaster if you had to buy a 3rd party device to make sure the bread didn't burn...
Not true. By the 1980s every "serious" operating system had the kind of "protection" that had been around since Multics: protection of one user from another. That just doesn't cut it when it comes to protecting the user from himself (or worse, from the operating system itself).
Microprocessors moved things backwards with their total lack of memory protection or processor modes, but once this problem was eradicated it was simply a return to the status quo ante.
A client of mine recently bought some new, relatively-fast (albeit Celeron) laptops. They have Windows XP SP2 (with firewall) but came also with a Symantec anti-virus product which also has its own firewall. They have subsequently installed the Microsoft anti-spyware software. That's a lot of software which not only has to intercept and check the "useful" software on the machine but also find time and bandwidth to update itself.
The machines run like dogs, slower than the 300Mhz machine I have which happily runs Windows 2K - without virus scanners, firewalls and assorted software. And the firewall product (redundant with SP2) is active even when it's turned off, preventing filesharing from working.
A relative has a kiddie-safe product which acts as a web proxy as well as the antivirus and anti-spyware products: it takes about 20 minutes for his machine to become usable after it is rebooted because of the various startup activities of these "security" products. You can hardly coax Office into life once the 20 minutes have passed.
The malware/firewall approach to computer security is simply broken - it slows the machine down and stops things (like networking) working in ways that the average user will simply be at a loss to fix.
I wouldn't advise anyone with a clue about computers to use anti-virus software and for those without a clue, it's a heavy price to pay in resource terms.
Unfortunately, the science of Operating Systems has mainly stagnated since the 1960s and building computer systems for the networked world needs a radically different approach.
This is one of the arguments frequently lobbed at the licence-fee funding of the BBC by commercial broadcasters in the UK (and in particular Murdoch's Sky and its press affiliates). "Why should the public be forced to pay for channels they don't want to watch?", the argument goes. The US is then cited as an example of where a wealth of different interests are served by cable channels for which people choose to pay. Strangely, no-one ever mentions the must-carry provisions which appear to support this diversity.
Future funding of the BBC is still being discussed and it will be interesting to see if this change in US regulation goes ahead what effect it turns out to have.
If you look beyond the pretty coloured icons you'll find the availability of packages for many distributions is not what it appears. You'll find comments such as:
"We currently do not have an official VLC media player package for SUSE"
or
"To get the latest VLC media player version, please use one of the Unofficial Fedora Core packages"
The latter of which assumes a certain amount of expertise in configuring yum to include additional repositories, which the average user in search of a media player might not have.
And even if you do, I suspect you will find that, for example, that DVB support may not be provided. So if you want that, you might have to resort to the source, where you will find a list of dependencies marked:
"Warning, this package list is mostly outdated."
And when you start to sort that out, you might just find if (for example) you're running Fedora Core 4 that the version of gcc you have by default won't actually compile some of that stuff anyway.
All of which is fine if you have a computer because your hobby is software development and an infinite amount of spare time and patience. Most people, though, just want to install the software and have it work as described and telling them that they can't because "Linux" is a kernel is not really assisting them in that endeavour...
I read that as "Vista Could Slip Earlier Than Expected". But I guess it depends on your expectations...
VLC manages to embody the essential dichotomy of the OSS vs Proprietary Software debate.
Get an installer for Windows or the Mac and you get a useful multi-purpose tool that has more flexibility and fewer restrictions than the equivalent commercial software.
Try to install it on Linux and you realise the advantages of a commercial platform onto which you simply install binary application packages. There are *some* packages available for VLC, provided you happen to have the right version of the right Linux distribution, but most have some important features configured out. Try to compile it yourself and get ready for a nightmare of dependencies on specific (sometimes elderly) versions of obscure libraries, header files that your Linux distribution didn't think to provide and a number of other little glitches that have you tearing your hair out. Or, more likely, giving up.
Now if only there were an open platform onto which you could simply copy an open application and just have it run...
Omar could soon be subject to an import tariff:
0 496.stm
http://news.bbc.co.uk/1/hi/entertainment/arts/436
Quite.
I've had the dubious privilege of attempting to convert a web app that was originally designed to use Microsoft Access (don't laugh, it's a surprisingly capable performer for web applications provided you use the OLEDB driver) to both postgreSQL and MySQL. On the whole, the postgreSQL port was relatively painless (apart from the fact that the ODBC driver sometimes returns spurious null rows) and allowed some of the application logic to be simplified by making use of triggers and stored procedures. The MySQL port turned out not to be worth the effort at the time (MySQL version 4.1) since the lack of subqueries and views would have meant an inordinate amount of change to the application code.
The "new" additional features in MySQL don't make it "enterprise class" - they're nothing to do with scale - they simply make it possible to use MySQL for a wider range of real-world problems than has hitherto been possible.
If the British collection society should disappear, it would be the death of an old and venerable joke which goes back as least as far as Morecambe and Wise:
Are you from the Performing Rights Society?
Well, tell these musicians they aren't performing right.
It sounded better in black and white...
I'd be interested to know what the performance impact of this is - exactly what counts as "too much of a slowdown".
Application heap allocation has "traditionally" been fairly inexpensive unless the heap has to be grown (update a couple of free block pointers/sizes) and the cost of growing the heap (which requires extending the virtual address space and therefore fiddling with page tables which would on a typical CPU require a mode change) is mitigated by allocating more virtual address space than is immediately needed.
If free space is always unmapped then each block allocation will require an alteration to the page tables, as will each unallocation. Not to mention that could cause the page-translation hardware to operate sub-optimally since the range of addresses comprising the working set will constantly change.
If most allocations are significantly less than a page size, then the performance impact may be minimal since whole pages will rarely become free, but if allocations typically exceed a page size, that would no longer be true. If the result is that some applications simply implement their own heap management to avoid the overhead, then you've simply increased the number of places that bugs can occur.
As far as I recall, journalists are explicitly excluded from the visa waiver programme. Journalists wishing to enter the United States have a wholly separate visa category.
In some ways this reminds me of the final death throes of Digital Equipment - the company had lost its way and multiple restructurings and board-level turmoil only made that worse.
On the other hand, when a company is producing products people want to buy, then the only thing management can really screw up is the financials. In the case of Microsoft, I see no sign that Windows or Office sales are going to plummet: the company is not exactly short of either revenue or cash.
What killed DEC was an environmental shift from minicomputers to PCs and betting against TCP/IP. I don't see any similar environmental shift threatening Microsoft in the short to medium term: OSS has pretty well missed the boat on that one and there's nothing similarly threatening on the horizon, yet. There will be of course: it's in the nature of technology companies to have their feet mired in legacy support and consequently to drown when the next wave of innovation eventually floods in.
A similar scheme (http://www.politics.co.uk/public-services/hodge-c hildrens-database-will-not-be-it-disaster-$7765060 .htm) is being planned for the UK. It follows the high-profile death of an abused child who was "known" to a variety of agencies who failed to communicate with each other. Whilst the motives appear to be virtuous, the possible implications of the scheme are serious and the benefits extremely dubious.
This is really about Microsoft staking its claim in an emerging market. It doesn't mean they're going to strike oil. WebTV hasn't really led to a rush to adopt a Microsoft-dominated media/PC convergence model. And neither has Windows MCE. Microsoft's ventures outside its traditional Windows and Office franchises have not been particularly successful.
Nobody would think of phoning people through their PC if there wasn't temporarily a tariff anomaly - that's simply not going to persist in the long term.
The kind of thing that will persist is a rather different kind of innovative integration that delivers services that can be used on familiar devices (phones, televisions, etc) as well as PCs - an example of which might be HomeChoice.
I really don't know. However, if I have VoIP service from Company A running over broadband from Company B using wires provided by Company C and wish to communicate with another party with services from D, E and F, then how do I identify which of (A, B, C, D, E, F) might be required to resolve the problem - and if the problem is with one or more of (D, E, F), with whom I have no contractual relationship, what incentive is there for them to fix it?
These are issues that have been addressed by fixed-line telephone companies by virtue of monopoly or regulation: VoIP will ultimately need one or the other if it's going to make it to granny territory. More likely, though, as telephone companies replace their circuit-switching kit with cheaper packet-switching kit, POTS costs will come down to a point at which granny can't see much of a saving(s) anyway.
"Operator, I'm trying to call my elderly mother, but there seems to be a fault..."
"Sir, you'll have to have your mother run traceroute and then call us back."
"How do I call my mother to tell her and how does she run traceroute?"
"Perhaps you can download the instructions from our website and mail them to her?"
Another reason the DVD case has its present size is so that it can occupy the retail shelving which previously held VHS tapes without the shelves looking bare...
As I understand it, the problem has not been so much in identifying people who may have been present, but in identifying the body parts relating to specific individuals so that the "correct" bits can be returned to relatives.
RFID tags would not help in this process, unless they were ubiquitous throughout the body. People already have deeply-embedded and widely-distributed tissue identification in the form of DNA. Given that it has apparently been necessary to resort to collecting maggots from the scene of the tube bombing(infested with rodents and with the temperature reaching 60C) to assist with the DNA identification of human fragments, the situation is far beyond one for which a simple technical fix is available.
Whilst I sympathise tremendously with the relative's desire for certain knowledge - and indeed their desire to be protected from the full horror - it does them a great disservice to pretend that there's an alternative. Not to mention the undervaluing of the forensic teams whose jobs must have been almost unbearable.