Re:'Flaws' Not that big of a deal
on
Latest SP2 News
·
· Score: 2, Insightful
Yeah, these "flaws" are retarded. Telling people to open a command line and run a command with several arguments is much more complex than simply telling them "click yes on the security dialog to run the program". Clicking yes on dialog boxes is something users do all the time and don't think twice about. In fact, if Microsoft really wanted to make it difficult to run programs downloaded from the Internet, they could have *required* that users perform heise's procedure to run them. It would probably be more effective than a simple warning dialog.
And why didn't communists adapt, with their organization and central planning, when capitalism did adapt in an efficient and decentralized way? It's not happenstance or a mere coincidence, as you suggest. It's an inherent flaw in the communist system. Capitalism's decentralized system of incentives is inherently a better motivator and decision guide than communism's central planning.
In no way did communism fail.
Now you're just being pedantic. OK, how's this: almost every implementation of communism has failed to produce a lasting, prosperous nation. Wikipedia's list of 20th century communist states reads like a list of places not to live:
"The Soviet Union (and its satellite states Poland, East Germany, Hungary, Bulgaria, Czechoslovakia, Romania and Mongolia), the People's Republic of China, Albania, People's Democratic Republic of Yemen, Socialist Federal Republic of Yugoslavia, Cuba, Vietnam (and previously North Vietnam), Kampuchea (Cambodia), Laos and North Korea. For brief periods communist regimes existed in Afghanistan, Ethiopia, Angola, Mozambique and in other developing countries." Granted, China's doing alright now, but only by adopting a capitalist economic structure, and I still wouldn't want to live there.
Notice how I didn't say capitalism was fair? It's not. In fact I believe I said that incentives and fairness are mutually incompatible. Regardless, the existence of a few Paris Hiltons doesn't compromise capitalism's ability to provide incentives for the masses, who are the ones who doing the producing after all.
That's not the only reason socialism fails. People are more productive with incentives to encourage them, and capitalism results in many more incentives for the average person to be productive. (note that incentives are not necessarily rewards; negative consequences are incentives too...) Since incentives and equality are mutually exclusive, a socialist society dedicated to equality won't be as productive as a capitalist society, and it will fall behind.
That's why you slow the light pulse down slightly while you figure out what to do with it. You read the address portion, let the rest pass by into some sort of delay device (either a loop or a material wich actually slows the light), calculate how to switch the packet, then direct the light as it leaves the delay device. This adds a tiny bit of latency but the throughput can be the same as a straight piece of fiber.
Blazing high speeds encourage more content. If you could download a movie in five minutes, either the MPAA would have to get off their butts and release movies over the Internet or P2P movie swapping would go mainstream. Either way, more content. If you could host a medium-to-large sized website on your home connection, you could provide more content yourself. Your friends and family could provide more content for you to download (photo, audio, or video blogs instead of text blogs). As it becomes cheaper to host real websites over home connections, more small content projects like Red vs. Blue or Homestar Runner will be able to get started and thrive. The speeds come before the content, but the content does come.
You made me curious; here's a page I found with a semi-rigorous calculation of the largest body which has an escape velocity small enough for a human to actually jump completely off of it. (I was going to do the calculation myself, but then I found this page) Link
For those too lazy to read the link, the result is a meteor with a diameter of about 7 km would be required to increase the escape velocity enough that you couldn't jump off. This of course assumes a certain density for the meteor and also that you are an olympic high-jumper. Also, it assumes that you can apply the same jumping force on the meteor as on the earth, which probably isn't true as you couldn't get a good running start. But it's an interesting result nonetheless, and using your definition these "moons" probably wouldn't qualify. Certainly comfortable walking would be impossible.
Also, with using individual atoms for computing, whilst it would be nice, it's also impossible(?) - given that the more accurately you try to measure one property of an atom, the less accurately you can measure it's other properties. There's a name for this, but I can't remember.
It's the Heisenburg uncertainty principle, and it doesn't rule out computing with individual atoms. It just means that computing with individual atoms will work a lot differently than it does with normal, mostly deterministic electronics. The field of quantum computing is all about exploiting the weird quantum properties of atoms to do even more computation than would be possible if they were completely deterministic little point particles.
which works in exactly the same way as far as managing undos. Maybe "completely analogous" is a bit strong to describe this implementation, but it has all the same functionality and is just as elegant as far as I'm concerned. That array thing could also be done with reflection in the same way:
C# and Java provide "reflection" APIs for implementing things like this. It would be quite easy to create a class entirely analagous to NSUndoManager in either language (and without the reference counting cruft necessary because of Objective-C's lack of garbage collection...)
I won't defend C++ here, though. It could be done with function pointers but it wouldn't be pretty.
Doom 3 is different from every other 3D game out there in that you really just can't see a lot of stuff because it's too dark, and that's the way it's *supposed* to be. Other games might have one or two "use your flashlight here" areas that are completely pitch black, but during the rest of the game you won't need the flashlight at all. In Doom the flashlight is meant to be an integral part of the gameplay. It's even got its own button right next to the movement keys. Every single room has corners dark enough that you can't see into them without the flashlight. The game is *completely playable* at the default gamma setting, just more difficult because in the dark you have to choose between seeing (flashlight) or shooting. You have to learn to stick to the lit areas so that you can see the monsters when they come out to attack you. (*gasp* stategy?) If Id had made gamma an option, people would just turn it way up because in every other game they can always see everything. The dark really is dark, people, you can't see in it. Don't change the gamma.
Hm, actually I hadn't thought of that (guess your subtle hint wasn't enough, and the fact that you say "change" the UI when it is clearly being replaced). If Mozilla popped up a giant obnoxious security warning every time a page removed the menu/address/status bars, that would be an acceptable solution. Not because I think it would prevent these kinds of attacks entirely, but because I think it would discourage legitimate sites from removing the address bar (nobody wants a giant security warning on their legit site). Once legit sites stop doing it the capability can really be removed in a later version of Mozilla, fixing the problem. (This would require Microsoft getting on board too with IE, but I think with their new security focus all it would take is one high-profile scam using this technique.)
I see no reason to limit the flexibility of the the available tools simply because a few users are to stupid to pay attention to a dialog box.
I'll have to disagree with you there. That statement is a classic example of the "blame the user" attitude so prevalent in computer science. The problem is that it doesn't matter who's at fault; blaming the user won't get you anywhere, and users are never going to change ("read your dialog boxes" public service announcements won't help). Since you can't fix these types of problems by changing the users, you have to fix them by changing the software, even if the software isn't "at fault" by some definition of "fault". Otherwise the problems will never be fixed.
Besides, you're hardly limiting the flexibility of any tools here. The only "flexibility" you're losing is the flexibility to make smaller windows and annoy the user by removing his UI. Your web applications can be just as powerful as they were before. I've wished for years I could disable this myself.
Sure, a Mozilla based app can be a real application. But if you want it rendered without a browser UI, you can distribute a tiny executable that embeds Gecko, only displays your application, and doesn't even have browser chrome. That way you can also have access to local files and more stuff that Mozilla would never let you have because it's too much of a security risk to put in the browser. There is no reason to put blatant security holes into the browser just to allow it to embed desktop applications, which have no place in a BROWSER. Anyway, all current web applications would continue to work just fine if Mozilla didn't allow them to remove the browser UI from windows, so it's not a compatibility issue or anything. I have never understood why Mozilla offered this capability in the first place.
Your post was pointless because it didn't give a viable solution to the problem. "Simply fixing these issues prevents the problem"? I'm not sure you understand the issue. These pages aren't *changing* Mozilla's UI, they are *recreating* it in XUL or DHTML after they remove the real UI using Javascript. How do you suggest Mozilla tell whether a page is attempting to mimic its UI or not? It's impossible. The only way to fix the problem is to prevent removing the real UI in the first place.
DHTML can do everything XUL can do, it's just a bunch more work and the code is uglier. Therefore this is an IE bug as much as it is a Mozilla bug. It's actually a "bug" in just about *every* browser; it's just that the exploit is made easier by the availability of XUL (which there really is no excuse for, but that's beside the point). The ONLY real fix is to do as the grandparent post suggested and *always* display the real menu, button, status, and address bars. Anything less is still vulnerable to this type of exploit. There is NO GOOD REASON to turn them off, ever. If you are writing a web application that assumes the back button doesn't exist, you're writing it wrong. If your application really *needs* to show windows without forward/back buttons and menu/status bars and stuff, chances are your web application would be much more appropriate as a *real* application. Either that or you really don't *need* those features as much as you think. (hint: if "I don't like the way they look" or "they take up too much space" is your reason for removing the menu/address bars, you don't really *need* to remove them. Your users will thank you for leaving them.).
I left that part out because it's irrelevant to my point, which is it doesn't matter if you use stored procedures or not; there's no inherent speed advantage. That's all I was trying to convey.
the database has pre-optimized the query plan at compile-time and runtime execution is therefore much faster
This is a common misconception, but it is not true any more, at least for MS SQL Server. I quote from MSDN:
"SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement."
That's only true if there are more than one or two *per area*. In most places this is not the case, resulting in a monopoly or small oligopoly situation. Regulation can help by mandating that lines be shared to other companies at reasonable prices, but there are flaws with this approach, and it can hardly be called a free market solution.
Three orders of magnitude less than the $50 Sveasoft is charging, of course. Dang it, I knew someone would call me on that as soon as I hit submit and read that sentence. Next time I will enumerate every single hidden assumption in my post so that nobody can get the wrong idea about anything, OK?
Skpye works because it is one peer to one peer. Streaming video works OK too in this environment (at least I hear that iChat AV does it well). I'm talking about real Internet TV, just like broadcast TV with the same scalability. One source (with upload bandwidth just a little more than required for one stream), millions of listeners, all in real-time. Since the source and most of the peers can only send out one or two streams at a time (and some won't even have the bandwidth for one, not to mention congestion problems in between hosts), there will need to be a *lot* of peers involved in distribution; probably around 50%. Any time one of them leaves the channel, the peers behind it will see a hiccup in the stream. Important peers leaving would result in intermittent service interruptions for large numbers of people watching the broadcast. Large amounts of peer turnover would make the stream completely unwatchable. Plus after you add in four or five hops backwards and forwards across the entire Internet you can forget about real time.
Like most Internet problems it can be solved by simply adding more bandwidth, but you're going to need more than 512 kbps per peer to broadcast TV-quality video reliably using a P2P method. You need more than that just for one stream. (I've seen Winamp TV broadcasts at 800 kbps; the compression artifacts were still quite obvious). You need each peer to be able to distribute at least two streams on average so you can get a nice tree going, and for redundancy in case of peers leaving the network three or four would be much better. I would estimate 5-10 Mbps per peer of upload bandwidth would be necessary for a workable, reliable P2P TV system. I doubt that kind of upload bandwidth will be widespread 10 years from now, especially outside of major urban areas. And the network backbones would have to be able to handle all of that traffic, which would be at least an order of magnitude larger than the same system using multicast. Would having to switch an order of magnitude less packets help some when implementing multicast?
Doesn't matter how you impose a restriction, or whether the restrictees agree to be restricted. No matter how you slice it, a restriction is being applied. The GPL doesn't say "you can restrict people if they agree to the restrictions", it says you may not restrict them.
They are imposing restrictions on the license they provide subscription services under
... but these restrictions, by their nature, provide a significant disincentive to redistributing the software, which amounts to a restriction on distributing the software as well according to my argument. The argument's strength really rests on the severity of the disincentive. If a company really has leverage over their customer, the disincentive could be quite strong and the restriction would be obvious in this case. Imagine IBM: "Here's an agreement that we won't sue you over any patents we own, but if you distribute our GPL'd software the agreement is ended." Then if the customer distributes the software, IBM Legal steamrollers over them and they are driven into the ground. I think there is a good argument for this being a restriction on distribution of the software. For Sveasoft though, the most they can do is refuse to do business with the customer again. Personally, I think this should be enough to carry the argument, obviously you do not. Now it's for the lawyers to decide.
Regardless of the legal technicalities, Sveasoft's behavior goes squarely against the core of the spirit of the GPL. That spirit is, basically, "if you are using a piece of software, you should be able to make and distribute unmodified or modified copies with no restrictions except those necessary to ensure that you do not take these rights from others". Though a judge might rule that what Sveasoft is doing isn't "restricting" in the specific sense from one specific sentence in the GPL, I sure would feel restricted if I was one of Sveasoft's customers right now.
I may suggest to the FSF that the wording of the sentence in question be changed to:
You may not impose any further restrictions or terms conditioned on the recipients' exercise of the rights granted herein.
Since Sveasoft is inarguably imposing "terms" on their customers conditioned on their exercise of the rights given to them by the GPL, this situation would be completely covered.
The difference is small and immaterial when it comes to violation of the sentence "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Sveasoft's intent in adding these terms to their contract is obviously to attempt to restrict distribution in some way. If their terms actually do succeed in deterring somebody from distributing the software, then they are acting as a restriction on that person's GPL-granted right to redistribute the software. In fact, merely applying the terms with the *intent* to restrict distribution, even if no restriction results, might be considered enough to damn Sveasoft in this case.
Once again, it's up to the legal system to decide these kinds of disputes; however I believe Sveasoft is obviously on the wrong side of the GPL here. They simply cannot attempt to restrict distribution, even if the method is circuitous.
If Sveasoft was party to this agreement, then it is they who are violating the GPL by distributing the software to their customers, not the customers violating it by redistributing it later. Since it is Sveasoft's restrictions that are preventing customers from redistributing, Sveasoft runs afoul of the clause that says you may not restrict redistribution, and the violation occurs at that point. The customers actually aren't violating section 7 because nobody is restricting their ability to give other people the right to redistribute. If they distribute they are only violating Sveasoft's (questionable) subscription agreement, which doesn't nullify the rights they have already gotten under the GPL or prevent them giving those rights to others.
Slashdot Mirror
Yeah, these "flaws" are retarded. Telling people to open a command line and run a command with several arguments is much more complex than simply telling them "click yes on the security dialog to run the program". Clicking yes on dialog boxes is something users do all the time and don't think twice about. In fact, if Microsoft really wanted to make it difficult to run programs downloaded from the Internet, they could have *required* that users perform heise's procedure to run them. It would probably be more effective than a simple warning dialog.
In no way did communism fail.
Now you're just being pedantic. OK, how's this: almost every implementation of communism has failed to produce a lasting, prosperous nation. Wikipedia's list of 20th century communist states reads like a list of places not to live: "The Soviet Union (and its satellite states Poland, East Germany, Hungary, Bulgaria, Czechoslovakia, Romania and Mongolia), the People's Republic of China, Albania, People's Democratic Republic of Yemen, Socialist Federal Republic of Yugoslavia, Cuba, Vietnam (and previously North Vietnam), Kampuchea (Cambodia), Laos and North Korea. For brief periods communist regimes existed in Afghanistan, Ethiopia, Angola, Mozambique and in other developing countries." Granted, China's doing alright now, but only by adopting a capitalist economic structure, and I still wouldn't want to live there.
Notice how I didn't say capitalism was fair? It's not. In fact I believe I said that incentives and fairness are mutually incompatible. Regardless, the existence of a few Paris Hiltons doesn't compromise capitalism's ability to provide incentives for the masses, who are the ones who doing the producing after all.
That's not the only reason socialism fails. People are more productive with incentives to encourage them, and capitalism results in many more incentives for the average person to be productive. (note that incentives are not necessarily rewards; negative consequences are incentives too...) Since incentives and equality are mutually exclusive, a socialist society dedicated to equality won't be as productive as a capitalist society, and it will fall behind.
That's why you slow the light pulse down slightly while you figure out what to do with it. You read the address portion, let the rest pass by into some sort of delay device (either a loop or a material wich actually slows the light), calculate how to switch the packet, then direct the light as it leaves the delay device. This adds a tiny bit of latency but the throughput can be the same as a straight piece of fiber.
Blazing high speeds encourage more content. If you could download a movie in five minutes, either the MPAA would have to get off their butts and release movies over the Internet or P2P movie swapping would go mainstream. Either way, more content. If you could host a medium-to-large sized website on your home connection, you could provide more content yourself. Your friends and family could provide more content for you to download (photo, audio, or video blogs instead of text blogs). As it becomes cheaper to host real websites over home connections, more small content projects like Red vs. Blue or Homestar Runner will be able to get started and thrive. The speeds come before the content, but the content does come.
For those too lazy to read the link, the result is a meteor with a diameter of about 7 km would be required to increase the escape velocity enough that you couldn't jump off. This of course assumes a certain density for the meteor and also that you are an olympic high-jumper. Also, it assumes that you can apply the same jumping force on the meteor as on the earth, which probably isn't true as you couldn't get a good running start. But it's an interesting result nonetheless, and using your definition these "moons" probably wouldn't qualify. Certainly comfortable walking would be impossible.
It's the Heisenburg uncertainty principle, and it doesn't rule out computing with individual atoms. It just means that computing with individual atoms will work a lot differently than it does with normal, mostly deterministic electronics. The field of quantum computing is all about exploiting the weird quantum properties of atoms to do even more computation than would be possible if they were completely deterministic little point particles.
I won't defend C++ here, though. It could be done with function pointers but it wouldn't be pretty.
KDE now provides a "Kiosk mode" that is designed to make this kind of locked-down desktop easy to achieve on any distribution with KDE. Here's a recent article on the subject, and here's the project homepage, and here's the KDE guide for sysadmins, which has lots of information useful to KDE server admins.
Doom 3 is different from every other 3D game out there in that you really just can't see a lot of stuff because it's too dark, and that's the way it's *supposed* to be. Other games might have one or two "use your flashlight here" areas that are completely pitch black, but during the rest of the game you won't need the flashlight at all. In Doom the flashlight is meant to be an integral part of the gameplay. It's even got its own button right next to the movement keys. Every single room has corners dark enough that you can't see into them without the flashlight. The game is *completely playable* at the default gamma setting, just more difficult because in the dark you have to choose between seeing (flashlight) or shooting. You have to learn to stick to the lit areas so that you can see the monsters when they come out to attack you. (*gasp* stategy?) If Id had made gamma an option, people would just turn it way up because in every other game they can always see everything. The dark really is dark, people, you can't see in it. Don't change the gamma.
I see no reason to limit the flexibility of the the available tools simply because a few users are to stupid to pay attention to a dialog box.
I'll have to disagree with you there. That statement is a classic example of the "blame the user" attitude so prevalent in computer science. The problem is that it doesn't matter who's at fault; blaming the user won't get you anywhere, and users are never going to change ("read your dialog boxes" public service announcements won't help). Since you can't fix these types of problems by changing the users, you have to fix them by changing the software, even if the software isn't "at fault" by some definition of "fault". Otherwise the problems will never be fixed.
Besides, you're hardly limiting the flexibility of any tools here. The only "flexibility" you're losing is the flexibility to make smaller windows and annoy the user by removing his UI. Your web applications can be just as powerful as they were before. I've wished for years I could disable this myself.
Your post was pointless because it didn't give a viable solution to the problem. "Simply fixing these issues prevents the problem"? I'm not sure you understand the issue. These pages aren't *changing* Mozilla's UI, they are *recreating* it in XUL or DHTML after they remove the real UI using Javascript. How do you suggest Mozilla tell whether a page is attempting to mimic its UI or not? It's impossible. The only way to fix the problem is to prevent removing the real UI in the first place.
DHTML can do everything XUL can do, it's just a bunch more work and the code is uglier. Therefore this is an IE bug as much as it is a Mozilla bug. It's actually a "bug" in just about *every* browser; it's just that the exploit is made easier by the availability of XUL (which there really is no excuse for, but that's beside the point). The ONLY real fix is to do as the grandparent post suggested and *always* display the real menu, button, status, and address bars. Anything less is still vulnerable to this type of exploit. There is NO GOOD REASON to turn them off, ever. If you are writing a web application that assumes the back button doesn't exist, you're writing it wrong. If your application really *needs* to show windows without forward/back buttons and menu/status bars and stuff, chances are your web application would be much more appropriate as a *real* application. Either that or you really don't *need* those features as much as you think. (hint: if "I don't like the way they look" or "they take up too much space" is your reason for removing the menu/address bars, you don't really *need* to remove them. Your users will thank you for leaving them.).
I left that part out because it's irrelevant to my point, which is it doesn't matter if you use stored procedures or not; there's no inherent speed advantage. That's all I was trying to convey.
This is a common misconception, but it is not true any more, at least for MS SQL Server. I quote from MSDN:
"SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement."
That's only true if there are more than one or two *per area*. In most places this is not the case, resulting in a monopoly or small oligopoly situation. Regulation can help by mandating that lines be shared to other companies at reasonable prices, but there are flaws with this approach, and it can hardly be called a free market solution.
I saw a Linux PC at Fry's Electronics the other day. Lindows, actually. It had crashed :-/
I disagree. I'll just put a pointer here to http://slashdot.org/comments.pl?sid=115310&thresho ld=-1&commentsort=3&tid=193&mode=thread&cid=976722 5 .
Three orders of magnitude less than the $50 Sveasoft is charging, of course. Dang it, I knew someone would call me on that as soon as I hit submit and read that sentence. Next time I will enumerate every single hidden assumption in my post so that nobody can get the wrong idea about anything, OK?
Like most Internet problems it can be solved by simply adding more bandwidth, but you're going to need more than 512 kbps per peer to broadcast TV-quality video reliably using a P2P method. You need more than that just for one stream. (I've seen Winamp TV broadcasts at 800 kbps; the compression artifacts were still quite obvious). You need each peer to be able to distribute at least two streams on average so you can get a nice tree going, and for redundancy in case of peers leaving the network three or four would be much better. I would estimate 5-10 Mbps per peer of upload bandwidth would be necessary for a workable, reliable P2P TV system. I doubt that kind of upload bandwidth will be widespread 10 years from now, especially outside of major urban areas. And the network backbones would have to be able to handle all of that traffic, which would be at least an order of magnitude larger than the same system using multicast. Would having to switch an order of magnitude less packets help some when implementing multicast?
They are imposing restrictions on the license they provide subscription services under
Regardless of the legal technicalities, Sveasoft's behavior goes squarely against the core of the spirit of the GPL. That spirit is, basically, "if you are using a piece of software, you should be able to make and distribute unmodified or modified copies with no restrictions except those necessary to ensure that you do not take these rights from others". Though a judge might rule that what Sveasoft is doing isn't "restricting" in the specific sense from one specific sentence in the GPL, I sure would feel restricted if I was one of Sveasoft's customers right now.
I may suggest to the FSF that the wording of the sentence in question be changed to:
You may not impose any further restrictions or terms conditioned on the recipients' exercise of the rights granted herein.
Since Sveasoft is inarguably imposing "terms" on their customers conditioned on their exercise of the rights given to them by the GPL, this situation would be completely covered.
Once again, it's up to the legal system to decide these kinds of disputes; however I believe Sveasoft is obviously on the wrong side of the GPL here. They simply cannot attempt to restrict distribution, even if the method is circuitous.
Yeah. It's making my ass numb.
LOL. Philosophy does tend to have that effect ;-)