And that last part is precisely why it could be done on DOS. With no multitasking this is trivial. On a modern multitasking OS, there are things that access the disk for reasons of their own, at unknown intervals.
Back when DOS was used, experts knew how their computer worked so well that they could know the purpose of every executable file, and knew when the computer was supposed to be writing to disk. You could figure out whether the computer was infected with a virus when the floppy drive or hard disk made a noise at a moment it shouldn't.
This no longer works in the modern world, especially on Windows (Linux is open and can be cut down enough that you can figure out what's going on). With the current virus scanners, file indexers, programs attempting to optimize by doing their own caching, the OS' own caching, usage of complex file formats, etc, it's no longer possible to predict when the disk is going to be accessed.
Yes, it's doable if you only use your removable storage to copy files to it, and then from it, but if you actually open some types of files on the removable drive, access patterns stop being predictable. Wow.
Write through caching can be done on any OS. It's a subset of write back caching. It doesn't have anything to do with the 'access patterns stopping being predictable' though - it's a cache policy. You check if the drive is removable and set the policy to write through, if not you allow write back - that's the change in Windows XP compared to 2000. Write through means you write blocks to disk before you return from the file write call, write back means you keep them in memory and then write them back at some later time.
So on a removable disk, once the write operation has finished the drive can be yanked. On a non removable one you can keep a list of dirty blocks in memory and then use some algorithm to write them back in an optimal order. So the non removable drives are as fast as possible and the removable ones are as safe as possible. If you yank the removable drive in the middle of write though, data will still be lost. But there's not much you can do about that.
Seems like PC USB are processor intensive - it use up an interrupt and fill a small buffer. Actually USB is quite system friendly. The CPU maintains a complicated tree structures of descriptors memory and then the host adapter parses it via bus master DMA and generates the appropriate bust transactions.
The CPU can request an interrupt when a transfer is complete or at the end of a frame to add new descriptors and remove ones that have completed. It's all pretty elegant really. Essentially when you want to send something you add a descriptor and then later you get an interrupt when the transfer is done, even if it took a few retries. It has to be like this, since Windows 95 had terrible worst case interrupt latency and that was where USB started off.
I dunno, I find the colors on my expensive dye sublimation printer are much more saturated and full bodied when I use a mid range $99.99 isotopically pure solid gold cable than a cheap $29.99 gold plated one. I don't think the the $299 solid platinum USB cables are worth the price though.
Will the new spec allow for super long USB cables? I doubt it. It's a marketing nightmare to sell someone a 10m cable and have them bring it back because it doesn't work with the USB 2.0 PC, or a USB 3.0 PC connected to a USB 2.0 device. Not that they're likely to know that they have USB 2.0, they'll just know that the "USB 3.0 only 10m cable" doesn't work.
Actually for peripheral manufacturers it's even more stark choice. If you have cheap microcontroller with a USB interface, and there is a very wide choice of them, writing the embedded software is absolutely trivial and there are loads of resources on the net if you get stuck. It's one of those things that's become very widely understood amongst engineers like all the other PC standards. I don't think Firewire is anything like that.
Actually USB does have a strange mode called USB On the Go. The idea is that the bus mastership can be passed around on the bus. It's not general though and PCs don't implement it as far as I know. It's designed so that PDAs and printers can act as device when a PC is present and a master when it isn't.
But yeah, Firewire was in retrospect a much better design that USB. The power supply issue is just another example of this.
USB has isochronous transfers too. The USB hub driver dedicates some of the frame time to isochronous transfers and some to interrupt transfers for polling mice and keyboards. Whatever is left is used for bulk transfers for things like USB storage devices.
From my experience USB is significantly (IIRC 20MB/sec 30MB/sec for reads) slower than Firewire for storage devices though even when each bus had only one device on it, so there must be some inefficiency in the USB mass storage specification. Then again maybe the USB/Firewire 2.5" drive I tested just had a more optimised Firewire implementation.
The first versions of smartdrive on Dos used write back caching which meant that the drive could be corrupted if you flicked the power switch immediately after copying a file. It would write cached data back when the system was idle, and could hook Ctrl Alt Delete and flush the cache before a reboot.
Later versions worked in a write through cache mode where the cache was guaranteed to have been written back by the time the Dos prompt came back. So it could be done, even in a tiny OS written mostly assembly language with no background processes.
As far as I know Windows 2000 does write caching on removable drives and relies on the user to stop them to flush the cache by clicking on an icon in the taskbar. Most users and a fair minority of programmers can't handle this concept properly - I've worked with people who've copied a zip file to a USB stick and then immediately disconnected it, ignoring the "Unsafe Removal" warning and my comment that this was a stupid thing to do. Later I rebooted a laptop with the stick plugged in and watched in total horror as chkdsk removed vital file.
XP and later only read cache on removable disks and lets you yank them whenever you want. Since there is no write caching, once a file has been copied it's really there on disk, not sitting in a cache. So USB sticks are slow but work for people who are dumb enough to ignore warnings about data loss. You can still override this though, right click on the drive, select properties and deselect the "Optimize for quick removal" checkbox. Then you have write caching enabled and you need to stop them using the taskbar icon or you'll get the warning and occasional data loss.
Umm, congratulations. You took something you didn't understand and rewrote it so that you did. My guess is that no one else will be able to understand your code either. Now you've got the ultimate job security of being the only person who can add back in all the features that you removed that people really needed. The irony of your last comment is no doubt completely lost on you.
By resources I mean programmers. If the programmers spend all their time removing features from code, they won't be available to add them. Even worse, they might not want to anymore.
You're missing the point, I'm advocating writing ugly code. I'm talking about code that has become complex through years of bug fixes and feature additions. That code is very valuable to the company that owns it. It's a compressed solution to problems customers have complained about its life. Refactoring throws away most of that.
I've worked at a load of places where there's insufficient resources to do things that customers actually want, but an endless program to refactor away the ugliness of code. And the thing is, it's bullshit. Customers don't care how ugly the code is, so long as it works. And good programmers can deal with ugly code - it's just the sort of people who are obsessed with refactoring that can't. So next time you find a thousand line function, or code full of #ifdefs ask yourself how much of that complexity is there because some customer demanded it. Will your rewritten 'pretty' version duplicate all features that the ugly version has? Do you even understand which ones are features and which ones are bugs? If so, why do you want to refactor it? And if not, how can you expect to get it right first time and not provoke howls of protest from the people that use it.
And if anyone whines about how old code needs to be rewritten, point them at this
http://www.joelonsoftware.com/articles/fog0000000027.html
Old code doesn't rust, it gets better, as bugs are fixed. Lou Montulli again: "I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked." That's just in a PC application. Try refactoring the 'ugliness' out of an embedded system and see how long your employer still has customers, and how long you still have a job. And it's interesting that evolution, an unconscious process that far outperforms human 'intelligent' designers doesn't have any concept of ugliness at all. Maybe that concept is just an artifact of your limited ability to deal with complexity.
for some reason, Canadians get screwed Isn't that because they killed Jesus, convinced George Bush to quit coke and try his hand at politics, bought most of the singles Rick Astley sold and told George Lucas he was a competent scriptwriter on his own and didn't need to hire someone else to do it?
I ran XP on a laptop with a 1Ghz P3, 384MB of Ram and a 20GB hard drive for ages. It was never noticably slow at anything except for copying things to USB since it only had 1.0. Of course you wouldn't want to run memory hogging applications like Firefox on it but Opera and IE ran fine. But it did everything I needed, except for games.
I dunno about that. That assumes the original programmer knew the code was incomplete. Most of the time code has sat around for ages and been looked at by hundreds of people without anyone thinking about a situation where it would fail. Admittedly it's a lot easier to fix code if you have the source code, but it doesn't make it any easier to spot bugs. Whover said "many eyeballs make all bugs shallow" has never worked for a company with thousands of developers building real time systems. Maybe it's true of Perl scripts and the like.
That's not really fair. OSs now use virtual memory for protection. There are schemes to use canaries on the stack so that buffer overflows are guaranteed to cause a crash rather than an exploit - software can be updated over the net to fix the crashes. There is a move to VM based software like Java and.Net that uses garbage collection and can be statically verified before it is JITted to native code.
I don't really believe that segment based protection could ever have eliminated stack overflow exploits at an acceptable performance level. Look at the assembler for a function that uses stack variables - they are all allocated by a single subtract operation. If they were allocated individually as far pointers the OS would need to be called for each one. It would need to switch to kernel mode and modify the descriptor table and then return. Once the function was done the whole process would need to be repeated. Most C functions would run hundreds of times slower if this was the case.
The performance cost of VM based solutions is far lower and they can still be run on current PCs, not some radically new architecture which would probably spend most of short life emulating old code badly anyway. E.g if you look at Itanium it is far less radical than a stack based machine and yet it still failed because it had a relatively minor performance disadvantage on old binaries.
NT based OSs always use UTC internally. The RTC is in local time, because that's what the majority of PC based OSs (i.e. 16 bit Windows, Dos and probably OS/2 and Xenix) used to set it to -
http://blogs.msdn.com/oldnewthing/archive/2004/09/02/224672.aspx
Linux installs had to step carefully around how the clock was set, because if they were sharing a computer with an MSWind machine they shouldn't use UTC. Yeah, but it's very convenient for people dual booting between MS OSs. Maybe Linux should have adopted the PC platform de facto standard of setting the Bios to local time even if like NT based OSs it uses UTC internally. Then people using it wouldn't have been inconvenienced.
It's not about changing time, only the time zone. If Windows would store the system time in UTC this would only change the way the time is displayed to the user, not the internal time.
There is nothing sensitive about that. Windows system time has always been in UTC. By default before Vista both changing the time and changing the time zone required that the user running the program be in the admin group (though Admins could change this and let anyone do it), but in Vista Microsoft changed things so that unprivileged users could change the time zone -
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/23/security-features-vs-convenience.aspx
To do this, we had to go through the various system tasks that users perform and for each one ask the question: "should the user have to be an administrator to complete this task?" What we found was that in Windows XP there were many cases where we required the administrative privilege if the user was making a change that impacted the entire system (rather than just their user account). We subsequently learned that this was too broad a distinction and in fact, with some common sense rules, we could protect the system while still making it usable. We also found that there were many cases in previous versions of Windows where we had lumped things together when instead only part of the task really should have required the user to be an administrator. For example, in Windows XP you had to be an administrator in order to change the time or the time zone of the system. The reason that time functions are usually restricted is that you can do some pretty sneaky things if you can change the system time -- like trick system logs or backdate emails. But as it turns out, changing the time zone of the machine so that a business traveler based on the West Coast goes to their meetings at the right time when they are visiting New York really doesnt need to be protected -- so in Windows Vista, we split that out and now allow a standard user to change the time zone. If you have a Vista machine, try it. Right click on the clock in task bar and choose Adjust Date and Time. Changing the time requires a UAC prompt, changing the time zone does not.
Incidentally Windows system time is stored as a 64 bit count of 100ns intervals since 1601. Why 100ns? Larry Osterman said http://blogs.msdn.com/oldnewthing/archive/2004/08/25/220195.aspx#220259
Because 100ns is "good enough". You can represent any date from the 1601 to the year 20,000 in 64bits worth of 100ns units.
1ns is too small, it runs out in 200 years. 1000ns is too granular for some clock speeds (it's 1/10th of a millisecond). Interesting, eh? 200 years was regard as too short a lifetime for NT based OSs and APIs, Dave Cutler probably expects NT to have a thousand year reign;-) . And 1000ns was too granular. Some book I read commented that the range of FILETIME is ok, but "in twenty years 100ns will be seen as hopelessly coarse"
Unix by contrast uses a 32 bit count of seconds which is both too coarse and will run out in a mere 30 years.
That's a problem with British people though isn't it? I've never heard of glassing people anywhere other than Britain.
England seems to be entering a wierd sort of state where if you bash someone in the face with a glass, which should be attempted murder and punishable with a life sentence, the pub is somehow at fault for giving you a glass, so everyone is given plastic ones instead. And if someone shoots up a school, everyone loses the right to join a shooting club. If there is any crime with knives, knives are banned. The actual perpetrators of the crimes tend to get a light sentence though compared to most other countries. It's almost like people are expected to be animals and the pub is responsible for their behaviour, a bit like a pet owner is of his pets.
Pretty soon I suspect there will be a Happy Slapping like craze for poking people in the eye with sharp fingernails and blinding them and then everyone in British will need to be declawed like pet cats. If you're still in Britain you'd better hope that the Happy Slappers don't start jackrolling women since the government might decide to castrate everyone like pets too.
Second, what are you going to do with all of those now-useless disks? As far as I know we don't have a reliable, biodegradable material out of which to make these disks Actually there is
So long as oil prices stay high, it's economic too. They quote $55 a barrel as making it attractive, my guess is that they should average well above that.
DIVX already proved there's no market for this, and trying it again isn't really all that productive. People who want the MPAA/RIAA to innovate want actual innovation, not rehashes of already-failed schemes. Cable on-demand programs, time limited DRMed online purchases, Xbox Live Video Marketplace, etc are all examples of viable approaches of innovating in content delivery. DIVX is a horrible, horrible failure. DIVX failed for a bunch of reasons. It's interesting that you think time limited DRMed online purchases are ok but time limited physical media is not. Time limited purchases are not inherently a bad idea, it's just that DIVX botched the implementation.
I think online DVD purchasing is not really viable at the moment since most people don't have a fast enough internet connection to make it work. There's a user friendliness issue too - people would presumably need to install special software to handle the download and enforce the DRM. And PCs are much too hackable for this sort of application because it only takes one person with a bit of reverse engineering experience and any DRM can be cracked. Plus most people don't like watching movies on their PCs. Certainly my parents generation would never do so, even though they're quite happy with a DVD player. They're not interested in watching movies more than once too.
I can vaguely imagine it working with cell phones though, provided bandwidth was cheap enough. You could stream the video too, so the handsets stay affordable. Cell phones are much harder to crack than PCs. And at least in Asia people are used to watching video on their cell phones. Admittedly that's broadcast TV and mostly because it is free. And cell phones don't really seem like a good platform for watching movies.
Perhaps it could work with satellite boxes though. Though in the UK video on demand for satellite doesn't really seem to have taken off.
But I'd still go for a time limited physical media over any online distribution method, just based on the way my parents are quite happy to spend a few hundred dollars on a decent video disk player for the living room but would not be at all concerned about disks that expired. The disks would need to be environmentally friendly in some way though. Maybe if they biodegraded or turned into blank writable disks it would be ok. It should also be possible to use the disks on most players, so it should be part of the standard to succeed. I'm not sure if BluRay actually allows this. Certainly if I designed it I'd add support, just in case one of the licensees wants to try it as a business model.
Slashdot Mirror
You should make sure the garbage bins are in a separate countries too. One of the countries should then be destoyed with thermonuclear warheads.
You know who else lived in Whittier? Richard Nixon!
Back when DOS was used, experts knew how their computer worked so well that they could know the purpose of every executable file, and knew when the computer was supposed to be writing to disk. You could figure out whether the computer was infected with a virus when the floppy drive or hard disk made a noise at a moment it shouldn't.
This no longer works in the modern world, especially on Windows (Linux is open and can be cut down enough that you can figure out what's going on). With the current virus scanners, file indexers, programs attempting to optimize by doing their own caching, the OS' own caching, usage of complex file formats, etc, it's no longer possible to predict when the disk is going to be accessed.
Yes, it's doable if you only use your removable storage to copy files to it, and then from it, but if you actually open some types of files on the removable drive, access patterns stop being predictable. Wow.
Write through caching can be done on any OS. It's a subset of write back caching. It doesn't have anything to do with the 'access patterns stopping being predictable' though - it's a cache policy. You check if the drive is removable and set the policy to write through, if not you allow write back - that's the change in Windows XP compared to 2000. Write through means you write blocks to disk before you return from the file write call, write back means you keep them in memory and then write them back at some later time.
So on a removable disk, once the write operation has finished the drive can be yanked. On a non removable one you can keep a list of dirty blocks in memory and then use some algorithm to write them back in an optimal order. So the non removable drives are as fast as possible and the removable ones are as safe as possible. If you yank the removable drive in the middle of write though, data will still be lost. But there's not much you can do about that.
The CPU can request an interrupt when a transfer is complete or at the end of a frame to add new descriptors and remove ones that have completed. It's all pretty elegant really. Essentially when you want to send something you add a descriptor and then later you get an interrupt when the transfer is done, even if it took a few retries. It has to be like this, since Windows 95 had terrible worst case interrupt latency and that was where USB started off.
I dunno, I find the colors on my expensive dye sublimation printer are much more saturated and full bodied when I use a mid range $99.99 isotopically pure solid gold cable than a cheap $29.99 gold plated one. I don't think the the $299 solid platinum USB cables are worth the price though.
But it doesn't really matter. Just get a bunch of 5m cables and hubs and string them together.
Actually for peripheral manufacturers it's even more stark choice. If you have cheap microcontroller with a USB interface, and there is a very wide choice of them, writing the embedded software is absolutely trivial and there are loads of resources on the net if you get stuck. It's one of those things that's become very widely understood amongst engineers like all the other PC standards. I don't think Firewire is anything like that.
If you want people skills go post on kuro5hin.
Actually USB does have a strange mode called USB On the Go. The idea is that the bus mastership can be passed around on the bus. It's not general though and PCs don't implement it as far as I know. It's designed so that PDAs and printers can act as device when a PC is present and a master when it isn't.
But yeah, Firewire was in retrospect a much better design that USB. The power supply issue is just another example of this.
USB has isochronous transfers too. The USB hub driver dedicates some of the frame time to isochronous transfers and some to interrupt transfers for polling mice and keyboards. Whatever is left is used for bulk transfers for things like USB storage devices.
From my experience USB is significantly (IIRC 20MB/sec 30MB/sec for reads) slower than Firewire for storage devices though even when each bus had only one device on it, so there must be some inefficiency in the USB mass storage specification. Then again maybe the USB/Firewire 2.5" drive I tested just had a more optimised Firewire implementation.
The first versions of smartdrive on Dos used write back caching which meant that the drive could be corrupted if you flicked the power switch immediately after copying a file. It would write cached data back when the system was idle, and could hook Ctrl Alt Delete and flush the cache before a reboot.
Later versions worked in a write through cache mode where the cache was guaranteed to have been written back by the time the Dos prompt came back. So it could be done, even in a tiny OS written mostly assembly language with no background processes.
As far as I know Windows 2000 does write caching on removable drives and relies on the user to stop them to flush the cache by clicking on an icon in the taskbar. Most users and a fair minority of programmers can't handle this concept properly - I've worked with people who've copied a zip file to a USB stick and then immediately disconnected it, ignoring the "Unsafe Removal" warning and my comment that this was a stupid thing to do. Later I rebooted a laptop with the stick plugged in and watched in total horror as chkdsk removed vital file.
XP and later only read cache on removable disks and lets you yank them whenever you want. Since there is no write caching, once a file has been copied it's really there on disk, not sitting in a cache. So USB sticks are slow but work for people who are dumb enough to ignore warnings about data loss. You can still override this though, right click on the drive, select properties and deselect the "Optimize for quick removal" checkbox. Then you have write caching enabled and you need to stop them using the taskbar icon or you'll get the warning and occasional data loss.
Umm, congratulations. You took something you didn't understand and rewrote it so that you did. My guess is that no one else will be able to understand your code either. Now you've got the ultimate job security of being the only person who can add back in all the features that you removed that people really needed. The irony of your last comment is no doubt completely lost on you.
By resources I mean programmers. If the programmers spend all their time removing features from code, they won't be available to add them. Even worse, they might not want to anymore.
You're missing the point, I'm advocating writing ugly code. I'm talking about code that has become complex through years of bug fixes and feature additions. That code is very valuable to the company that owns it. It's a compressed solution to problems customers have complained about its life. Refactoring throws away most of that.
And if anyone whines about how old code needs to be rewritten, point them at this
http://www.joelonsoftware.com/articles/fog0000000027.html Old code doesn't rust, it gets better, as bugs are fixed. Lou Montulli again: "I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked." That's just in a PC application. Try refactoring the 'ugliness' out of an embedded system and see how long your employer still has customers, and how long you still have a job. And it's interesting that evolution, an unconscious process that far outperforms human 'intelligent' designers doesn't have any concept of ugliness at all. Maybe that concept is just an artifact of your limited ability to deal with complexity.
I ran XP on a laptop with a 1Ghz P3, 384MB of Ram and a 20GB hard drive for ages. It was never noticably slow at anything except for copying things to USB since it only had 1.0. Of course you wouldn't want to run memory hogging applications like Firefox on it but Opera and IE ran fine. But it did everything I needed, except for games.
I dunno about that. That assumes the original programmer knew the code was incomplete. Most of the time code has sat around for ages and been looked at by hundreds of people without anyone thinking about a situation where it would fail. Admittedly it's a lot easier to fix code if you have the source code, but it doesn't make it any easier to spot bugs. Whover said "many eyeballs make all bugs shallow" has never worked for a company with thousands of developers building real time systems. Maybe it's true of Perl scripts and the like.
He missed a trick though. He could have said the choice was between "walled garden data hoarders or a 1984 style world where people have no privacy"
That's not really fair. OSs now use virtual memory for protection. There are schemes to use canaries on the stack so that buffer overflows are guaranteed to cause a crash rather than an exploit - software can be updated over the net to fix the crashes. There is a move to VM based software like Java and .Net that uses garbage collection and can be statically verified before it is JITted to native code.
I don't really believe that segment based protection could ever have eliminated stack overflow exploits at an acceptable performance level. Look at the assembler for a function that uses stack variables - they are all allocated by a single subtract operation. If they were allocated individually as far pointers the OS would need to be called for each one. It would need to switch to kernel mode and modify the descriptor table and then return. Once the function was done the whole process would need to be repeated. Most C functions would run hundreds of times slower if this was the case.
The performance cost of VM based solutions is far lower and they can still be run on current PCs, not some radically new architecture which would probably spend most of short life emulating old code badly anyway. E.g if you look at Itanium it is far less radical than a stack based machine and yet it still failed because it had a relatively minor performance disadvantage on old binaries.
http://blogs.msdn.com/oldnewthing/archive/2004/09/02/224672.aspx Linux installs had to step carefully around how the clock was set, because if they were sharing a computer with an MSWind machine they shouldn't use UTC. Yeah, but it's very convenient for people dual booting between MS OSs. Maybe Linux should have adopted the PC platform de facto standard of setting the Bios to local time even if like NT based OSs it uses UTC internally. Then people using it wouldn't have been inconvenienced.
There is nothing sensitive about that. Windows system time has always been in UTC. By default before Vista both changing the time and changing the time zone required that the user running the program be in the admin group (though Admins could change this and let anyone do it), but in Vista Microsoft changed things so that unprivileged users could change the time zone -
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/23/security-features-vs-convenience.aspx To do this, we had to go through the various system tasks that users perform and for each one ask the question: "should the user have to be an administrator to complete this task?" What we found was that in Windows XP there were many cases where we required the administrative privilege if the user was making a change that impacted the entire system (rather than just their user account). We subsequently learned that this was too broad a distinction and in fact, with some common sense rules, we could protect the system while still making it usable. We also found that there were many cases in previous versions of Windows where we had lumped things together when instead only part of the task really should have required the user to be an administrator. For example, in Windows XP you had to be an administrator in order to change the time or the time zone of the system. The reason that time functions are usually restricted is that you can do some pretty sneaky things if you can change the system time -- like trick system logs or backdate emails. But as it turns out, changing the time zone of the machine so that a business traveler based on the West Coast goes to their meetings at the right time when they are visiting New York really doesnt need to be protected -- so in Windows Vista, we split that out and now allow a standard user to change the time zone. If you have a Vista machine, try it. Right click on the clock in task bar and choose Adjust Date and Time. Changing the time requires a UAC prompt, changing the time zone does not.
Incidentally Windows system time is stored as a 64 bit count of 100ns intervals since 1601. Why 100ns? Larry Osterman said
http://blogs.msdn.com/oldnewthing/archive/2004/08/25/220195.aspx#220259 Because 100ns is "good enough". You can represent any date from the 1601 to the year 20,000 in 64bits worth of 100ns units.
1ns is too small, it runs out in 200 years. 1000ns is too granular for some clock speeds (it's 1/10th of a millisecond). Interesting, eh? 200 years was regard as too short a lifetime for NT based OSs and APIs, Dave Cutler probably expects NT to have a thousand year reign
Unix by contrast uses a 32 bit count of seconds which is both too coarse and will run out in a mere 30 years.
I dunno, I'd pay to hear a Britney cover of "Wait for the Blackout". Particularly now she's a lot fucking crazier now than Dave Vanian ever was.
That's a problem with British people though isn't it? I've never heard of glassing people anywhere other than Britain.
England seems to be entering a wierd sort of state where if you bash someone in the face with a glass, which should be attempted murder and punishable with a life sentence, the pub is somehow at fault for giving you a glass, so everyone is given plastic ones instead. And if someone shoots up a school, everyone loses the right to join a shooting club. If there is any crime with knives, knives are banned. The actual perpetrators of the crimes tend to get a light sentence though compared to most other countries. It's almost like people are expected to be animals and the pub is responsible for their behaviour, a bit like a pet owner is of his pets.
Pretty soon I suspect there will be a Happy Slapping like craze for poking people in the eye with sharp fingernails and blinding them and then everyone in British will need to be declawed like pet cats. If you're still in Britain you'd better hope that the Happy Slappers don't start jackrolling women since the government might decide to castrate everyone like pets too.
http://jscms.jrn.columbia.edu/cns/2005-03-15/russell-cornplastic/
So long as oil prices stay high, it's economic too. They quote $55 a barrel as making it attractive, my guess is that they should average well above that. DIVX already proved there's no market for this, and trying it again isn't really all that productive. People who want the MPAA/RIAA to innovate want actual innovation, not rehashes of already-failed schemes. Cable on-demand programs, time limited DRMed online purchases, Xbox Live Video Marketplace, etc are all examples of viable approaches of innovating in content delivery. DIVX is a horrible, horrible failure. DIVX failed for a bunch of reasons. It's interesting that you think time limited DRMed online purchases are ok but time limited physical media is not. Time limited purchases are not inherently a bad idea, it's just that DIVX botched the implementation.
I think online DVD purchasing is not really viable at the moment since most people don't have a fast enough internet connection to make it work. There's a user friendliness issue too - people would presumably need to install special software to handle the download and enforce the DRM. And PCs are much too hackable for this sort of application because it only takes one person with a bit of reverse engineering experience and any DRM can be cracked. Plus most people don't like watching movies on their PCs. Certainly my parents generation would never do so, even though they're quite happy with a DVD player. They're not interested in watching movies more than once too.
I can vaguely imagine it working with cell phones though, provided bandwidth was cheap enough. You could stream the video too, so the handsets stay affordable. Cell phones are much harder to crack than PCs. And at least in Asia people are used to watching video on their cell phones. Admittedly that's broadcast TV and mostly because it is free. And cell phones don't really seem like a good platform for watching movies.
Perhaps it could work with satellite boxes though. Though in the UK video on demand for satellite doesn't really seem to have taken off.
But I'd still go for a time limited physical media over any online distribution method, just based on the way my parents are quite happy to spend a few hundred dollars on a decent video disk player for the living room but would not be at all concerned about disks that expired. The disks would need to be environmentally friendly in some way though. Maybe if they biodegraded or turned into blank writable disks it would be ok. It should also be possible to use the disks on most players, so it should be part of the standard to succeed. I'm not sure if BluRay actually allows this. Certainly if I designed it I'd add support, just in case one of the licensees wants to try it as a business model.