If you want to see some of his best writing (and most diverse) get his short story anthology Maps in a Mirror. It's also annotated, so it gives you a great peek into his mind and how/why he writes certain stories. That really shows off the brilliance of OSC as a writer.
Also, if you are or want to be a writer yourself (rather than a typical/. complainer), then you can learn a lot from OSC. His book on how to write SciFi is the best on that topic. He also provides a lot of help for writers on his website.
Really, what makes OSC great is perhaps not any particular work, but rather his grasp of people, and that great stories must be about the characters. Otherwise all you have is a literary carchase and explosions, just special effects with no meat.
Oh, and if the Full House thing at the end of the review puzzles you, then you just haven't read enough of his reviews to understand his sense of humor, or that he is a devoted parent and thus sometimes cares about things that may seem quite corny to adults.
We can only hope that Creative refuses to license its patent. And in the best case Apple looses and is forced to stop production of its iPod (in current form anyway). This is not out of spite of Apple or its products, but as a necessary step to patent reform.
When I say best case, I mean from a long term perspective. One of the main reasons there is so little effort to reform US patent law is because the ad-hoc and unspoken system of cross licensing that exists among the biggest players hides most of the pain and stupidity of the patent system from the mass consumer. Cross licensing pratices are nearly as harmful as patents themselves, as it basically allows the largest corporations to play by different anticapitalistic rules than the smaller company or inventor. It's only when actual consumers are affected in-masse and it's clear that its because of stupid patents that any real presure on lawmakers will be made. Before it will get better there has to be at least one (maybe many) very large cases where patent law completely disrupts the economy and the public is aware of the cause.
This is a good study of how hard it is to design secure systems. It's just like a non-cryptographer trying to create their own cipher, only in the visual processing world. Sadly, the article does not touch on non-visual captchas, which are alternatives for the blind. It would also be interesting to see what Jakob Nielsen might have to say on this technology from a usability perspective.
Of course, one of the primary bad things is that the concept of a captcha is patented, and the patent language is very broad. US Patent# 6,195,698
Thank goodness we might finally see proper PNG alpha channel support after, what, a decade? But there are some other annoyances which I hope also get on their list...
Use title attribute instead of alt for tooltips.
Understand more display properties, such as table-row, table-cell, etc.
Support XMLHttpRequest() javascript call in addition to ActiveX object for AJAX.
Support application/xhtml+xml content type (complete with <![CDATA[... ]]> sections)
Follow <link rel="icon"...> to get site icon in formats other than *.ico.
Allow all empty elements to use XML syntax, like <script/>, not just <script></script>
Meanwhile I get lots of naughty SPAM without an ID check, and even google images turns up stuff that will make my eyeballs melt out of my head. Not to mention that the URL bar in my browser is very dangerous, and should be banned. And have you even tried running the WebCollage screen saver? Where's the ESRB been?
Why in the world would anybody want to turn over this control to such a corrupt and bureaucratic organization. The address assignments is not a very defendable reason, it's more likely the other types of control they could start imposing. Like even more outrageous copy controls, censorship, taxes, and other forms of non-democratic social engineering, or anything to further progress on the anti-American movement. That's all the UN is about these days, and we've already surrendered too much of our (US) freedom to the UN already.
Another Paul Graham article, and textbook editing
on
Improving Education?
·
· Score: 1
First, with ISO-quality standards, updates are made carefully and slowly to insure the least pain to all users relying on the standard. Backwards compatibility is usually the most important concern to the maintainers; there's no "willy nilly" changing going on. [Compare this to say Java, whose specs change much more quickly and perhaps more "willy" than C++]
There are many reasons to update standards periodically:
1. Most standards bodies (such as ISO) *require* that all standards be updated, or at least re-affirmed, on a periodic basis; usually once per decade. Otherwise they are considered abandonded and "revoked" from having its standard status. This helps weed out truely abandoned standards as well as insures that the standard is properly maintained and retains its usefulness.
2. As with most language standards, there are always many many small technical imperfections, or more commonly ambiguities, that need to be addressed or clarified. Most of these will never affect the "common" programmer, except perhaps those on the fringe (such as with embedded systems and so forth).
3. Practical experiences with a language often show shortcommings that, although may be technically minor, greatly detract from the language's usefulness in some cases. For instance when the C standard was last updated they made the numerical semantics much tighter (because they found out FORTRAN programmers could not adequately port programs to C without them). These changes would be hardly noticed by most programmers who don't do heavy and precise computation; but greatly welcomed by those who did.
4. Sometimes novel techniques or components are invented which prove to be very general solutions to widely-encountered problems, and which fit the "style" of the language very closely. Once these experimental components are deemed very mature and stable, adding them into the language proper can benifit all language users. For C++, many of these new extensions come out of the Boost project. But only the most mature and the most general-purpose extensions should be considered for standardization.
One of the great things about "AJAX" is that the "X" is optional. No reason to do XML at all unless that's what you want. So, if XML is overkill for your application, take a look at JSON, http://www.json.org/
I think it's better than CSV even. And it's got bindings to tons of languages, not just Javascript. So producing the server-side is also very easy.
The GUID (as called by Microsoft) has it's history in the UUID, which was first "invented" by OSF as part of it's big DCE specs (long before Microsoft adopted the format and gave it a spiffy new name).
The UUID and GUID look alike, but the UUID was constructed in a much different manner than GUIDs seem to be nowdays. GUIDs are basically 128-bits of random data (usually made by passing pseudo-random seeds through a hash). UUIDs on the other hand contained structured data too in addition to randomness, to try to prevent accidental reuse. For instance the rightmost
48 bits come from the Ethernet MAC address if available. Other bits contained date/time information, process/thread ids, etc.
There was an expired Draft RFC written in February 1998
which explained a lot of the technical details of GUIDs and UUIDs (surprisingly authored by Microsoft). You may still be able to find copies of it out on the net (the filename was "draft-leach-uuids-guids-01.txt")
Don't forget to go to Preferences > Security > SSL > Extra SSL3/TLS and enable the following cipher first:
(X) No encryption with RSA authentication and SHA1 MAC
Then disable all the other less-secure ciphers. This will make your https connections super secure!!
(Despite my sarcasm, it's important to realize that https doesn't automatically mean secure. You need to make sure you negotiated good algorithms, that you trust the server certificate, and that the issuer of that certificate was not your own company's CA set up to run an https proxy).
If your tool is used to bypass copy protection then it is illegal according to the DMCA.
There is a necessary qualification though, circumvention is only illegal if the copy protection actually protects a copyrighted work to which I have no copyright permission otherwise.
If I produce my own works, then I own the copyright and I'm exempt from circumventing my own protection. I could also release my works to the Public Domain, and therefore anybody could legally circumvent any copy protection that may happen to be on that work since it doesn't qualify for DMCA protection. Now just because the same code can both decrypt MY works as well as somebody else's doesn't give users the right to decrypt those other works; just mine. But, as the writer of software, that's not my problem. I should be able to traffic in such programs if I own the copyright to the works it protects...it exempts me from the DMCA "trafficking" sections. I'm not solving the "can't copy" problem; but I'm trying to solve the "can't write software" problem.
Furthermore, the DMCA provides explicit exemptions for reverse engineering.
Plus I would bet 2-1 that their encryption scheme is patented.
True, this would legally prevent me from reproducing the same "invention". But that would also mean that the copy protection technique itself is publically disclosed, something that would be welcome amyway. It also doesn't necessarily mean I can't create an equivalent protection mechanism. The encrypted content itself (the data on the disc) is not patentable.
The only hope is for independent developers to create submarine patents and hit a few of the big guys with them.
Yes, I do belive this is a potentially powerful technique to use to disarm the DMCA (and similar shameful laws). But it's hard to cover all bases, and is expensive. However I think just like the GPL cleverly uses copyright law against the hoarding of knowledge, that Patent law ought to be able to be used in such a backwards scheme too, an antipatent.
The DMCA does not (yet) prohibit reverse engineering, nor does it prohibit you from decrypting anything. It only disallows the "trafficking" of the decryption tools that may be used to bypass copy control mechanisms on somebody else's content (without substantial other uses).
But what if... 1. I reverse engineer Company S's encoding method -- legal. 2. I create an encryptor, which can be used to encode a disc using that same technique, and open encryptor code to public (as long as it can't directly decrypt) -- legal, with patent caveat. 3. I create and publish my OWN content encoded using that method (to which I own the copyright) -- legal. 4. I then create a decyptor program which will decrypt MY content, which has a built in simple password "copy control" mechanism (but since I'm lazy it's pretty trivial) -- legal. 5. I open up my decryptor program with source for all people who download my content and pay me $1 for the "password key" -- legal?
Now, by "conincidence", the password key which protects MY work for which you purchased a license, also just happens to decode all Company S's content too, since it uses the same legally reverse-engineered algorithms. But since that code was legally developed, and is used to protect MY OWN content, then can't I release it?
Isn't the key to avoiding DMCA nonsense to create your own content...then don't you have the same right to protect and decrypt your own content as Company S does? Who says only S**y is allowed to create discs with intentionally corrupt sectors; and therefore only S**y can say who can write programs that ignore such sectors?
Your comment is absolutely correct. Profit and piracy have always been side issues, a diversionary tactict. The real issue is one of controlling content *creation* and distribution. What the RIAA/MPAA really want is to make sure that independent content producers HAVE to use their services to be able to publish. They are the middlemen, and they want to stay that way. Allowing artists to publish directly to consumers is their worst nightmare, regardless if there is an effective payment system or copy controls.
Think about all the DRM stuff. Even the technologically flawed controls in DVDs should make this clear. They don't do a darn thing about stopping piracy. But they DO inhibit the independent creation of content (or are the first step in such a plan). Because the technology must be licensed, the keys must be issued, and it's not opened up to anybody except their small set of cartel members.
Now it just so happens that their best bet is to use the whole "piracy is stealing" approach as the most likely to cause sympathy with legislators. So once they get mandated technological controls in place in all hardware devices, then it's relatively easy for them to start using those same mechanisms to start locking out content creators...not just those pirate consumers.
Lexmark abusing the DMCA as a way to prevent other manufacturers from producing products had nothing to do with actual piracy or IP "stealing". But that was just a preview of what the RIAA/MPAA ultimately want to be able to do themselves...to be able to lock out all other producers. This is what a cartel is all about; only they're paying off the legislative system to make their cartel not only legal, but also mandated by force of law!
Re:Details of First4Internet DRM implementation
on
Sony's New DRM Technique
·
· Score: 2, Interesting
So it's a virus then.
What we need is more DRM, something like MS Trusted Computing to protect us from this other....! Oh wait....
I like how Sony made a point of saying the discs conform to the Phillips CD spec. That still doesn't mean the CD is "pure", and that it is being deceptively marketed and sold.
Leave it to the Music Distribution Cartel to team up with the Software Monopoly to insure that everybody is screwed over; listeners as well as artists.
My immediate question is if these discs will work fine under non-Microsoft OS's and devices. Is the music still encoded in normal Audio CD format on the discs if you ignore the extra data portion.
how do you search for a string in your bash command history using default emacs-ish keys?
Control-R -- reverse interactive history search.
And how do you tell it you will be replacing the next N words with some input text?
ESC 5 ESC D -- delete following 5 words.
If your keyboard has one, the Alt key can be used instead of ESC. Or for more complex repetitive tasks, you can even use keyboard macros, such as:
ESC ( ESC D foo ESC ) ESC 5 ESC e
Where ESC ( and ) start and finish the definition of a keyboard macro, and ESC e replays the macro (similar to vi's dot "." command. The ESC 5 says to do the next thing 5 times. And the stuff inside the macro says to delete the following word and type " foo" in it's place.
However, bash is not full emacs. Also bash, like many other command-line apps such as MySQL, uses the GNU readline library to do all the command-line editing and history functions. The keybindings are completely customizable by editing your ~/.inputrc file. Read the man page for readline....there's lots of useful tips in there to become a command-line editing guru.
I also, having been around from the really old Unix days, miss the old vi-versus-emacs battles that used to take place so often. Now it's more common for the two workhorses to join forces against all the new friendly editors.
Oh, and the hjkl sequence for cursor movement is also quite useful in nethack; proof enough for me.
You the end user (photographer) hold the copyright to everything you produce using the camera (since you bought it without restriction). The DMCA gives you full rights to everything you produce, including decrypting the w.b. data, reprogramming the camera, etc. The problem is, you can't get help from anybody else (like Adobe) in order to exercise your own rights over your own copyrighted material.
What the DMCA does prevent is anybody (like Adobe) from "traficking" in software which decrypts the data. It doesn't matter who actually owns the copyright...even if the photographer releases everything to the Public Domain. It's the fact that there could exist any copyrighted photo which Adobe's software could be used to decrypt by anybody else who's not the copyright holder.
Heck, the Nikon CEO could take his own Nikon camera, take one picture, and thus Nikon would own the copyright to one image, which Adobe's "piracy tool" could be used to unlock. Note this could also affect non-commercial software too, like The Gimp, if they wanted to support the proprietary Nikon white balance.
Of course the DMCA is completely absurd and is only useful for legalizing outright fraud and extortion schemes; it does almost nothing to actually protect copyright or prevent piracy. But I still want to know why in the world is the camera encrypting anything to begin with?
I knew one hospital that would regularly incinerate keyboards that were at a high risk of contamination, or that were known to be contaminated (like spilled blood).
The article said something about the hospital just throwing them away, but if they thought there was any serious contamination (other than a common germ that will die in 24 hours) they would be treated as medical waste and disposed of more properly.
Anybody else notice the watermarks over the imagery that reads "(C) 2005 Google". It's especially visible over light areas such as beaches. Of course it's their right, just interesting. And there is a fixed copyright in the lower right that reads "Imagery (c) 2005 DigitalGlobe, EarthSat", at least in some California areas.
Anyway, this is really nice. To be able to switch between traditional line-art mode and imagery. It's neat to do something like a text search on a hospital and then switch to image mode and see the + marking the hellicopter landing pad right under the marker flag.
And he also denounced DRM in his 27 Feb 2005 Review, stating that he is himself boycotting Virgin Records for their abuse of copyright fair use.
"I regard [encrypting CDs to prevent MP3 ripping] as cheating the customer, since it is widely known that many customers expect to be able to do exactly that, and copyright law allows it.
"Therefore I will never again buy a cd from Virgin Records. Cheat me once, shame on you. Cheat me twice, shame on me."
So maybe his position isn't all black-and-white.
This was one step in the media cartel's plan
on
The VHS is Dead
·
· Score: 1
Anybody remember when the media folks were arguing before congress in favor of laws to allow them to restrict fair use with digital media; BECAUSE, as they said, there were analog equivalents which people could use that still preserved their fair use rights.
Only, if the anolog equipment dies (no new equipment, spare parts, video tape, etc); then where will our fair rights be? Everything will be locked up so tight in DRM by then that there will be no rights at all. And I'm sure the media people making those arguments knew full well that all they had to do was wait a little longer and then they could seize complete control.
No new fair rights are being built into new technologies. The only thing that's happing is that rights are being revoked, slowly, one new technology at a time. And it's being done so cleverly that nobody notices.
This same trick is being used by a lot of industries. Say, you don't want your automobile to monitor where you go and how fast your drive? Then just buy an older model car. But in 10 years; oops, I guess you have little choice. To bad, the laws were already passed because we argued then that you had an option.
I think the most important contribution Adobe could make would be to lessen the restrictions on several key Intelectual Property (sic) assets. Of course to make this even potentially reasonable for Adobe, they could do so in a copylefted-approach, so that the IP rights are only granted in a non-discriminatory manner when used in open-source code or applications. Surely that has to be a way for Adobe to keep its monoplistic protections against other commercial players, yet allow the free software community enough leeway to actually deal with Adobe (and in the long run help Adobe). This is in some ways similar to the Sun/Java debate.
Several key technologies currently keep Linux way behind, especially in the high-end graphics market. Some I can think of surround fonts, such as hinting, or even the free distribution of the core fonts that make up PDF or Postscript; and also especially around color processing. Adobe has literally hundreds and hundreds of patents and other protectionist assets that are an extreme hinderance to Linux adoption of their "standards"; especially in the higher-end markets and applications.
Slashdot Mirror
If you want to see some of his best writing (and most
/. complainer), then you can learn a lot
diverse) get his short story anthology Maps in a Mirror.
It's also annotated, so it gives you a great peek into
his mind and how/why he writes certain stories. That
really shows off the brilliance of OSC as a writer.
Also, if you are or want to be a writer yourself (rather
than a typical
from OSC. His book on how to write SciFi is the best
on that topic. He also provides a lot of help for
writers on his website.
Really, what makes OSC great is perhaps not any particular
work, but rather his grasp of people, and that great
stories must be about the characters. Otherwise all you
have is a literary carchase and explosions, just special
effects with no meat.
Oh, and if the Full House thing at the end of the review
puzzles you, then you just haven't read enough of his
reviews to understand his sense of humor, or that he
is a devoted parent and thus sometimes cares about things
that may seem quite corny to adults.
And I have 100000000000000000000...0000000000000000000Mail (100 zeros), just in case anybody has any bright ideas [I'm looking at you Google]...
We can only hope that Creative refuses to license its patent. And in the best case Apple looses and is forced to stop production of its iPod (in current form anyway). This is not out of spite of Apple or its products, but as a necessary step to patent reform.
When I say best case, I mean from a long term perspective. One of the main reasons there is so little effort to reform US patent law is because the ad-hoc and unspoken system of cross licensing that exists among the biggest players hides most of the pain and stupidity of the patent system from the mass consumer. Cross licensing pratices are nearly as harmful as patents themselves, as it basically allows the largest corporations to play by different anticapitalistic rules than the smaller company or inventor. It's only when actual consumers are affected in-masse and it's clear that its because of stupid patents that any real presure on lawmakers will be made. Before it will get better there has to be at least one (maybe many) very large cases where patent law completely disrupts the economy and the public is aware of the cause.
This is a good study of how hard it is to design secure systems. It's just like a non-cryptographer trying to create their own cipher, only in the visual processing world. Sadly, the article does not touch on non-visual captchas, which are alternatives for the blind. It would also be interesting to see what Jakob Nielsen might have to say on this technology from a usability perspective.
Of course, one of the primary bad things is that the concept of a captcha is patented, and the patent language is very broad. US Patent# 6,195,698
Also see the Wikipedia article for more information.
Thank goodness we might finally see proper PNG alpha channel support after, what, a decade? But there are some other annoyances which I hope also get on their list...
Meanwhile I get lots of naughty SPAM without an ID check, and even google images turns up stuff that will make my eyeballs melt out of my head. Not to mention that the URL bar in my browser is very dangerous, and should be banned. And have you even tried running the WebCollage screen saver? Where's the ESRB been?
No, somebody register the TLD "un." quick.
Why in the world would anybody want to turn over this control to such a corrupt and bureaucratic organization. The address assignments is not a very defendable reason, it's more likely the other types of control they could start imposing. Like even more outrageous copy controls, censorship, taxes, and other forms of non-democratic social engineering, or anything to further progress on the anti-American movement. That's all the UN is about these days, and we've already surrendered too much of our (US) freedom to the UN already.
An even more relavant essay of his is What You Wish You'd Known.
Also be sure to check out The Muddle Machine by Tamim Ansary, a school textbook editor who describes the apalling state of textbook publication today.
First, with ISO-quality standards, updates are made carefully and slowly to insure the least pain to all users relying on the standard. Backwards compatibility is usually the most important concern to the maintainers; there's no "willy nilly" changing going on. [Compare this to say Java, whose specs change much more quickly and perhaps more "willy" than C++]
There are many reasons to update standards periodically:
1. Most standards bodies (such as ISO) *require* that all standards be updated, or at least re-affirmed, on a periodic basis; usually once per decade. Otherwise they are considered abandonded and "revoked" from having its standard status. This helps weed out truely abandoned standards as well as insures that the standard is properly maintained and retains its usefulness.
2. As with most language standards, there are always many many small technical imperfections, or more commonly ambiguities, that need to be addressed or clarified. Most of these will never affect the "common" programmer, except perhaps those on the fringe (such as with embedded systems and so forth).
3. Practical experiences with a language often show shortcommings that, although may be technically minor, greatly detract from the language's usefulness in some cases. For instance when the C standard was last updated they made the numerical semantics much tighter (because they found out FORTRAN programmers could not adequately port programs to C without them). These changes would be hardly noticed by most programmers who don't do heavy and precise computation; but greatly welcomed by those who did.
4. Sometimes novel techniques or components are invented which prove to be very general solutions to widely-encountered problems, and which fit the "style" of the language very closely. Once these experimental components are deemed very mature and stable, adding them into the language proper can benifit all language users. For C++, many of these new extensions come out of the Boost project. But only the most mature and the most general-purpose extensions should be considered for standardization.
For a look at what's on the C++ issue lists, look at http://www.open-std.org/jtc1/sc22/wg21/
One of the great things about "AJAX" is that the "X" is optional. No reason to do XML at all unless that's what you want. So, if XML is overkill for your application, take a look at JSON, http://www.json.org/
I think it's better than CSV even. And it's got bindings to tons of languages, not just Javascript. So producing the server-side is also very easy.
The GUID (as called by Microsoft) has it's history in the UUID, which was first "invented" by OSF as part of it's big DCE specs (long before Microsoft adopted the format and gave it a spiffy new name).
The UUID and GUID look alike, but the UUID was constructed in a much different manner than GUIDs seem to be nowdays. GUIDs are basically 128-bits of random data (usually made by passing pseudo-random seeds through a hash). UUIDs on the other hand contained structured data too in addition to randomness, to try to prevent accidental reuse. For instance the rightmost 48 bits come from the Ethernet MAC address if available. Other bits contained date/time information, process/thread ids, etc.
There was an expired Draft RFC written in February 1998 which explained a lot of the technical details of GUIDs and UUIDs (surprisingly authored by Microsoft). You may still be able to find copies of it out on the net (the filename was "draft-leach-uuids-guids-01.txt")
Don't forget to go to Preferences > Security > SSL > Extra SSL3/TLS and enable the following cipher first:
(X) No encryption with RSA authentication and SHA1 MAC
Then disable all the other less-secure ciphers. This will make your https connections super secure!!
(Despite my sarcasm, it's important to realize that https doesn't automatically mean secure. You need to make sure you negotiated good algorithms, that you trust the server certificate, and that the issuer of that certificate was not your own company's CA set up to run an https proxy).
There is a necessary qualification though, circumvention is only illegal if the copy protection actually protects a copyrighted work to which I have no copyright permission otherwise.
If I produce my own works, then I own the copyright and I'm exempt from circumventing my own protection. I could also release my works to the Public Domain, and therefore anybody could legally circumvent any copy protection that may happen to be on that work since it doesn't qualify for DMCA protection. Now just because the same code can both decrypt MY works as well as somebody else's doesn't give users the right to decrypt those other works; just mine. But, as the writer of software, that's not my problem. I should be able to traffic in such programs if I own the copyright to the works it protects...it exempts me from the DMCA "trafficking" sections. I'm not solving the "can't copy" problem; but I'm trying to solve the "can't write software" problem.
Furthermore, the DMCA provides explicit exemptions for reverse engineering.
True, this would legally prevent me from reproducing the same "invention". But that would also mean that the copy protection technique itself is publically disclosed, something that would be welcome amyway. It also doesn't necessarily mean I can't create an equivalent protection mechanism. The encrypted content itself (the data on the disc) is not patentable.
Yes, I do belive this is a potentially powerful technique to use to disarm the DMCA (and similar shameful laws). But it's hard to cover all bases, and is expensive. However I think just like the GPL cleverly uses copyright law against the hoarding of knowledge, that Patent law ought to be able to be used in such a backwards scheme too, an antipatent.
The DMCA does not (yet) prohibit reverse engineering, nor does it prohibit you from decrypting anything. It only disallows the "trafficking" of the decryption tools that may be used to bypass copy control mechanisms on somebody else's content (without substantial other uses).
But what if...
1. I reverse engineer Company S's encoding method -- legal.
2. I create an encryptor, which can be used to encode a disc using that same technique, and open encryptor code to public (as long as it can't directly decrypt) -- legal, with patent caveat.
3. I create and publish my OWN content encoded using that method (to which I own the copyright) -- legal.
4. I then create a decyptor program which will decrypt MY content, which has a built in simple password "copy control" mechanism (but since I'm lazy it's pretty trivial) -- legal.
5. I open up my decryptor program with source for all people who download my content and pay me $1 for the "password key" -- legal?
Now, by "conincidence", the password key which protects MY work for which you purchased a license, also just happens to decode all Company S's content too, since it uses the same legally reverse-engineered algorithms. But since that code was legally developed, and is used to protect MY OWN content, then can't I release it?
Isn't the key to avoiding DMCA nonsense to create your own content...then don't you have the same right to protect and decrypt your own content as Company S does? Who says only S**y is allowed to create discs with intentionally corrupt sectors; and therefore only S**y can say who can write programs that ignore such sectors?
Your comment is absolutely correct. Profit and piracy have always been side issues, a diversionary tactict. The real issue is one of controlling content *creation* and distribution. What the RIAA/MPAA really want is to make sure that independent content producers HAVE to use their services to be able to publish. They are the middlemen, and they want to stay that way. Allowing artists to publish directly to consumers is their worst nightmare, regardless if there is an effective payment system or copy controls.
Think about all the DRM stuff. Even the technologically flawed controls in DVDs should make this clear. They don't do a darn thing about stopping piracy. But they DO inhibit the independent creation of content (or are the first step in such a plan). Because the technology must be licensed, the keys must be issued, and it's not opened up to anybody except their small set of cartel members.
Now it just so happens that their best bet is to use the whole "piracy is stealing" approach as the most likely to cause sympathy with legislators. So once they get mandated technological controls in place in all hardware devices, then it's relatively easy for them to start using those same mechanisms to start locking out content creators...not just those pirate consumers.
Lexmark abusing the DMCA as a way to prevent other manufacturers from producing products had nothing to do with actual piracy or IP "stealing". But that was just a preview of what the RIAA/MPAA ultimately want to be able to do themselves...to be able to lock out all other producers. This is what a cartel is all about; only they're paying off the legislative system to make their cartel not only legal, but also mandated by force of law!
So it's a virus then.
What we need is more DRM, something like MS Trusted Computing to protect us from this other....! Oh wait....
I like how Sony made a point of saying the discs conform to the Phillips CD spec. That still doesn't mean the CD is "pure", and that it is being deceptively marketed and sold.
Leave it to the Music Distribution Cartel to team up with the Software Monopoly to insure that everybody is screwed over; listeners as well as artists.
My immediate question is if these discs will work fine under non-Microsoft OS's and devices. Is the music still encoded in normal Audio CD format on the discs if you ignore the extra data portion.
Control-R -- reverse interactive history search.
ESC 5 ESC D -- delete following 5 words.
If your keyboard has one, the Alt key can be used instead of ESC. Or for more complex repetitive tasks, you can even use keyboard macros, such as:
ESC ( ESC D foo ESC ) ESC 5 ESC e
Where ESC ( and ) start and finish the definition of a keyboard macro, and ESC e replays the macro (similar to vi's dot "." command. The ESC 5 says to do the next thing 5 times. And the stuff inside the macro says to delete the following word and type " foo" in it's place.
However, bash is not full emacs. Also bash, like many other command-line apps such as MySQL, uses the GNU readline library to do all the command-line editing and history functions. The keybindings are completely customizable by editing your ~/.inputrc file. Read the man page for readline....there's lots of useful tips in there to become a command-line editing guru.
I also, having been around from the really old Unix days, miss the old vi-versus-emacs battles that used to take place so often. Now it's more common for the two workhorses to join forces against all the new friendly editors.
Oh, and the hjkl sequence for cursor movement is also quite useful in nethack; proof enough for me.
You can recreate the screenshots yourself. Just save the following to a file longhorn.html:
<html><body bgcolor="BLUE">
Error 0. An unknown driver did something really bad.
</body></html>
Have fun with it.
You the end user (photographer) hold the copyright to everything you produce using the camera (since you bought it without restriction). The DMCA gives you full rights to everything you produce, including decrypting the w.b. data, reprogramming the camera, etc. The problem is, you can't get help from anybody else (like Adobe) in order to exercise your own rights over your own copyrighted material.
What the DMCA does prevent is anybody (like Adobe) from "traficking" in software which decrypts the data. It doesn't matter who actually owns the copyright...even if the photographer releases everything to the Public Domain. It's the fact that there could exist any copyrighted photo which Adobe's software could be used to decrypt by anybody else who's not the copyright holder.
Heck, the Nikon CEO could take his own Nikon camera, take one picture, and thus Nikon would own the copyright to one image, which Adobe's "piracy tool" could be used to unlock. Note this could also affect non-commercial software too, like The Gimp, if they wanted to support the proprietary Nikon white balance.
Of course the DMCA is completely absurd and is only useful for legalizing outright fraud and extortion schemes; it does almost nothing to actually protect copyright or prevent piracy. But I still want to know why in the world is the camera encrypting anything to begin with?
I knew one hospital that would regularly incinerate keyboards that were at a high risk of contamination, or that were known to be contaminated (like spilled blood).
The article said something about the hospital just throwing them away, but if they thought there was any serious contamination (other than a common germ that will die in 24 hours) they would be treated as medical waste and disposed of more properly.
Anybody else notice the watermarks over the imagery that reads "(C) 2005 Google". It's especially visible over light areas such as beaches. Of course it's their right, just interesting. And there is a fixed copyright in the lower right that reads "Imagery (c) 2005 DigitalGlobe, EarthSat", at least in some California areas.
Anyway, this is really nice. To be able to switch between traditional line-art mode and imagery. It's neat to do something like a text search on a hospital and then switch to image mode and see the + marking the hellicopter landing pad right under the marker flag.
And he also denounced DRM in his 27 Feb 2005 Review, stating that he is himself boycotting Virgin Records for their abuse of copyright fair use.
So maybe his position isn't all black-and-white.
Anybody remember when the media folks were arguing before congress in favor of laws to allow them to restrict fair use with digital media; BECAUSE, as they said, there were analog equivalents which people could use that still preserved their fair use rights.
Only, if the anolog equipment dies (no new equipment, spare parts, video tape, etc); then where will our fair rights be? Everything will be locked up so tight in DRM by then that there will be no rights at all. And I'm sure the media people making those arguments knew full well that all they had to do was wait a little longer and then they could seize complete control.
No new fair rights are being built into new technologies. The only thing that's happing is that rights are being revoked, slowly, one new technology at a time. And it's being done so cleverly that nobody notices.
This same trick is being used by a lot of industries. Say, you don't want your automobile to monitor where you go and how fast your drive? Then just buy an older model car. But in 10 years; oops, I guess you have little choice. To bad, the laws were already passed because we argued then that you had an option.
I think the most important contribution Adobe could make would be to lessen the restrictions on several key Intelectual Property (sic) assets. Of course to make this even potentially reasonable for Adobe, they could do so in a copylefted-approach, so that the IP rights are only granted in a non-discriminatory manner when used in open-source code or applications. Surely that has to be a way for Adobe to keep its monoplistic protections against other commercial players, yet allow the free software community enough leeway to actually deal with Adobe (and in the long run help Adobe). This is in some ways similar to the Sun/Java debate.
Several key technologies currently keep Linux way behind, especially in the high-end graphics market. Some I can think of surround fonts, such as hinting, or even the free distribution of the core fonts that make up PDF or Postscript; and also especially around color processing. Adobe has literally hundreds and hundreds of patents and other protectionist assets that are an extreme hinderance to Linux adoption of their "standards"; especially in the higher-end markets and applications.