I indeed made up those numbers -- I forgot to qualify that in my post. I didn't have it in me to research it myself. Then that whole clog thing struck me funny, and now I've inadvertently spread disinformation about bike statistics. And probably pissed off the clog-wearing bikers of the world while I was at it.
For the record: the number of bicycle thefts per 100 people in America in the year 2000: 2.7. In Sweden: 9.4.
Number of bicycles per 100 people in America in the year 2000: 4. In Sweeden: 90.
The point is that I imagine that the number of bikes per hundred in other countries is probably a lot higher than in the US. The relevant thing here would probably be the number of bikes stolen as a percentage of total bikes.
Man up and get yourself a goddam SUV! Only a damn clog-wearing fairy would ride a bike anyway! And how do you ride a bike with clogs on, anyway?!?
"Dear Slashdot, I've noticed that I need a root canal. I bought a Dremel and the biggest cordless drill they had at Home Depot, and I have a bottle of tequila. Can anyone advise me about how to proceed with doing the root canal on myself?"
Problem #2: Disproving "trade secret" status is pointless(not to mention, unlikely to happen). It's still copyright SOMEONE ELSE, and YOU CAN'T USE IT unless they let you!
Yes, the actual code is indeed protected by the copyright. However the way that the code works might constitute a trade secret. So if you implement the same algorithm/strategy without using the same code, you could be on the hook for a trade secret violation.
Problem #3: It's been said time+time again, there is no proprietary code that belongs to SCO in the Linux kernel. This project, therefore, is entirely moot, at least in regards to the SCO lawsuit...and it can only, in fact, cause damage, because you're implying there IS code that belongs to SCO that "we" need to find a way to justify its presence in the kernel...when in fact no such code exists.
Only a moron would be pursuing this on the merits of just the copyright. I haven't read the filings, but I presume that it's broader than copyrights, and includes all forms of intellectual property (which includes trade secrets, which is the most relevant area of possible infringement.) Defending against a trade secret infringement complaint is an uphill battle -- it will be very interesting to account for all of the areas of the code in question, and prove that it wasn't a misappropriated trade secret.
For those using Outlook and Outlook Express (regardless of any feelings you might have personally against them, and regardless of the quality of the products, there are people who use them), it comes with S/MIME support which is another great way to keep your email private and secure. OpenSSL implements S/MIME also, if you're looking for a free solution.
Re:They needed three days to figure this out?
on
Spam Meeting Wrap-up
·
· Score: 3, Insightful
And the answer is a total re-write of the SMTP specification and standard to allow accountability and traceability of email messages
I agree -- a completely backward compatible re-write of the SMTP specification, and getting people to deploy it is exactly what's needed.
You see the problem with that statement, of course, don't you? Making it backward compatible and getting it deployed tend to be "the hard part". We already have transport-level authentication and privacy (through TLS), as well as application-level authentication and privacy (through S/MIME and OpenPGP). So how do you deploy those mechanisms in such a way that maintains compatibility, scales, and gets adopted by organizations?
Short answers are fine, but there are people who have been examining these issues for years without significant progress. Partially because it's a hard problem, but partially because it's not clear that someone's willing to spend money on it.
I presume the way they were able to do the voices during the interview is by having the useless clips of the actual show being shown over them while they're "in character", thus negating most of the useful aspect of the interview (showing them as actual people speaking as the characters). As if any of us need to be reminded what the characters look like, or what episodes they were in.
I love press releases in the form of security alerts.
"AT&T decided that the risk of not getting any free press was great, so it has taken the unusual step of posting an alert to law enforcement agencies nationwide."
Yeah, I think that it's fantastic that news.google.com and Asahi can get their shit straightened out enough to get registration-free NYT links, but Slashdot can't. Perhaps it's blindingly complicated enough that we can't understand it, but right now it just pisses me off that any references with registration required get put on Slashdot to begin with.
Yes, the person who posted this article took some liberty equating "VDT" with "CRT" -- to the point where it is genuinely misleading. The referenced article talks about problems that logically seem to be independent of the actual display technology, and I presume that their use of the term "VDT" is meant to purposely encompass all types of monitors, CRT and LCD included.
Irrespective of this, you should still buy yourself a badass three panel LCD. At least when you collapse in a quivering pile you'll have a damned fine display for your family to inherit.
In general, it is a difficult problem to say "we need to be HIPAA-compliant". It generally needs to break down to finding all of the points where healthcare information flows outside the organization, and then protecting that information.
From the standpoint of email, there was a great amount of effort put into this in 2001. Check out this press release which summarizes the effort. Basically, there was a group of email vendors led by the Massachusetts Health Data Consortium (MHDC) that got together and standardized a method of doing server to server encryption of email. This effort is currently an Internet Draft, draft-ramsdell-enc-smime-gateway, and it will actually be moved to the IETF-SMIME working group in time for the next meeting. It is basically a profile of the DOMSEC effort, which is in turn a profile of S/MIME. I participated in this effort on behalf of Tumbleweed, and at the end of it all, the products were all working together, and I am a co-author and editor of the draft.
The bottom line is that there exist commercially available solutions from multiple vendors which satisfy the HIPAA requirements for secure email, which is most likely a large part of your charge. These products are generally usable in a "gateway" configuration where they can be placed next to an existing mail server to automatically encrypt / decrypt mail according to policy. Further, this effort is being discussed and documented in the IETF so that new implementations can be created.
Slashdot Mirror
I indeed made up those numbers -- I forgot to qualify that in my post. I didn't have it in me to research it myself. Then that whole clog thing struck me funny, and now I've inadvertently spread disinformation about bike statistics. And probably pissed off the clog-wearing bikers of the world while I was at it.
Number of bicycles per 100 people in America in the year 2000: 4. In Sweeden: 90.
The point is that I imagine that the number of bikes per hundred in other countries is probably a lot higher than in the US. The relevant thing here would probably be the number of bikes stolen as a percentage of total bikes.
Man up and get yourself a goddam SUV! Only a damn clog-wearing fairy would ride a bike anyway! And how do you ride a bike with clogs on, anyway?!?
OK, so this is a 142MB zip file. What's inside of it? QuickTime? WMV? I don't wanna spend 1/2 hour downloading it on my G5 to find that it's a WMV.
I notice some important features that are missing from the iRiver blah blah that were pointed out in a previous post:
iTunes
iTunes
iTunesiTunesiTunes
iTunes Music Store
Not sure about everyone else, but I'm sold on the $.99/track bandwagon.
"Dear Slashdot, I've noticed that I need a root canal. I bought a Dremel and the biggest cordless drill they had at Home Depot, and I have a bottle of tequila. Can anyone advise me about how to proceed with doing the root canal on myself?"
A friend of mine wrote up a rather entertaining summary of the Great Auckland blackout. Hope they don't mind the Slashdotting. http://www.cs.auckland.ac.nz/~pgut001/misc/mercury .txt
Problem #2: Disproving "trade secret" status is pointless(not to mention, unlikely to happen). It's still copyright SOMEONE ELSE, and YOU CAN'T USE IT unless they let you!
Yes, the actual code is indeed protected by the copyright. However the way that the code works might constitute a trade secret. So if you implement the same algorithm/strategy without using the same code, you could be on the hook for a trade secret violation.
Problem #3: It's been said time+time again, there is no proprietary code that belongs to SCO in the Linux kernel. This project, therefore, is entirely moot, at least in regards to the SCO lawsuit...and it can only, in fact, cause damage, because you're implying there IS code that belongs to SCO that "we" need to find a way to justify its presence in the kernel...when in fact no such code exists.
Only a moron would be pursuing this on the merits of just the copyright. I haven't read the filings, but I presume that it's broader than copyrights, and includes all forms of intellectual property (which includes trade secrets, which is the most relevant area of possible infringement.) Defending against a trade secret infringement complaint is an uphill battle -- it will be very interesting to account for all of the areas of the code in question, and prove that it wasn't a misappropriated trade secret.
For those using Outlook and Outlook Express (regardless of any feelings you might have personally against them, and regardless of the quality of the products, there are people who use them), it comes with S/MIME support which is another great way to keep your email private and secure. OpenSSL implements S/MIME also, if you're looking for a free solution.
I agree -- a completely backward compatible re-write of the SMTP specification, and getting people to deploy it is exactly what's needed.
You see the problem with that statement, of course, don't you? Making it backward compatible and getting it deployed tend to be "the hard part". We already have transport-level authentication and privacy (through TLS), as well as application-level authentication and privacy (through S/MIME and OpenPGP). So how do you deploy those mechanisms in such a way that maintains compatibility, scales, and gets adopted by organizations?
Short answers are fine, but there are people who have been examining these issues for years without significant progress. Partially because it's a hard problem, but partially because it's not clear that someone's willing to spend money on it.
Arithmetic according to C: float x = 3.14159; float y = 1/2 * x; Value of y? zero.
Value of understanding C programming and avoiding this problem? Priceless.
I presume the way they were able to do the voices during the interview is by having the useless clips of the actual show being shown over them while they're "in character", thus negating most of the useful aspect of the interview (showing them as actual people speaking as the characters). As if any of us need to be reminded what the characters look like, or what episodes they were in.
I love press releases in the form of security alerts.
"AT&T decided that the risk of not getting any free press was great, so it has taken the unusual step of posting an alert to law enforcement agencies nationwide."
Yeah, I think that it's fantastic that news.google.com and Asahi can get their shit straightened out enough to get registration-free NYT links, but Slashdot can't. Perhaps it's blindingly complicated enough that we can't understand it, but right now it just pisses me off that any references with registration required get put on Slashdot to begin with.
Irrespective of this, you should still buy yourself a badass three panel LCD. At least when you collapse in a quivering pile you'll have a damned fine display for your family to inherit.
In general, it is a difficult problem to say "we need to be HIPAA-compliant". It generally needs to break down to finding all of the points where healthcare information flows outside the organization, and then protecting that information.
From the standpoint of email, there was a great amount of effort put into this in 2001. Check out this press release which summarizes the effort. Basically, there was a group of email vendors led by the Massachusetts Health Data Consortium (MHDC) that got together and standardized a method of doing server to server encryption of email. This effort is currently an Internet Draft, draft-ramsdell-enc-smime-gateway, and it will actually be moved to the IETF-SMIME working group in time for the next meeting. It is basically a profile of the DOMSEC effort, which is in turn a profile of S/MIME. I participated in this effort on behalf of Tumbleweed, and at the end of it all, the products were all working together, and I am a co-author and editor of the draft.
The bottom line is that there exist commercially available solutions from multiple vendors which satisfy the HIPAA requirements for secure email, which is most likely a large part of your charge. These products are generally usable in a "gateway" configuration where they can be placed next to an existing mail server to automatically encrypt / decrypt mail according to policy. Further, this effort is being discussed and documented in the IETF so that new implementations can be created.