Sometimes, it's not so useful to rely on/. for breaking cutting edge news...
The drug you are interested in is PTC124, otherwise known as Ataluren. It is currently in phase 2 clinical trials IN HUMANS (in the UK, at least) - We have boxes of it...
Well, I'm not usually particularly vocal about issues like this. However, I was fortunate enough to have been in a university with an IT chief whose stated policy was "by all means crack away, so long as you tell me what you've done and how you did it". It was always a battle of wits between us and them, but always friendly. To my knowledge, we never had any serious breach, and holes that were discovered were quickly patched.
Contrawise, this seems to be the second security breach at Carleton Uni in the last few months. Personally, I wouldn't trust their IT system admins one inch.
I have emailed my thoughts on the matter to the President, and to the members of the Senate of Carleton University. Addresses are on their website. Perhaps, if they receive enough messages, they may choose to change their course of action...
Is there any available list of WHICH processors are affected? Are we talking ALL Core 2 Duo chips, of ALL varieties, including mobile? What other chips are involved? (Personally, I find the whole genealogy if Intel chips very very hard to follow).
WTF is going on? I'd be very interested to know just exactly what is happening here.
On the one hand we have a Gov't scheme funding a private company - not only to enforce the law, but also one passed specifically to give UnSpam the right to collect ongoing revenues. In my eyes, this is a government sponsored monopoly - ergo a BAD thing.
Then again, the scheme has failed to give the Gov't the profits they had hoped for. As you shouldn't pass laws simply to generate revenue (unless you are at least honest and call it "Taxation"), I feel halfway between "Tough shit, guys", and "You should get your asses kicked out of office".
Not that I have any hard information, but I guess these guys are using this as an information gathering exercise prior to something bigger (at least I hope it leads to something...)
The gathering of IP addresses has been discussed here before (though I cannot offhand remember when). It is theorectically trivial to serve up a cryptohash of the IP address of the visitor harvesting email addresses with the intention of spamming. So, we know how the email address in question was gathered.
SMTP connection tracking will tell us from which IP address the email was delivered.
What we don't know is how these two events are linked - ie. who is involved in the chain. Hopefully, court action will force the participants out, and maybe reveal other interesting information...
and I wish these guys all the best. Someone is actually attempting to do something. It may not work first time - but they are giving it a damn good go, and I for one hope they suceed.
There was a utility, some time ago, available for Win/MSDOS to do just this. At the time, it was shareware. Sadly, I cannot find any reference to it now. I wish there was a FOSS equivalent, as of all the archival media we have, this (with decent ink) at least has a proven track record of hundreds, if not thousands, of years.
Sadly, part of the main problem has been the reluctance, nay, the refusal of many many mail admins and other interested parties to sit down together and thrash out solutions to the problem. Every time there is a reasonable suggestion to help control this issue, it is the people within who refuse to help, and find ways to critisize and block a new rfc adoption. And, whilst we delay, the spammers have open season. It's no wonder the problem is getting worse, because no-one is really doing anything to make it better.
It really is time drastic changes were made. For a start, the rfc's need to be altered to address the issue of mail forwarding. No longer should a forwarded mail be bounced to the original sender - it MUST be bounced back to the forwarding service. They should bear the cost of dealing with the problem, rather than offloading it to the ex-recipients mail server and making the problem worse. For our server, 99% of bigfoot mail is spam. Soon, we will unilaterally block them...
Once forwarding is sensibly sorted, THEN we can address the proposals that preceded SPF. Then we can start to look at automatically refusing to accept mail WITHOUT the expense of scanning it... In the mean time, we are forced into adopting layers upon layers of Heath Robinson fixes in a vain attempt to control the problem, rather than taking the bull by the horns and actually dealing with the problem once and for all. But a change means that too many lazy mail-admins in net-world are going to have to fix SMTP hosts that are already broken, but currently work because of the compromises everyone else has to make. THEY, ultimately, are the people responsible for all the spam in our mailboxes.
Ahem, actually, there aren't that many places where you could either move the stones, or put a different arrangement in the same place. The lattitude is highly specific - most henges occur around 51-59 deg north. The 'magic' number happens to be 55 degrees, which just so happens to be the the same lattitude as Hadrians Wall - not designed to keep the Scots in/out (which has never worked!), but to desecrate this 'magic' spot.
I didn't believe in much of the hype about the henges, until I started reading. Fact: all the henges use the same unit of measurement, despite being scattered in distance and time. This unit is _very_ precise. Another 'horrible' fact: multiply this unit by 60 minutes, then by the no of degrees in a circle, and you get the circumference of the earth, accurate to todays estimate to within 20 meters or so!!!
Not fact, but plausible theory (for me at least), is The Book of Enoch (bits in the Bible, Dead Sea Scrolls...) clearly describe a henge - and the estimated location was approx (yes, you guessed it) 55 degrees north. Odd, for a Jewish text...
There's too much to go on, but the 'coincidences' are so numerous, it is hard NOT to reach the conclusion that these sites were very accurate, and very important.
Get a good read - fascinating even if you don't believe. Uriel's Machine, by Knight & Lomas.
I welcome anything that is going to make it easier for me (as an MTA admin) to reject crappy email. And this COULD help.
But will it?
First, it is a DNS admin and MTA tool, not an end-user aid. You're not going to see a plug-in for LookOut Express, or anything else.
Second. End users don't care about (and generally don't know about) DNS etc. therefore are unlikely to demand that this be implemented. They certainly won't pay for it.
Domain registrars are not going to implement this due to time and cost and hassle.
And, sadly, postmasters won't either, because a huge number are too clueless to run a properly configured mail exchange anyway. Hell, I end up having long discussions about the validity of RFC1123 5.2.5. If I could rely on HELO verification, I could cut out well over 50% of the spam on my server. The sad thing is I can't, because too many postmasters either can't set up a 'proper' system, or argue about the semantics of a long standing RFC.
I will watch this project, and if it gets RFC bect-practice (or any other) status, then I will implement the functionality. For those who can take the time and effort to implement it, it will confer benefit (at least if you send mail through us). But I fear too many people are ambivalent to the problem of spam to do anything about it. Convince everyone to send a true HELO argument, implement SECDNS, and all the other measures that would help, and we could be well on our way.
And dial-up users with their own domain COULD make use of this, again WITH A BIT OF EFFORT. And if your ISP/Domain registrar/DNS admin wont help you, CHANGE YOUR ACCOUNT TO SOMEONE WHO WILL! If you want a free ride, and use Hotmail etc. don't complain about the spam problem - spam is part of their package.
... the Linux userbase is literally NOTHING compared to the Windows userbase
...it still just lacks the pure numbers of Windows, or even Mac.
Ah, the wisdom of Lord Dreamer!
Not quite sure how you make the case for dropping development of Linux drivers, on the grounds of a "BAD BUSINESS IDEA". I have these observetions:
First would be that of Atari & Bioware's business model. Neverwinter client was Linux beta LONG before the Mac. Even now, Shadows of Undrentide is available for Windows and Linux as non-beta, but not at all for the Mac.
Be it NWN, Quake, or foobar, the best games designed for networked play come with, surprise surprise, Linux servers.
Looking at some of our website stats for browsers used (UK-Jive, >1,000 page visits per day), I get the following:
0.3 % - Win 3.1
1.0 % - Win 95
1.4 % - Win NT
1.4 % - Mac
4.0 % - Linux
4.5 % - Win ME
10.9 % - Win 2000
18.2 %- Win 98
22.8 % - Win XP
So we have Linux more popular than the Mac, and even in direct competition with Win NT and ME (and before you lump all the Windows platforms together, remember that most of them require seperate drivers). So, in summary, there are no hard feelings. The Linux platform is no longer a minority, and R+D on the platform is time and money well spent. As soon as hardcore gamers realise that their game will run faster under an optimised Linux platform than Windows (if drivers and clients are available), then you will see an explosive growth in the Linux market. This, however, is dependant purely upon the synergy between ATI / NVIDIA / whatever, and the companies with a realistic view such as Bioware.
Slashdot Mirror
Sometimes, it's not so useful to rely on /. for breaking cutting edge news...
The drug you are interested in is PTC124, otherwise known as Ataluren. It is currently in phase 2 clinical trials IN HUMANS (in the UK, at least) - We have boxes of it...
Well, I'm not usually particularly vocal about issues like this. However, I was fortunate enough to have been in a university with an IT chief whose stated policy was "by all means crack away, so long as you tell me what you've done and how you did it". It was always a battle of wits between us and them, but always friendly. To my knowledge, we never had any serious breach, and holes that were discovered were quickly patched.
Contrawise, this seems to be the second security breach at Carleton Uni in the last few months. Personally, I wouldn't trust their IT system admins one inch.
I have emailed my thoughts on the matter to the President, and to the members of the Senate of Carleton University. Addresses are on their website. Perhaps, if they receive enough messages, they may choose to change their course of action...
Is there any available list of WHICH processors are affected?
Are we talking ALL Core 2 Duo chips, of ALL varieties, including mobile?
What other chips are involved? (Personally, I find the whole genealogy if Intel chips very very hard to follow).
Ah! One of the many Microshite's patents that didn't manage to make it into the Linux sourcecode. Perhaps Novell could implement this feature?
WTF is going on? I'd be very interested to know just exactly what is happening here.
On the one hand we have a Gov't scheme funding a private company - not only to enforce the law, but also one passed specifically to give UnSpam the right to collect ongoing revenues. In my eyes, this is a government sponsored monopoly - ergo a BAD thing.
Then again, the scheme has failed to give the Gov't the profits they had hoped for. As you shouldn't pass laws simply to generate revenue (unless you are at least honest and call it "Taxation"), I feel halfway between "Tough shit, guys", and "You should get your asses kicked out of office".
HOWEVER, what _REALLY_ is peaking my interest is UnSpam Technologies, Inc. This, dear Readers, is the same outfit you read about 2 weeks ago on this illustrious rag, about the impending court action.
So, the questions I pose are:
Not that I have any hard information, but I guess these guys are using this as an information gathering exercise prior to something bigger (at least I hope it leads to something...)
The gathering of IP addresses has been discussed here before (though I cannot offhand remember when). It is theorectically trivial to serve up a cryptohash of the IP address of the visitor harvesting email addresses with the intention of spamming. So, we know how the email address in question was gathered.
SMTP connection tracking will tell us from which IP address the email was delivered.
What we don't know is how these two events are linked - ie. who is involved in the chain. Hopefully, court action will force the participants out, and maybe reveal other interesting information...
and I wish these guys all the best. Someone is actually attempting to do something. It may not work first time - but they are giving it a damn good go, and I for one hope they suceed.
The opportunities are endless....
... but the idea has been eloquently covered before
with the Beowoulf Vax Cluster.
http://www.theregister.co.uk/2002/05/11/bofh_and_t he_vax_cluster/
There was a utility, some time ago, available for Win/MSDOS to do just this. At the time, it was shareware. Sadly, I cannot find any reference to it now. I wish there was a FOSS equivalent, as of all the archival media we have, this (with decent ink) at least has a proven track record of hundreds, if not thousands, of years.
Sadly, part of the main problem has been the reluctance, nay, the refusal of many many mail admins and other interested parties to sit down together and thrash out solutions to the problem. Every time there is a reasonable suggestion to help control this issue, it is the people within who refuse to help, and find ways to critisize and block a new rfc adoption. And, whilst we delay, the spammers have open season. It's no wonder the problem is getting worse, because no-one is really doing anything to make it better.
It really is time drastic changes were made. For a start, the rfc's need to be altered to address the issue of mail forwarding. No longer should a forwarded mail be bounced to the original sender - it MUST be bounced back to the forwarding service. They should bear the cost of dealing with the problem, rather than offloading it to the ex-recipients mail server and making the problem worse. For our server, 99% of bigfoot mail is spam. Soon, we will unilaterally block them...
Once forwarding is sensibly sorted, THEN we can address the proposals that preceded SPF. Then we can start to look at automatically refusing to accept mail WITHOUT the expense of scanning it... In the mean time, we are forced into adopting layers upon layers of Heath Robinson fixes in a vain attempt to control the problem, rather than taking the bull by the horns and actually dealing with the problem once and for all. But a change means that too many lazy mail-admins in net-world are going to have to fix SMTP hosts that are already broken, but currently work because of the compromises everyone else has to make. THEY, ultimately, are the people responsible for all the spam in our mailboxes.
Ahem, actually, there aren't that many places where you could either move the stones, or put a different arrangement in the same place. The lattitude is highly specific - most henges occur around 51-59 deg north. The 'magic' number happens to be 55 degrees, which just so happens to be the the same lattitude as Hadrians Wall - not designed to keep the Scots in/out (which has never worked!), but to desecrate this 'magic' spot. I didn't believe in much of the hype about the henges, until I started reading. Fact: all the henges use the same unit of measurement, despite being scattered in distance and time. This unit is _very_ precise. Another 'horrible' fact: multiply this unit by 60 minutes, then by the no of degrees in a circle, and you get the circumference of the earth, accurate to todays estimate to within 20 meters or so!!! Not fact, but plausible theory (for me at least), is The Book of Enoch (bits in the Bible, Dead Sea Scrolls ...) clearly describe a henge - and the estimated location was approx (yes, you guessed it) 55 degrees north. Odd, for a Jewish text...
There's too much to go on, but the 'coincidences' are so numerous, it is hard NOT to reach the conclusion that these sites were very accurate, and very important.
Get a good read - fascinating even if you don't believe. Uriel's Machine, by Knight & Lomas.
I welcome anything that is going to make it easier for me (as an MTA admin) to reject crappy email. And this COULD help. But will it? First, it is a DNS admin and MTA tool, not an end-user aid. You're not going to see a plug-in for LookOut Express, or anything else. Second. End users don't care about (and generally don't know about) DNS etc. therefore are unlikely to demand that this be implemented. They certainly won't pay for it. Domain registrars are not going to implement this due to time and cost and hassle. And, sadly, postmasters won't either, because a huge number are too clueless to run a properly configured mail exchange anyway. Hell, I end up having long discussions about the validity of RFC1123 5.2.5. If I could rely on HELO verification, I could cut out well over 50% of the spam on my server. The sad thing is I can't, because too many postmasters either can't set up a 'proper' system, or argue about the semantics of a long standing RFC. I will watch this project, and if it gets RFC bect-practice (or any other) status, then I will implement the functionality. For those who can take the time and effort to implement it, it will confer benefit (at least if you send mail through us). But I fear too many people are ambivalent to the problem of spam to do anything about it. Convince everyone to send a true HELO argument, implement SECDNS, and all the other measures that would help, and we could be well on our way. And dial-up users with their own domain COULD make use of this, again WITH A BIT OF EFFORT. And if your ISP/Domain registrar/DNS admin wont help you, CHANGE YOUR ACCOUNT TO SOMEONE WHO WILL! If you want a free ride, and use Hotmail etc. don't complain about the spam problem - spam is part of their package.
Tech support (ha!) now claim that this number is just for info, and are referring all calls such as this to the sitefinder@verisign-grs.com bitbucket.
Just pondering - is this THE weapon of mass destruction the military has been looking so hard to find ....
Errr, robots & other OS's perchance???
...it still just lacks the pure numbers of Windows, or even Mac.
Ah, the wisdom of Lord Dreamer!
Not quite sure how you make the case for dropping development of Linux drivers, on the grounds of a "BAD BUSINESS IDEA". I have these observetions:First would be that of Atari & Bioware's business model. Neverwinter client was Linux beta LONG before the Mac. Even now, Shadows of Undrentide is available for Windows and Linux as non-beta, but not at all for the Mac.
Be it NWN, Quake, or foobar, the best games designed for networked play come with, surprise surprise, Linux servers.Looking at some of our website stats for browsers used (UK-Jive, >1,000 page visits per day), I get the following:
- 0.3 % - Win 3.1
- 1.0 % - Win 95
- 1.4 % - Win NT
- 1.4 % - Mac
- 4.0 % - Linux
- 4.5 % - Win ME
- 10.9 % - Win 2000
- 18.2 %- Win 98
- 22.8 % - Win XP
So we have Linux more popular than the Mac, and even in direct competition with Win NT and ME (and before you lump all the Windows platforms together, remember that most of them require seperate drivers). So, in summary, there are no hard feelings. The Linux platform is no longer a minority, and R+D on the platform is time and money well spent. As soon as hardcore gamers realise that their game will run faster under an optimised Linux platform than Windows (if drivers and clients are available), then you will see an explosive growth in the Linux market. This, however, is dependant purely upon the synergy between ATI / NVIDIA / whatever, and the companies with a realistic view such as Bioware.