I personally find that moving my head to go from one task to another is much faster than finding and moving a window to change tasks. It's just a matter of a little window-placement and sizing displine. It's easy for me, but I can see why others would have trouble.
That being said, I'd be in favor of a window manager that help me enforce my window placement and sizing by logically segementing a single physical screen. That would give you the kind of segmenting you get from multiple monitors, but with the flexibility to easy remove or re-apportion the segments as your tasks changed.
You never run out of trackpad no matter how big your screen is. Plus you can "throw" the ball (i.e. push it very quickly then release it so that it continues to spin after you let go) to get across the monitor very quickly.
I personally like the Kensington Expert Mouse for the scroll wheel and the extra-large ball, but it's a bit pricey. I'm sure there are cheaper options available.
Yeah, and when you need to select 25 of 100 non-consecutive JPEG files from a folder to copy I'm sure you always use the command line instead of ctrl-click and drag.
I'm fixated on MS Word because that is the layout tool/word processor/text editor for the vast majority of the computing world. I'm glad you use other tools. I'm not denying that other tools exist or may be better for certain tasks. But when we're discussing generic office document creation -- like in this thread entitled "Google 'Office' Release" -- MS Word is the standard of comparision.
And as far as diffing MS Word files goes -- the change tracking in Word is hardly comparable to a standard diff mechanism. It is rudamentally the same, but it can only show you changes in place, it has extremely limited time-based tracking (i.e. you can't say "show me all changes between 2 weeks ago and 1 week ago") compared to CVS/SVN, and it has the potentially embarassing/damaging behavior of leaving your change history in the file unless you take extra care to delete that history.
RTF would make somewhat better use of CVS/SVN diffs, though the infrequent occurance of line breaks is still a bit of an issue. But if you think the average user -- you know, the guy the Google Office is targeted at -- is willing to:
A) select a non-default format every time he creates a document or uses "Save As..."
B) give up most of the features he needs to do layout work (i.e. turn Word into a word processor)
C) ignore the warning that Word gives often about losing formatting when you save to RTF
I think you're mistaken.
I think you're making three mistakes here. First, LaTeX is a layout application, than many people use for word processing. You can't compare it to MSWord and assume you've done a comparison of WYSIWYG versus markup.
I think you're making the mistake there. In general use, people make no distinction between a text editor, a word processor, and layout program.
For one thing, in Windows the only pre-installed "text editor" is Notepad, and even I can't be bothered to use that for text entry. So the distinction between "word processor" and "text editor" is lost on anyone who doesn't regularly fire up vim/emacs/nano/etc. Needless to say, this isn't the average MS Word user.
For another, most MS Office users, unless they are familar with publishing, use Word as a layout tool. Between the expense of having a dedicated layout tool, the complication of having to use more than one program, and the fact that MS has shoe-horned 473 "layout" features in Word, the average user doesn't even know that there's another way to do things. I agree that the world would be better if Word were a word processor and you imported its output into a layout program when layout was important, but in actual use that rarely happens.
Collaborating with LaTeX is a pain in the butt in almost every instance I've used it because their are invariably people who don't know the language and who then have to learn it, greatly slowing the whole process.
Slower than using MS Word or InDesign, both of which allow only 1 person at a time to work on a document? If you'd ever had to compile chapters from 30 people for a 500-page report you'd know that copy-and-pasting a Word document together is not the ideal scenario. Latex lets me include 30 chapter files into 1 book file and compile. That's worth 30 minutes of instruction on how to use header levels, paragraph marks, tables and include image files.
As for CVS and Subversion, I often use them to check in both binary and XML files from other word processors and layout applications and collaboration with them is not a problem using these tools.
I'd give good money to see you make a useful diff from a binary (i.e. MS Word) "text" file using CVS/SVN. Having old versions is not the only use of a version management system, nor even the one quoted in the parent -- version control with diffing capabilities.
It's somewhat more likely to be net-0 than you might think, even with carefully selected data sets. Most optical system encode data at somewhat more than 1 bit-per-bit, taking care to ensure that even extremely non-random data results in a sizeable number of on/off transitions. Failure to do this sort of encoding would require that both ends have very accurate clocks, and a pre-transmission syncronization process, least timing error accumulate and bits be lost of duplicated. By enforcing a minimum number of transitions the remote clocks can be simply be edge syncronized, and can drift significantly without error because the next edge is only a few bits away.
Music CD technology came out and eliminated playback and copy-related degradation. While I agree that 16-bit sampling is less than ideal, the lack of dynamic range on CDs is much more a problem with the over-use of compressors than a technological limitation. Modern recording is done at much better sample depths, but CDs are still compressed to maximize playback volume. In other words, the loss of dynamic range is a marketing problem, not a technological one.
Digital cable does change channels slowly. I'll give you that one; it's really pretty hard to avoid with MPEG compression. But it's not like you didn't get anything back in trade -- digital cable eliminates transmission losses, which increases picture quality significantly in places with marginal cable reception. And what are you doing watching live TV anyway; if you're paying for digital cable I'd strongly recommend the $5/month upgrade to get a PVR. You'll forget all about channel changing.
Wide screen TVs came out and now I can get more picture data in my new shows, watch my movies in (or closer to) their original aspect ratio and with more pixels, and with nothing more than trivial, remote-controlled configuration I can watch older content in the correct aspect ratio. If you want to pick on wide screen TVs you'll have to do better; maybe something about uselessly increased power use because parts of the screen go wasted when watching 4:3 content (ignoring the fact that many wide screen TVs are LCDs and are much more efficient).
And I'm not sure how you can even suggest that surgical and pharmaceutical treatments are a sign of how technology degrades medicine. Sure, some people misuse technology. Welcome to life. But without modern diagnostic, surgical, and pharmacological technology thousands more people would die from what a currently treatable conditions.
Finally, neither complexity, adaptability, nor productivity imply efficiency. Nature is reasonably good at getting things done, even complicated things, but it rarely does them in the most efficient way. Take for example, the construction of human muscle tissue from ingested animal muscle tissue. The ingested proteins are broken down into amino acids and rebuilt into basically identical proteins at some other point the body. It would be significantly more efficient to simply transport whole proteins (or even chains of proteins) to the muscle construction site. But such a system would require that the ingested protein was 100% compatible with the muscle structure you were trying to construct, which limits both adaptability to variable protein sources and the complexity of the muscle tissue being constructed. In short, nature generally balances efficiency with adaptability and overall productivity, rather than optimizing simply for efficiency. As such, given a sufficiently limited scope, it's quite possible to design a more efficient system than nature would.
Would you lock that teen up for 10 years without a computer and hope that when you let him out later he was somehow more mature and better able to program your firewall? What do you propose we do between now and "20-50 years" from now to ensure that GM processes mature rather than stagnate?
Right, because that corn you're eating somehow wasn't genetically engineered to turn it from a large grass into the cob-bearing monstrosity we know today.
Seriously, even if you ignore the pre-genetics selective breeding that people have been doing literally since pre-historic times, I'm pretty sure that Gegor Mendel started genetically modifying food over 100 years ago.
Being afraid of GM food is like being afraid of electric. We haven't studied the effects of long-term exposure to electric fields either, but no one is claiming we should shut down the power grid until we have a chance to conduct a multi-generational study (at least no one you'd take seriously). Yes, GM food could be harmful. Yes, bad people could do bad things with it. But it can also be incredibly useful. So like all other advances in science, we need to be careful not fearful.
Re:If so close, then why even wireless?
on
HP's Memory Spot Chip
·
· Score: 3, Interesting
Because a wired reader would:
1. Require the reader to be properly oriented, not merely within range, so that the 2+ contacts required are aligned
2. Render the chip unreadable when it's dirty
3. Render the chip unreadable when it's wet
4. Prevent the chip from be layered inside paper/plastic/fabric -- it would have to be exposed, which complicates manufacturing
No, but like every decent password-update system written since 1967, it does require me to enter my old password before I can choose a new one. Likewise, transfers and bill payments all require both an input and a validation step, in seperate page submissions, and the validation step includes a unique transaction ID. Could a sufficiently advanced JavaScript overcome these limitations? Certainly, but it's not as trivial as having a valid session ID and blindly submitting a form.
First it *can* be an average interval, because the only real-time operation you need is the actual analog line-level output control. Unless you're outputting directly from a main-bus-connected parallel port, there's something in the middle (probably several somethings) that buffers some data for you. In fact, just to avoid sync issues the output device must necessarily buffer an entire frame. On a stream-oriented device like a broadcast output card I'd imagine that several frames are buffered, as latency isn't generally an issue in such systems, but even if it's only one it means that you can be off by almost 100% of a frame interval without any degredation in output.
Second, 1/30th of a second is an eternity on a modern machine. With 32-bit color a 640 x 480 frame is only 1.17 MB of data. On a 32-bit 667 MHz bus (i.e. a relatively slow modern computer) it would take only 0.014 seconds to transfer an entire second's worth of data to the output device. You're right that other programs could theoretically interfere. If only there were some way you could guarantee that a process got run time at least every 1/30th of a second and had priority over other processes when it ran... maybe some sort of 100+ Hz interupt signal that the system could provide to allow this sort of relatively low-accuracy timing. Seriously, check your man pages for setitimer() and setpriority(). And that's not even mentioning the possibility of a dedicated MPEG decoding card, which would make your only point of contention the system bus. Maybe it's hassle to do video playback on your desktop while you're browsing the web, but as the sole function of the playback box, I fail to see how it could be an issue sans underlying configuration problems (which would be an issue even in a real-time system, they just wouldn't interfere with the current playback stream).
Third, modern high-speed hard drives (2.5" @ 15k) have sustained read rates approaching 100 MBps. The 10 GB/h rate I suggested before, which is very generous, is 2.84 MBps. Under what sort of "worst case" scenario, short of outright failure, would such drives not be able to produce the 1/30 of their rated speed needed for flawless playback? Similarly a simple 100 Mbps network has more than 4 times the raw capacity needed. Even at 50% efficiency a 100 Mbps network could re-transmit every single packet and still delivery everything on-time, without any extra buffering. Also keep in mind that MPEG must be decoded as frames, so you don't need per-packet delivery times, just per-frame, meaning that an particular packet or set of packets could be delayed or retransmitted several times so long as most of them arrive on the first try. And this is not even considering the possibility of a 1000 Mbps network, which is what I'd expect connected to a drive with a 100 MBps transfer rate.
Finally, I can't figure out why you think it's important to never drop a frame. While it's technically possible to make dropped frames very unlikely, what does that buy you? As far as I can tell it increases the cost of the video system without providing any pragmatic benefit. Dropping the second field of 1 frame (i.e. 50% of the frame) of a 30 fps video stream would likely not even be noticed unless the first field were very high brightness. You might notice the entire frame being dropped, but even that would be trivial unless it happened frequently. It's not like Aunt Betty's life support is regulated by the video stream; it's just a video stream. If data integrity were that important you wouldn't have compressed it in the first place.
Seriously, we've been doing 640 x 480 @ 60 Hz in "real-time" on desktop computers for over a decade. Granted, 15 years ago you did not have the main bus bandwidth to updated the entire frame each time it was redrawn, but it's certainly not a taxing operation on modern computers. How many gamers whine when their frame rate drops below 60 Hz at 1280 x 1024? What you're talking about is, frankly, trivial given modern computer speeds. I don't know why you're making it such a big deal.
In case you were unaware, producing 645 x 484 @ 29.97 Hz is well within the realm of modern (or even not-so-modern) hardware. We're talking about less than 10 GB per *hour* here, even with ridiculously high rate compressed video streams. And even without a dedicated board, better-than-real-time MPEG decoding is trivial on even very modest new computers.
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects,
so therefore cannot be held accountable for them.
I fail to see how s/\W//g wouldn't leave me with "safe" input. I've yet to see an SQL injection attack that doesn't need a character outside of [a-zA-Z_].
Actually, there's an RFC about this. GET is to be used when requests make no changes to the data -- say when you're reading the database (like from the USPS website) -- and POST is to be used when requests change some data or state.
There's a limit to how many people can receive millions of dollars in medical treatments under any sort of cost-sharing or insurance plan, even if there is 100% participation and 100% cost-sharing. And so long as there aren't very many people who need such treatments, the cost of insurance with adequately high payouts should still be reasonable, as cost by frequency product would still be low.
Perhaps I misunderstand, but it seems that you're presuming that somehow a total-health cost-sharing system would provide a higher efficiency (in terms of premium costs vs. benefits received) than an insurance program. I don't see any reason to believe this would be true, and in fact, I can name a couple why it wouldn't -- higher administrative costs to process more claims and lower disincentive for frivolous healthcare services.
Of course they won't cover chronic illnesses after you discover them. It's not a risk once you know about it, it's just a liability.
Failing to have approriate insurance before you discover your chronic illness is unfortunate, but hardly the fault of the insurer.
If you wanted to do something about not allowing insurers to fail to renew policies because someone is making continuing claims then I might agree, though the circumstances in which this is currently legal are already limited.
It's also quite possible to get a policy that pays $X upon discovery of your chronic illness Y, so that the risk of being dropped from coverage no longer exists, as the payout is up-front. Such policies are not entirely common, but they can be obtained.
The compromise between the two is *insurance*. You pay for you own basic medial expenses. If something catastophic happens, like getting hit by a car, you can use your insurance to cover the exceptional medical expenses. Then I don't have to depend on everyone pulling their weight, nor do I have to provide for those who don't.
The theoretical purpose of medical insurance is not... protect you in case of a large number of bills
Check out the Insurance article on Wikipedia: http://en.wikipedia.org/wiki/Insurance. The purpose of insurance is to provide protection against uncertain, accidental, infrequent, large losses. In the realm of health care, "a large number of medial bills" probably fits into that category.
Insurance companies may cover their expenses by pooling your risk with other customers, but that's just a question of their business practices, and is unrelated to the reason you buy health insurance -- to protect you against exceptional expenses relating to your health care. Routine medical treatment does not fall into that category.
The purpose of say, a Health Management Organization is to provide the sort of cost-sharing arrangement you describe. HMOs are design to cover both exceptional and routine medical treatment, but are specifically not insurance.
There are many people who want to pay into a cost-sharing system like and HMO and avoid paying directly for most of their health care. For people who use more than the average amount of health care this is a great plan (as long as they can dupe some below-average users into the same plan). But I can budget for my routine medical expenses, and insure myself against expenses outside of my bugdet, just like I do for my car and home. Adding this sort of nomenclature confusion to the mix does not help anyone.
This sort of system has been in use for 100+ years in vehicles with air brakes (trains and road vehciles). There are certainly cases where it would be bad -- any time you're moving fast, when the pavement is slippery, etc. -- but if you're moving more slowly it wouldn't be such a big deal, and overall it's still probably better than just having no brakes.
Moreover, a single wheel failure (hard brake lock) in a vehcile with ABS shouldn't result in a total loss of control. Once the locked wheel begins to slide the other 3 working brakes should be able to provide braking power sufficient to keep the vehicle moving mostly forward, and even to respond to some steering input. A 4-wheel failure (as happens in current air brake systems) would be much, much worse.
Slashdot Mirror
I personally find that moving my head to go from one task to another is much faster than finding and moving a window to change tasks. It's just a matter of a little window-placement and sizing displine. It's easy for me, but I can see why others would have trouble.
That being said, I'd be in favor of a window manager that help me enforce my window placement and sizing by logically segementing a single physical screen. That would give you the kind of segmenting you get from multiple monitors, but with the flexibility to easy remove or re-apportion the segments as your tasks changed.
One word: Trackball.
You never run out of trackpad no matter how big your screen is. Plus you can "throw" the ball (i.e. push it very quickly then release it so that it continues to spin after you let go) to get across the monitor very quickly.
I personally like the Kensington Expert Mouse for the scroll wheel and the extra-large ball, but it's a bit pricey. I'm sure there are cheaper options available.
Yeah, and when you need to select 25 of 100 non-consecutive JPEG files from a folder to copy I'm sure you always use the command line instead of ctrl-click and drag.
That's probably true. Now if only someone other than you were having that discusion you'd be all set.
I'm fixated on MS Word because that is the layout tool/word processor/text editor for the vast majority of the computing world. I'm glad you use other tools. I'm not denying that other tools exist or may be better for certain tasks. But when we're discussing generic office document creation -- like in this thread entitled "Google 'Office' Release" -- MS Word is the standard of comparision.
And as far as diffing MS Word files goes -- the change tracking in Word is hardly comparable to a standard diff mechanism. It is rudamentally the same, but it can only show you changes in place, it has extremely limited time-based tracking (i.e. you can't say "show me all changes between 2 weeks ago and 1 week ago") compared to CVS/SVN, and it has the potentially embarassing/damaging behavior of leaving your change history in the file unless you take extra care to delete that history.
RTF would make somewhat better use of CVS/SVN diffs, though the infrequent occurance of line breaks is still a bit of an issue. But if you think the average user -- you know, the guy the Google Office is targeted at -- is willing to:
A) select a non-default format every time he creates a document or uses "Save As..."
B) give up most of the features he needs to do layout work (i.e. turn Word into a word processor)
C) ignore the warning that Word gives often about losing formatting when you save to RTF
I think you're mistaken.
I think you're making three mistakes here. First, LaTeX is a layout application, than many people use for word processing. You can't compare it to MSWord and assume you've done a comparison of WYSIWYG versus markup.
I think you're making the mistake there. In general use, people make no distinction between a text editor, a word processor, and layout program.
For one thing, in Windows the only pre-installed "text editor" is Notepad, and even I can't be bothered to use that for text entry. So the distinction between "word processor" and "text editor" is lost on anyone who doesn't regularly fire up vim/emacs/nano/etc. Needless to say, this isn't the average MS Word user.
For another, most MS Office users, unless they are familar with publishing, use Word as a layout tool. Between the expense of having a dedicated layout tool, the complication of having to use more than one program, and the fact that MS has shoe-horned 473 "layout" features in Word, the average user doesn't even know that there's another way to do things. I agree that the world would be better if Word were a word processor and you imported its output into a layout program when layout was important, but in actual use that rarely happens.
Collaborating with LaTeX is a pain in the butt in almost every instance I've used it because their are invariably people who don't know the language and who then have to learn it, greatly slowing the whole process.
Slower than using MS Word or InDesign, both of which allow only 1 person at a time to work on a document? If you'd ever had to compile chapters from 30 people for a 500-page report you'd know that copy-and-pasting a Word document together is not the ideal scenario. Latex lets me include 30 chapter files into 1 book file and compile. That's worth 30 minutes of instruction on how to use header levels, paragraph marks, tables and include image files.
As for CVS and Subversion, I often use them to check in both binary and XML files from other word processors and layout applications and collaboration with them is not a problem using these tools.
I'd give good money to see you make a useful diff from a binary (i.e. MS Word) "text" file using CVS/SVN. Having old versions is not the only use of a version management system, nor even the one quoted in the parent -- version control with diffing capabilities.
It's somewhat more likely to be net-0 than you might think, even with carefully selected data sets. Most optical system encode data at somewhat more than 1 bit-per-bit, taking care to ensure that even extremely non-random data results in a sizeable number of on/off transitions. Failure to do this sort of encoding would require that both ends have very accurate clocks, and a pre-transmission syncronization process, least timing error accumulate and bits be lost of duplicated. By enforcing a minimum number of transitions the remote clocks can be simply be edge syncronized, and can drift significantly without error because the next edge is only a few bits away.
Music CD technology came out and eliminated playback and copy-related degradation. While I agree that 16-bit sampling is less than ideal, the lack of dynamic range on CDs is much more a problem with the over-use of compressors than a technological limitation. Modern recording is done at much better sample depths, but CDs are still compressed to maximize playback volume. In other words, the loss of dynamic range is a marketing problem, not a technological one.
Digital cable does change channels slowly. I'll give you that one; it's really pretty hard to avoid with MPEG compression. But it's not like you didn't get anything back in trade -- digital cable eliminates transmission losses, which increases picture quality significantly in places with marginal cable reception. And what are you doing watching live TV anyway; if you're paying for digital cable I'd strongly recommend the $5/month upgrade to get a PVR. You'll forget all about channel changing.
Wide screen TVs came out and now I can get more picture data in my new shows, watch my movies in (or closer to) their original aspect ratio and with more pixels, and with nothing more than trivial, remote-controlled configuration I can watch older content in the correct aspect ratio. If you want to pick on wide screen TVs you'll have to do better; maybe something about uselessly increased power use because parts of the screen go wasted when watching 4:3 content (ignoring the fact that many wide screen TVs are LCDs and are much more efficient).
And I'm not sure how you can even suggest that surgical and pharmaceutical treatments are a sign of how technology degrades medicine. Sure, some people misuse technology. Welcome to life. But without modern diagnostic, surgical, and pharmacological technology thousands more people would die from what a currently treatable conditions.
Finally, neither complexity, adaptability, nor productivity imply efficiency. Nature is reasonably good at getting things done, even complicated things, but it rarely does them in the most efficient way. Take for example, the construction of human muscle tissue from ingested animal muscle tissue. The ingested proteins are broken down into amino acids and rebuilt into basically identical proteins at some other point the body. It would be significantly more efficient to simply transport whole proteins (or even chains of proteins) to the muscle construction site. But such a system would require that the ingested protein was 100% compatible with the muscle structure you were trying to construct, which limits both adaptability to variable protein sources and the complexity of the muscle tissue being constructed. In short, nature generally balances efficiency with adaptability and overall productivity, rather than optimizing simply for efficiency. As such, given a sufficiently limited scope, it's quite possible to design a more efficient system than nature would.
Would you lock that teen up for 10 years without a computer and hope that when you let him out later he was somehow more mature and better able to program your firewall? What do you propose we do between now and "20-50 years" from now to ensure that GM processes mature rather than stagnate?
Right, because that corn you're eating somehow wasn't genetically engineered to turn it from a large grass into the cob-bearing monstrosity we know today.
Seriously, even if you ignore the pre-genetics selective breeding that people have been doing literally since pre-historic times, I'm pretty sure that Gegor Mendel started genetically modifying food over 100 years ago.
Being afraid of GM food is like being afraid of electric. We haven't studied the effects of long-term exposure to electric fields either, but no one is claiming we should shut down the power grid until we have a chance to conduct a multi-generational study (at least no one you'd take seriously). Yes, GM food could be harmful. Yes, bad people could do bad things with it. But it can also be incredibly useful. So like all other advances in science, we need to be careful not fearful.
Because a wired reader would:
1. Require the reader to be properly oriented, not merely within range, so that the 2+ contacts required are aligned
2. Render the chip unreadable when it's dirty
3. Render the chip unreadable when it's wet
4. Prevent the chip from be layered inside paper/plastic/fabric -- it would have to be exposed, which complicates manufacturing
No, but like every decent password-update system written since 1967, it does require me to enter my old password before I can choose a new one. Likewise, transfers and bill payments all require both an input and a validation step, in seperate page submissions, and the validation step includes a unique transaction ID. Could a sufficiently advanced JavaScript overcome these limitations? Certainly, but it's not as trivial as having a valid session ID and blindly submitting a form.
First it *can* be an average interval, because the only real-time operation you need is the actual analog line-level output control. Unless you're outputting directly from a main-bus-connected parallel port, there's something in the middle (probably several somethings) that buffers some data for you. In fact, just to avoid sync issues the output device must necessarily buffer an entire frame. On a stream-oriented device like a broadcast output card I'd imagine that several frames are buffered, as latency isn't generally an issue in such systems, but even if it's only one it means that you can be off by almost 100% of a frame interval without any degredation in output.
Second, 1/30th of a second is an eternity on a modern machine. With 32-bit color a 640 x 480 frame is only 1.17 MB of data. On a 32-bit 667 MHz bus (i.e. a relatively slow modern computer) it would take only 0.014 seconds to transfer an entire second's worth of data to the output device. You're right that other programs could theoretically interfere. If only there were some way you could guarantee that a process got run time at least every 1/30th of a second and had priority over other processes when it ran... maybe some sort of 100+ Hz interupt signal that the system could provide to allow this sort of relatively low-accuracy timing. Seriously, check your man pages for setitimer() and setpriority(). And that's not even mentioning the possibility of a dedicated MPEG decoding card, which would make your only point of contention the system bus. Maybe it's hassle to do video playback on your desktop while you're browsing the web, but as the sole function of the playback box, I fail to see how it could be an issue sans underlying configuration problems (which would be an issue even in a real-time system, they just wouldn't interfere with the current playback stream).
Third, modern high-speed hard drives (2.5" @ 15k) have sustained read rates approaching 100 MBps. The 10 GB/h rate I suggested before, which is very generous, is 2.84 MBps. Under what sort of "worst case" scenario, short of outright failure, would such drives not be able to produce the 1/30 of their rated speed needed for flawless playback? Similarly a simple 100 Mbps network has more than 4 times the raw capacity needed. Even at 50% efficiency a 100 Mbps network could re-transmit every single packet and still delivery everything on-time, without any extra buffering. Also keep in mind that MPEG must be decoded as frames, so you don't need per-packet delivery times, just per-frame, meaning that an particular packet or set of packets could be delayed or retransmitted several times so long as most of them arrive on the first try. And this is not even considering the possibility of a 1000 Mbps network, which is what I'd expect connected to a drive with a 100 MBps transfer rate.
Finally, I can't figure out why you think it's important to never drop a frame. While it's technically possible to make dropped frames very unlikely, what does that buy you? As far as I can tell it increases the cost of the video system without providing any pragmatic benefit. Dropping the second field of 1 frame (i.e. 50% of the frame) of a 30 fps video stream would likely not even be noticed unless the first field were very high brightness. You might notice the entire frame being dropped, but even that would be trivial unless it happened frequently. It's not like Aunt Betty's life support is regulated by the video stream; it's just a video stream. If data integrity were that important you wouldn't have compressed it in the first place.
Seriously, we've been doing 640 x 480 @ 60 Hz in "real-time" on desktop computers for over a decade. Granted, 15 years ago you did not have the main bus bandwidth to updated the entire frame each time it was redrawn, but it's certainly not a taxing operation on modern computers. How many gamers whine when their frame rate drops below 60 Hz at 1280 x 1024? What you're talking about is, frankly, trivial given modern computer speeds. I don't know why you're making it such a big deal.
In case you were unaware, producing 645 x 484 @ 29.97 Hz is well within the realm of modern (or even not-so-modern) hardware. We're talking about less than 10 GB per *hour* here, even with ridiculously high rate compressed video streams. And even without a dedicated board, better-than-real-time MPEG decoding is trivial on even very modest new computers.
Apparently you missed section 9 of RFC 2616:
9.1 Safe and Idempotent Methods
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects,
so therefore cannot be held accountable for them.
I fail to see how s/\W//g wouldn't leave me with "safe" input. I've yet to see an SQL injection attack that doesn't need a character outside of [a-zA-Z_].
Actually, there's an RFC about this. GET is to be used when requests make no changes to the data -- say when you're reading the database (like from the USPS website) -- and POST is to be used when requests change some data or state.
There's a limit to how many people can receive millions of dollars in medical treatments under any sort of cost-sharing or insurance plan, even if there is 100% participation and 100% cost-sharing. And so long as there aren't very many people who need such treatments, the cost of insurance with adequately high payouts should still be reasonable, as cost by frequency product would still be low.
Perhaps I misunderstand, but it seems that you're presuming that somehow a total-health cost-sharing system would provide a higher efficiency (in terms of premium costs vs. benefits received) than an insurance program. I don't see any reason to believe this would be true, and in fact, I can name a couple why it wouldn't -- higher administrative costs to process more claims and lower disincentive for frivolous healthcare services.
Of course they won't cover chronic illnesses after you discover them. It's not a risk once you know about it, it's just a liability.
Failing to have approriate insurance before you discover your chronic illness is unfortunate, but hardly the fault of the insurer.
If you wanted to do something about not allowing insurers to fail to renew policies because someone is making continuing claims then I might agree, though the circumstances in which this is currently legal are already limited.
It's also quite possible to get a policy that pays $X upon discovery of your chronic illness Y, so that the risk of being dropped from coverage no longer exists, as the payout is up-front. Such policies are not entirely common, but they can be obtained.
Which is why you only want to insure against exceptional risks -- i.e. getting hit by a car -- and not against all risk -- i.e. routine medical exams.
The compromise between the two is *insurance*. You pay for you own basic medial expenses. If something catastophic happens, like getting hit by a car, you can use your insurance to cover the exceptional medical expenses. Then I don't have to depend on everyone pulling their weight, nor do I have to provide for those who don't.
The theoretical purpose of medical insurance is not ... protect you in case of a large number of bills
Check out the Insurance article on Wikipedia: http://en.wikipedia.org/wiki/Insurance. The purpose of insurance is to provide protection against uncertain, accidental, infrequent, large losses. In the realm of health care, "a large number of medial bills" probably fits into that category.
Insurance companies may cover their expenses by pooling your risk with other customers, but that's just a question of their business practices, and is unrelated to the reason you buy health insurance -- to protect you against exceptional expenses relating to your health care. Routine medical treatment does not fall into that category.
The purpose of say, a Health Management Organization is to provide the sort of cost-sharing arrangement you describe. HMOs are design to cover both exceptional and routine medical treatment, but are specifically not insurance.
There are many people who want to pay into a cost-sharing system like and HMO and avoid paying directly for most of their health care. For people who use more than the average amount of health care this is a great plan (as long as they can dupe some below-average users into the same plan). But I can budget for my routine medical expenses, and insure myself against expenses outside of my bugdet, just like I do for my car and home. Adding this sort of nomenclature confusion to the mix does not help anyone.
This sort of system has been in use for 100+ years in vehicles with air brakes (trains and road vehciles). There are certainly cases where it would be bad -- any time you're moving fast, when the pavement is slippery, etc. -- but if you're moving more slowly it wouldn't be such a big deal, and overall it's still probably better than just having no brakes.
Moreover, a single wheel failure (hard brake lock) in a vehcile with ABS shouldn't result in a total loss of control. Once the locked wheel begins to slide the other 3 working brakes should be able to provide braking power sufficient to keep the vehicle moving mostly forward, and even to respond to some steering input. A 4-wheel failure (as happens in current air brake systems) would be much, much worse.