While commenters here will be quick to point out that the font doesn't actually provide protection, you have to realize that there are people who will actually perceive the font as offering protection. Setting the record straight is just as important as recognizing the artistic message behind the act. We can appreciate the intent and the result, but we should also not delude ourselves that it has purpose beyond simply conveying an artistic message.
What's interesting is that this actually enriches the post-modern interpretation of the artwork, rather than detracting from it. Not only does the work demonstrate the superficial rejection of the all-seeing police state, but to those who understand and appreciate the technical aspects of the digitization of data, it also demonstrates deeper opposing meanings that are equally valid:
that despite the effort of the common man, it is practically impossible to hide from the panopticon;
that the commercialization and publication of a "standard" way to avoid breaches of privacy (i.e. a monoculture of privacy applications, like how so many people turn to 1Password) inevitably lead to breaches of privacy due to the shared central point of weakness; and
that, ultimately, the assumption of and reliance on a shallow culture of privacy ("oh, just use PGP and you're safe!") is insufficient.
I neglected the bit which admitted that EAC is closed-source, but did want to emphasize that cdparanoia is just about as good as EAC... as long as your goal is simply determining if you have a bad rip. What you can't do is rely on cdparanoia to properly correct your data. I've encountered at least one disc which was deterministically "mis-corrected" on one of my drives but ripped without any errors (corrected or otherwise) on the other. But I know for a fact that of the 288 CDs in my collection that I believe to have been ripped accurately so far, I have yet to come across a CD which cdparanoia claimed ripped completely cleanly (i.e. with not even a single "corrected" error) which failed to match AccurateRip hashes generated by the same disc on a Windows machine.
Even ignoring the occasional "your CD matches no known pressing" hits I get with AccurateRip, I've come across only two discs which ripped cleanly and failed to match any known hash stored in AccurateRip, but even in those cases, the same "non-matching" hashes were generated on Windows with a completely different CD drive. The discs in question only had one and two hashes stored in the AccurateRip database, raising the more probable possibility that the hashes in the AccurateRip database were wrong rather than my rips.
Which is Windows-only and makes use of cdparanoia. If you want an open-source solution on Windows, it's an option I suppose, but the OP noted that he was using Linux to do his ripping. In that case, CDex isn't any better than using cdparanoia straight-out.
I noted that morituri supported AccurateRip when I was doing some research on whether it would be possible to implement AccurateRip in rubyripper, and, when I found the licensing issue, I concluded that you might not have noticed it, as it's rather subtle (my apologies in not bringing it up to you directly before now). In short, it's basically the same issue that resulted in VLC being removed from Apple's App Store
The basis for my interpretation was the fact that the AccurateRip database is, according to their website, "free for non-commercial usage, [while] commercial usage is restricted to prior agreement". This imposes an "additional restriction" under the terms of section 7 of GPLv3. As such, any end-user is permitted to "remove that term" (i.e. the restriction on commercial usage) from their license of your GPL program and thus make commercial use of morituri. But as this violates the terms of agreement to use the AccurateRip database, it becomes effectively impossible to meet both the requirements of both the GPL and the AccurateRip license (since you don't have the right to add the commercial restriction to the GPL for your end-users, per section 10 of GPLv3 (section 6 of GPLv2)). As such, you are not legally permitted to distribute any object or source code licensed under the GPL that also makes use of the AccurateRip database.
Now of course as the author of morituri, you could relicense your code under an alternative license that was compatible with AccurateRip's commercial-use restrictions such as the BSD or MIT licenses (caveat: any contributors would also have to relicense their code under said license), but you could not use (or for that matter modify) the GPL to do so.
I suppose I should add (with respect to your FSF-based definition of free software) that icedax in cdrkit (GPLv2) would probably suffice as well as cdda2wav in cdrtools (CDDL) for the purpose of warming up the drive, seeing as the former is forked from an earlier, GPL'd, codebase of the latter. The -Z flag of cdparanoia may also suffice to do warmup if you want to avoid the cdrkit vs. cdrtools issue altogether, but I haven't tested it to be sure.
Also, please don't rely on cdparanoia to correctly handle AccurateRip sample offsets equal to or greater than 512 samples in either direction (due to how it handles sample offsets). Rubyripper (or at least the version on the master branch) handles this correctly by correcting the sector offset for sample offsets greater than or equal to 512 samples. (If you have an offset of +667, for example, adjusting for this requires that you actually add one sector to the start and ending offsets of the track (i.e. you'll need to use sector-based ripping rather than track-based ripping), and then assume an offset of +667 % 512 = +155 samples). cdparanoia also can't read into the lead-out of a CD even if the drive ostensibly supports it, so you'll have to manually add some empty samples to the end of your file if you have a positive offset.
1. The problem with EAC is that it's not open-source, and while it'll run on Linux with Wine, it requires you to use a GUI, which may not be an option on headless boxes. I won't deny that cdparanoia isn't as good as XLD, EAC, or dBPoweramp, but for a Linux box, it's still about as good as you can get, and although it doesn't support C2, cdparanoia III 10.2 does finally do well with most disc caches today. I mentioned in another reply here that I've used cdparanoia pretty reliably, although there are still issues (you need to keep a close eye on the quality gauge, as its repair mechanisms can actually deterministically mess up a CD rip!) But with a high-quality CD drive (Like the Plextors you mention) that gives low error rates by default and some double-checking of cdparanoia errors (i.e. assume that if cdparanoia reports that a track has errors that it didn't correct them), cdparanoia will work about as well as any other option. Yeah, you can't recover from errors as well as EAC or dBPoweramp can, but if you've got a pretty clean CD collection, you won't be too bad off. Combine cdparanoia with some of the command-line AccurateRip tools out there (as you mention), and you can probably be pretty sure your rips are good.
2. The only downside with AccurateRip is that it's not actually compatible with the GPL (use of the database imposes additional restrictions that aren't GPL compatible). The CUETools Database is GPL compatible (and even can repair some errors using some parity data!), but as of right now, no command-line tools play with it on Linux, and it's probably always going to be a little worse than AccurateRip due to fewer tools supporting it. I've been meaning to add support to rubyripper, but I haven't gotten around to it yet.
3. The Plextor PX-716UF is the external USB version of the 716SA, and may be better suited to setups where you absolutely don't want an IDE bus in your machine.
I've done a lot of work on streamlining my own ripping process (I've got well over 900 CDs to be ripped and tagged) and in the process, I got involved in helping out with developing rubyripper, a wrapper for cdparanoia. In the process, I've learned a lot about doing accurate rips and figuring out the various intricacies of the CD format. One of the things I observed was the relatively slow speed of ripping on my LG Blu-ray drive: it behaved exactly like you described: It would take 15 minutes to rip something (effectively ripping at 2x, 4x at BEST).
Now these drives do have something called "RipLock" to limit the ripping speed of DVDs and Blu-Rays, but this feature ostensibly doesn't affect CD ripping. What I eventually learned, however, is that the LG/Hitachi (HL-ST-DT) drives which make up the majority of DVD drives out on the market today actually do not have a firmware which plays well with the way that cdparanoia does its ripping and error checking. It turns out that HL-ST-DT drives actually read at a slower speed until they have read enough sequential sectors (about 30 seconds of audio), at which point they will actually speed up to full speed and stay at that speed.
Thus, my solution to the slow-ripping problem was to actually use cdda2wav in non-paranoia mode (so as to read sequential sectors) to read the first 30 seconds of the CD audio so as to warm up the drive speed. Once this is done, I can then run cdparanoia as before, and actually can rip at a reasonable rate.
Of course this isn't to say that the HL-ST-DT drives are very good. They've got a pretty big sample offset (+667) and actually have a pretty bad successful rip rate (closer to 90% instead of 97 or 98%). The best investment I've made so far is to buy a Plextor PX-716UF, which I use to rerip CDs that don't rip right on the HL-ST-DT drive. By doing this, I've probably managed to eliminate 4 out of every 5 "bad" rips; the only remaining "bad" rips are from obviously physically damaged discs (cracks, pitting, etc.), which I consider a pretty good hit rate. Of course the only downside of these drives is that they don't play well with the DVD-side of dual-discs.
Yep, you heard me right: old Plextor drives STILL can't be beat in rip quality with practically any drive out today. (But make sure you get an old one, not one of the newer ones that's just a rebranded Hitachi that claims to be a Plextor. Basically, any Plextor with a rip offset of +30 is good, but you might also want to refer to the Plextors on this list)
That's pretty much my interpretation of the issue. I've never seen anything that said that the Commission could be ordered around by the Parliament, and since the Commission is the only EU governing body with legislative initiative, all they have to do is keep proposing the ratification of ACTA until the Parliament caves. And even then, the individual member states could ratify ACTA without the EU doing so anyway...
Having been a student at BOTH in the past couple of years, I safely say that they now no longer seem to explicitly use SSN as student ID. Which isn't to say that they don't hold it in storage in some Bursars/Registrars Office database, but both now appear to use proprietary 9 digit numbers instead of SSNs for most purposes.
It's a heck of a lot easier to shout non-unique names to identify someone though in most situations... I mean, I'm pretty sure no one wants to have to yell at their kid "76995cdc-9825-4b13-b66a-a60b26b6cc41! Stop drawing on the wall!"
The problem with typography on the Internet is the desire of font creators to limit distribution of their work (as the font files themselves are copyrighted in the US, and the font designs elsewhere). Thus, DRM is most likely inevitable in some form or other. This is why PDF obeys the 'no-embedding' bit in TTF, and has the option (if not the requirement) to embed only parts of fonts.
But why stick with a proprietary format? I always wondered what the problem would be with establishing some sort of private/public key signature/encryption method of DRM.
In this way, one would use a signature on the font to ensure that the font can only be used on one domain/rooted-URL and to also 'affix' some sort of source on the file (so that taking the raw font-file won't work elsewhere, and if the decrypted data is redistributed, the source domain/site is plainly visible) and would, furthermore, only be able to be decrypted with a one-time key unique to the session (transferred with SSL?). The end user is ALWAYS going to be able to theoretically pull out the decrypted TTF or rewrite the 'tag' on the decrypted TTF marking its original source, but you're never going to get around that problem in open-source implementations, as black boxes aren't going to be kosher either. At the very least though, you could build on the idea to make it difficult enough for others to crack without trying, and prosecute with the DMCA when they do...
I don't agree with this in the long term, but it's a better solution than a proprietary black box, and is perhaps a reasonable compromise for open-source implementation as well as meeting the rather restrictive demands of the font foundries...
Interestingly, jslint doesn't complain about the above code (if you assume that doSomething was already written and defined as a global function and that we're running in a browser such that document is already defined as a global variable.)
Yeah, building multiple functions is a bit wasteful. I suppose you could get by by attaching new properties to the elements and having the function attached to onclick reference the objects by using the event's target/srcElement property to get back to the custom variable.
That's one of the either really good or really bad things about JavaScript: there's a heck of a lot of vastly different things you can do to get the same effect.
Yeah, but can JavaScript really be sure that elements wasn't altered by the contents of the loop? Granted, that's a theoretical mistake on my part to not store it in a variable for that case, but in practice, I'm relatively sure it doesn't matter (seeing as we can PROVE that there is no change in the number of items in the array, assuming, of course, that setting onclick does exactly what we expect it to... But now we're getting into pedantic reasoning for sample code that doesn't even do anything!)
That being said, I'm not entirely sure where the cost of calling elements.length comes in, unless no JavaScript engines actually keep length as a property on the array object, instead preferring to count the elements every time (or if accessing a property of an object is significantly more expensive than accessing a variable).
I mean, come on, we're talking about a simple instance variable that just needs updating on a push or a pop...
All Prototype's bind does is hide the fact that it's creating and calling a generator function anyway... It still fundamentally has to wrap the function in a closure-generating function because JavaScript doesn't have block scoping.
By the way, if you like level 2 events, I hope you don't have any clients using IE!
To be clear, parent is comparing lexical to dynamic scope.
The above silly example, is an example of not taking advantage of block structure.
If you write everything as if it were a C program, yeah, lexical scope can be weird.
My apologies. I suppose I'm confusing my closures with scoping, but the way closures are done in Javascript belies the fact that it doesn't have single-assign variables.
I must admit that JavaScript's method of scoping isn't the best (mostly because it has variables that can be reassigned, and scoping binds to the variables, not the values) but I can say that scoping is a time-saver if you do it right and (for example) have a bunch of anchors that all need slightly different arguments in their onclick event handlers.
I've more than once used something like:
function onclickGenerator(i) { return function() { doSomething(i); }; }
var elements = document.getElementsByTagName('a'); for (var i = 0; i < elements.length; i++) { elements[i].onclick = onclickGenerator(i); }
It would be nice if it treated scope by binding values, not variables though... (If you tried doing the above by replacing onclickGenerator(i) with function() { doSomething(i); }, every element would end up calling doSomething(elements.length);, instead of doSomething(value_of_i_at_onclick_set_time);
Owner of www.example.com: "Uh, yeah, I want to see the child porn blacklist. I think you might have blocked my site by mistake."
ISP: "Hey! This guy is trying to view the child porn blacklist!"
Police: "Oh hey, website owner. We're arresting you under suspicion of possessing child pornography."
Owner of www.example.com: "Wait, what?"
Police: "You asked for the list of sites, and on top of that, you tried to visit www.example.com, which was on the list. Clearly you wanted to see child porn."
The problem is our constitution, which requires a "majority" of electoral votes to become president rather than simply the greatest number... it locks us into a two party system. You won't get choice in the economy if you don't get choice in the government which presides over it.
It's not the electoral system. Only one person can hold the singular political office that is the Presidency. If you're complaining about the two-party system, look at the first-past-the-post system we use to elect people to office. Proportional Representation systems would fix this in the legislatures, and instant-runoff voting can somewhat ameliorate the issues in the cases where we still can only elect one person (e.g. the Presidency)
The real problem with this concept, however, is threefold:
1. The politicians will never allow something that weakens their power to get reelected (and thus, anything that weakens the two-party system. This is why it's so hard for third-parties to even get on the ballot, and why many states still have closed primaries, despite the benefits to the public to allow open ones)
2. The public has an investment in having a representative they can point to and say 'that's my representative' and when, in trouble, can ask for help getting through government issues, etc.
3. Groups that are already represented by a minority (e.g. small states like Wyoming and Rhode Island in the House) will be completely ignored because their several hundred thousand votes are now positioned relative to the 'nation' and hence, irrelevant compared to the millions of voters in New York and California. This same argument is also used to defend the Electoral College, because otherwise, small states would be irrelevant for candidates to pander to or listen to.
That this likely means the exact opposite. Elliptic Curve Cryptography is relatively difficult to crack (not unlike RSA). More to the point, it's also not liable to factorization attacks like RSA is. Furthermore, the best crack of elliptic curve technology is of a 109-bit key, and still took 3,600 or 15,000 computer-years (whether it's a binary or prime field case, respectively).
Nintendo's not stupid. They've used RSA encryption to keep the average hacker out of DS-wireless homebrew, and this is most likely a mandated response to the Splinter Cell hack that allowed soft modding on the Xbox. It won't stop hacking through security holes in the internet protocols (a-la PSO+BBA), but they're certainly making efforts to prevent corrupted data from opening up softmod paths.
HTML5 is being developed hand-in-hand with XHTML5, which is merely the XML serialization of HTML5. Don't worry. You don't have to give up <br/> if you don't want to.
That being said, I do believe that CSS still has fundamental problems that not even CSS3 seems to be solving, such as taking into consideration the growing use of HTML as an application framework rather than a document framework. The most notable issue of this would be the inability to center an object vertically in a viewport without Javascript to determine its size, which is a klutzy hack at best. The float: and clear: primitives, as you mention, are also comparatively weak (since you can't just float an element, have text flow around it, AND position it vertically), though CSS3 is introducing a Multi-column layout module. There are other issues too, but I can't pull them off the top of my head at this time.
Slashdot Mirror
While commenters here will be quick to point out that the font doesn't actually provide protection, you have to realize that there are people who will actually perceive the font as offering protection. Setting the record straight is just as important as recognizing the artistic message behind the act. We can appreciate the intent and the result, but we should also not delude ourselves that it has purpose beyond simply conveying an artistic message.
What's interesting is that this actually enriches the post-modern interpretation of the artwork, rather than detracting from it. Not only does the work demonstrate the superficial rejection of the all-seeing police state, but to those who understand and appreciate the technical aspects of the digitization of data, it also demonstrates deeper opposing meanings that are equally valid:
Opera has said that they will also be moving to Blink as they transition away from the Presto engine.
If samzenpus doesn't know, Soulskill might. I heard he even has a hypothesis as to what happened then!
http://science.slashdot.org/story/12/06/28/1356230/has-a-biochem-undergrad-solved-a-cosmic-radiation-mystery
I neglected the bit which admitted that EAC is closed-source, but did want to emphasize that cdparanoia is just about as good as EAC... as long as your goal is simply determining if you have a bad rip. What you can't do is rely on cdparanoia to properly correct your data. I've encountered at least one disc which was deterministically "mis-corrected" on one of my drives but ripped without any errors (corrected or otherwise) on the other. But I know for a fact that of the 288 CDs in my collection that I believe to have been ripped accurately so far, I have yet to come across a CD which cdparanoia claimed ripped completely cleanly (i.e. with not even a single "corrected" error) which failed to match AccurateRip hashes generated by the same disc on a Windows machine.
Even ignoring the occasional "your CD matches no known pressing" hits I get with AccurateRip, I've come across only two discs which ripped cleanly and failed to match any known hash stored in AccurateRip, but even in those cases, the same "non-matching" hashes were generated on Windows with a completely different CD drive. The discs in question only had one and two hashes stored in the AccurateRip database, raising the more probable possibility that the hashes in the AccurateRip database were wrong rather than my rips.
Which is Windows-only and makes use of cdparanoia. If you want an open-source solution on Windows, it's an option I suppose, but the OP noted that he was using Linux to do his ripping. In that case, CDex isn't any better than using cdparanoia straight-out.
I noted that morituri supported AccurateRip when I was doing some research on whether it would be possible to implement AccurateRip in rubyripper, and, when I found the licensing issue, I concluded that you might not have noticed it, as it's rather subtle (my apologies in not bringing it up to you directly before now). In short, it's basically the same issue that resulted in VLC being removed from Apple's App Store
The basis for my interpretation was the fact that the AccurateRip database is, according to their website, "free for non-commercial usage, [while] commercial usage is restricted to prior agreement". This imposes an "additional restriction" under the terms of section 7 of GPLv3. As such, any end-user is permitted to "remove that term" (i.e. the restriction on commercial usage) from their license of your GPL program and thus make commercial use of morituri. But as this violates the terms of agreement to use the AccurateRip database, it becomes effectively impossible to meet both the requirements of both the GPL and the AccurateRip license (since you don't have the right to add the commercial restriction to the GPL for your end-users, per section 10 of GPLv3 (section 6 of GPLv2)). As such, you are not legally permitted to distribute any object or source code licensed under the GPL that also makes use of the AccurateRip database.
Now of course as the author of morituri, you could relicense your code under an alternative license that was compatible with AccurateRip's commercial-use restrictions such as the BSD or MIT licenses (caveat: any contributors would also have to relicense their code under said license), but you could not use (or for that matter modify) the GPL to do so.
I suppose I should add (with respect to your FSF-based definition of free software) that icedax in cdrkit (GPLv2) would probably suffice as well as cdda2wav in cdrtools (CDDL) for the purpose of warming up the drive, seeing as the former is forked from an earlier, GPL'd, codebase of the latter. The -Z flag of cdparanoia may also suffice to do warmup if you want to avoid the cdrkit vs. cdrtools issue altogether, but I haven't tested it to be sure.
Also, please don't rely on cdparanoia to correctly handle AccurateRip sample offsets equal to or greater than 512 samples in either direction (due to how it handles sample offsets). Rubyripper (or at least the version on the master branch) handles this correctly by correcting the sector offset for sample offsets greater than or equal to 512 samples. (If you have an offset of +667, for example, adjusting for this requires that you actually add one sector to the start and ending offsets of the track (i.e. you'll need to use sector-based ripping rather than track-based ripping), and then assume an offset of +667 % 512 = +155 samples). cdparanoia also can't read into the lead-out of a CD even if the drive ostensibly supports it, so you'll have to manually add some empty samples to the end of your file if you have a positive offset.
1. The problem with EAC is that it's not open-source, and while it'll run on Linux with Wine, it requires you to use a GUI, which may not be an option on headless boxes. I won't deny that cdparanoia isn't as good as XLD, EAC, or dBPoweramp, but for a Linux box, it's still about as good as you can get, and although it doesn't support C2, cdparanoia III 10.2 does finally do well with most disc caches today. I mentioned in another reply here that I've used cdparanoia pretty reliably, although there are still issues (you need to keep a close eye on the quality gauge, as its repair mechanisms can actually deterministically mess up a CD rip!) But with a high-quality CD drive (Like the Plextors you mention) that gives low error rates by default and some double-checking of cdparanoia errors (i.e. assume that if cdparanoia reports that a track has errors that it didn't correct them), cdparanoia will work about as well as any other option. Yeah, you can't recover from errors as well as EAC or dBPoweramp can, but if you've got a pretty clean CD collection, you won't be too bad off. Combine cdparanoia with some of the command-line AccurateRip tools out there (as you mention), and you can probably be pretty sure your rips are good.
2. The only downside with AccurateRip is that it's not actually compatible with the GPL (use of the database imposes additional restrictions that aren't GPL compatible). The CUETools Database is GPL compatible (and even can repair some errors using some parity data!), but as of right now, no command-line tools play with it on Linux, and it's probably always going to be a little worse than AccurateRip due to fewer tools supporting it. I've been meaning to add support to rubyripper, but I haven't gotten around to it yet.
3. The Plextor PX-716UF is the external USB version of the 716SA, and may be better suited to setups where you absolutely don't want an IDE bus in your machine.
I've done a lot of work on streamlining my own ripping process (I've got well over 900 CDs to be ripped and tagged) and in the process, I got involved in helping out with developing rubyripper, a wrapper for cdparanoia. In the process, I've learned a lot about doing accurate rips and figuring out the various intricacies of the CD format. One of the things I observed was the relatively slow speed of ripping on my LG Blu-ray drive: it behaved exactly like you described: It would take 15 minutes to rip something (effectively ripping at 2x, 4x at BEST).
Now these drives do have something called "RipLock" to limit the ripping speed of DVDs and Blu-Rays, but this feature ostensibly doesn't affect CD ripping. What I eventually learned, however, is that the LG/Hitachi (HL-ST-DT) drives which make up the majority of DVD drives out on the market today actually do not have a firmware which plays well with the way that cdparanoia does its ripping and error checking. It turns out that HL-ST-DT drives actually read at a slower speed until they have read enough sequential sectors (about 30 seconds of audio), at which point they will actually speed up to full speed and stay at that speed.
Thus, my solution to the slow-ripping problem was to actually use cdda2wav in non-paranoia mode (so as to read sequential sectors) to read the first 30 seconds of the CD audio so as to warm up the drive speed. Once this is done, I can then run cdparanoia as before, and actually can rip at a reasonable rate.
Of course this isn't to say that the HL-ST-DT drives are very good. They've got a pretty big sample offset (+667) and actually have a pretty bad successful rip rate (closer to 90% instead of 97 or 98%). The best investment I've made so far is to buy a Plextor PX-716UF, which I use to rerip CDs that don't rip right on the HL-ST-DT drive. By doing this, I've probably managed to eliminate 4 out of every 5 "bad" rips; the only remaining "bad" rips are from obviously physically damaged discs (cracks, pitting, etc.), which I consider a pretty good hit rate. Of course the only downside of these drives is that they don't play well with the DVD-side of dual-discs.
Yep, you heard me right: old Plextor drives STILL can't be beat in rip quality with practically any drive out today. (But make sure you get an old one, not one of the newer ones that's just a rebranded Hitachi that claims to be a Plextor. Basically, any Plextor with a rip offset of +30 is good, but you might also want to refer to the Plextors on this list)
That's pretty much my interpretation of the issue. I've never seen anything that said that the Commission could be ordered around by the Parliament, and since the Commission is the only EU governing body with legislative initiative, all they have to do is keep proposing the ratification of ACTA until the Parliament caves. And even then, the individual member states could ratify ACTA without the EU doing so anyway...
Having been a student at BOTH in the past couple of years, I safely say that they now no longer seem to explicitly use SSN as student ID. Which isn't to say that they don't hold it in storage in some Bursars/Registrars Office database, but both now appear to use proprietary 9 digit numbers instead of SSNs for most purposes.
That's nothing new with Verizon. Heck, they've been crippling Bluetooth for ages.
It's a heck of a lot easier to shout non-unique names to identify someone though in most situations... I mean, I'm pretty sure no one wants to have to yell at their kid "76995cdc-9825-4b13-b66a-a60b26b6cc41! Stop drawing on the wall!"
The problem with typography on the Internet is the desire of font creators to limit distribution of their work (as the font files themselves are copyrighted in the US, and the font designs elsewhere). Thus, DRM is most likely inevitable in some form or other. This is why PDF obeys the 'no-embedding' bit in TTF, and has the option (if not the requirement) to embed only parts of fonts.
But why stick with a proprietary format? I always wondered what the problem would be with establishing some sort of private/public key signature/encryption method of DRM.
In this way, one would use a signature on the font to ensure that the font can only be used on one domain/rooted-URL and to also 'affix' some sort of source on the file (so that taking the raw font-file won't work elsewhere, and if the decrypted data is redistributed, the source domain/site is plainly visible) and would, furthermore, only be able to be decrypted with a one-time key unique to the session (transferred with SSL?). The end user is ALWAYS going to be able to theoretically pull out the decrypted TTF or rewrite the 'tag' on the decrypted TTF marking its original source, but you're never going to get around that problem in open-source implementations, as black boxes aren't going to be kosher either. At the very least though, you could build on the idea to make it difficult enough for others to crack without trying, and prosecute with the DMCA when they do...
I don't agree with this in the long term, but it's a better solution than a proprietary black box, and is perhaps a reasonable compromise for open-source implementation as well as meeting the rather restrictive demands of the font foundries...
Interestingly, jslint doesn't complain about the above code (if you assume that doSomething was already written and defined as a global function and that we're running in a browser such that document is already defined as a global variable.)
Yeah, building multiple functions is a bit wasteful. I suppose you could get by by attaching new properties to the elements and having the function attached to onclick reference the objects by using the event's target/srcElement property to get back to the custom variable.
That's one of the either really good or really bad things about JavaScript: there's a heck of a lot of vastly different things you can do to get the same effect.
Yeah, but can JavaScript really be sure that elements wasn't altered by the contents of the loop? Granted, that's a theoretical mistake on my part to not store it in a variable for that case, but in practice, I'm relatively sure it doesn't matter (seeing as we can PROVE that there is no change in the number of items in the array, assuming, of course, that setting onclick does exactly what we expect it to... But now we're getting into pedantic reasoning for sample code that doesn't even do anything!)
That being said, I'm not entirely sure where the cost of calling elements.length comes in, unless no JavaScript engines actually keep length as a property on the array object, instead preferring to count the elements every time (or if accessing a property of an object is significantly more expensive than accessing a variable).
I mean, come on, we're talking about a simple instance variable that just needs updating on a push or a pop...
That'd be bassackwards wouldn't it? Now you've put the assignment back in the looping part, which is what we're trying to avoid.
All Prototype's bind does is hide the fact that it's creating and calling a generator function anyway... It still fundamentally has to wrap the function in a closure-generating function because JavaScript doesn't have block scoping.
By the way, if you like level 2 events, I hope you don't have any clients using IE!
To be clear, parent is comparing lexical to dynamic scope.
The above silly example, is an example of not taking advantage of block structure.
If you write everything as if it were a C program, yeah, lexical scope can be weird.
My apologies. I suppose I'm confusing my closures with scoping, but the way closures are done in Javascript belies the fact that it doesn't have single-assign variables.
I must admit that JavaScript's method of scoping isn't the best (mostly because it has variables that can be reassigned, and scoping binds to the variables, not the values) but I can say that scoping is a time-saver if you do it right and (for example) have a bunch of anchors that all need slightly different arguments in their onclick event handlers.
I've more than once used something like:
It would be nice if it treated scope by binding values, not variables though... (If you tried doing the above by replacing onclickGenerator(i) with function() { doSomething(i); }, every element would end up calling doSomething(elements.length);, instead of doSomething(value_of_i_at_onclick_set_time);
Owner of www.example.com: "Uh, yeah, I want to see the child porn blacklist. I think you might have blocked my site by mistake."
ISP: "Hey! This guy is trying to view the child porn blacklist!"
Police: "Oh hey, website owner. We're arresting you under suspicion of possessing child pornography."
Owner of www.example.com: "Wait, what?"
Police: "You asked for the list of sites, and on top of that, you tried to visit www.example.com, which was on the list. Clearly you wanted to see child porn."
It's not the electoral system. Only one person can hold the singular political office that is the Presidency. If you're complaining about the two-party system, look at the first-past-the-post system we use to elect people to office. Proportional Representation systems would fix this in the legislatures, and instant-runoff voting can somewhat ameliorate the issues in the cases where we still can only elect one person (e.g. the Presidency)
The real problem with this concept, however, is threefold:
1. The politicians will never allow something that weakens their power to get reelected (and thus, anything that weakens the two-party system. This is why it's so hard for third-parties to even get on the ballot, and why many states still have closed primaries, despite the benefits to the public to allow open ones)
2. The public has an investment in having a representative they can point to and say 'that's my representative' and when, in trouble, can ask for help getting through government issues, etc.
3. Groups that are already represented by a minority (e.g. small states like Wyoming and Rhode Island in the House) will be completely ignored because their several hundred thousand votes are now positioned relative to the 'nation' and hence, irrelevant compared to the millions of voters in New York and California. This same argument is also used to defend the Electoral College, because otherwise, small states would be irrelevant for candidates to pander to or listen to.
That this likely means the exact opposite. Elliptic Curve Cryptography is relatively difficult to crack (not unlike RSA). More to the point, it's also not liable to factorization attacks like RSA is. Furthermore, the best crack of elliptic curve technology is of a 109-bit key, and still took 3,600 or 15,000 computer-years (whether it's a binary or prime field case, respectively).
Nintendo's not stupid. They've used RSA encryption to keep the average hacker out of DS-wireless homebrew, and this is most likely a mandated response to the Splinter Cell hack that allowed soft modding on the Xbox. It won't stop hacking through security holes in the internet protocols (a-la PSO+BBA), but they're certainly making efforts to prevent corrupted data from opening up softmod paths.
Now if W3C gets around to implementing the &tex; entity, I think we'll be all set.
HTML5 is being developed hand-in-hand with XHTML5, which is merely the XML serialization of HTML5. Don't worry. You don't have to give up <br /> if you don't want to.
That being said, I do believe that CSS still has fundamental problems that not even CSS3 seems to be solving, such as taking into consideration the growing use of HTML as an application framework rather than a document framework. The most notable issue of this would be the inability to center an object vertically in a viewport without Javascript to determine its size, which is a klutzy hack at best. The float: and clear: primitives, as you mention, are also comparatively weak (since you can't just float an element, have text flow around it, AND position it vertically), though CSS3 is introducing a Multi-column layout module. There are other issues too, but I can't pull them off the top of my head at this time.