Some people use the word "coercion" rather than force in this context to avoid this sort of pedantic ear-wibbling. You are correct, of course, a "free" market is no such thing for the lower layers of it.
I wonder if there's be as much support if they were shutting down sites that sell radar detectors. There's no legitimate purpose to have one of these, they're explicitly sold and advertised as devices to allow you to speed without getting a ticket, they're illegal in many places, but we don't have special laws about "contributory speeding", so nothing is involved.
Note: I think that shutting down tracker sites is perfectly reasonable, assuming that they actually are hosting torrents for illegal stuff and not just torrents in general. I just get annoyed by all the special legislation that gets thrown at copyright.
"PostgreSQL handles virtually all the standard SQL constructs. It is easy (relatively speaking) to administer, it is fast, it is efficient, it has a great API, and it supports ODBC, why would you choose something else?"
Mark Woodward, Mohawk Software
"Virtuall all"? "Relatively speaking"? I think Postgre is great, but they need to get better stuff than this on thier front page.
I have to agree with the stupid whiny thing, but on the other hand, it's not like it's well known what you have to do as far as release forms goes for crowd footage. And if the crowd footage happens to be of very young college girls with thier tops off, then anyone with half a brain should realize they need to go the extra mile to make 100% certain than they aren't shipping anything with underage girls in it. If she was an out of focus background character cause she streaked by while they were filming someone else, that'd be a different story.
Yes. Free as in Beer is what Oracle is right now. Go ahead, go download it. It's free. (Note that you can't deploy it or do anything else interesting without paying money). Free as in speech is what this guy wants because he wants to modify and absorb and grow what Oracle does, mixing it with other databases to get the best solution for him. This is what the sharing of ideas and concepts (and yes, code) is all about.
MySQL absolutely cannot compete in the market where Oracle shines. However, Oracle is used in a lot of places you don't need it. On the other hand, once you've spent a million dollars on an Oracle installation you may as well use it for everything.
Disclaimer: I'm a MySQL hater and wouldn't recommend it in any circumstance. Postgresql on the other hand is fantastic and should get a lot more love than it does. It still can't compare to Oracle in the huge installations, but it can certainly replace Oracle in all sorts of common usage.
There have been an enormous number of exploits for PHP. Granted, they are (generally) rapidly fixed, but then, so were sendmails. It's got an extremely unimpressive security record for a product where (at least) baseline security is enormously important. In addition to that, PHP's design and style encourages the use of unsafe constructs (this is much the same argument used against C, but C's tricks are generally well known and there's effective workarounds for them, PHP less so). It's not 100% fair to blame PHP for bad apps but it's design does encourage that sort of usage and I have to smack them for that. It's really easy to write horribly insecure web applications and it'd be nice if you could trust PHP to take care of the most obvious problems and discourage the obvious holes that it can't plug, like sql injection. How many holes have come because of problems with the functionality or use of PHPs stupid magic quotes?
PCRE can be used in a threadsafe manner, as can most of the other libraries you mentioned. If PHP doesn't do it, that's fine, but it's a PHP issue.
From the point of view of the kind of person who makes billions of dollars, that's losing. BillG has far more money than he needs. It's likely that nobody in his immediate family will need to work for a living for at least several generations. Many other MS execs also have inane amounts of wealth. But just shrugging and saying "screw you, we've got all the money we need" isn't something that's in thier character. If it were, they'd have already taken thier cash and gone home.
Of course, this sort of decision wouldn't be up to one person in a publicly traded company like MS anyway. If they did do it, they would very likely be nailed with a nasty shareholder suit and they could well lose a lot of those billions.
It's not that hard to switch, especially if you don't have any other choice. Taking the hardass stance of "you can't tell us what to do because we own you" would be the WORST thing MS can do. There are viable alternatives, they're just less attractive because of the effort MS puts into suppressing them. The linux desktop may not (and this is subjective, of course) compare with WinXP yet but it beats the hell out of Win NT and Win 95 and people used those happily for years. Microsoft would lose the entire European market, would face signifigant pressure from US based companies with EU presences and would generally get a bad mark for making itself look like an ass in front of the whole world. I'm sure in his pissier moments Bill has considered it. I'm equally sure that he knows he'd lose hardcore if he did.
I'm not really familiar with the Perl or Ruby interperters, but the Python interperter is fully threadsafe, including it's usage of all the libraries it links against. Arbitrary C extensions may not be, but all the standard ones are.
What PHP is doing is NOT taking the extra step and instead throwing up thier hands and saying that they don't know if PHP is threadsafe, they aren't sure if they only use threadsafe libraries or use them in a threadsafe manner, and they don't feel like finding out, so don't use PHP in a threaded environment unless you're prepared to deal with problems. This is reasonable, because thread safety is hard and you shouldn't make guarantees about it unless you know what you're doing. But get it out of your head that this is some sort of proof of security consciousness on behalf of PHP. Honestly, considering PHPs desperate race to defeat sendmail as the king of all exploitable applications, I'm not really prepared to take ANY security statements from them seriously
I also think it'd be nice of them to clarify WHY you shouldn't use Apache 2.0 with PHP ("Because PHP isn't designed to be used in a threaded environment and we aren't prepared to make guarantees about it's behavior under those circumstances") rather than a dismissive comment that makes it sound like a failing of Apache, which it is not.
One of the things every EULA I've ever seen includes is a clause allowing them to change the terms. I can't imagine this would hold in court but who the hell knows.
My dream of the "perfect" software economy: No EULAs. If you want to license, rather than sell your software, you have to do it that - there's an up front presentation of the contract (which is no longer an EULA, it's a contract for services), which both parties must sign in a legally binding way, BEFORE money changes hands. It's the responsibility of the seller to ensure that everything is taken care of properly - unlike the way this case presents it, where the purchaser has to go out of thier way to find out what rights they're giving up. Software sold as a retail product is covered only by copyright law, same as movies and CDs. I would bet a fair amount of money that this would have almost exactly zero effect on the economics of selling software.
EULAs for a service, like internet access and MMORPGs are of course reasonable, but they must be a) also presented at the time of purchase and b) the agreed upon version is the binding one (no changes allowed) until the next billing date. If you pre-pay for a year of service, the agreement you signed is the only valid one for that year. At the end of the year, if they want to change the terms, they must present you with the new terms, which you may accept or reject as you will.
This isn't perfect, of course, but in my mind it's a really reasonable compromise between the needs of software/service vendors and the rights of consumers.
Of course you can't know if there were ones you didn't notice. I didn't claim there weren't any. However, the fact that this one was noticed is a validation of the system. I can tell you this - if a similiar attack had occured at most of the closed source places I've worked, it most likely would not have been caught. I believe this would be true in the majority of closed source shops, with some exceptions for really paranoid people making really paranoid software. Note that a lot of people making the software you think should be paranoid turn out to not be, ie Diebold.
It's important to remember that none of these things happened BECAUSE of open source - illicit penetration like this can and does happen to closed source as well, as well as all sorts of accidents (for example, MS shipped a whole slew of visual studio CDs with a virus burned on them). People are often scared of transparency, because they don't want to hear about the problems. A little bit of education can help this.
It happened with Linux (the kernel itself). A security exploit was entered. It's worth pointing out, however, that this exploit never made it into any kernel release or build, as it was noticed practically instantly by Linus and others and immediate steps taken. The only reason we know about it at all is because of the open development process.
I'm a die-hard Java hater but I have to say that a web server is actually one of the few applications that Java can actually perform really, really well at. Java in client applications makes my skin itch, though.
This is not native widget support. It's native THEME support, which is a different animal. It's too bad, there's been some talk about using native widgets (via wxWidgets, for example), but the OO people don't seem interested.
An impressive engineering, technical, and economic feat, but not one that really impacts science. It's not about the coolest applications of science, but rather about the coolest discoveries in science.
There haven't been any technical details yet, but the gist of SCOs argument seems to be that it wasn't actually an anonymous ftp server and that a password was supposed to be required for access (this having been set up for SCOs existing linux customers, but not for the general public). I didn't really follow the details of what and how SCO was hosting Linux at the time when everyone cared, so I don't know exactly when they moved everything into it's private areas (I don't believe anything is publically accessible now?), but it seems crazy for them to claim otherwise if it wasn't really protected. I guess they may be trying for a "your word against ours" argument, but that seems extreme, even for them.
The other possibility is that they're going to claim that IBM needed explicit permission to access a resource that was publically posted and anonymously available, which doesn't seem supported by current case law. Now that I think about SCOs more recent filings, an extreme interpertation of law that's not actually supported by a reading of either the law or previous cases seems to be right up thier alley;)
Remote is exactly *wrong* for this exploit, because it cannot be exploited remotely. Trojanning is a technique that can (sometimes) be used to escalate a local exploit to a remote one. As another poster mentioned, by that definition every exploit is remote, even things that aren't exploits - if I email a binary to you with instructions to run it as root, is that really a remote exploit?
Your concern about exposure if valid, but I don't see how it relates to the fact that this particular exploit is *incorrectly* termed remote. The only way to leverage this exploit is to compromise (via trojan, or by exploiting a real remote vulnerability, or any other way you can think of) an already existing local account.
I just tried it with IE 6, XP SP1, and I couldn't recreate the vulnerability. I have IE set to ask before running ActiveX controls, and although I said "yes", the exploit failed to work - I got a new window with the paypal address, but real paypal content. The secunia window popped up an "Access Denied" javascript error.
You missed the important part, which is "remote". Yes, it's a bug. Yes, the bug exposes a security risk. No, it's not a remote exploit. You can't (reasonably) execute it without already having legitimate (or at least seemingly legitimate, say by exploiting a REAL remote vulnerability) access. A remote vulnerability is one that you can induce without regular access - in practical terms they're generally limited to bugs in outward-facing services, or in very low level components like the TCP stack. A local exploit is one that can only be exploited from within, once you have nominally legit access. If there's no SSH or other remote shell, for example, a local exploit would require you to physically be at the machine.
The 9 years he got is a lot more than the typical sentence for most white collar crime, like stock fraud. Or even what the Enron guys got, for that matter. It's also more than the average sentence for most violent crime.
Judgement calls about what's "worse" are always hard to make and generally suspect, but giving him a ton more jail time just because he used a computer is stupid. Whether that means we should up sentences for everything more, or whether we should drop his is really a judgement call. But it's got to be one or the other, cause as it is something is seriously twisted.
Re:Actually, it's an ARM7
on
A .Net CPU
·
· Score: 1
Maybe it's 450,000.NET opcodes per second. 60 instructions per opcode would be pretty good, actually.
Slashdot Mirror
Some people use the word "coercion" rather than force in this context to avoid this sort of pedantic ear-wibbling. You are correct, of course, a "free" market is no such thing for the lower layers of it.
Note: I think that shutting down tracker sites is perfectly reasonable, assuming that they actually are hosting torrents for illegal stuff and not just torrents in general. I just get annoyed by all the special legislation that gets thrown at copyright.
"PostgreSQL handles virtually all the standard SQL constructs. It is easy (relatively speaking) to administer, it is fast, it is efficient, it has a great API, and it supports ODBC, why would you choose something else?"
Mark Woodward, Mohawk Software "Virtuall all"? "Relatively speaking"? I think Postgre is great, but they need to get better stuff than this on thier front page.
I have to agree with the stupid whiny thing, but on the other hand, it's not like it's well known what you have to do as far as release forms goes for crowd footage. And if the crowd footage happens to be of very young college girls with thier tops off, then anyone with half a brain should realize they need to go the extra mile to make 100% certain than they aren't shipping anything with underage girls in it. If she was an out of focus background character cause she streaked by while they were filming someone else, that'd be a different story.
Yes. Free as in Beer is what Oracle is right now. Go ahead, go download it. It's free. (Note that you can't deploy it or do anything else interesting without paying money). Free as in speech is what this guy wants because he wants to modify and absorb and grow what Oracle does, mixing it with other databases to get the best solution for him. This is what the sharing of ideas and concepts (and yes, code) is all about.
Disclaimer: I'm a MySQL hater and wouldn't recommend it in any circumstance. Postgresql on the other hand is fantastic and should get a lot more love than it does. It still can't compare to Oracle in the huge installations, but it can certainly replace Oracle in all sorts of common usage.
I had a cellphone once that would crash regularly. Some crappy samsung thing, I think. Drove me batty.
PCRE can be used in a threadsafe manner, as can most of the other libraries you mentioned. If PHP doesn't do it, that's fine, but it's a PHP issue.
GDI+ is the System.Drawing namespace, which is implemented in Mono. It may not be feature complete.
Of course, this sort of decision wouldn't be up to one person in a publicly traded company like MS anyway. If they did do it, they would very likely be nailed with a nasty shareholder suit and they could well lose a lot of those billions.
It's not that hard to switch, especially if you don't have any other choice. Taking the hardass stance of "you can't tell us what to do because we own you" would be the WORST thing MS can do. There are viable alternatives, they're just less attractive because of the effort MS puts into suppressing them. The linux desktop may not (and this is subjective, of course) compare with WinXP yet but it beats the hell out of Win NT and Win 95 and people used those happily for years. Microsoft would lose the entire European market, would face signifigant pressure from US based companies with EU presences and would generally get a bad mark for making itself look like an ass in front of the whole world. I'm sure in his pissier moments Bill has considered it. I'm equally sure that he knows he'd lose hardcore if he did.
What PHP is doing is NOT taking the extra step and instead throwing up thier hands and saying that they don't know if PHP is threadsafe, they aren't sure if they only use threadsafe libraries or use them in a threadsafe manner, and they don't feel like finding out, so don't use PHP in a threaded environment unless you're prepared to deal with problems. This is reasonable, because thread safety is hard and you shouldn't make guarantees about it unless you know what you're doing. But get it out of your head that this is some sort of proof of security consciousness on behalf of PHP. Honestly, considering PHPs desperate race to defeat sendmail as the king of all exploitable applications, I'm not really prepared to take ANY security statements from them seriously
I also think it'd be nice of them to clarify WHY you shouldn't use Apache 2.0 with PHP ("Because PHP isn't designed to be used in a threaded environment and we aren't prepared to make guarantees about it's behavior under those circumstances") rather than a dismissive comment that makes it sound like a failing of Apache, which it is not.
My dream of the "perfect" software economy:
No EULAs. If you want to license, rather than sell your software, you have to do it that - there's an up front presentation of the contract (which is no longer an EULA, it's a contract for services), which both parties must sign in a legally binding way, BEFORE money changes hands. It's the responsibility of the seller to ensure that everything is taken care of properly - unlike the way this case presents it, where the purchaser has to go out of thier way to find out what rights they're giving up. Software sold as a retail product is covered only by copyright law, same as movies and CDs. I would bet a fair amount of money that this would have almost exactly zero effect on the economics of selling software.
EULAs for a service, like internet access and MMORPGs are of course reasonable, but they must be a) also presented at the time of purchase and b) the agreed upon version is the binding one (no changes allowed) until the next billing date. If you pre-pay for a year of service, the agreement you signed is the only valid one for that year. At the end of the year, if they want to change the terms, they must present you with the new terms, which you may accept or reject as you will.
This isn't perfect, of course, but in my mind it's a really reasonable compromise between the needs of software/service vendors and the rights of consumers.
Of course you can't know if there were ones you didn't notice. I didn't claim there weren't any. However, the fact that this one was noticed is a validation of the system. I can tell you this - if a similiar attack had occured at most of the closed source places I've worked, it most likely would not have been caught. I believe this would be true in the majority of closed source shops, with some exceptions for really paranoid people making really paranoid software. Note that a lot of people making the software you think should be paranoid turn out to not be, ie Diebold.
It's important to remember that none of these things happened BECAUSE of open source - illicit penetration like this can and does happen to closed source as well, as well as all sorts of accidents (for example, MS shipped a whole slew of visual studio CDs with a virus burned on them). People are often scared of transparency, because they don't want to hear about the problems. A little bit of education can help this.
It happened with Linux (the kernel itself). A security exploit was entered. It's worth pointing out, however, that this exploit never made it into any kernel release or build, as it was noticed practically instantly by Linus and others and immediate steps taken. The only reason we know about it at all is because of the open development process.
I'm a die-hard Java hater but I have to say that a web server is actually one of the few applications that Java can actually perform really, really well at. Java in client applications makes my skin itch, though.
This is not native widget support. It's native THEME support, which is a different animal. It's too bad, there's been some talk about using native widgets (via wxWidgets, for example), but the OO people don't seem interested.
An impressive engineering, technical, and economic feat, but not one that really impacts science. It's not about the coolest applications of science, but rather about the coolest discoveries in science.
The other possibility is that they're going to claim that IBM needed explicit permission to access a resource that was publically posted and anonymously available, which doesn't seem supported by current case law. Now that I think about SCOs more recent filings, an extreme interpertation of law that's not actually supported by a reading of either the law or previous cases seems to be right up thier alley
Your concern about exposure if valid, but I don't see how it relates to the fact that this particular exploit is *incorrectly* termed remote. The only way to leverage this exploit is to compromise (via trojan, or by exploiting a real remote vulnerability, or any other way you can think of) an already existing local account.
I just tried it with IE 6, XP SP1, and I couldn't recreate the vulnerability. I have IE set to ask before running ActiveX controls, and although I said "yes", the exploit failed to work - I got a new window with the paypal address, but real paypal content. The secunia window popped up an "Access Denied" javascript error.
You missed the important part, which is "remote". Yes, it's a bug. Yes, the bug exposes a security risk. No, it's not a remote exploit. You can't (reasonably) execute it without already having legitimate (or at least seemingly legitimate, say by exploiting a REAL remote vulnerability) access. A remote vulnerability is one that you can induce without regular access - in practical terms they're generally limited to bugs in outward-facing services, or in very low level components like the TCP stack. A local exploit is one that can only be exploited from within, once you have nominally legit access. If there's no SSH or other remote shell, for example, a local exploit would require you to physically be at the machine.
Judgement calls about what's "worse" are always hard to make and generally suspect, but giving him a ton more jail time just because he used a computer is stupid. Whether that means we should up sentences for everything more, or whether we should drop his is really a judgement call. But it's got to be one or the other, cause as it is something is seriously twisted.
Maybe it's 450,000 .NET opcodes per second. 60 instructions per opcode would be pretty good, actually.