Heh. If the switch to the Euro was any indication, then you can expect to have a bunch of forgeries real soon now. Because the notes are so new, they don't even have to be very good forgeries, so colour laser printed ones would probably fool a significant number of people, especially if the feel of the paper is right.
True, mankind has been in space since the 1960's, but the fact remains that just *two* space programs have achieved this to date. Comments like "Hey China, welcome to the 1960's" are akin to saying "Hey Cortez, welcome to the 1490's" upon his return from America.
I personally think this is the best news to happen to space exploration for ages; it might just scare enough people in the US/EU to kick a little more funding towards NASA/ESA.
Targetting lower priority MX's makes a lot of sense from the point of view of a spammer. A huge number of SMEs out there with their own mailserver are using an ISP's servers as their backup(s) and these are probably not going to have as high a level of anti-spam filtering. The additional MX approach sounds like a good backstop though.
I'll have to check my SpamAssassin rule set, but I think a small positive score if a backup MX was used as a relay might be in order. What would be really slick would be to weight the score based on uptime of the primary MX; if the primary was up when the mail hit the secondary then a bigger score should be given. I'm not sure how to implement that though (if it's even possible) because you need to know that the server was up *and* accessible from the Internet.
I'm not sure when the feature was introduced, but later versions of Sendmail allow you to set different timeouts for different message priorities. The necessary settings for your "sendmail.mc" file are:
confTO_QUEUERETURN_NORMAL
confTO_QUEUERETURN_URGENT
confTO_QUEUERETURN_NONURGENT
and the same again with "WARN" in the place of "RETURN". The best thing is, if you set these in a certain way it *really* causes grief for those pricks that like to set the urgent flag on all their emails because they get innundated with warnings. It's like a LART, only without the lawsuit.;)
Because of incremental increases?
on
Why Only Music?
·
· Score: 1
Why only music? Because at the moment that's all that's being widely copied over the Internet. So say we get a "tax" on CD/Rs and DVD/Rs to cover the costs of this as some countries have already done, issues of legitimate use aside. The tax is paid to the music studios for distribution to their clients, for a small administrative fee of course.
In a few years, maybe less, when bandwidth increases the movie studios will be moaning that their copyright is being widely impinged too, and they want a slice of the pie. Obviously there is not enough to cover both, so we have to pay *more* tax to cover the movie studios as well. More money changing hands is also more taxes for governments too, so the corporates and governments go laughing off to the bank while the users are left worse off.
Needless to say, I don't like this concept at all. When the automobile came along, the makers of horse drawn carriages had to either adapt and make coachwork for autos, or died. Here we are, a century or so later and it's the turn of the media industry to be put through the wringer. The choices are the same; adapt or die - the sooner they realise that legislation and taxation is only prolonging the issue and start adaptating (or not), the better.
I'd liken Red Hat to a business suit; not really practical for rolling your sleeves up and getting dirty, but still required by staid corporate types everywhere. Odd how that tallies with its prime marketplace...;)
So, CD+DRM is not a CD and therefore DRM does not work? That's weak. Try this:
A CD+DRM must still work on an audio CD player, no matter what, or there point is no point in producing the CD in the first place, although for some of the pap being pushed at present that would not be a bad thing, but I digress... That means that the raw CD audio data must be accessible to a CD audio drive. If it's accessible to a CD audio drive, then it must *also* be readable as raw data by a CD ROM drive (which is often the same thing anyway), even if you have to resort to a raw sector read. If you can read the CD audio data, then you can create a copy, and guess what? It's just raw audio data! Open it your favorite audio editor as 16bit, 44.1KHz stereo raw audio and you can MP3/OGG it, save it as WAV and burn to CDR, whatever.
The only *possible* counter to this is deliberate errors on the disk media which, besides causing audio distortion, can be skipped over and replaced with silence or deleted as you prefer. If the studios hadn't pissed off so many people with their heavy handedness, I'm sure someone would have explained to them how they are being ripped off by SunComm et al by now. Screw 'em!
On the subject of child porn's "underground" portrayal in the (mainstream) media I once read an article about an IT journalist who was always being asked by his non IT colleagues "Where's the porn?" Their intent was obviously to write another "Diss of the Internet as a hive of pedophiles" article that were and are so common. His standard response was "If it's is easy to find as you and your ilk claim, then I'm sure you can find it all by yourself, can't you."
When the journalists reporting on the subject don't have a clue, then it's hardly suprising that their articles are somewhat skewed. Skip forward a few years and now we are getting the same standards of journalistic brilliance applied to P2P and the whole copyright issue.
I challenge anyone here to cite any quantative evidence that replying to spam has resulted in them receiving so much as one extra message.
Do it yourself. Find a few unsubscribe links in some of the dodgier spams that include the email address they were sent to in them. Replace that address with a new non-guessable (and disposable!) email address and "unsubscribe", if you suddenly get spam on that account, then you've just disproved your call of "bullshit". Can't argue with evidence you've gathered yourself, can you?
OTOH, I did read an article about a guy who *did* unsubscribe from everything to see what effect it would have, and his spam level did go down. Whether that would still hold or not is another story, but I certainly wouldn't recommend anyone unsubscribe from a spam list.
You are being far too literal. If he'd bookmarked a Chinese language version of Google, then he'd probably know what the characters were, wouldn't he? Since he didn't and there is also a trojan going around that redirects its victims to a faked Google site, I'd say it was prudent to check for that trojan's fingerprint, wouldn't you?
Good security isn't just having a good firewall and your patches upto date, it's also not trusting that firewall and those patches and investigating anomalies. A suspect Google logo and a trojan in the wild that redirects Google is an anomaly in my book, hence the recommendation to investigate.
Ah, but in this context that could be a good thing since a slower Internet = more latency = longer TTL on your data. Take the ping for example; if it takes twice as long for your ping to echo back with your data, then you only need to retransmit back to storage at half the rate.
I wasn't trying DoS the Internet your honour... I was trying to improve data retention times!;)
It says that if you are running Windows then you should probabably check your hosts file for an entry that redirects Google to another IP. If said file does contain such an entry then it *also* says you need to patch your system because you've been trojaned.
If it's something you are loaning, a library book, DVD, car or whatever, then no, you wouldn't zap the RFID. Why would you want to when your privacy is far more likely to be compromised by some script kiddie breaking into the computer that stores the loan information than someone getting within a few meters of you with a RFID scanner? The only additional thing that the library gets out of RFID tags is convenience, which to an extent, you share in when you loan the book. They can still have a computer that contains your details and a list of the books you have loaned with the current system if they wanted to.
Yes, there are potential privacy issues with RFID tags, but with the right combination of legal requirements and *technology* they can be overcome. We're supposed to be good with technology around here, "News for Nerds" and all, and this *is* a technology problem at heart, so instead of just bitching about the issues, why not solve them and have our cake as well as eat it?
Exactly the way I look at it; RFID tags are just *so* cool from a practical standpoint they are simply inevitable. You say that you could think of a thousand practical uses for RFID, and while I know that's a figure of speech, if push came to shove you probably *could* think of a thousand uses. Maybe not a million though.;)
These things get their power through inductance, do they not? So what's wrong with, say, using a small amount of inducted power to read the data they contain, but a larget amount will induce enough power to pop an incorporated fuse? I'm sure the tinfoil hat brigade will have their doubts, but for these things to be useful, they've got to be able to transmit, and that means they can be detected.
Trying to get the things banned outright seems a bit like trying to prevent the sun from rising in the morning. Lobbying for a requirement that the things contain a permanent off switch however might stand a chance of success, and then we get the best of both worlds for a change.
I believe that SGI did actually find some code that infringed upon SCO's IP, but I'm damned if I can find the article I read that in. I suspect that this might be the same code that was briefly in Linux, but was ripped out because it wasn't good enough. I have not seen anything to support this though, so it's pure speculation based on:
SCO showing some Linux code that it claimed infringed its IP
That code being tracked back to SGI
That code being shown to have been removed from the kernel for being too crufty
I think this was the "Greek" code sample from Germany, anyone know for sure?
Actually, this is standard practice, or should be, and not just in the IT industry either. By having a company engineer disconnect the network, collect any company owned kit, etc. there is an audit trail that exonerates the ex-employee from any allegations of misappropriation of those resources.
I'd be interested to see what those obligations were.
Probably should have RTFA then, huh? Both the.COM and.NET contracts were linked from Dr. Twomey's letter. Verisign's lawyers are probably pouring over section "Y" as you read this.;)
What will happen when VeriSign doesn't do anything tomorrow?
Well, if Verisign jerks ICANN around too much I suppose ICANN could take.COM and/or.NET off them and give them/it to another registrar. I expect the idea will have been floated at ICANN by now, but this will take time to setup. That leaves ICANN with two options to implement it: pursue it through the courts now or just wait until Verisign's current contract is up.
Regardless of how this turns out, I expect Verisign will have lost it's stranglehold on at least one more TLD by the time its current contract expires. Personally I think this would be a good thing anyway; the big TLDs should never be allowed to be in the same corporate basket again. Some healthy competition should help keep the registrars on the straight and narrow: don't like the way.COM is run, fine, go to.ORG instead, or whatever other.TLD is available that floats your boat.
Yeah, I'd go for the same thing, but this seems a little bit beyond the RIAA/MPAA's usual demonstated technical level. The registrant data on the domains and the IP block data submitted by their upstream ISP (SpeedNet) tallies, and the IPs *are* in Israel. It might be bonafide in that I doubt very much that the RIAA/MPAA are going to have much legal sway in Palestine, but the thing just smacks of blatant scam to sucker in the terminally dense to me; *far* too good to be true.
Let's try that again... Clicked "Submit" instead of "Preview" thanks to the damn Citrix display lags... Still, at least I know what tags need work now! Anyhow, the following obfuscates the email address "no-one@nowhere.com":
<script>
<!--
function escramble(){
var a,b,c,d,e
a='<a href="mai'
b='no-one'
c='">'
a+='lto:'
b+='@nowhere'
e='</a>'
b+='.com'
d=b
document.write(a+b+c+d+e)
}
escramble() //-->
</script>
how many analysts spoke out at the beginning of the dot com bubble insightfully? (i.e. "this won't last?") IIRC everyone, yes including the analysts, were basically like "hey everybody what a wonderful opportunity! buy buy buy!"
Nothing wrong with that; the stock was sky rocketing so "buy, buy, buy" *was* good advice. The truly shrewd and insightful financial analysts were the ones that said "sell, sell, sell" before the bubble popped. Thinking back though, the only person I can recall who commented on that inevitability in time to do anything about it was Bill Gates.
The point about it being guesswork stands though, it might be informed, but it's still a guess.
The use of an image is good (for the non-vision impaired), including a poorly munged ALT tag is not so good. Any spam harvesting robot is not going to be bothered too much about the page layout, it's just going to be looking for regexps that look like email addresses. "jim@_REMOVE_ALL_OF_THIS_23421232_me.com" is a very recognisable email address, and the mixed case is a sign munging is going on.
Personally, I think this is a case of diminishing returns. Putting your email address in clear text on a mailto is an invitatation to spammers, but the more effort you put into obfuscation, the less returns you get for later efforts. My personal website uses a little JavaScript routine that breaks the entire "mailto" into vars, ammends some of those by adding substrings, then prints the result. I also include an explaination of why I've done this and a verbose description of how to take my initial, surname and domain name and generate a valid email from that. Clickable links and no spam received yet!
At some point, I might get around to using extended character encodings in the JavaScript, but frankly, the few robots that are going to get *this* far have earned the right to try the next step. Congratulations; you have passed the enterance exam and earned the right to try and get your spam through the SpamAssassin Gauntlet!
Not exactly. As far as I can tell from the quick scan of the PDFs and the statement that it just requires the kernel to be reconfigured, it's just a replacement hardware abstraction layer. I'm guessing that on NT/XP the only component that will need replacing is the HAL, and maybe some device drivers. If the concept takes off, then that's no different for a vendor than providing a different kernel/HAL tweaked for both single CPU and SMP systems, as many distros and Microsoft already do.
True, it's not a drop in like VMWare or Bochs, but this could be the killer app for people who run big VM based compilation servers like SourceForge. When you are talking iron of that kind of scale, a few percentage points saved on performance can easily equate to a significant amount of cash on the hardware budget.
Slashdot Mirror
Heh. If the switch to the Euro was any indication, then you can expect to have a bunch of forgeries real soon now. Because the notes are so new, they don't even have to be very good forgeries, so colour laser printed ones would probably fool a significant number of people, especially if the feel of the paper is right.
I personally think this is the best news to happen to space exploration for ages; it might just scare enough people in the US/EU to kick a little more funding towards NASA/ESA.
I'll have to check my SpamAssassin rule set, but I think a small positive score if a backup MX was used as a relay might be in order. What would be really slick would be to weight the score based on uptime of the primary MX; if the primary was up when the mail hit the secondary then a bigger score should be given. I'm not sure how to implement that though (if it's even possible) because you need to know that the server was up *and* accessible from the Internet.
- confTO_QUEUERETURN_NORMAL
- confTO_QUEUERETURN_URGENT
- confTO_QUEUERETURN_NONURGENT
and the same again with "WARN" in the place of "RETURN". The best thing is, if you set these in a certain way it *really* causes grief for those pricks that like to set the urgent flag on all their emails because they get innundated with warnings. It's like a LART, only without the lawsuit.In a few years, maybe less, when bandwidth increases the movie studios will be moaning that their copyright is being widely impinged too, and they want a slice of the pie. Obviously there is not enough to cover both, so we have to pay *more* tax to cover the movie studios as well. More money changing hands is also more taxes for governments too, so the corporates and governments go laughing off to the bank while the users are left worse off.
Needless to say, I don't like this concept at all. When the automobile came along, the makers of horse drawn carriages had to either adapt and make coachwork for autos, or died. Here we are, a century or so later and it's the turn of the media industry to be put through the wringer. The choices are the same; adapt or die - the sooner they realise that legislation and taxation is only prolonging the issue and start adaptating (or not), the better.
I'd liken Red Hat to a business suit; not really practical for rolling your sleeves up and getting dirty, but still required by staid corporate types everywhere. Odd how that tallies with its prime marketplace... ;)
A CD+DRM must still work on an audio CD player, no matter what, or there point is no point in producing the CD in the first place, although for some of the pap being pushed at present that would not be a bad thing, but I digress... That means that the raw CD audio data must be accessible to a CD audio drive. If it's accessible to a CD audio drive, then it must *also* be readable as raw data by a CD ROM drive (which is often the same thing anyway), even if you have to resort to a raw sector read. If you can read the CD audio data, then you can create a copy, and guess what? It's just raw audio data! Open it your favorite audio editor as 16bit, 44.1KHz stereo raw audio and you can MP3/OGG it, save it as WAV and burn to CDR, whatever.
The only *possible* counter to this is deliberate errors on the disk media which, besides causing audio distortion, can be skipped over and replaced with silence or deleted as you prefer. If the studios hadn't pissed off so many people with their heavy handedness, I'm sure someone would have explained to them how they are being ripped off by SunComm et al by now. Screw 'em!
When the journalists reporting on the subject don't have a clue, then it's hardly suprising that their articles are somewhat skewed. Skip forward a few years and now we are getting the same standards of journalistic brilliance applied to P2P and the whole copyright issue.
Do it yourself. Find a few unsubscribe links in some of the dodgier spams that include the email address they were sent to in them. Replace that address with a new non-guessable (and disposable!) email address and "unsubscribe", if you suddenly get spam on that account, then you've just disproved your call of "bullshit". Can't argue with evidence you've gathered yourself, can you?
OTOH, I did read an article about a guy who *did* unsubscribe from everything to see what effect it would have, and his spam level did go down. Whether that would still hold or not is another story, but I certainly wouldn't recommend anyone unsubscribe from a spam list.
Good security isn't just having a good firewall and your patches upto date, it's also not trusting that firewall and those patches and investigating anomalies. A suspect Google logo and a trojan in the wild that redirects Google is an anomaly in my book, hence the recommendation to investigate.
I wasn't trying DoS the Internet your honour... I was trying to improve data retention times! ;)
It says that if you are running Windows then you should probabably check your hosts file for an entry that redirects Google to another IP. If said file does contain such an entry then it *also* says you need to patch your system because you've been trojaned.
Yes, there are potential privacy issues with RFID tags, but with the right combination of legal requirements and *technology* they can be overcome. We're supposed to be good with technology around here, "News for Nerds" and all, and this *is* a technology problem at heart, so instead of just bitching about the issues, why not solve them and have our cake as well as eat it?
These things get their power through inductance, do they not? So what's wrong with, say, using a small amount of inducted power to read the data they contain, but a larget amount will induce enough power to pop an incorporated fuse? I'm sure the tinfoil hat brigade will have their doubts, but for these things to be useful, they've got to be able to transmit, and that means they can be detected.
Trying to get the things banned outright seems a bit like trying to prevent the sun from rising in the morning. Lobbying for a requirement that the things contain a permanent off switch however might stand a chance of success, and then we get the best of both worlds for a change.
- SCO showing some Linux code that it claimed infringed its IP
- That code being tracked back to SGI
- That code being shown to have been removed from the kernel for being too crufty
I think this was the "Greek" code sample from Germany, anyone know for sure?Or at least, that's the theory...
Three companies, three options. Try and match them up...
.
.
.
Head exploded yet?
Probably should have RTFA then, huh? Both the .COM and .NET contracts were linked from Dr. Twomey's letter. Verisign's lawyers are probably pouring over section "Y" as you read this. ;)
Well, if Verisign jerks ICANN around too much I suppose ICANN could take .COM and/or .NET off them and give them/it to another registrar. I expect the idea will have been floated at ICANN by now, but this will take time to setup. That leaves ICANN with two options to implement it: pursue it through the courts now or just wait until Verisign's current contract is up.
Regardless of how this turns out, I expect Verisign will have lost it's stranglehold on at least one more TLD by the time its current contract expires. Personally I think this would be a good thing anyway; the big TLDs should never be allowed to be in the same corporate basket again. Some healthy competition should help keep the registrars on the straight and narrow: don't like the way .COM is run, fine, go to .ORG instead, or whatever other .TLD is available that floats your boat.
Yeah, I'd go for the same thing, but this seems a little bit beyond the RIAA/MPAA's usual demonstated technical level. The registrant data on the domains and the IP block data submitted by their upstream ISP (SpeedNet) tallies, and the IPs *are* in Israel. It might be bonafide in that I doubt very much that the RIAA/MPAA are going to have much legal sway in Palestine, but the thing just smacks of blatant scam to sucker in the terminally dense to me; *far* too good to be true.
'
a+='lto:'
b+='@zocalo'
e=''
b+='.uk.com'
d=b
document.write(a+b+c+d+e)
}
escramble()
Nothing wrong with that; the stock was sky rocketing so "buy, buy, buy" *was* good advice. The truly shrewd and insightful financial analysts were the ones that said "sell, sell, sell" before the bubble popped. Thinking back though, the only person I can recall who commented on that inevitability in time to do anything about it was Bill Gates.
The point about it being guesswork stands though, it might be informed, but it's still a guess.
Personally, I think this is a case of diminishing returns. Putting your email address in clear text on a mailto is an invitatation to spammers, but the more effort you put into obfuscation, the less returns you get for later efforts. My personal website uses a little JavaScript routine that breaks the entire "mailto" into vars, ammends some of those by adding substrings, then prints the result. I also include an explaination of why I've done this and a verbose description of how to take my initial, surname and domain name and generate a valid email from that. Clickable links and no spam received yet!
At some point, I might get around to using extended character encodings in the JavaScript, but frankly, the few robots that are going to get *this* far have earned the right to try the next step. Congratulations; you have passed the enterance exam and earned the right to try and get your spam through the SpamAssassin Gauntlet!
True, it's not a drop in like VMWare or Bochs, but this could be the killer app for people who run big VM based compilation servers like SourceForge. When you are talking iron of that kind of scale, a few percentage points saved on performance can easily equate to a significant amount of cash on the hardware budget.