That's totally false. How DO you come up with that kind of nonsense?
Mostly because the use of the overbroad phrase "intellectual property" gives people the impression that all "IP" is alike, so if something applies to trademarks -- why, it must be true about copyright or patent law as well!
That's my guess, anyhow. Yours is probably as good.
If it were just spam, maybe you'd have a point. Maybe. I don't think so, but there are other people arguing the point, so I'll leave it to them.
The key distinction you're missing is that this fellow was committing fraud -- promising people jobs (if they'd pay some money up-front) and giving them lists of completely useless information, among other things. Mass email was just the mechanism. His prosecution, thus, was totally legit -- on that point alone!
Taxing spam would be difficult. Folks who are willing to commit fraud (as most spammers are) and hide their identities (as most spammers do) aren't likely to shake at the thought of a bit of tax evasion. And if you were to implement it somehow, and make it stick -- how do you distribute the money? Much of the internet's infrastructure is privately owned; would you give it to the involved companies, and ask them to be nice and please spend it on modernization? Would you use it to upgrade government-owned 'net usage? What good does that do to folks not getting their access via a.edu?
If you've got the ability to find and prosecute these folks for tax evasion (as you must have to make a tax stick), you've got the ability to find and prosecute them for fraud, or sending unsolicited commercial email, or anything else. Declaring a pretend tax to legitimize spam is useless as an antispam measure, and likely to do more harm than good.
Copyright isn't waived that way; neither are patents (though one may lose the ability to enforce them in specific cases, the patent itself isn't going to be lost due to submerging it).
Interesting counter question: How many OSS Windows apps are compiled using a warezed version of Visual Studio?
All the OSS Windows projects I've worked on (like the one I'm hacking right now) have gone to significant lengths to be compatible with MINGW32.
This is actually quite handy, because it means I can cross-compile from Linux. (Yup, I'm writing Windows code, but compiling it with a Linux compiler and testing it with WINE... ain't OSS great?!)
I'm willing to leave and even earn less if I can buy a house and not live paycheck to paycheck.
I've said this before: Considered Austin, TX?
"Paid enough to afford a house" is damn little here. I just bought one, and the cash component of my pay (at the startup [yup, interesting work] that I'm at) is just 4000 more than a year's rent (alone, no other expenses) cost there.
Austin, Texas: Get paid $55K (if you could find a $50K job in East Buttfuck). Pay 25% federal tax plus 0.0% state tax. House costs $100K-$250K.
It's still a huge improvement over thte PRK financially, and you still get to live somewhere with interesting people (who aren't rednecks or rabid Bush supporters) and interesting things to do.
Plus, by moving here, you're increasing land values, and making my ($120K) house worth more. So everybody wins!:)
Bah. Small towns aren't all so bad -- I'd still be in Chico, CA (where I went to school) if the market for tech jobs there hadn't been so abysmal. (My best job prospect there was writing financial software in C++ for the rest of my life, or continuing to do contract work at fairly low rates for local non-tech companies -- no, thanks).
Compared to the traffic and unfriendliness [mostly -- I'm in Austin now, and folks are friendly 'nuff here] of the larger cities, I think there's a quite strong argument to be made for living in rural areas -- especially if the "no jobs there!" objection goes away.
It didn't come up because it was too early in the process. The current goings-on are strictly a dismissal motion, and so they would have been required to stick strictly to the issues in SCO's complaint... except that SCO went and brought up outside evidence first, making it fair game for Novell to act in kind.
Enlightened self-interest, not simple self-interest. There's a very substantial difference. If everyone engaging this behaviour would help you, then by engaging in this behaviour yourself you're bringing about this desired result which is eventually to your own benefit.
It's not just selflessly "doing your bit for the world", either. Consider: There are presumably a lot of people are in situations similar to your own and have a similar mindset. Correspondingly, if you rationally decide to do $FOO [which happens to have positive externalities], it's likely that others who think like you will also decide to do $FOO, thus resulting in intended net effect. See superrationality.
Libertarians are often criticized for taking the position that greed is good. However, it's this more farsighted form of greed that we generally respect.
It's also conceivable that their interest is related to the market we're in (health care -- we make electronic medical records software), or the potential for large numbers of future sales (if our suits' numbers are right, we'll be shipping a lot of servers in the next few years -- we're small right now, but our product is Damn Good Stuff).
I hope Novell is very smart in the way they market it.
Yup, they are -- if not marketing, at least sales.
We're probably going to switch to it at my workplace -- we're certainly going Novell's SLES9 on the servers we ship, as soon as I finish handling the technical headaches involved with getting off of RHEL3. (For the workstations, they're currently a very aging, heavily customized RH9 environment -- no longer supported, so we're moving them over too).
And why? Besides the price point, and the goodies SLES9 comes with that RHEL3 doesn't, there's one huge advantage Novell has:
Their "sales staff" has technical people too, and they're helpful and available. We were feeding money into Red Hat, and getting practically nothing back by way of support. Novell, on the other hand, is giving us all kinds of support (and access to goodies like the NLD beta) -- and we haven't even paid them yet!
I have no doubt that Red Hat would do the same thing for a big enough shop -- but right now we're a small, cash-impacted startup. The level of support they've given us already shows an impressive level of dedication. We're impressed, anyhow.
(The first time they visited us, they brought along one employee who was formerly Ximian, one who was formerly SuSE, and one who was a Noveller all along. I took that as Good Tidings as to their directional change, as well).
As I understand it, this is being applied to protect conversations between two branch offices -- a case where there are likely to be a number of separate streams running simultaniously over the same line.
IAX2's trunking support should help, then, by reducing the VPN-related overhead in much the same way as it reduces IP overhead.
If you're running a UDP protocol, you've still got UDP headers and IP headers and optionally Ethernet headers, wrapped around whatever you're carrying
Not Ethernet headers if they're running OpenVPN in tun mode, which is the intelligent configuration here (tap mode, the bridging configuration where Ethernet headers are used, is mostly used just by folks who want to do Windows networking over the tunnel without a WINS server). OpenVPN also uses LZO compression, which should help with any non-payload data. (That said, it temporarily disables compression if the stream is made of noncompressable data -- and in the case of precompressed payload, that's pretty darned likely to be the case). (Hrm -- it'd be intelligent to still compress the non-payload info... I don't actually know if the code does that, but am now tempted to go take a look).
So yes, you make a point -- but even so, it's not as bad as it could be.
...so the minimum overhead for just doing the RTP+UDP+IP headers is several times the size of the voice traffic they carry, and IPSEC adds another two layers of headers, or SSL adds about three, and pretty soon that cute little elegant 8kbps compressed voice stream is looking like 40-80kbps and won't fit on your modem.
OpenVPN isn't IPsec, and while it uses the OpenSSL library for all the crypto "heavy lifting", it has its own over-the-wire protocol and is much more efficient than the traditional SSL way of doing things.
I use OpenVPN at work, and while I haven't done specific measurements, we've generally found it to be very efficient (not to mention easy-to-use and hassle-free compared to its IPsec-based competitors). Because in UDP mode it doesn't try to guarantee reliability, it also doesn't break protocols (like those used for VoIP data) that expect late packets to just be dropped.
So, in short, I'm not at all convinced that the use of OpenVPN is at all unfortunate or problematic here.
Back when I was in school I got a small (summer project) research grant for "Design and Implementation of a Secure Credit Card Replacement". The system it described was a small embedded device with a keypad (for entering both prices and PINs), a private key, a public identifier, a counter and a one-way hash mechanism.
The end result is that you'd tell it how much you wanted to pay and put in your PIN, and it's give back a string that could be given to the credit company to process a transaction -- but only for that exact amount, and only once. 'Twas an interesting project, but it would require a lot of hardware and software expendature to implement, and so was never likely to go anywhere in practice.
Dunno 'bout that, though -- I respect the WSJ (even) more than the New York Times. (If your opinion differs I'd be curious to hear, in broad strokes, the reasoning behind it).
USA Today? Heard of it, but I don't recall ever actually reading a copy.
I received it, and I didn't request it. (I've never gotten any other "executive emails" from Microsoft, either).
Notably, the message contains a subscribe (no, not unsubscribe, subscribe) link. Doesn't seem to me much like something they'd send only to folks who are suscribers already.
This email is one in an occasional series of emails from Microsoft executives about technology and public-policy issues important to computer users, our industry, and anyone who cares about the future of high technology. If you would like to receive these emails in the future, please go to http://register.microsoft.com/subscription/subscri beMe.asp?lcid=1033&id=155 to subscribe.
Unless there is an official hand recount, most ballots are seen only once with no checks. It wouldn't be hard for someone to count a few votes incorrectly.
Yes, it would. Vote-counting happens with individuals supervising from both major parties. Contrary to what you imply, votes aren't counted by a single individual each with no oversight.
Further, many jurisdictions require recounts whenever a vote is closer than a given percentage -- so in cases where it really matters, votes will be seen more than once.
It wouldn't be that hard for a broken (or tampered with) computer to count a large number wrong, or one person systematicly count them incorrectly.
The former is a very real problem, but one that more traditional counting mechanisms don't have (or make easily traceable).
All your complaints about possible exploits only reenforce my belief that you have to be able to check your vote after it is counted.
If you continue to think that the system as it stands are inadequate, there's plenty of research that indicates how it ought to be done (while avoiding the pitfalls that concern me). See here.
Open Source code doesn't do you any good, if the CPU microcode has been tampered with. The whole machines should be open hardware, and a statistically significant number of them, randomly selected, should be taken apart before, during, and immediately after the elections to verify their hardware contents and software.
No -- ideally, you want away to avoid that being necessary. Letting the voter review the (physical paper) output from the machine means that they can guarantee that it's operating correctly; consequently, there's no need to do additional verification.
No comment on all the other (loony) miscellany in your post.
Much of the communication between insurance companies and billing companies, or practices and and billing companies is still done in paper. The entire system needs to be digitized before you can really say that paper has been removed from the system.
Slashdot Mirror
That's totally false. How DO you come up with that kind of nonsense?
Mostly because the use of the overbroad phrase "intellectual property" gives people the impression that all "IP" is alike, so if something applies to trademarks -- why, it must be true about copyright or patent law as well!
That's my guess, anyhow. Yours is probably as good.
GPG keys can be password-protected.
If it were just spam, maybe you'd have a point. Maybe. I don't think so, but there are other people arguing the point, so I'll leave it to them.
.edu?
The key distinction you're missing is that this fellow was committing fraud -- promising people jobs (if they'd pay some money up-front) and giving them lists of completely useless information, among other things. Mass email was just the mechanism. His prosecution, thus, was totally legit -- on that point alone!
Taxing spam would be difficult. Folks who are willing to commit fraud (as most spammers are) and hide their identities (as most spammers do) aren't likely to shake at the thought of a bit of tax evasion. And if you were to implement it somehow, and make it stick -- how do you distribute the money? Much of the internet's infrastructure is privately owned; would you give it to the involved companies, and ask them to be nice and please spend it on modernization? Would you use it to upgrade government-owned 'net usage? What good does that do to folks not getting their access via a
If you've got the ability to find and prosecute these folks for tax evasion (as you must have to make a tax stick), you've got the ability to find and prosecute them for fraud, or sending unsolicited commercial email, or anything else. Declaring a pretend tax to legitimize spam is useless as an antispam measure, and likely to do more harm than good.
Copyright isn't waived that way; neither are patents (though one may lose the ability to enforce them in specific cases, the patent itself isn't going to be lost due to submerging it).
Interesting counter question: How many OSS Windows apps are compiled using a warezed version of Visual Studio?
All the OSS Windows projects I've worked on (like the one I'm hacking right now) have gone to significant lengths to be compatible with MINGW32.
This is actually quite handy, because it means I can cross-compile from Linux. (Yup, I'm writing Windows code, but compiling it with a Linux compiler and testing it with WINE... ain't OSS great?!)
I'm willing to leave and even earn less if I can buy a house and not live paycheck to paycheck.
I've said this before: Considered Austin, TX?
"Paid enough to afford a house" is damn little here. I just bought one, and the cash component of my pay (at the startup [yup, interesting work] that I'm at) is just 4000 more than a year's rent (alone, no other expenses) cost there.
There's a middle way, too.
:)
Austin, Texas: Get paid $55K (if you could find a $50K job in East Buttfuck). Pay 25% federal tax plus 0.0% state tax. House costs $100K-$250K.
It's still a huge improvement over thte PRK financially, and you still get to live somewhere with interesting people (who aren't rednecks or rabid Bush supporters) and interesting things to do.
Plus, by moving here, you're increasing land values, and making my ($120K) house worth more. So everybody wins!
Bah. Small towns aren't all so bad -- I'd still be in Chico, CA (where I went to school) if the market for tech jobs there hadn't been so abysmal. (My best job prospect there was writing financial software in C++ for the rest of my life, or continuing to do contract work at fairly low rates for local non-tech companies -- no, thanks).
Compared to the traffic and unfriendliness [mostly -- I'm in Austin now, and folks are friendly 'nuff here] of the larger cities, I think there's a quite strong argument to be made for living in rural areas -- especially if the "no jobs there!" objection goes away.
It didn't come up because it was too early in the process. The current goings-on are strictly a dismissal motion, and so they would have been required to stick strictly to the issues in SCO's complaint... except that SCO went and brought up outside evidence first, making it fair game for Novell to act in kind.
Enlightened self-interest, not simple self-interest. There's a very substantial difference. If everyone engaging this behaviour would help you, then by engaging in this behaviour yourself you're bringing about this desired result which is eventually to your own benefit.
It's not just selflessly "doing your bit for the world", either. Consider: There are presumably a lot of people are in situations similar to your own and have a similar mindset. Correspondingly, if you rationally decide to do $FOO [which happens to have positive externalities], it's likely that others who think like you will also decide to do $FOO, thus resulting in intended net effect. See superrationality.
Libertarians are often criticized for taking the position that greed is good. However, it's this more farsighted form of greed that we generally respect.
Nope. Linus explicitly exempted binary kernel modules, whereas Henrik hasn't exempted Qt.
Yup, I hope so too.
It's also conceivable that their interest is related to the market we're in (health care -- we make electronic medical records software), or the potential for large numbers of future sales (if our suits' numbers are right, we'll be shipping a lot of servers in the next few years -- we're small right now, but our product is Damn Good Stuff).
I hope Novell is very smart in the way they market it.
Yup, they are -- if not marketing, at least sales.
We're probably going to switch to it at my workplace -- we're certainly going Novell's SLES9 on the servers we ship, as soon as I finish handling the technical headaches involved with getting off of RHEL3. (For the workstations, they're currently a very aging, heavily customized RH9 environment -- no longer supported, so we're moving them over too).
And why? Besides the price point, and the goodies SLES9 comes with that RHEL3 doesn't, there's one huge advantage Novell has:
Their "sales staff" has technical people too, and they're helpful and available. We were feeding money into Red Hat, and getting practically nothing back by way of support. Novell, on the other hand, is giving us all kinds of support (and access to goodies like the NLD beta) -- and we haven't even paid them yet!
I have no doubt that Red Hat would do the same thing for a big enough shop -- but right now we're a small, cash-impacted startup. The level of support they've given us already shows an impressive level of dedication. We're impressed, anyhow.
(The first time they visited us, they brought along one employee who was formerly Ximian, one who was formerly SuSE, and one who was a Noveller all along. I took that as Good Tidings as to their directional change, as well).
As I understand it, this is being applied to protect conversations between two branch offices -- a case where there are likely to be a number of separate streams running simultaniously over the same line.
IAX2's trunking support should help, then, by reducing the VPN-related overhead in much the same way as it reduces IP overhead.
If you're running a UDP protocol, you've still got UDP headers and IP headers and optionally Ethernet headers, wrapped around whatever you're carrying
Not Ethernet headers if they're running OpenVPN in tun mode, which is the intelligent configuration here (tap mode, the bridging configuration where Ethernet headers are used, is mostly used just by folks who want to do Windows networking over the tunnel without a WINS server). OpenVPN also uses LZO compression, which should help with any non-payload data. (That said, it temporarily disables compression if the stream is made of noncompressable data -- and in the case of precompressed payload, that's pretty darned likely to be the case). (Hrm -- it'd be intelligent to still compress the non-payload info... I don't actually know if the code does that, but am now tempted to go take a look).
So yes, you make a point -- but even so, it's not as bad as it could be.
...so the minimum overhead for just doing the RTP+UDP+IP headers is several times the size of the voice traffic they carry, and IPSEC adds another two layers of headers, or SSL adds about three, and pretty soon that cute little elegant 8kbps compressed voice stream is looking like 40-80kbps and won't fit on your modem.
OpenVPN isn't IPsec, and while it uses the OpenSSL library for all the crypto "heavy lifting", it has its own over-the-wire protocol and is much more efficient than the traditional SSL way of doing things.
I use OpenVPN at work, and while I haven't done specific measurements, we've generally found it to be very efficient (not to mention easy-to-use and hassle-free compared to its IPsec-based competitors). Because in UDP mode it doesn't try to guarantee reliability, it also doesn't break protocols (like those used for VoIP data) that expect late packets to just be dropped.
So, in short, I'm not at all convinced that the use of OpenVPN is at all unfortunate or problematic here.
Back when I was in school I got a small (summer project) research grant for "Design and Implementation of a Secure Credit Card Replacement". The system it described was a small embedded device with a keypad (for entering both prices and PINs), a private key, a public identifier, a counter and a one-way hash mechanism.
The end result is that you'd tell it how much you wanted to pay and put in your PIN, and it's give back a string that could be given to the credit company to process a transaction -- but only for that exact amount, and only once. 'Twas an interesting project, but it would require a lot of hardware and software expendature to implement, and so was never likely to go anywhere in practice.
The nicotine isn't what makes secondhand smoke so dangerous.
And just out of curiosity, wouldn't the master file be really compressible?
Not really -- good hashes act random.
Heh.
Dunno 'bout that, though -- I respect the WSJ (even) more than the New York Times. (If your opinion differs I'd be curious to hear, in broad strokes, the reasoning behind it).
USA Today? Heard of it, but I don't recall ever actually reading a copy.
I received it, and I didn't request it. (I've never gotten any other "executive emails" from Microsoft, either).
Notably, the message contains a subscribe (no, not unsubscribe, subscribe) link. Doesn't seem to me much like something they'd send only to folks who are suscribers already.
Unless there is an official hand recount, most ballots are seen only once with no checks. It wouldn't be hard for someone to count a few votes incorrectly.
Yes, it would. Vote-counting happens with individuals supervising from both major parties. Contrary to what you imply, votes aren't counted by a single individual each with no oversight.
Further, many jurisdictions require recounts whenever a vote is closer than a given percentage -- so in cases where it really matters, votes will be seen more than once.
It wouldn't be that hard for a broken (or tampered with) computer to count a large number wrong, or one person systematicly count them incorrectly.
The former is a very real problem, but one that more traditional counting mechanisms don't have (or make easily traceable).
All your complaints about possible exploits only reenforce my belief that you have to be able to check your vote after it is counted.
If you continue to think that the system as it stands are inadequate, there's plenty of research that indicates how it ought to be done (while avoiding the pitfalls that concern me). See here.
Open Source code doesn't do you any good, if the CPU microcode has been tampered with. The whole machines should be open hardware, and a statistically significant number of them, randomly selected, should be taken apart before, during, and immediately after the elections to verify their hardware contents and software.
No -- ideally, you want away to avoid that being necessary. Letting the voter review the (physical paper) output from the machine means that they can guarantee that it's operating correctly; consequently, there's no need to do additional verification.
No comment on all the other (loony) miscellany in your post.
Okay, "next to unheard of" is a little overboard -- but in terms of percentage, market penetration is still low.
Much of the communication between insurance companies and billing companies, or practices and and billing companies is still done in paper. The entire system needs to be digitized before you can really say that paper has been removed from the system.
We're working on it.