The article says that possible other cause could be static electricity. As I saw many static electricity sparkles but never saw a sparkle coming out of a cellphone (save the time it was disassembled on my table and I shorted the battery), nor there is any part that could cause sparkling, I suppose the cellphone was not the cause. The manual warnings are there more likely in order to protect the manufacturer from the frivolous lawsuits.
My expectation is that few people will respect such ban and nothing happens as the result.
Great. How do you enforce this? I regularly consult for friends in the USA/Canada. All transactions so far happened by mail or IM (and usually are paid by barter, consultations from their respective areas of competence). But, given the fact that "import" of so-called "intellectual property" happened, under the tariff radar, untaxed, how would you prove that? If you suggest eavesdropping on mail, I counter with GPG, or Jabber-over-SSL.
I usually have to solve problems when the shops are either closed or far away (and when you add the time lost by going to the shop and back, the cost equations often start looking somehow different). Besides, this is not a hour or more, but maybe 5 minutes or less, at least if you can recognize the right end of the screwdriver.
Can the wheel be encased in eg. a steel rod cage? Something that water can flow through freely but dense enough to screen out the hippos, gators, and floating logs?
Normal VGA cables won't be too good. The horizontal and vertical sync signals are no big deal - TTL levels, digital logic, low-frequency. The problem is in the video; you may like to try three higher-quality 75-ohm coax cables (I believe the VGA outputs/inputs are matched to 75 ohm). If that won't be enough, you may try to use converters from asymmetrical to symmetrical signal and back and use CAT5 cable instead of coax (the solution described in an earlier answer, you can buy them commercially or make from parts - Maxim makes MAX435 and MAX436 chips specifically for this purpose, though I am not sure if they would cope with the bandwidth of 1600x1200 in some sane refresh rate).
You can disassemble the power supply, bravely ignoring the warnings on its case, and check for yourself if the switch is connected to the board (and where), and check by an ohmmeter if it is really switched. Very basic knowledge of switched power supplies is helpful here. Also, a test of the PS on some dummy (or at least cheap) load after the visual and functionality check of the switch will be good to be certain.
Hey - it is not bad idea! Remember the stories of cop raids that occassionally pop up on Slashdot or Kuro5hin, when the coppers haul away trucks of hardware, including peoples' dissertations and business records? A stealth data storage, located somewhere outside of the normal scope of attention could be a lifesaver in such situations.
Various things like the WiFi data storage units could be helpful in this way; hide one between the walls, and "forget" about it. The raid team then either misses it, or somebody rats about it (which is not likely if you keep it for yourself), or they do a TSCM scan (which is quite unlikely), or they have to disassemble the building (which they are unlikely to do as it is not standard way to secure the evidence and it takes too much work).
Beware: some CD drives refuse to read some brands of CD-RWs. I have a drive, some rebranded Phillips, that when fed with a Verbatim mini-CDRW just "dies" and requires hard reset. Does that with all the CDRWs from the batch. Of course the same drive works flawlessly with Verbatim mini-CD-Rs.
Prepare EDL files for MPlayer and use that for playing the DVDs. As a bonus, you can edit out the FBI warnings. Not sure how legal it is to do, though, but I don't suppose that's of any practical concern for normal people.
As long as their USE is not mandatory, it's okay with me. The added cost to the player is small to none, as it's basically just a couple lines of firmware code, and as long as I can switch it off, I can avoid it having impact on me. If it in addition keeps the Religious Nuts quiet, it's a nice bonus.
But with this new device, you could argue that Clearplay and RCA are making the derivative work and selling it to customers.
Then I can argue that Clearplay and RCA only give the customer the tools for creating the derivative content, because the customer creates it on his own by conscious decision, by switching on the autoskip capability and playing the DVD through it.
No meaningful difference against selling black ink for blacking-out "objectionable" parts in eg. a book (though in this case it'd be rather selling cut-off masks for individual pages and a can of spray paint).
The diference is, if it is you hitting the fast forward buttons,
then you are creating that derivative work for personal use...
Okay. Suppose I take a microcontroller and wire it to the remote, so it
counts seconds after I press Play, and then in specified moments tells
the remote to send "FastForward" for specified time, then "Play" again.
Then I feed the chip with the offsets for the specified movie. To
complicate the matter a bit, let's say I got the file with the offsets
from a friend with the same system.
How does it differ, according to your opinion, from pressing the
buttons myself? From the same situation, but the timecode list being
written on a sheet of paper and me using the tape-position display on
the VCR? Where's the difference between ME pressing the buttons, ME
pressing the buttons according to a list, a MICROCONTROLLER sending the
keypress events by remote control, according to the same list, or the
MICROCONTROLLER in the player itself doing the same? In all the cases,
it's ME who watches the movie.
The diference is, if it is you hitting the fast forward buttons, then you are creating that derivative work for personal use, which falls under fair use of the material.
Well... and this differs from applying third-party cutting instructions exactly HOW?
MPlayer has a feature, EDL - a list of timecode offsets you want to skip during playback. If I make an EDL for a DVD, should I be banned from distributing it? If somebody other does the same, should I be banned from downloading and using it? If so, WHY? If it is my conscious decision to apply the EDL during playback, why I shouldn't be permitted to do so?
Imagine going to a "scary" movie with all the scare taken out of it simply because you now don't even have to cover your eyes.
If it is my decision to do so, and I am fully informed about going to see "castrated" version, why not? My mistake for doing that, my loss.
That said, I should be able to see the cut-list, possibly with brief descriptions of what gets cut off. Maybe a list of timecode offset ranges with machine-readable description of the scenes would be the best way - I then could tell the machine what it should skip. (And yes, there should be categories like "long-boring-unimportant-dialogue".)
Such classification files then could be available in the way like eg. DivX subtitle files are.
MPlayer has this feature too. You can supply it with a file describing the timecode ranges you want to autoskip. I consider it very useful, as long as the choice of if using it and what file to use remains mine.
A better take on the same problem would be using some image characteristics instead of the timecode offset, as then the file could be used even for TV recordings, where the codes could differ. Any video-processing people here?
Ummm... how outsourcing the decision what offsets to skip to the "patch" vendor differs from doing it myself? Why should I be stripped of the right to both offer and acquire such patches? I suppose publishing a human-readable list of SMPTE offsets where "wrong" words or images appear is protected by The First - if so, why the machine-readable version of the same shouldn't be?
Then you, the unprivileged user, should have no permissions to screw with it. That's the unix way.
It has been said that when the only tool you've used is a hammer, every problem looks like a nail.
Many problems *ARE* nails.
"Bah, those drooling lusers who use screwdrivers or saws."
...on nails.
That if that clever one line script which renames "*.c" files to "*.bak" files, also renamed
".config" to ".bakonfig", hey, no problem. It happens. It's just part of the Unix everyday life.
Or that if that clever GUI file manager lets you move a directory into another directory just by an accidentally done click-drag to the directory just above or just below. (Happens fairly often.) Or when the user, drunk with the perceived power that the GUI gives, totally hoses the machine. (You can do the same with CLI as well - you can flatten your thumb with a hammer or perforate it with a drill, the choice of tool to screw yourself is on you.)
And no ammount of whining and moaning is going to bring back the "good old days" when you passed for a guru by just knowing how to find a file.
No problem. The users will find the way to their guru when they click-drag their directory to an unexpected location.
And no ammount of whining and moaning will bring back the days when writing a piss-poor 100 line incomplete program with counted as being a l33t programmer.
Two words: Visual Basic.
A very important advantage of CLI is for system service and debugging, especially over the phone. It's much easier to dictate commands and get their results read back than trying to navigate the pointclicking user through the maze of menus. Especially when you need a certain file and Microsoft in their unlimited wisdom decided that file extensions are to be hidden by default, and that some file types have the same icons - resulting in two or more different files with the same icon and name. Not a show stopper, but a huge annoyance.
The problem isn't located in CLI vs GUI. The problem is located between the chairs and the mice.
The "good old days" are about nostalgically remembering the time when the mainstream systems used to have powerful CLI tools instead of the half-assed half-baked GUI ones.
And yes, it is theoretically possible to make a good GUI tool. They are just rare and far between, as it takes much more work in comparison with making a good CLI, so the programmers usually stop not when it's excellent, but when it's just good-enough.
Textual informations have the highest content/size ratio, are very easy to hide. I can imagine a follow-up to FreeNet, let's call it StegoNet. Another possibility, providing plausible deniability, is to spread the nodes using a worm.
So once the hardware is secure & the software is secure...
...full-scale open solutions appear more widely on the market. See eg. MythTV, for the example of a largely successful effort. Together with players from less-brand vendors. Just don't expect to find them en-masse in Wal-Mart.
The recent developments in the area of mini-sized motherboards open a nice secondary market for homemade fully customized unlicenced players.
You can build a Macrovision-removing device for a standard videosignal from few chips. The Net is full of various schematics, ranging in complexity from a microcontroller to a sync detector with some timer circuits. The principle is to bring the videosignal corrupted by Macrovision additions (high-brightness blinking during the blanking interval, which confuses the AGC circuits in the VCRs) back to normal (by removing these additions, forcing them to black level that belongs there).
Skewed stats. Google most likely takes their info from User-Agent headers. Many browsers allow setting up this header arbitrarily. Because way too many websites have the annoying habit of serving only MSIE, lots of other browsers are configured to pose as MSIE.
I somehow doubt they use more reliable OS-discovery method, eg. passive fingerprinting.
Slashdot Mirror
My expectation is that few people will respect such ban and nothing happens as the result.
Do they have other reasonable choices to make?
One more question: if import of IP is taxed, how to handle mailing lists and newsgroups, where a lot of "property" gets freely exchanged?
Great. How do you enforce this? I regularly consult for friends in the USA/Canada. All transactions so far happened by mail or IM (and usually are paid by barter, consultations from their respective areas of competence). But, given the fact that "import" of so-called "intellectual property" happened, under the tariff radar, untaxed, how would you prove that? If you suggest eavesdropping on mail, I counter with GPG, or Jabber-over-SSL.
I usually have to solve problems when the shops are either closed or far away (and when you add the time lost by going to the shop and back, the cost equations often start looking somehow different). Besides, this is not a hour or more, but maybe 5 minutes or less, at least if you can recognize the right end of the screwdriver.
Can the wheel be encased in eg. a steel rod cage? Something that water can flow through freely but dense enough to screen out the hippos, gators, and floating logs?
Normal VGA cables won't be too good. The horizontal and vertical sync signals are no big deal - TTL levels, digital logic, low-frequency. The problem is in the video; you may like to try three higher-quality 75-ohm coax cables (I believe the VGA outputs/inputs are matched to 75 ohm). If that won't be enough, you may try to use converters from asymmetrical to symmetrical signal and back and use CAT5 cable instead of coax (the solution described in an earlier answer, you can buy them commercially or make from parts - Maxim makes MAX435 and MAX436 chips specifically for this purpose, though I am not sure if they would cope with the bandwidth of 1600x1200 in some sane refresh rate).
You can disassemble the power supply, bravely ignoring the warnings on its case, and check for yourself if the switch is connected to the board (and where), and check by an ohmmeter if it is really switched. Very basic knowledge of switched power supplies is helpful here. Also, a test of the PS on some dummy (or at least cheap) load after the visual and functionality check of the switch will be good to be certain.
Various things like the WiFi data storage units could be helpful in this way; hide one between the walls, and "forget" about it. The raid team then either misses it, or somebody rats about it (which is not likely if you keep it for yourself), or they do a TSCM scan (which is quite unlikely), or they have to disassemble the building (which they are unlikely to do as it is not standard way to secure the evidence and it takes too much work).
Beware: some CD drives refuse to read some brands of CD-RWs. I have a drive, some rebranded Phillips, that when fed with a Verbatim mini-CDRW just "dies" and requires hard reset. Does that with all the CDRWs from the batch. Of course the same drive works flawlessly with Verbatim mini-CD-Rs.
The best thing I could do then: go buy better locks.
Prepare EDL files for MPlayer and use that for playing the DVDs. As a bonus, you can edit out the FBI warnings. Not sure how legal it is to do, though, but I don't suppose that's of any practical concern for normal people.
As long as their USE is not mandatory, it's okay with me. The added cost to the player is small to none, as it's basically just a couple lines of firmware code, and as long as I can switch it off, I can avoid it having impact on me. If it in addition keeps the Religious Nuts quiet, it's a nice bonus.
Death doesn't always imply violence. Ever heard about old age? What about a nice case of Alzheimer? :)
Then I can argue that Clearplay and RCA only give the customer the tools for creating the derivative content, because the customer creates it on his own by conscious decision, by switching on the autoskip capability and playing the DVD through it.
No meaningful difference against selling black ink for blacking-out "objectionable" parts in eg. a book (though in this case it'd be rather selling cut-off masks for individual pages and a can of spray paint).
Okay. Suppose I take a microcontroller and wire it to the remote, so it counts seconds after I press Play, and then in specified moments tells the remote to send "FastForward" for specified time, then "Play" again. Then I feed the chip with the offsets for the specified movie. To complicate the matter a bit, let's say I got the file with the offsets from a friend with the same system.
How does it differ, according to your opinion, from pressing the buttons myself? From the same situation, but the timecode list being written on a sheet of paper and me using the tape-position display on the VCR? Where's the difference between ME pressing the buttons, ME pressing the buttons according to a list, a MICROCONTROLLER sending the keypress events by remote control, according to the same list, or the MICROCONTROLLER in the player itself doing the same? In all the cases, it's ME who watches the movie.
Well... and this differs from applying third-party cutting instructions exactly HOW?
MPlayer has a feature, EDL - a list of timecode offsets you want to skip during playback. If I make an EDL for a DVD, should I be banned from distributing it? If somebody other does the same, should I be banned from downloading and using it? If so, WHY? If it is my conscious decision to apply the EDL during playback, why I shouldn't be permitted to do so?
If it is my decision to do so, and I am fully informed about going to see "castrated" version, why not? My mistake for doing that, my loss.
That said, I should be able to see the cut-list, possibly with brief descriptions of what gets cut off. Maybe a list of timecode offset ranges with machine-readable description of the scenes would be the best way - I then could tell the machine what it should skip. (And yes, there should be categories like "long-boring-unimportant-dialogue".)
Such classification files then could be available in the way like eg. DivX subtitle files are.
A better take on the same problem would be using some image characteristics instead of the timecode offset, as then the file could be used even for TV recordings, where the codes could differ. Any video-processing people here?
Ummm... how outsourcing the decision what offsets to skip to the "patch" vendor differs from doing it myself? Why should I be stripped of the right to both offer and acquire such patches? I suppose publishing a human-readable list of SMPTE offsets where "wrong" words or images appear is protected by The First - if so, why the machine-readable version of the same shouldn't be?
Then you, the unprivileged user, should have no permissions to screw with it. That's the unix way.
It has been said that when the only tool you've used is a hammer, every problem looks like a nail.
Many problems *ARE* nails. "Bah, those drooling lusers who use screwdrivers or saws."
That if that clever one line script which renames "*.c" files to "*.bak" files, also renamed ".config" to ".bakonfig", hey, no problem. It happens. It's just part of the Unix everyday life.
Or that if that clever GUI file manager lets you move a directory into another directory just by an accidentally done click-drag to the directory just above or just below. (Happens fairly often.) Or when the user, drunk with the perceived power that the GUI gives, totally hoses the machine. (You can do the same with CLI as well - you can flatten your thumb with a hammer or perforate it with a drill, the choice of tool to screw yourself is on you.)
And no ammount of whining and moaning is going to bring back the "good old days" when you passed for a guru by just knowing how to find a file.
No problem. The users will find the way to their guru when they click-drag their directory to an unexpected location.
And no ammount of whining and moaning will bring back the days when writing a piss-poor 100 line incomplete program with counted as being a l33t programmer.
Two words: Visual Basic.
A very important advantage of CLI is for system service and debugging, especially over the phone. It's much easier to dictate commands and get their results read back than trying to navigate the pointclicking user through the maze of menus. Especially when you need a certain file and Microsoft in their unlimited wisdom decided that file extensions are to be hidden by default, and that some file types have the same icons - resulting in two or more different files with the same icon and name. Not a show stopper, but a huge annoyance.
The problem isn't located in CLI vs GUI. The problem is located between the chairs and the mice.
The "good old days" are about nostalgically remembering the time when the mainstream systems used to have powerful CLI tools instead of the half-assed half-baked GUI ones.
And yes, it is theoretically possible to make a good GUI tool. They are just rare and far between, as it takes much more work in comparison with making a good CLI, so the programmers usually stop not when it's excellent, but when it's just good-enough.
GUI? Phooey.
Textual informations have the highest content/size ratio, are very easy to hide. I can imagine a follow-up to FreeNet, let's call it StegoNet. Another possibility, providing plausible deniability, is to spread the nodes using a worm.
The recent developments in the area of mini-sized motherboards open a nice secondary market for homemade fully customized unlicenced players.
Screw DMCA.
I somehow doubt they use more reliable OS-discovery method, eg. passive fingerprinting.