So I guess it all comes down to what the definition of the word "unwillingly" is.:-)
Perhaps... I don't think a monopoly or product-tying has to be absolutely unavoidable to be coercive. It just has to be sufficiently pervasive as to make it unfavorable, in terms of cost and effort, to get around it.
I would call my acceptance of the Microsoft Tax "unwilling" since the only way to escape from it is to buy from a low-volume manufacturer or choose from a very reduced selection (such as Dell's Linux systems, presumably negotiated with Microsoft??), thereby negating the benefits of not paying for Windows.
It's the "least bad option" in some cases, but there's a much better option (buy the same computer with no OS) that's artificially suppressed by Microsoft.
On a serious note, why not get your computer built for you (or DIY if you can). I had mine built by a small local company (Intel core2 quad, 4Gig RAM and 250Gig hard drive so a decent spec) and it cost well under £300. It came 'empty' - no OS - so I could install Ubuntu with NO Windoze contamination. It works geat. It's never given me any trouble at all and it does everything I want, quickly and very well.
It's a reasonable point, and it's true that some companies will actually refund the Microsoft Tax if you demand it... although it inevitably turns out to take so much time and effort that it's not worth it.
The problem is that most of the best prices on pre-built computers come with Windows pre-installed. Sure, Dell may sell some systems running Ubuntu... but the selection is limited. For example, none of them use AMD processors. So, invariably, for me to get the best price on what I want, I have to accept Windows bundled with it. I am getting the best price, but it would be even lower if the seller weren't passing along the cost (perhaps $10-100, hard to say) of a Windows OEM license.
I imagine many manufacturers would willingly offer a choice of Operating System ("none: subtract $40" or "Windows: $0") if Microsoft didn't strong-arm them.
Also, I have built a number of DIY computers. However, often you can get a better deal buying a pre-built system from a big box store.
However, it has one major hurdle to overcome: it doesn't support Windows.
Fuck Windows. Seriously.
I've been unwillingly paying the Microsoft tax for TEN YEARS. All I ever do is wipe Windows and install Linux. If my new computer can't run Windows then... great!! Maybe I won't have to pay the tax.
I'd love a low-power, high-performance ARM notebook. I'd be happy with MIPS or Loongson (Chinese MIPS clone) as well. Debian already has a full-blown ARM port and I'll bet they could get it working on an ARM netbook in a day. Ubuntu would undoubtedly be soon-to-follow.
As a side benefit, having multiple widely-used architectures for desktop systems (x86 and ARM) would be a support nightmare for hardware companies that still keep their drivers proprietary and undocumented. Yeah, I'm looking at you, Broadcom and NVidia. This would just be another nail in the coffin for their obstructionist attitudes towards free/open-source operating systems.
Right, but merging and wholesale transfers of brainpower are built into Open Source as well. As in the case of Compiz and Beryl reunifying amicably, and the XFree86 devs jumping to X.org when an unfavorable license change was announced.
Permissive and GPL-compatible licensing and goodwill are what makes these things possible. We've seen IBM and Mozilla and Sun and even Apple relicense or dual-license some software under the GPL to improve collaboration. I doubt Microsoft would be obliging in that regard.
If Microsoft could split the open-source community into non-cooperating groups that used incompatible licenses... well, they'd like that a lot.:-)
It's pure idiocy to not take advantage of the ability to have your code merged in, and condemns your customers to not only having to build their own kernels or use ones you provide, but keeps them stuck with old kernel versions.
Right... there's a quite a mess in the embedded world with a lot of device makers stuck on bug-ridden, horribly hacked-up 2.4 kernels. In particular, the execrably unhelpful Broadcom has never released any open-source drivers for its WiFi chipsets, and no binary drivers for 2.6.x kernels (except recently for x86).
Microsoft just doesn't "get" the way Linux works. It's kind of astonishing that even the developers responsible for writing Linux kernel code there haven't figured out the value of cooperating with the kernel team. Well... maybe they have and the suits overruled them. Hard to say.
Thank them for what? MS's contributed drivers are useless to anyone who isn't running MS's own hypervisor and Linux underneath (i.e., MS's customers). They didn't donate this code out of any altruism, only pure self-interest.
Yeah, and they only decide to "donate" this code after it was pointed out to them that keeping the code private was a violation of the GPL, since it's clearly a derivative work of the Linux kernel.
So what do they do? Instead of GPL'ing it and working to maintain and clean up the code themselves, they just dump it on the kernel maintainers. Lame.
In my mind, it shows that Microsoft still doesn't take Linux seriously on some level. They don't bother to build a useful working relationship with the kernel devs because they see this as a one-off interaction just to "get Linux working with Windows."
Contrast this with, say, Intel or AMD or Realtek or IBM or pretty much any hardware company. Of course, contributing to the Linux kernel is a matter of "pure self-interest" for those companies too: they want to make their Linux-using customers to buy and happily use their hardware. But those companies learn to work with the mainstream kernel development process, because they see a long-term interest in a good relationship with the community of Linux developers and users.
... doesn't seem to be working so well against open-source stuff. Maybe Microsoft's new strategy is to split and balkanize the open-source community with a bunch of conflicting licenses and communities.
in audio and video? yes you are right. but in Ebooks it's REally stinking easy to hide a watermark that will not get destroyed. I do t hat all the time on a customers PDF generator for files he sells online. I dynamically generate the PDF when the customer buys it. It has embedded in it TWO copies of the watermark which is the purchaser's information. On the front page is a "bookplate" that states the user's name and personal info, Later on in the book I hide an encrypted version in other places. It's not easy to find either I've had several buddies try and crack it.
...
it can be defeated if someone finds it and erases all traces throughout the ebook. WE have yet to see that happen in the past 3 years.
Interesting approach. One of the things that I always observe about engineers who produce DRM/watermarking schemes is that they always seem fairly confident that their version is unbreakable. Whereas basically every DRM scheme ever has been broken as soon as there were enough hackers around who cared about it/used it.
Your watermark program may be quite robust as these things go, but it still doesn't address the underlying issue I emphasized above: digital data is designed to be easy to copy, so once your watermark is circumvented or ignored, there's nothing stopping further distribution.
Ways to break it, off the top of my head:
Buy a copy with a stolen card or account, and distribute that via P2P. Even if your client manages to "nail someone to the wall," it won't be the actual infringer, and thus the watermark has no deterrent value.
Lossy compression again. Remove any obvious visible watermarks, and convert the PDF to DjVu format which stores everything as a high-compressed image optimized for text.
OCR the whole thing and distribute the work as a text file. Quite practical for fiction and general works... not nearly as easy for works with a lot of art or complex text formatting.
If you had a C64 and did any sort of programming on it you would know that the basic interpreter was just a rom mapped to a section of the under lying ram space. You could flip the basic interpreter rom image in or out as you saw fit by using assember code.
Yes, I did have a C64, did do some programming with it, and do know that the BASIC interpreter ROM could be mapped in and out of the 64k memory space.
I'm not familiar with the code for any commercial programs... but I seem to recall having heard about lots of hacks that used routines in the BASIC ROM in lots of interesting ways... beyond just using it to boot.
And this is why I wonder just how much of the BASIC ROM can be excised from the emulator without severely hurting game compatibility.
Everyone on Slashdot seems to think the developer intentionally left an obvious, easy backdoor into the BASIC interpreter just to spite Apple.
But here's what I'm wondering: is it actually possible to remove BASIC from the C64's ROM, and still be sure that games will run?
If I recall correctly, the in-ROM BASIC interpreter provided a bunch of useful routines that you could access from machine code, and a lot of games and apps would call into these routines, or copy them elsewhere in memory, sometimes in ways that would seem horrifically non-portable and non-obvious today. It might be that it's just not really possible to excise the BASIC interpreter and still run a decent number of games.
I haven't done much C64 in many years though. Can anyone fill us in on the technical feasibility of completely removing the BASIC interpreter?
Unfortunately, it's not so easy to do this. When embedding a watermark, there are three fundamental approaches:...
So it's not an easy problem, and as compression improves, option #2 there will get even harder over time.
That's a good summary. However, I believe digital watermarking has the same fundamental flaw as DRM: the means, expertise, and equipment to create and modify digital files are plentiful in this day and age.
Any idiot can copy a music file to a friend's computer. So DRM attempts to limit that easy copying, but as soon as it's broken, it's broken. Likewise, the bar is not much higher for being able to modify, edit, or sample a music file: audio editing software, MP3 encoders, tagging software, hex editors... all easily-available, easy-to-learn (with guides all over the web), and easy-to-use. So watermarks attempt to add a unique, recognizable, but unintrusive tag to that file, and they run back into the same issue that the underlying data is very easy to manipulate.
Contrast this situation with that of paper money, which often contains watermarks: The bar to "editing" or "copying" money is a lot higher. Sure, you can make a crappy copy of a $20 bill on a printer, but it won't turn out well. The recipes for real currency paper are secret and centralized, so difficult to steal. The physical equipment to print real money is extraordinarily large, immobile, and expensive, and easier to regulate since there are few legitimate, small-scale uses for things like color-changing ink and microprinting. Lastly, there are more, and smarter, serious guys with guns who take a professional interest in counterfeiting than in file-sharing.
In my view, any purely technical means to limit the distribution or modification of digital data is bound to fail. I mean, we've spent decadestrying to make digital data easy to copy and modify... and gosh, we've succeeded.
DRM and watermarks both rely on, essentially, an intentional obfuscation of data. But the means to detect (watermarks) or reverse (DRM) that obfuscation must then be widely distributed for them to be useful. Security through obscurity, minus most of the obscurity. Secure cryptosystems like PGP or SSL depend on a very small core of obscurity (a secret key) and construct elaborate safeguards and mechanisms to keep that secret key from ever traversing the network, and from "leaking" its content onto the data in a visible way. And still flaws are sometimes found. DRM takes that secret key and spreads it around all over the place. Lame.
Even though the encrypted shared file is freely copyable, the key file to unlock it is "tamper-proof" so it has it's own DRM to make it "un-copyable".
Right, they are just "moving" the DRM. Instead of having a DRM-ed media file, you will have an encrypted media file, and a DRM-ed decryption key. Your ability to access the decryption key is wrapped in DRM, so that you can't use it to make a permanent unencrypted copy, and you can't use it if anybody else "has it".
This solves nothing. In fact it would probably be even more of a pain than current DRM, since now you have to keep track of two files. And probably every DRM-happy media player maker would implement their own standards for the file format.
The real problem, only alluded to in the article, is that the whole idea of "digital personal property" is just an attempt to create artificial scarcity where none really exists. The bandwidth, storage space, and equipment needed to create copies of digital media are in plentiful supply, and the marginal cost per copy is essentially zero.
Big Contentâ is just dying to shoe-horn us back into the era where the means and expertise to create and distribute content are rare and costly...
It's a matter of precision and recall, a very elementary and important concept of statistics.
Basically, anyone who designs or uses any kind of test designed to find the proverbial needle-in-a-haystack ought to learn some basic fscking statistics and how they apply to this situation. And yes, that includes police officers and screening personnel in the field, in my opinion.
Now if the patent system could just figure out how to keep bullshit patents from getting approved in the first place, we'd be doing a lot better. 20 years is WAY too long to have any kind of process patent like One Click or FAT, not to mention a lot of them are relatively obvious extensions of current technology. Granted, the FAT32 long file name hack is pretty elegant and clever, and I can see why it may have deserved a patent, but now it's just an anticompetitive weapon rather than a technological differentiator. It should have been valid for maybe 10 years, tops.
I'm gonna disagree with that. There's nothing perfectly clever or novel about the "long file name hack." It's Backwards Compatibility 101, and I would argue that any person with "ordinary skill in the art" of filesystem design could have come up with it. I, for one, was 12 years old when it came out, and understood it immediately:-)
Why was the long filename support needed in the first place? Why, because older versions of FAT only supported 8.3 filenames! And whose fault is that? Microsoft's!!! Other equally old filesystems like the original Unix File System and Mac OS's HFS supported longer filenames.
So, in order to allow backwards-compatibility, Microsoft kept the 8.3 filenames in FAT, but also added a separate area of the disk to store longer filenames, and came up with some rudimentary rules to sync them up... like "LISTOF~1.DOC" for "List of things to do.doc".
It's a reasonable solution to a lame problem. There are some weirdly ambiguous situations dealing with mixed-case short filenames, and such, but it doesn't create too many headaches. I wouldn't call it particularly elegant or clever though.
This is definitely a bad idea. It will break interoperability with old hardware that can only handle short names. This isn't just PCs but embedded systems where a FAT-12 floppy may be the only convenient way to transfer files. This "solution" will require one to generate the short name first before the files are copied onto the destination media. Hopefully it will be easily disabled in the code.
Yes, it will be easily to disable. It's just a patch that provides a compile-time option for the Linux kernel. You can still compile it with full-fledged FAT support. The patch mostly addresses the needs of big companies and distributors likely to be targeted by the patent vultures at MS.
Pretty much all modern MP3 players (those made in the last 5-8 years, Sansa, iPod, Zen, etc.) have 32-bit CPUs (typically ARM) running at 10s to 100s of MHz, with many megabytes of RAM. This allows them to do software decoding of music and video, which is now cheaper and more flexible to implement than dedicated decoding hardware.
That being nice, FAT is a pretty simple and easy-to-implement filesystem, and it's nice for that purpose, but it's got some warts itself. These BS patents of Microsoft are fairly pathetic: basically they describe a crufty but workable backwards-compatible way to handle long filenames, when shoft "8.3" filenames were in fact a problem wholly created by FAT in the first place. So basically Microsoft has patented "cleaning up our own mess, sort of".
How do simpler devices that write to FAT deal with it?
cameras, pdas, etc
All modern PDAs can typically deal with long filenames fully, so no problems there. They would read the long filenames properly from a FAT disk created with this Linux patch.
Digital cameras typically use short filenames exclusively (e.g. IMPC1234.JPG). They mostly only write files and don't read files other than those that they've created themselves. This patch doesn't affect filename reading, only filename writing, so cameras would work okay too.
MP3 players typically deal with long filenames as well, so no problems again, hopefully... as long as they obey the specs for reading FAT partitions.
So this patch should not interfere much with interoperability with modern accessory/embedded devices. Of course, the patch does remove some functionality... namely the ability to create nicely matched short filenames when you're also creating a long filename. But I do believe it's a fairly clever way to avoid this bullshit patent while maintaining interoperability.
It's important to understand that this patch DOES NOT permanently remove any functionality from the Linux kernel. It merely provides a kernel config option to disable full FAT operation. Depending on your jurisdiction/comfort level/Microsoft-hatred/etc. you can choose to enable/disable the patch.
It seems that Wales is more-or-less accepted as the "Benevolent Dictator For Life" of Wikipedia. Much along the lines of other open-source projects that have BDFLs, such as Linus Torvalds for the Linux Kernel, or Guido van Rossum for Python.
I guess one thing that checks these leaders' power is that the licensing of their projects allows any group of sufficiently disgruntled developers/participants to fork it and start a new project. I think this provides a useful tension between strong leadership and lsitening to the concerns of others. Do you think this mechanism is enough to keep Jimmy Wales from over-extending his leadership position in Wikimedia projects? I'm not sure myself...
There are only 2 advantages to using XLR mic inputs.
1. XLR mics usually have a balanced output, helping with noise cancellation on long cable runs, and giving twice the effective signal voltage of an unbalanced mic. This really is only an advantage with long runs of cable.
I've heard this issue before. How long is a "long run"?
2. Condenser XLR mics can be powered from 48V phantom power which is possible due to haveing 2 signal conductors. Otherwise the mic must be run off a battery giving much less output.
This one I hadn't heard. I've just read the wikipedia article on phantom power for condenser microphones. It doesn't seem like a great deal of current is required (10 mA max). Can this issue be alleviated by using lower-voltage DC power from batteries?
Aside from not being full frame, it also only does 1080P video @ 20FPS... I understand that it *can* do 30 but Canon crippled it as to not encroach on the 5D market. Has anyone seen any "updated" firmware to crank the frames for the T1i?:)
I wouldn't be surprised to see CHDK come out with an un-crippled 1080P video mode for the T1I/500D. There's unfortunately a hardware-based dealbreaker for that system, though: no external mic input at all. Ugh. Making it pretty much useless for anything beyond home videos, as the on-camera mic is mono, noisy, and low-quality.
There is a XLR adapter for the EOS 5D Mark II. It's made by Beachtek.
Yes indeed. And it http://www.adorama.com/VDBDXA5D.html">costs about $375, which ain't cheap but combined with the Canon 5D it's still under $3,000, or with the Pentax K7 under $1,700.
if you are a indie film maker, why are you using a DSLR instead of a HD video camera that will shoot better video for less money?
I don't think there is any "HD video camera that will shoot better video for less money". Do you know of any that costs $2,500 and has a sensor even close to as big and good-in-low-light as the Canon 5D Mark II? Or as many affordable lens choices?
I recently particpated in the 48 Hour Film Project in Washington, DC. A few of the submitted films were shot on the Canon 5D Mark II DSLR. The image quality was phenomenal, blowing away MiniDV and as good as some of the groups that had $10k+ of pro equipment.
Personally, I'm a Pentax guy, and really excited about the new Pentax K7 DSLR with HD video capability. Unlike the Canon 5D, it allows aperture control during filming... which should allow for some cool effects. And it only costs about $1,200 for a 14 megapixel weather-sealed camera with 720p and 1080i movie modes, half the price of the 5D.
I'd rather have XLR mic in and record real audio than use a DSLR as a video camera.
I'm not enough of an A/V aficionado to really appreciate the advantages of XLR, but it looks like this issue has already been addressed. There's an add-on unit ($375, it ain't cheap) to add XLR and all kind of other audio gizmos to the Canon 5D. I wouldn't be surprised if we see DSLRs with built-in XLR in a year or two.
A public service announcement for all citizens of the US of A: stop mutilating your children's cocks.
Seriously, what is the matter with you nutjobs? The idea that circumcision promotes cock health is long since disproven. Put the knife down. Step away from the cock. Thank you.
Sheesh. We "nutjobs" would take you guys a lot more seriously if you stopped calling this practice "mutilation" or "child abuse." It's long-ingrained in many cultures that love and dote on children.
I'm circumcised and enjoy sex a lot. Maybe I'd enjoy it "more" without it, but I don't really care.
Circumcision may have only slight health benefits for men in the Western world today, but it also offers only very slight risks as well. Lots of us do it for religious or cultural reasons, and to my knowledge there's no greater incidence of sexual dysfunction or other problems like that in societies where that behavior is prevalent.
Slashdot Mirror
So I guess it all comes down to what the definition of the word "unwillingly" is. :-)
Perhaps... I don't think a monopoly or product-tying has to be absolutely unavoidable to be coercive. It just has to be sufficiently pervasive as to make it unfavorable, in terms of cost and effort, to get around it.
I would call my acceptance of the Microsoft Tax "unwilling" since the only way to escape from it is to buy from a low-volume manufacturer or choose from a very reduced selection (such as Dell's Linux systems, presumably negotiated with Microsoft??), thereby negating the benefits of not paying for Windows.
It's the "least bad option" in some cases, but there's a much better option (buy the same computer with no OS) that's artificially suppressed by Microsoft.
On a serious note, why not get your computer built for you (or DIY if you can). I had mine built by a small local company (Intel core2 quad, 4Gig RAM and 250Gig hard drive so a decent spec) and it cost well under £300. It came 'empty' - no OS - so I could install Ubuntu with NO Windoze contamination. It works geat. It's never given me any trouble at all and it does everything I want, quickly and very well.
It's a reasonable point, and it's true that some companies will actually refund the Microsoft Tax if you demand it... although it inevitably turns out to take so much time and effort that it's not worth it.
The problem is that most of the best prices on pre-built computers come with Windows pre-installed. Sure, Dell may sell some systems running Ubuntu... but the selection is limited. For example, none of them use AMD processors. So, invariably, for me to get the best price on what I want, I have to accept Windows bundled with it. I am getting the best price, but it would be even lower if the seller weren't passing along the cost (perhaps $10-100, hard to say) of a Windows OEM license.
I imagine many manufacturers would willingly offer a choice of Operating System ("none: subtract $40" or "Windows: $0") if Microsoft didn't strong-arm them.
Also, I have built a number of DIY computers. However, often you can get a better deal buying a pre-built system from a big box store.
However, it has one major hurdle to overcome: it doesn't support Windows.
Fuck Windows. Seriously.
I've been unwillingly paying the Microsoft tax for TEN YEARS. All I ever do is wipe Windows and install Linux. If my new computer can't run Windows then... great!! Maybe I won't have to pay the tax.
I'd love a low-power, high-performance ARM notebook. I'd be happy with MIPS or Loongson (Chinese MIPS clone) as well. Debian already has a full-blown ARM port and I'll bet they could get it working on an ARM netbook in a day. Ubuntu would undoubtedly be soon-to-follow.
As a side benefit, having multiple widely-used architectures for desktop systems (x86 and ARM) would be a support nightmare for hardware companies that still keep their drivers proprietary and undocumented. Yeah, I'm looking at you, Broadcom and NVidia. This would just be another nail in the coffin for their obstructionist attitudes towards free/open-source operating systems.
branching... it's built into opensource.
Right, but merging and wholesale transfers of brainpower are built into Open Source as well. As in the case of Compiz and Beryl reunifying amicably, and the XFree86 devs jumping to X.org when an unfavorable license change was announced.
Permissive and GPL-compatible licensing and goodwill are what makes these things possible. We've seen IBM and Mozilla and Sun and even Apple relicense or dual-license some software under the GPL to improve collaboration. I doubt Microsoft would be obliging in that regard.
If Microsoft could split the open-source community into non-cooperating groups that used incompatible licenses... well, they'd like that a lot. :-)
It's pure idiocy to not take advantage of the ability to have your code merged in, and condemns your customers to not only having to build their own kernels or use ones you provide, but keeps them stuck with old kernel versions.
Right... there's a quite a mess in the embedded world with a lot of device makers stuck on bug-ridden, horribly hacked-up 2.4 kernels. In particular, the execrably unhelpful Broadcom has never released any open-source drivers for its WiFi chipsets, and no binary drivers for 2.6.x kernels (except recently for x86).
Microsoft just doesn't "get" the way Linux works. It's kind of astonishing that even the developers responsible for writing Linux kernel code there haven't figured out the value of cooperating with the kernel team. Well... maybe they have and the suits overruled them. Hard to say.
Thank them for what? MS's contributed drivers are useless to anyone who isn't running MS's own hypervisor and Linux underneath (i.e., MS's customers). They didn't donate this code out of any altruism, only pure self-interest.
Yeah, and they only decide to "donate" this code after it was pointed out to them that keeping the code private was a violation of the GPL, since it's clearly a derivative work of the Linux kernel.
So what do they do? Instead of GPL'ing it and working to maintain and clean up the code themselves, they just dump it on the kernel maintainers. Lame.
In my mind, it shows that Microsoft still doesn't take Linux seriously on some level. They don't bother to build a useful working relationship with the kernel devs because they see this as a one-off interaction just to "get Linux working with Windows."
Contrast this with, say, Intel or AMD or Realtek or IBM or pretty much any hardware company. Of course, contributing to the Linux kernel is a matter of "pure self-interest" for those companies too: they want to make their Linux-using customers to buy and happily use their hardware. But those companies learn to work with the mainstream kernel development process, because they see a long-term interest in a good relationship with the community of Linux developers and users.
... doesn't seem to be working so well against open-source stuff. Maybe Microsoft's new strategy is to split and balkanize the open-source community with a bunch of conflicting licenses and communities.
Division, Discord, and Destruction
in audio and video? yes you are right. but in Ebooks it's REally stinking easy to hide a watermark that will not get destroyed. I do t hat all the time on a customers PDF generator for files he sells online. I dynamically generate the PDF when the customer buys it. It has embedded in it TWO copies of the watermark which is the purchaser's information. On the front page is a "bookplate" that states the user's name and personal info, Later on in the book I hide an encrypted version in other places. It's not easy to find either I've had several buddies try and crack it.
it can be defeated if someone finds it and erases all traces throughout the ebook. WE have yet to see that happen in the past 3 years.
Interesting approach. One of the things that I always observe about engineers who produce DRM/watermarking schemes is that they always seem fairly confident that their version is unbreakable. Whereas basically every DRM scheme ever has been broken as soon as there were enough hackers around who cared about it/used it.
Your watermark program may be quite robust as these things go, but it still doesn't address the underlying issue I emphasized above: digital data is designed to be easy to copy, so once your watermark is circumvented or ignored, there's nothing stopping further distribution.
Ways to break it, off the top of my head:
If you had a C64 and did any sort of programming on it you would know that the basic interpreter was just a rom mapped to a section of the under lying ram space. You could flip the basic interpreter rom image in or out as you saw fit by using assember code.
Yes, I did have a C64, did do some programming with it, and do know that the BASIC interpreter ROM could be mapped in and out of the 64k memory space.
I'm not familiar with the code for any commercial programs... but I seem to recall having heard about lots of hacks that used routines in the BASIC ROM in lots of interesting ways... beyond just using it to boot.
And this is why I wonder just how much of the BASIC ROM can be excised from the emulator without severely hurting game compatibility.
Everyone on Slashdot seems to think the developer intentionally left an obvious, easy backdoor into the BASIC interpreter just to spite Apple.
But here's what I'm wondering: is it actually possible to remove BASIC from the C64's ROM, and still be sure that games will run?
If I recall correctly, the in-ROM BASIC interpreter provided a bunch of useful routines that you could access from machine code, and a lot of games and apps would call into these routines, or copy them elsewhere in memory, sometimes in ways that would seem horrifically non-portable and non-obvious today. It might be that it's just not really possible to excise the BASIC interpreter and still run a decent number of games.
I haven't done much C64 in many years though. Can anyone fill us in on the technical feasibility of completely removing the BASIC interpreter?
Unfortunately, it's not so easy to do this. When embedding a watermark, there are three fundamental approaches: ...
So it's not an easy problem, and as compression improves, option #2 there will get even harder over time.
That's a good summary. However, I believe digital watermarking has the same fundamental flaw as DRM: the means, expertise, and equipment to create and modify digital files are plentiful in this day and age.
Any idiot can copy a music file to a friend's computer. So DRM attempts to limit that easy copying, but as soon as it's broken, it's broken. Likewise, the bar is not much higher for being able to modify, edit, or sample a music file: audio editing software, MP3 encoders, tagging software, hex editors... all easily-available, easy-to-learn (with guides all over the web), and easy-to-use. So watermarks attempt to add a unique, recognizable, but unintrusive tag to that file, and they run back into the same issue that the underlying data is very easy to manipulate.
Contrast this situation with that of paper money, which often contains watermarks: The bar to "editing" or "copying" money is a lot higher. Sure, you can make a crappy copy of a $20 bill on a printer, but it won't turn out well. The recipes for real currency paper are secret and centralized, so difficult to steal. The physical equipment to print real money is extraordinarily large, immobile, and expensive, and easier to regulate since there are few legitimate, small-scale uses for things like color-changing ink and microprinting. Lastly, there are more, and smarter, serious guys with guns who take a professional interest in counterfeiting than in file-sharing.
In my view, any purely technical means to limit the distribution or modification of digital data is bound to fail. I mean, we've spent decades trying to make digital data easy to copy and modify... and gosh, we've succeeded.
DRM and watermarks both rely on, essentially, an intentional obfuscation of data. But the means to detect (watermarks) or reverse (DRM) that obfuscation must then be widely distributed for them to be useful. Security through obscurity, minus most of the obscurity. Secure cryptosystems like PGP or SSL depend on a very small core of obscurity (a secret key) and construct elaborate safeguards and mechanisms to keep that secret key from ever traversing the network, and from "leaking" its content onto the data in a visible way. And still flaws are sometimes found. DRM takes that secret key and spreads it around all over the place. Lame.
Even though the encrypted shared file is freely copyable, the key file to unlock it is "tamper-proof" so it has it's own DRM to make it "un-copyable".
Right, they are just "moving" the DRM. Instead of having a DRM-ed media file, you will have an encrypted media file, and a DRM-ed decryption key. Your ability to access the decryption key is wrapped in DRM, so that you can't use it to make a permanent unencrypted copy, and you can't use it if anybody else "has it".
This solves nothing. In fact it would probably be even more of a pain than current DRM, since now you have to keep track of two files. And probably every DRM-happy media player maker would implement their own standards for the file format.
The real problem, only alluded to in the article, is that the whole idea of "digital personal property" is just an attempt to create artificial scarcity where none really exists. The bandwidth, storage space, and equipment needed to create copies of digital media are in plentiful supply, and the marginal cost per copy is essentially zero.
Big Contentâ is just dying to shoe-horn us back into the era where the means and expertise to create and distribute content are rare and costly...
Apple Blames 'External Forces' For Exploding iPhones
Gee, I thought that explosions are always caused by internal forces... almost by definition!
It's a matter of precision and recall, a very elementary and important concept of statistics.
Basically, anyone who designs or uses any kind of test designed to find the proverbial needle-in-a-haystack ought to learn some basic fscking statistics and how they apply to this situation. And yes, that includes police officers and screening personnel in the field, in my opinion.
Now if the patent system could just figure out how to keep bullshit patents from getting approved in the first place, we'd be doing a lot better. 20 years is WAY too long to have any kind of process patent like One Click or FAT, not to mention a lot of them are relatively obvious extensions of current technology. Granted, the FAT32 long file name hack is pretty elegant and clever, and I can see why it may have deserved a patent, but now it's just an anticompetitive weapon rather than a technological differentiator. It should have been valid for maybe 10 years, tops.
I'm gonna disagree with that. There's nothing perfectly clever or novel about the "long file name hack." It's Backwards Compatibility 101, and I would argue that any person with "ordinary skill in the art" of filesystem design could have come up with it. I, for one, was 12 years old when it came out, and understood it immediately :-)
Why was the long filename support needed in the first place? Why, because older versions of FAT only supported 8.3 filenames! And whose fault is that? Microsoft's!!! Other equally old filesystems like the original Unix File System and Mac OS's HFS supported longer filenames.
So, in order to allow backwards-compatibility, Microsoft kept the 8.3 filenames in FAT, but also added a separate area of the disk to store longer filenames, and came up with some rudimentary rules to sync them up... like "LISTOF~1.DOC" for "List of things to do.doc".
It's a reasonable solution to a lame problem. There are some weirdly ambiguous situations dealing with mixed-case short filenames, and such, but it doesn't create too many headaches. I wouldn't call it particularly elegant or clever though.
This is definitely a bad idea. It will break interoperability with old hardware that can only handle short names. This isn't just PCs but embedded systems where a FAT-12 floppy may be the only convenient way to transfer files. This "solution" will require one to generate the short name first before the files are copied onto the destination media. Hopefully it will be easily disabled in the code.
Yes, it will be easily to disable. It's just a patch that provides a compile-time option for the Linux kernel. You can still compile it with full-fledged FAT support. The patch mostly addresses the needs of big companies and distributors likely to be targeted by the patent vultures at MS.
Pretty much all modern MP3 players (those made in the last 5-8 years, Sansa, iPod, Zen, etc.) have 32-bit CPUs (typically ARM) running at 10s to 100s of MHz, with many megabytes of RAM. This allows them to do software decoding of music and video, which is now cheaper and more flexible to implement than dedicated decoding hardware.
That being nice, FAT is a pretty simple and easy-to-implement filesystem, and it's nice for that purpose, but it's got some warts itself. These BS patents of Microsoft are fairly pathetic: basically they describe a crufty but workable backwards-compatible way to handle long filenames, when shoft "8.3" filenames were in fact a problem wholly created by FAT in the first place. So basically Microsoft has patented "cleaning up our own mess, sort of".
Hmm, I'm not so sure this is a good idea.....
How do simpler devices that write to FAT deal with it?
cameras, pdas, etc
All modern PDAs can typically deal with long filenames fully, so no problems there. They would read the long filenames properly from a FAT disk created with this Linux patch.
Digital cameras typically use short filenames exclusively (e.g. IMPC1234.JPG). They mostly only write files and don't read files other than those that they've created themselves. This patch doesn't affect filename reading, only filename writing, so cameras would work okay too.
MP3 players typically deal with long filenames as well, so no problems again, hopefully... as long as they obey the specs for reading FAT partitions.
So this patch should not interfere much with interoperability with modern accessory/embedded devices. Of course, the patch does remove some functionality... namely the ability to create nicely matched short filenames when you're also creating a long filename. But I do believe it's a fairly clever way to avoid this bullshit patent while maintaining interoperability.
It's important to understand that this patch DOES NOT permanently remove any functionality from the Linux kernel. It merely provides a kernel config option to disable full FAT operation. Depending on your jurisdiction/comfort level/Microsoft-hatred/etc. you can choose to enable/disable the patch.
A thoughtful post indeed.
It seems that Wales is more-or-less accepted as the "Benevolent Dictator For Life" of Wikipedia. Much along the lines of other open-source projects that have BDFLs, such as Linus Torvalds for the Linux Kernel, or Guido van Rossum for Python.
I guess one thing that checks these leaders' power is that the licensing of their projects allows any group of sufficiently disgruntled developers/participants to fork it and start a new project. I think this provides a useful tension between strong leadership and lsitening to the concerns of others. Do you think this mechanism is enough to keep Jimmy Wales from over-extending his leadership position in Wikimedia projects? I'm not sure myself...
There are only 2 advantages to using XLR mic inputs.
1. XLR mics usually have a balanced output, helping with noise cancellation on long cable runs,
and giving twice the effective signal voltage of an unbalanced mic. This really is only an advantage with long runs of cable.
I've heard this issue before. How long is a "long run"?
2. Condenser XLR mics can be powered from 48V phantom power which is possible due to haveing 2 signal conductors. Otherwise the mic must be run off a battery giving much less output.
This one I hadn't heard. I've just read the wikipedia article on phantom power for condenser microphones. It doesn't seem like a great deal of current is required (10 mA max). Can this issue be alleviated by using lower-voltage DC power from batteries?
Aside from not being full frame, it also only does 1080P video @ 20FPS... I understand that it *can* do 30 but Canon crippled it as to not encroach on the 5D market. Has anyone seen any "updated" firmware to crank the frames for the T1i? :)
I wouldn't be surprised to see CHDK come out with an un-crippled 1080P video mode for the T1I/500D. There's unfortunately a hardware-based dealbreaker for that system, though: no external mic input at all. Ugh. Making it pretty much useless for anything beyond home videos, as the on-camera mic is mono, noisy, and low-quality.
There is a XLR adapter for the EOS 5D Mark II. It's made by Beachtek.
Yes indeed. And it http://www.adorama.com/VDBDXA5D.html">costs about $375, which ain't cheap but combined with the Canon 5D it's still under $3,000, or with the Pentax K7 under $1,700.
Yup it's cool, but...
if you are a indie film maker, why are you using a DSLR instead of a HD video camera that will shoot better video for less money?
I don't think there is any "HD video camera that will shoot better video for less money". Do you know of any that costs $2,500 and has a sensor even close to as big and good-in-low-light as the Canon 5D Mark II? Or as many affordable lens choices?
I recently particpated in the 48 Hour Film Project in Washington, DC. A few of the submitted films were shot on the Canon 5D Mark II DSLR. The image quality was phenomenal, blowing away MiniDV and as good as some of the groups that had $10k+ of pro equipment.
Personally, I'm a Pentax guy, and really excited about the new Pentax K7 DSLR with HD video capability. Unlike the Canon 5D, it allows aperture control during filming... which should allow for some cool effects. And it only costs about $1,200 for a 14 megapixel weather-sealed camera with 720p and 1080i movie modes, half the price of the 5D.
I'd rather have XLR mic in and record real audio than use a DSLR as a video camera.
I'm not enough of an A/V aficionado to really appreciate the advantages of XLR, but it looks like this issue has already been addressed. There's an add-on unit ($375, it ain't cheap) to add XLR and all kind of other audio gizmos to the Canon 5D. I wouldn't be surprised if we see DSLRs with built-in XLR in a year or two.
A public service announcement for all citizens of the US of A: stop mutilating your children's cocks.
Seriously, what is the matter with you nutjobs? The idea that circumcision promotes cock health is long since disproven. Put the knife down. Step away from the cock. Thank you.
Sheesh. We "nutjobs" would take you guys a lot more seriously if you stopped calling this practice "mutilation" or "child abuse." It's long-ingrained in many cultures that love and dote on children.
I'm circumcised and enjoy sex a lot. Maybe I'd enjoy it "more" without it, but I don't really care.
Circumcision may have only slight health benefits for men in the Western world today, but it also offers only very slight risks as well. Lots of us do it for religious or cultural reasons, and to my knowledge there's no greater incidence of sexual dysfunction or other problems like that in societies where that behavior is prevalent.
Meta-whoosh (-;
I'm gonna pat myself on the back and conclude that I do a sublime, pitch-perfect impression of a semi-coherent, semi-informed Windoze fanboy.