If you get an email address from them, you agree to their policy, which is to delete email accounts that haven't been accessed in a while. The grace period is longer at other providers, but it is still a very common type of rule, simply because users never bother to remove old accounts. They would just pile up if there was no rule in place to delete accounts after some inactivity. In fact, I find it comforting that Lycos actually deletes email and doesn't keep it around forever. If I were offered the choice of two types of accounts, one which can not ever be deleted and one which expires after a month, I'd take the latter.
No, you're trying to squeeze something that isn't a hierarchy into a hierarchy. The domain name system is based on the concept of administrative domains and delegation of subdomains. The keyword is "administrative". The domains are not meant to describe functions or real world concepts because these are rarely hierarchical.
Look, it took you three tries to even understand what is being attacked. Don't you think YOU need to take a step back and think about what one could do with this in a Web 2.0 environment? I mean, the paper actually hints at the chain of events which becomes possible by being able to craft requests to a third party domain from within the user's browser. You just have to read and understand it.
In fact I have tested it. It works as advertised, but apparently you don't understand the problem. Of course that doesn't stop you from deriding a correct and concise summary.
Before you embarass yourself any further, please do read the paper and try for yourself if a script can sniff the communication of a script from a different domain (which runs on the same page) and also intercept the communication and thereby talk to the domain of the other script from which it would normally be forbidden by security rules. For the sake of this argument, the malicious script gets to run first, because that is in line with the attack vectors which are described in the rest of the paper.
No, Greasemonkey exposed security sensitive functions to websites. They were meant to be used by Greasemonkey scripts but websites had access too.
This is about the way Javascript implements object oriented programming: In Javascript you don't define classes from which objects are instantiated. In a nutshell, you create prototype objects and new objects are copies of the prototypes. The "attack" is to change existing prototypes. For example, you can add a new function to the String prototype or replace an existing function with your own implementation. Every String object then gets the new function. There is one problem with this: Cross site checks don't apply. A script from one site can't simply communicate with another site, but it can modify the prototypes that the scripts from the other site use and subvert the communication of the other script with its host.
It doesn't make a difference, at least not for one-pass overwriting. Since the last (only) pass is normally readable, you know the pattern that you need to eliminate to get to the residual magnetic information. That's all theory though. I'm still waiting for someone to tell harddisk manufacturers how they can double the capacity of their products by allowing access to information which has been written over once.
Anything beyond dd if=/dev/zero of=/dev/hdx is a sign of mild paranoia. No commercial recovery service claims to be able to recover overwritten data. They would certainly advertise that capability, don't you think? These guys have clean rooms, create images of the raw magnetization of the platters and restore the data from these images. If you're up against more sophisticated technology than that, there are far easier ways to get your data.
it's unlikely that anything can be recovered from any recent drive except perhaps one or two levels via basic error-cancelling techniques. In particular the the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.
So, not only does he think that the chances of recovering data are pretty slim, it also looks like he hasn't actually tried to recover some data from a recent drive. That is from a person who spent way too much time on figuring out how to erase data logically when it would be much more secure and foolproof (probably cheaper too) to simply melt the drive if your data is that big a secret. IOW, if you are a double-0 agent, you shouldn't have written unencrypted data to the drive in the first place and you should never let the undamaged platters leave the building. For the rest of us, dd if=/dev/zero of=/dev/hdx will suffice.
Technically you're right: JSON is not limited to Javascript, even though the acronym means "JavaScript Object Notation". However, since JSON messages are by definition valid Javascript object definitions, it's not surprising that it's mostly used in the way GMail uses it: The page loads and executes scripts to move data from the server into the application on the client. This typical way of using JSON is prone to be exploited in the described fashion, unless the programmer has implemented additional security.
The problem is that the user has the cookie because he's logged into GMail (in a different window or tab, or he forgot to log out). The cookie which is sent with the request for the script is from the domain of the web app that the script is part of, not from the attacking website. One way to deal with this type of vulnerability is to check the HTTP referrer header, but since many users disable the referrer (mostly for privacy reasons), such a check would either not protect these users or prevent them from using the application. In essence, the website requesting the information would have to send something with the request that a third party can't know and can't cause another entity to add to the request (like the cookie). This means that the programmer has to take an extra precaution beyond implementing the functionality in a robust fashion, hence my assumption that many applications are similarly vulnerable.
Loading script files to exchange data with the server is a very common mechanism. It even has a name: JSON. It wouldn't surprise me to find that there are many more web applications which could be exploited in this way. This isn't a browser vulnerability or a simple bug. It is a design flaw of a widely used communication protocol.
Wouldn't all this be solved by encrypted online voting, where you could check your own votes by a profile tied to an anonymous registration key issued by the DMV?
The problem with most "verified" voting mechanisms is that they allow voters to prove a vote for a certain party, which in turn makes buying votes feasible. You have to create a pretty elaborate system to prevent this kind of abuse and most of the proposed systems which look like they could solve this still don't prevent ballot stuffing.
Classic paper ballot voting solves these problems by using an observable and public process. The only secret act is the casting of the vote and there is practically nothing a voter can do in that secret phase to change the outcome beyond his normal participation in the poll. All other steps in an election are, at least theoretically, public: You can watch the sealing of the empty ballot boxes, you can watch the admission of the voters and you can observe the counting. Nobody has to trust someone else. If people take an interest in the process, they can see for themselves that it is done right.
Electronic voting always has the problem that you can't observe the code execution. Sure, you can verify that the code in the PROM is correct, but you can't verify that the code is what actually gets executed on election day. You can't verify the contents of the memory modules beyond what another unverifiable machine tells you. IMHO, the problems with electronic voting are unsolvable without giving up at least one of the democratic principles of a secret ballot. The central problem is that there is secret information involved which cannot be verifiable to the point that you can verify the whole process.
Of course it's also inefficient to start late, but one should not try to start earlier than necessary. The task will occupy your mind longer and especially if you don't like to do the work, it will stress you longer. The task does not become more difficult if you put it off until you need to do it. It just gets longer, because you will allow interruptions (there's still time, so...).
In a word: No. Large swaths of land become uninhabitable all the time. Earth is not a holiday resort where everything is controlled and nothing changes. Volcanic activity makes and breaks entire civilizations, deserts grow, landmasses get covered by huge ice crusts, lakes turn into swamps or dry out. Earth constantly changes. Pointing to one instance of change doesn't prove anything. It shouldn't even raise eyebrows. Many of the picture postcard islands are and have always been on the edge of inhabitability. I am not contesting the general notion of global warming, but if you want to be taken seriously, you can't ignore that man-made changes to climate may be fast compared to natural cycles, but in relation to our life-span, they're still rather slow. They're also not obvious, because the system is very complex and not at all a simple chain of causality (greenhouse gas, higher temperature, sea level rises). And the effects are still mostly masked by a huge amount of noise. As drastic as the change may be, nature is still much more chaotic and stronger than man.
The reasoning is still bollocks. For the sake of this argument, let's assume that a CF lasts 10 times as long, costs 20 times as much as an incandescent bulb and uses about a fifth of the energy to provide the same amount of light. Let c be the cost of an incandescent bulb. Replacing the incandescent bulb early adds at most 3*c to your cost: 1*c for throwing out a new incandescent bulb and 2*c for needing a CF 1/10 of its lifetime longer (20*c/10). Now it all comes down to the price of energy. If we assume that an incandescent bulb costs more than three times its own price in electricity over its lifetime, you save money no matter when you replace it: Let's say the 60W bulb costs $0.50 and lasts 1000 hours. That's 60kWh. The CF uses one fifth: 12kWh. Over the lifetime of the incandescent bulb, the incandescent bulb uses 48kWh more than the CF. $1.50 is the threshold, so if you pay more than $0.03125 per kWh, buy CF bulbs now.
It is important to realize that the cut off energy price doesn't depend on the time of replacement. Let x be the fraction of the lifetime left in an incandescent bulb at the time of replacement. The total cost for the remaining time is x*c for the wasted capacity of the incandescent bulb, (x/10)*20*c for the additional partial cost of the CF and the energy cost savings are (4/5)*x*1000*60Wh*p (p=price/kWh).
Cost with x=1 (replacing a new bulb): 1*c + (1/10)*20*c - (4/5)*1*60kWh*p equals 3*c - 48kWh*p, which, given c=$0.50, is negative (=saving money) for p>$0.03125/kWh.
Cost with x=0 (replacing a dead bulb): 0*c + (0/10)*20*c - (4/5)*0*60kWh*p equals 0, which is not surprising because there is no time left.
Cost with x=0.5: 0.5*c + (0.5/10)*20*c - (4/5)*0.5*60kWh*p equals 1.5*c - 24kWh*p, which, given c=$0.50, is negative (=saving money) for p>$0.03125/kWh.
Or solve with x as a parameter: x*c + (x/10)*20*c - (4/5)*x*60kWh*p 0 3*c*x - 48kWh*p*x < 0 0.0625*c*x < p*x// note: x just scales the equation c*x < 16*p*x
Only the absolute savings over the remaining lifetime of the incandescent bulb are smaller when you replace later (for p higher than the cut off), down to 0 when you replace only dead bulbs. For the given parameters (60W, lifetime*10, cost*20, energy-use/5), replacing incandescent bulbs always saves money if 16kWh cost more than the incandescent bulb.
No, the developers are not to blame, at least not the website developers. For some unknown reason, people think that web authors should code to "web standards", so that the pages work everywhere. Well, bullshit. Everybody who has ever made a webpage which goes beyond static, structured text knows it doesn't work that way. You can code to web standards, and then you have to tweak things for every single browser because they're all flawed, some more, some less. The problem is only partially attributable to browser programmers. Often the standards are incomplete, unclear or even contradicting. Practically all of the standards except for the early HTML versions are byzantine. Web programming is dirty dirty work. Authors need years of experience to get even simple things like drop down menus right. That should give you an idea how broken the whole thing is. If you think I'm exaggerating, you haven't written web apps of a noteworthy complexity. The web was designed for hypertext documents, hierarchically structured interlinked documents. The fact that it works as a distributed application platform at all is a freaking miracle.
Opera does everything in a slightly different way. The level of compatibility between cutting edge webapp programming on Gecko, IE7, Konqueror, Safari and Opera is about the same (now), but there are always small differences. If a complicated web app works in Opera, that means it has been tested and adapted to work in Opera. It wasn't built for another browser, let alone web standards, and simply works in Opera too. The same of course is true for every other browser, but that's where the numbers join the discussion: Does it make sense to find and work around all those little peculiarities of a browser with such a small market share? Opera should really make sure on their end that pages which work in IE7, Gecko or Safari (pick ONE) work 100% in the Opera browser. If you ever get more than 3% market share, you can stop kissing the bigger browser makers' asses if you want, but right now you're not in the position to tell everybody that your interpretation of the standards is the right one.
Without more information about what exactly goes wrong, this discussion is pointless. In my experience however, there is a good chance that Opera is at fault. The first usable Opera version, from a web compatibility point of view, is 9.0. Versions before that had serious bugs in the DHTML and CSS departments. DOM was supported at all as late as Opera 8.0! Granted, IE is even buggier, but it is reasonable to pick up after Microsoft, because most people still use their piece of shit browsers (yep, browsers, IE7 is a little less broken, but still holds the red lantern). Not so with Opera. Very few people use their desktop browsers and PDA users usually need a page tailored to mobile use anyway.
My own way of developing websites is to code to standards, test with Gecko, create an IE compatibility layer of conditional code afterwards and that's it. I test with other browsers (Konqueror, Safari, Opera), but if bugs remain, they better be fixable by minor CSS tweaks, because that's all I'm willing to tweak. Anything more would mean another cycle of IE fixing, and that's just not going to happen unless specifically asked and paid for.
I mostly agree, but you know the saying: When you build a foolproof tool, nature makes bigger fools. There is a balance where automatic overrides don't introduce more problems than they solve. Every uncaught user error beyond that limit isn't even partially the tool's (or the tool builder's) fault. A car navigation system is a problem in itself if it tries to prevent you from driving off a cliff while you want to cross the gap on the newly built bridge.
On the matter of PHP, I have no doubt that the language is problematic. There are just too many non-obvious ways to shoot yourself in the foot. A language which is mostly used to process untrusted input should make it easy to write code that is safe from certain low level attacks. The language cannot enforce proper application logic, but it shouldn't take as much knowledge and leg work to avoid run-of-the-mill code injection as it does with PHP.
Civilization only works where it provides people with a "better fix". The whole bread and circuses thing. Most people are very bad at putting uncertain future rewards before immediate satisfaction. I'm not saying you shouldn't try to change people's behaviour, but you have to know what you're up against. Telling people to cut back if they can afford not to is a losing proposition.
waste simply through their animal prejudices and "preferences"
You cannot fight against evolution and win. If your solution includes telling people to go against their most basic desires and needs, it is certain failure.
Bad idea. Journaling filesystems only guarantee a consistent filesystem after a sudden power off. They do not guarantee consistent data. Most don't even journal data, just the metainformation that goes with it. Journaling is important because an inconsistent filesystem can destroy huge amounts of data at once, but inconsistencies in the filesystem aren't the only worry when you stop programs without giving them a chance for a clean shutdown.
I can see a certain delay after power-on. Harddisks need to spin up and external devices might wait half a second for the voltages to stabilize (it isn't necessary inside a PC, where the mainboard gets a voltage-ok signal from the power supply). But beyond that, what reason is there for a device to not answer right away? If it isn't there 1 second after it got power, it won't be there 10 seconds later either. In conclusion, booting up shoot take at most harddisk spinup time plus the time it takes to load 100MB (another 3 seconds perhaps). When you're done waiting for the code to arrive in RAM, everything else should be in a state where it answers immediately. You can treat networks as disconnected until you get an IP.
Slashdot Mirror
If you get an email address from them, you agree to their policy, which is to delete email accounts that haven't been accessed in a while. The grace period is longer at other providers, but it is still a very common type of rule, simply because users never bother to remove old accounts. They would just pile up if there was no rule in place to delete accounts after some inactivity. In fact, I find it comforting that Lycos actually deletes email and doesn't keep it around forever. If I were offered the choice of two types of accounts, one which can not ever be deleted and one which expires after a month, I'd take the latter.
No, you're trying to squeeze something that isn't a hierarchy into a hierarchy. The domain name system is based on the concept of administrative domains and delegation of subdomains. The keyword is "administrative". The domains are not meant to describe functions or real world concepts because these are rarely hierarchical.
standard PC case and its measurements. [...] Everything is very much metric.
Everything but the damn screws. What were they thinking? The photography biz is guilty, too: Tripod screws are 1/4 inch or 3/8 inch UNC screws.
Look, it took you three tries to even understand what is being attacked. Don't you think YOU need to take a step back and think about what one could do with this in a Web 2.0 environment? I mean, the paper actually hints at the chain of events which becomes possible by being able to craft requests to a third party domain from within the user's browser. You just have to read and understand it.
In fact I have tested it. It works as advertised, but apparently you don't understand the problem. Of course that doesn't stop you from deriding a correct and concise summary.
Before you embarass yourself any further, please do read the paper and try for yourself if a script can sniff the communication of a script from a different domain (which runs on the same page) and also intercept the communication and thereby talk to the domain of the other script from which it would normally be forbidden by security rules. For the sake of this argument, the malicious script gets to run first, because that is in line with the attack vectors which are described in the rest of the paper.
No, Greasemonkey exposed security sensitive functions to websites. They were meant to be used by Greasemonkey scripts but websites had access too.
This is about the way Javascript implements object oriented programming: In Javascript you don't define classes from which objects are instantiated. In a nutshell, you create prototype objects and new objects are copies of the prototypes. The "attack" is to change existing prototypes. For example, you can add a new function to the String prototype or replace an existing function with your own implementation. Every String object then gets the new function. There is one problem with this: Cross site checks don't apply. A script from one site can't simply communicate with another site, but it can modify the prototypes that the scripts from the other site use and subvert the communication of the other script with its host.
It doesn't make a difference, at least not for one-pass overwriting. Since the last (only) pass is normally readable, you know the pattern that you need to eliminate to get to the residual magnetic information. That's all theory though. I'm still waiting for someone to tell harddisk manufacturers how they can double the capacity of their products by allowing access to information which has been written over once.
Anything beyond dd if=/dev/zero of=/dev/hdx is a sign of mild paranoia. No commercial recovery service claims to be able to recover overwritten data. They would certainly advertise that capability, don't you think? These guys have clean rooms, create images of the raw magnetization of the platters and restore the data from these images. If you're up against more sophisticated technology than that, there are far easier ways to get your data.
From the epilogue:
it's unlikely that anything can be recovered from any recent drive except perhaps one or two levels via basic error-cancelling techniques. In particular the the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.
So, not only does he think that the chances of recovering data are pretty slim, it also looks like he hasn't actually tried to recover some data from a recent drive. That is from a person who spent way too much time on figuring out how to erase data logically when it would be much more secure and foolproof (probably cheaper too) to simply melt the drive if your data is that big a secret. IOW, if you are a double-0 agent, you shouldn't have written unencrypted data to the drive in the first place and you should never let the undamaged platters leave the building. For the rest of us, dd if=/dev/zero of=/dev/hdx will suffice.
Technically you're right: JSON is not limited to Javascript, even though the acronym means "JavaScript Object Notation". However, since JSON messages are by definition valid Javascript object definitions, it's not surprising that it's mostly used in the way GMail uses it: The page loads and executes scripts to move data from the server into the application on the client. This typical way of using JSON is prone to be exploited in the described fashion, unless the programmer has implemented additional security.
The problem is that the user has the cookie because he's logged into GMail (in a different window or tab, or he forgot to log out). The cookie which is sent with the request for the script is from the domain of the web app that the script is part of, not from the attacking website. One way to deal with this type of vulnerability is to check the HTTP referrer header, but since many users disable the referrer (mostly for privacy reasons), such a check would either not protect these users or prevent them from using the application. In essence, the website requesting the information would have to send something with the request that a third party can't know and can't cause another entity to add to the request (like the cookie). This means that the programmer has to take an extra precaution beyond implementing the functionality in a robust fashion, hence my assumption that many applications are similarly vulnerable.
Loading script files to exchange data with the server is a very common mechanism. It even has a name: JSON. It wouldn't surprise me to find that there are many more web applications which could be exploited in this way. This isn't a browser vulnerability or a simple bug. It is a design flaw of a widely used communication protocol.
To all the geeks who run their computers on UTC: It's one hour past midnight in your favorite timezone! Stop discussing bubble sizes...
Wouldn't all this be solved by encrypted online voting, where you could check your own votes by a profile tied to an anonymous registration key issued by the DMV?
The problem with most "verified" voting mechanisms is that they allow voters to prove a vote for a certain party, which in turn makes buying votes feasible. You have to create a pretty elaborate system to prevent this kind of abuse and most of the proposed systems which look like they could solve this still don't prevent ballot stuffing.
Classic paper ballot voting solves these problems by using an observable and public process. The only secret act is the casting of the vote and there is practically nothing a voter can do in that secret phase to change the outcome beyond his normal participation in the poll. All other steps in an election are, at least theoretically, public: You can watch the sealing of the empty ballot boxes, you can watch the admission of the voters and you can observe the counting. Nobody has to trust someone else. If people take an interest in the process, they can see for themselves that it is done right.
Electronic voting always has the problem that you can't observe the code execution. Sure, you can verify that the code in the PROM is correct, but you can't verify that the code is what actually gets executed on election day. You can't verify the contents of the memory modules beyond what another unverifiable machine tells you. IMHO, the problems with electronic voting are unsolvable without giving up at least one of the democratic principles of a secret ballot. The central problem is that there is secret information involved which cannot be verifiable to the point that you can verify the whole process.
Of course it's also inefficient to start late, but one should not try to start earlier than necessary. The task will occupy your mind longer and especially if you don't like to do the work, it will stress you longer. The task does not become more difficult if you put it off until you need to do it. It just gets longer, because you will allow interruptions (there's still time, so...).
In a word: No. Large swaths of land become uninhabitable all the time. Earth is not a holiday resort where everything is controlled and nothing changes. Volcanic activity makes and breaks entire civilizations, deserts grow, landmasses get covered by huge ice crusts, lakes turn into swamps or dry out. Earth constantly changes. Pointing to one instance of change doesn't prove anything. It shouldn't even raise eyebrows. Many of the picture postcard islands are and have always been on the edge of inhabitability. I am not contesting the general notion of global warming, but if you want to be taken seriously, you can't ignore that man-made changes to climate may be fast compared to natural cycles, but in relation to our life-span, they're still rather slow. They're also not obvious, because the system is very complex and not at all a simple chain of causality (greenhouse gas, higher temperature, sea level rises). And the effects are still mostly masked by a huge amount of noise. As drastic as the change may be, nature is still much more chaotic and stronger than man.
The reasoning is still bollocks. For the sake of this argument, let's assume that a CF lasts 10 times as long, costs 20 times as much as an incandescent bulb and uses about a fifth of the energy to provide the same amount of light. Let c be the cost of an incandescent bulb. Replacing the incandescent bulb early adds at most 3*c to your cost: 1*c for throwing out a new incandescent bulb and 2*c for needing a CF 1/10 of its lifetime longer (20*c/10). Now it all comes down to the price of energy. If we assume that an incandescent bulb costs more than three times its own price in electricity over its lifetime, you save money no matter when you replace it: Let's say the 60W bulb costs $0.50 and lasts 1000 hours. That's 60kWh. The CF uses one fifth: 12kWh. Over the lifetime of the incandescent bulb, the incandescent bulb uses 48kWh more than the CF. $1.50 is the threshold, so if you pay more than $0.03125 per kWh, buy CF bulbs now.
// note: x just scales the equation
It is important to realize that the cut off energy price doesn't depend on the time of replacement. Let x be the fraction of the lifetime left in an incandescent bulb at the time of replacement. The total cost for the remaining time is x*c for the wasted capacity of the incandescent bulb, (x/10)*20*c for the additional partial cost of the CF and the energy cost savings are (4/5)*x*1000*60Wh*p (p=price/kWh).
Cost with x=1 (replacing a new bulb): 1*c + (1/10)*20*c - (4/5)*1*60kWh*p
equals 3*c - 48kWh*p, which, given c=$0.50, is negative (=saving money) for p>$0.03125/kWh.
Cost with x=0 (replacing a dead bulb): 0*c + (0/10)*20*c - (4/5)*0*60kWh*p
equals 0, which is not surprising because there is no time left.
Cost with x=0.5: 0.5*c + (0.5/10)*20*c - (4/5)*0.5*60kWh*p
equals 1.5*c - 24kWh*p, which, given c=$0.50, is negative (=saving money) for p>$0.03125/kWh.
Or solve with x as a parameter: x*c + (x/10)*20*c - (4/5)*x*60kWh*p 0
3*c*x - 48kWh*p*x < 0
0.0625*c*x < p*x
c*x < 16*p*x
Only the absolute savings over the remaining lifetime of the incandescent bulb are smaller when you replace later (for p higher than the cut off), down to 0 when you replace only dead bulbs. For the given parameters (60W, lifetime*10, cost*20, energy-use/5), replacing incandescent bulbs always saves money if 16kWh cost more than the incandescent bulb.
No, the developers are not to blame, at least not the website developers. For some unknown reason, people think that web authors should code to "web standards", so that the pages work everywhere. Well, bullshit. Everybody who has ever made a webpage which goes beyond static, structured text knows it doesn't work that way. You can code to web standards, and then you have to tweak things for every single browser because they're all flawed, some more, some less. The problem is only partially attributable to browser programmers. Often the standards are incomplete, unclear or even contradicting. Practically all of the standards except for the early HTML versions are byzantine. Web programming is dirty dirty work. Authors need years of experience to get even simple things like drop down menus right. That should give you an idea how broken the whole thing is. If you think I'm exaggerating, you haven't written web apps of a noteworthy complexity. The web was designed for hypertext documents, hierarchically structured interlinked documents. The fact that it works as a distributed application platform at all is a freaking miracle.
Opera does everything in a slightly different way. The level of compatibility between cutting edge webapp programming on Gecko, IE7, Konqueror, Safari and Opera is about the same (now), but there are always small differences. If a complicated web app works in Opera, that means it has been tested and adapted to work in Opera. It wasn't built for another browser, let alone web standards, and simply works in Opera too. The same of course is true for every other browser, but that's where the numbers join the discussion: Does it make sense to find and work around all those little peculiarities of a browser with such a small market share? Opera should really make sure on their end that pages which work in IE7, Gecko or Safari (pick ONE) work 100% in the Opera browser. If you ever get more than 3% market share, you can stop kissing the bigger browser makers' asses if you want, but right now you're not in the position to tell everybody that your interpretation of the standards is the right one.
Without more information about what exactly goes wrong, this discussion is pointless. In my experience however, there is a good chance that Opera is at fault. The first usable Opera version, from a web compatibility point of view, is 9.0. Versions before that had serious bugs in the DHTML and CSS departments. DOM was supported at all as late as Opera 8.0! Granted, IE is even buggier, but it is reasonable to pick up after Microsoft, because most people still use their piece of shit browsers (yep, browsers, IE7 is a little less broken, but still holds the red lantern). Not so with Opera. Very few people use their desktop browsers and PDA users usually need a page tailored to mobile use anyway.
My own way of developing websites is to code to standards, test with Gecko, create an IE compatibility layer of conditional code afterwards and that's it. I test with other browsers (Konqueror, Safari, Opera), but if bugs remain, they better be fixable by minor CSS tweaks, because that's all I'm willing to tweak. Anything more would mean another cycle of IE fixing, and that's just not going to happen unless specifically asked and paid for.
I mostly agree, but you know the saying: When you build a foolproof tool, nature makes bigger fools. There is a balance where automatic overrides don't introduce more problems than they solve. Every uncaught user error beyond that limit isn't even partially the tool's (or the tool builder's) fault. A car navigation system is a problem in itself if it tries to prevent you from driving off a cliff while you want to cross the gap on the newly built bridge.
On the matter of PHP, I have no doubt that the language is problematic. There are just too many non-obvious ways to shoot yourself in the foot. A language which is mostly used to process untrusted input should make it easy to write code that is safe from certain low level attacks. The language cannot enforce proper application logic, but it shouldn't take as much knowledge and leg work to avoid run-of-the-mill code injection as it does with PHP.
Civilization only works where it provides people with a "better fix". The whole bread and circuses thing. Most people are very bad at putting uncertain future rewards before immediate satisfaction. I'm not saying you shouldn't try to change people's behaviour, but you have to know what you're up against. Telling people to cut back if they can afford not to is a losing proposition.
waste simply through their animal prejudices and "preferences"
You cannot fight against evolution and win. If your solution includes telling people to go against their most basic desires and needs, it is certain failure.
Bad idea. Journaling filesystems only guarantee a consistent filesystem after a sudden power off. They do not guarantee consistent data. Most don't even journal data, just the metainformation that goes with it. Journaling is important because an inconsistent filesystem can destroy huge amounts of data at once, but inconsistencies in the filesystem aren't the only worry when you stop programs without giving them a chance for a clean shutdown.
I can see a certain delay after power-on. Harddisks need to spin up and external devices might wait half a second for the voltages to stabilize (it isn't necessary inside a PC, where the mainboard gets a voltage-ok signal from the power supply). But beyond that, what reason is there for a device to not answer right away? If it isn't there 1 second after it got power, it won't be there 10 seconds later either. In conclusion, booting up shoot take at most harddisk spinup time plus the time it takes to load 100MB (another 3 seconds perhaps). When you're done waiting for the code to arrive in RAM, everything else should be in a state where it answers immediately. You can treat networks as disconnected until you get an IP.
to prove my innocence
Are we that far off track already?