Well, if you leave off the base62 encode option, you get a file that's "prepped" for better gzipping. But of course that doesn't require an eval, which was the point of this whole thread, so you're right about that.
I've also noticed, though, that IE will barf on long Javascript files, so doing the base62 compression on the Javascript even with gzip is a workaround for that.
There are certainly legitimate uses of eval, and legitimate reasons to "obfuscate". Like to compress the script that you send to each & every client. The savings in bandwidth for you (and for them, especially if they're on dialup) can add up. For example: http://www.javascriptcompressor.com
But the malicious mirror also has a steady stream of data coming in, which includes IP addresses of people running vulnerable services, and which services those are. Before the patch is finished installing, the user is rooted.
It sounds like Debian users are still okay, since there are no official mirrors for security.debian.org. Sometimes this causes problems; I remember it being unreachable back when X was one enormous package and there was a big bugfix. But it helps for situations like these.
We're not talking about recording from input; we're talking about making a copy of the output as it goes to the speakers. I don't think there's any D to A involved in recording this way, although you do lose a generation, and of course if the source was compressed you're in extra trouble.
A separate drive (or array of drives) is still a much better backup than a RAID. It guards against filesystem corruption as well as accidental deletes.
Really all RAID buys you is more uptime. You must still do backups. There are plenty of cases where uptime is necessary, and RAID is great, don't get me wrong.
Doubly ironic that the article you point to makes the exact same mistake that it warns against: it uses a seemingly random string instead of example.com. Great story, though.
Ever tried to edit an ODF on a Xfce4 system with 100mb free?
I didn't think so.
Shut up, idiot.
You've made my point.
Suppose I saved a file in Office 2007's format. To read it, I need Office 2007, and a machine capable of running that exact piece of software, on the exact hardware architecture of the original. Such software may be bloated and not run on my machine (or, more likely, run poorly in emulation).
However, if I have the specification for the document, other software that suits me better can be written, with 100% file compatibility.
I'm not talking about software, I'm talking about encoding my content in somebody else's format. Anybody's allowed to make whatever software they like to handle it in whatever way, and charge whatever amount, as long as the output is something I have the option of manipulating myself.
Here's your food and shelter analogy: if I'm eating a Wendy's hamburger when I write a book, my readers are not required to be eating a Wendy's hamburger when they read it. Similarly, if I'm writing in an apartment managed by XYZ company, reader's don't require a license from XYZ company.
So if users actually _use_ it, why put the blame on Adobe?
Perhaps the fundamentalist notion that _everything_ must be free (as in speech) is just too extreme for, hmmmm, real people?
Here's an idea! Let's just assume that it'll always be zero-cost. Let's further assume that it'll always be available on any platform that anyone might like, rather than pushing people towards platforms that the vendor likes.
Now that that's out of the way, I can feel confident putting my content into this format, knowing that I, the content creator, <sarcasm>am in control</sarcasm>.
Who really owns something that you make in Flash? Just as when you write a document in Word, when you compose in a proprietary format, you hand the keys over to the vendor. You, and anybody who wants to view or edit what you've created, have to go through the One Software Company. And that's permanent; whatever DRM or platform decisions the company makes in the future will bind you as well.
Please keep mentioning this. Jury nullification needs to be brought up as often as possible until it becomes common knowledge that the jury judges the law as well as the facts.
What's different this time may be that nobody else has anything better. Last time, AMD64 was the easier solution, and it clobbered Itanium. Can AMD (or anybody) simply choose to keep making single cores faster, or is multi-core the way CPUs really must go from here?
Until it changes without notice to read "we'll do whatever we want" and they still have all your data you gave them under the previous policy.
So even a great policy doesn't really mean jack, if you don't trust the people and the company. And not just now, you have to trust everybody who might ever have access to that data in the future!
Spammers require a number of resources, all of them finite:
Compute time (whether they "own" it or not, it's still a limited resource)
Programming time to write their bot (somebody has to write and maintain these things)
Nobody's claiming that greylisting and holding connections open will reduce spam to zero. But what if greylisting makes it twice as hard to write and maintain a spambot? Wouldn't that reduce spam?
What if every server that detected spam held the connection open for a couple of minutes? Wouldn't that reduce the amount of spam a compromised machine could send by, say, 10x?
And if the bot sends a reset instead of a quit, or otherwise does something wrong with SMTP, we've just made them identify themselves as a spammer. Drop that message like a hot potato.
That may be a difference. I have quite a small installation, and none of my users are interested in (or capable of) procmail stuff. Although I think exim (which is what I'm using, btw, and do endorse) may have a way to interact with procmail before accepting or rejecting a message. Not sure about that.
Slashdot Mirror
Yes, and also to shrink variable names, arguments, etc. See Javascript compression guru Dean Edwards's take on the subject.
Well, if you leave off the base62 encode option, you get a file that's "prepped" for better gzipping. But of course that doesn't require an eval, which was the point of this whole thread, so you're right about that.
I've also noticed, though, that IE will barf on long Javascript files, so doing the base62 compression on the Javascript even with gzip is a workaround for that.
There are certainly legitimate uses of eval, and legitimate reasons to "obfuscate". Like to compress the script that you send to each & every client. The savings in bandwidth for you (and for them, especially if they're on dialup) can add up. For example: http://www.javascriptcompressor.com
Chaff is the husk around a grass seed. Wheat is what's separated from chaff, not weed. The chaff is the bad part.
Next you'll be saying they should have their own schools!
Without https you are still vulnerable to packet sniffing, dns poisioning and man in the middle attacks.
True, but at least those are much more difficult than just getting on the mirror list.
But the malicious mirror also has a steady stream of data coming in, which includes IP addresses of people running vulnerable services, and which services those are. Before the patch is finished installing, the user is rooted.
It sounds like Debian users are still okay, since there are no official mirrors for security.debian.org. Sometimes this causes problems; I remember it being unreachable back when X was one enormous package and there was a big bugfix. But it helps for situations like these.
(n/t)
We're not talking about recording from input; we're talking about making a copy of the output as it goes to the speakers. I don't think there's any D to A involved in recording this way, although you do lose a generation, and of course if the source was compressed you're in extra trouble.
A separate drive (or array of drives) is still a much better backup than a RAID. It guards against filesystem corruption as well as accidental deletes.
Really all RAID buys you is more uptime. You must still do backups. There are plenty of cases where uptime is necessary, and RAID is great, don't get me wrong.
for instance, if the person who wrote this slashdot story had used "example.com" for his domain, what would you suggest he use for his friends domain?
example.net
Doubly ironic that the article you point to makes the exact same mistake that it warns against: it uses a seemingly random string instead of example.com. Great story, though.
Ever tried to edit an ODF on a Xfce4 system with 100mb free?
I didn't think so.
Shut up, idiot.
You've made my point.
Suppose I saved a file in Office 2007's format. To read it, I need Office 2007, and a machine capable of running that exact piece of software, on the exact hardware architecture of the original. Such software may be bloated and not run on my machine (or, more likely, run poorly in emulation).
However, if I have the specification for the document, other software that suits me better can be written, with 100% file compatibility.
I have to point out that Microsoft has already tried many of these tactics to take over the Web entirely, and got frighteningly close.
I'm not talking about software, I'm talking about encoding my content in somebody else's format. Anybody's allowed to make whatever software they like to handle it in whatever way, and charge whatever amount, as long as the output is something I have the option of manipulating myself.
Here's your food and shelter analogy: if I'm eating a Wendy's hamburger when I write a book, my readers are not required to be eating a Wendy's hamburger when they read it. Similarly, if I'm writing in an apartment managed by XYZ company, reader's don't require a license from XYZ company.
Truly, you have a dizzying intellect.
So if users actually _use_ it, why put the blame on Adobe?
Perhaps the fundamentalist notion that _everything_ must be free (as in speech) is just too extreme for, hmmmm, real people?
Here's an idea! Let's just assume that it'll always be zero-cost. Let's further assume that it'll always be available on any platform that anyone might like, rather than pushing people towards platforms that the vendor likes.
Now that that's out of the way, I can feel confident putting my content into this format, knowing that I, the content creator, <sarcasm>am in control</sarcasm>.
Who really owns something that you make in Flash? Just as when you write a document in Word, when you compose in a proprietary format, you hand the keys over to the vendor. You, and anybody who wants to view or edit what you've created, have to go through the One Software Company. And that's permanent; whatever DRM or platform decisions the company makes in the future will bind you as well.
Please keep mentioning this. Jury nullification needs to be brought up as often as possible until it becomes common knowledge that the jury judges the law as well as the facts.
What's different this time may be that nobody else has anything better. Last time, AMD64 was the easier solution, and it clobbered Itanium. Can AMD (or anybody) simply choose to keep making single cores faster, or is multi-core the way CPUs really must go from here?
Until it changes without notice to read "we'll do whatever we want" and they still have all your data you gave them under the previous policy.
So even a great policy doesn't really mean jack, if you don't trust the people and the company. And not just now, you have to trust everybody who might ever have access to that data in the future!
Spammers require a number of resources, all of them finite:
Nobody's claiming that greylisting and holding connections open will reduce spam to zero. But what if greylisting makes it twice as hard to write and maintain a spambot? Wouldn't that reduce spam?
What if every server that detected spam held the connection open for a couple of minutes? Wouldn't that reduce the amount of spam a compromised machine could send by, say, 10x?
And if the bot sends a reset instead of a quit, or otherwise does something wrong with SMTP, we've just made them identify themselves as a spammer. Drop that message like a hot potato.
When Web sites had "best viewed with IE4" banners, and screw anybody who had a Non-Approved (tm) browsing apparatus! That's what the Web is all about!
That may be a difference. I have quite a small installation, and none of my users are interested in (or capable of) procmail stuff. Although I think exim (which is what I'm using, btw, and do endorse) may have a way to interact with procmail before accepting or rejecting a message. Not sure about that.