I guess water sprinklers could screw it up in some places
The crooks won't care too much if they miss a property or two; someone else on the next block over who isn't as careful/paranoid will do just as well...
I think you might want to revise your opinion there. Tablets are doing very well indeed; you're starting to see more corporate apps shift over to them, particularly ones without lots of typed data entry or where there's some crappy old touchscreen gadget to replace. While it's clear they aren't a replacement for everything, there's a big niche that they occupy very nicely.
No, GNOME 3's big problem is that it's never gained any real traction in the tablet space, so all the compromises it made in order to play there have basically come to naught.
It seems like every other environment has decided that letting the user configure things how they want them to be is "too hard".
The only true configurability is what you get when you build your environment from source where you know how to alter that source to achieve what you want yourself. Like that you're not beholden to what any vendor of the moment says. Can't program? You're stuck with whatever those who can decide to let you do.
OTOH, any sufficiently complex configuration system looks like (and is) programming. And a poor syntactic skin over Lisp too, of course. Don't despair; there's still hope...
Is it just the windows version of java? What about tomcat and other enterprisey java packages? Do they suffer from the same flaws?
Not nearly so much. They don't use the same model as java-in-the-browser, and so don't suffer from the same threats. You have to work at it to make tomcat insecure from its Java nature; though you can of course deliberately install insecure webapps in it, that's about as significant as running bad CGI scripts inside Apache: idiots will be idiots and crap programmers will be crap programmers.
Enterprisey Java programs tend to not run arbitrary code that someone "out there on the web" specifies. In fact, they spend quite a bit of effort to make sure that they don't. (They also tend to run on systems that don't even have a web browser installed.)
Which makes me question the wisdom of urban datacenters in the first place.
It's nothing particularly special to the datacenter being in a city. Get a big enough disaster and you will be knocked off the net, wherever you are and whatever steps you take to prevent it. The best mitigation strategy is to have geographically distributed datacenters that can run replicated services that are structured so that losing one site entirely is not crippling (though it might hurt a lot). This isn't a simple thing to do — for most types of service, you have to design the overall service from the ground up to work that way — but it's not too bad. (And at least with the Cloud you don't have to build your own collection of geographically-separated datacenters or pound your head against the problems you usually get with hosting providers when you're desperate for service in a hurry.)
Mind you, rents in NYC are so high that I'd guess that nobody's going there for the cheapness of the service. Instead, it's probably for the proximity to the Wall St. exchanges. The fun thing with that? Any datacenter which could satisfy the latency requirements for people in that business would have been deeply hit by this particular disaster, and all the places that could easily offer continuous service this time would never be able to normally compete for this particular type of business. To double the fun, the exchanges were closed for two days anyway. That's modern capitalism at work...
Wrong. They are the admin's fault, along with the fault of others as well. Blame can be spread, but not absolved. The admin should not have let things get into a state where things could get hacked, whatever his line management said. What's worse, if things were in a management state where the admin had decided to do a private passive-aggressive work-to-rule (I've known a few admins like that; technically competent, but total dicks) then they're absolutely making things worse and are thoroughly to blame.
Mind you, I'm not absolving management here. It takes two to tango.
A vaccine is something you take prior to getting sick.
More specifically, a vaccine makes the disease a much less serious issue, as it enables the body's immune system to squish it very rapidly and with few ill effects. That is, it changes the nature of the disease as a process occurring in the body (and to our benefit); it's immune system hacking really.
Given that we're not the primary hosts for influenza, a general vaccine (if possible) will be highly beneficial. Well, provided it's restricted to people and not also used to try to partially stamp it out in the natural reservoir; that would be bad because it would put strong selection pressure on the virus to evolve into something that the vaccine wouldn't help with.
I will take the opposing view, which I call "reality". Intel is a full process level ahead and 14nm is coming in a little over a year. They are dominant in manufacturing, that helps a _lot_. Remind me what the A6X was manufactured at? Oh, yeah - 32nm. Maybe late next year we'll see 20nm ARM chips...maybe.
Your ignorance is fascinating. Intel are the biggest single manufacturer, yes, but ARM sells to nearly every other manufacturer. It's a different business model. Let's emphasize that for you: ARM are fab-less; they don't manufacture themselves. A consequence of this is that the process scales for ARM are usually a lot larger, and that's because the non-Intel manufacturers are a generation or two behind. (Intel spends a lot on staying ahead on that front.) But that's OK; the other manufacturers are usually using those ARM cores to produce SOC, that is, a CPU plus extra bits for a specific application (such as hardware for doing 4G mobile comms or video stream processing). Specialist hardware beats a general CPU in the application for which that specialist hardware was designed, which shouldn't be a surprise (it's been true for as far back as I can think).
I'll bet that ARM will only really start worrying about Intel at the point when Intel start trying to sell high-performance CPU cores for SOC use together with the right to use Intel's own fabs to make the resulting parts. Or if Intel start helping other companies to tech up to an equivalent level so as to be able to make parts at the same scale as Intel. Also known as a cold day in hell; that's totally alien to Intel's business model. (Heck, if Intel were to help other fabs to be able to make 14nm parts, I'd bet that ARM would happily produce a 14nm core to use with that process...)
Oh, and for the mobile phone market, there's Atom.
Are Intel licensing that to other manufacturers for SOC use? No? Then it's not a real player; cutting the component count at the overall device level is more important than speed to phone makers, as it's cheaper for them like that.
Concur. ARM is fucked, it's funny people don't see that. They will move back to basically providing only ultra low cost and ultra low power chips. They will see their high end aspirations kicked to the ground, and will be pushed lower and lower in the tablet and mobile phone market over the next 2 years.
ARM's core business is processor cores — CPU layouts to laymen — that other companies can take and add their own extra bits to before manufacturing. It's called System-on-Chip (SOC) and it's an area where Intel doesn't have much of a grasp precisely because it involves giving your design to other companies, letting them modify it by adding stuff, and then manufacture it themselves (or through a third-party). Now, it's hardly surprising that the high-end SOC guys want a larger addressing mode; the forces which pushed desktops also push mobile devices and the like.
What amuses me is the push to e.g. servers. Gee, can I get a server with 1000 cores that's slower in almost every operation than a 16 core Xeon server? Oh, and can you make it useless for virtualizing servers or doing anything but light load trivially parallelizable tasks?
I know a few scientists with tasks to do that are embarrassingly parallel and with far more data than you can shake a whole bushel of sticks at. Being able to stuff even more cores into a rack (where power and cooling are usually the main constraints) is going to be of great interest to them. Whether it will beat out GPUs is the real question though. I expect it will for some workloads (ones with more complex conditional processing in the individual units of processing) but not others. And Intel remains the fastest situations where raw single-threaded power is required, which frankly is a lot of code.
Supercomputing doesn't operate under the same constraints that desktop or normal server computing does. Supercomputer makers try to pack as much computing power in as small a space as possible (because delays effectively due to the speed of light are quite a significant problem otherwise). All too often, the main challenge with a supercomputer is stopping it from cooking itself and setting fire to the building...
Only if you think that the kernel is the only thing that is the OS, or if you think that the only part of a Linux-based system that should be called "Linux" is the kernel.
The place where something finally called a method on a null is not necessary place where the bug is. The question is why that variable has a null value at that moment. You will not find it in the stack trace.
If your logic is so complicated that you can't tell where a variable should have been assigned, your code is already an unmanageable mess. Add preconditions on the arguments to your methods and enforce them by throwing an informative exception if they are not satisfied; that helps hugely. If it doesn't, it's time to also do postconditions and invariants. If you don't understand what those preconditions and postconditions should be, that's a much more important problem than where your code is throwing a NullPointerException...
Now for your humorous AbstractSingletonProxyFactoryBean. If you're writing a webpage with some fancy graphics on the front and not much user interaction, then you'll probably come across this class and think wtf would anyone ever use it? If you come from the data processing world with many systems working on the same data, you pretty much don't live without it.
Good Java programmers don't use that sort of class. Well, not explicitly. They have a Dependency Injection system (like Spring or OSGi Blueprint) that deals with these details for them, and lets them just write the interesting parts of the program.
Having such systems makes Java much easier to program with; you just have to remember the First Rule of Fight Club... err... Spring: nobody talks about Spring (in their code). By that I mean that you should not mention any part of Spring in your code at all (not always possible, alas); let Spring manage the configuration and setup (which it is very good at) and let your code focus on the real operational logic. This is much simpler than doing it yourself, and the more complicated the application the more this is true.
And, finally, I don't believe in "bad" people any more than I believe in "evil spirits".
They do exist. They're not that common, but they cause a disproportionate amount of harm. Usually they fall foul of the cops and the courts and end up doing a lot of jail time. Which in turn institutionalizes them, which doesn't help much, but they're definitely a small minority of inmates (and an even smaller minority of the overall population). If you're not involved in criminal justice, you probably won't have too many dealings with the real bad people.
More common is for people to be thinking that they're doing the right thing even when it is hurting others excessively. That's a much more complex case, as it usually isn't clear cut at all whether the benefits outweigh the costs.
If this is the case, then there are real concerns about the future for the US as a nation. The state will remain, but it will not govern for the interest of the citizen anymore. But perhaps it already happened?
I don't think you've really lost sight of the American Dream, the thing that drives people to believe that the USA should exist. I do worry that, as a nation, you're stoking the flames of extremism and revolution. The particular problem is the concentration of wealth into the hands of the elite who at the same time think they don't have to treat the rest of society well. The longer they continue like this, the worse it will be when the fracture happens, and I don't know whether you've got to the point yet where a non-violent resolution is even possible any more.
I worry (in part because of the US habit of sharing their troubles with the rest of the world) and I don't know what I could do even if I was a US citizen.
I would argue needing a debugger is also a sign of language flaws. Debuggers help you find issues with your code while it runs.
The biggest code smell is the lack of an ability to attach a REPL to a running program so you can poke around in it, define new things at runtime and experiment with them until they work, and then translate that back into "fixed" code in a source file. But that's not really the way you do things in Java (and a few other languages as well).
IDEs are great, but you have to admit that Java forces you to use one.
The problem is the language's social convention (for want of a better term) that long package names, class names and method names are used. Auto-completion and support for managing the imports are the features that make a Java IDE win out over an editor like Emacs (which I used to use for Java programming). Other languages use much terser conventions and make it easier to code with a normal editor with no ill-effects (though some go a bit far) so I'm sure that the problem is the very long names; frankly, typing that much stuff out by hand every time gets old very fast indeed.
The other things that IDEs tend to offer are less useful to me because of the type of code I usually write. (Security-sensitive server code that integrates a bunch of other people's code is a PITA to test and debug anyway, and I try to avoid confusing naming in the first place so refactorings aren't a problem anyway.)
Eclipse starts to get annoying type lag around 30k lines of code in a single file, as you get bigger and bigger upwards to 100k or more, it can take several seconds between characters you type.
I've emphasized your problem and it's not Java-specific at all; it'd be horrible in any language at all. Even in C, I consider 10kloc to be an excessively long file. I have one project with an 11kloc file, and I hate how long it is; it's in a module that someone else is in charge of though, so I'm hesitant to interfere; the project also has a separate file with a 6kloc function, but that can't be shortened as it is a bytecode execution core (before anyone asks, the project style is not very dense by comparison with how a lot of other people write C; different styles would be a lot shorter).
Split that code up a bit into sensible-sized pieces. Do it today. Define pieces that have sensible responsibilities and which expose sane APIs, and then don't violate those APIs. Sure, it takes a little time to do but it makes it so much easier to understand. As a side benefit, your tools will also become better able to help you, but that's not why you should do this: the greater comprehensibility to you (and your coworkers, assuming that's relevant) is far more important!
There's no global warming equivalent for earthquakes.
Except there is. Rising sea levels and changes in precipitation patterns can both alter the loading on faults, and even small changes that way can have big effects through triggering earthquakes and volcanoes (dependent on the local geology, of course). On the other hand, it's very hard to say for sure what the effects will be; you can't predict the size of earthquakes this way, nor the violence of volcanic eruptions. All we can really say is that altering the loading due to water, whether seawater or in an aquifer or in lakes and rivers, can cause the earth to flex somewhat (that's basic physics) and that can in turn trigger more violent earth movement events. (I believe that there has been research that has shown that earthquakes are more likely to happen in spring, typically associated with when most snow melts off mountains, but I could have mis-remembered that.)
It's all rather non-linear and complicated, so nobody's making any real predictions. After all, it might just cause more very small earthquakes and minor eruptions. We just don't have nearly enough data to be able to guess what the overall effect will be.
Also keep in mind that with HTTPS you cannot server multiple websites from the same IP (and the IP is not encrypted for obvious reasons), so there is no mistaking which website (or subdomain of that website for that matter) the user is visiting.
You're wrong there. Multidomain certificates just cost more and are a little more complicated to create. (They also have to either list the domains that they are for or the super-domain, depending on exactly which type of certificate they are.)
Slashdot Mirror
"electromagnetic hypersensitivity (EHS)
Is that the disease that people get even when the devices they blame for it have no power at all?
I guess water sprinklers could screw it up in some places
The crooks won't care too much if they miss a property or two; someone else on the next block over who isn't as careful/paranoid will do just as well...
[Tablets] are now obviously an outgoing fad
I think you might want to revise your opinion there. Tablets are doing very well indeed; you're starting to see more corporate apps shift over to them, particularly ones without lots of typed data entry or where there's some crappy old touchscreen gadget to replace. While it's clear they aren't a replacement for everything, there's a big niche that they occupy very nicely.
No, GNOME 3's big problem is that it's never gained any real traction in the tablet space, so all the compromises it made in order to play there have basically come to naught.
It seems like every other environment has decided that letting the user configure things how they want them to be is "too hard".
The only true configurability is what you get when you build your environment from source where you know how to alter that source to achieve what you want yourself. Like that you're not beholden to what any vendor of the moment says. Can't program? You're stuck with whatever those who can decide to let you do.
OTOH, any sufficiently complex configuration system looks like (and is) programming. And a poor syntactic skin over Lisp too, of course. Don't despair; there's still hope...
Is it just the windows version of java? What about tomcat and other enterprisey java packages? Do they suffer from the same flaws?
Not nearly so much. They don't use the same model as java-in-the-browser, and so don't suffer from the same threats. You have to work at it to make tomcat insecure from its Java nature; though you can of course deliberately install insecure webapps in it, that's about as significant as running bad CGI scripts inside Apache: idiots will be idiots and crap programmers will be crap programmers.
Enterprisey Java programs tend to not run arbitrary code that someone "out there on the web" specifies. In fact, they spend quite a bit of effort to make sure that they don't. (They also tend to run on systems that don't even have a web browser installed.)
I live in Las Vegas.
Not exactly living in a population-weighted average location, I see...
Yes, but plants and sub-stations don't need to shop on e-Bay or check their Facebook status now do they?
You mean you don't detect when your power station has been hacked by seeing whether the generators have unfriended you?
At the same time, it will make it extremely difficult to improve it.
What, "improvements" like ICANN's new TLD wheezes?
Which makes me question the wisdom of urban datacenters in the first place.
It's nothing particularly special to the datacenter being in a city. Get a big enough disaster and you will be knocked off the net, wherever you are and whatever steps you take to prevent it. The best mitigation strategy is to have geographically distributed datacenters that can run replicated services that are structured so that losing one site entirely is not crippling (though it might hurt a lot). This isn't a simple thing to do — for most types of service, you have to design the overall service from the ground up to work that way — but it's not too bad. (And at least with the Cloud you don't have to build your own collection of geographically-separated datacenters or pound your head against the problems you usually get with hosting providers when you're desperate for service in a hurry.)
Mind you, rents in NYC are so high that I'd guess that nobody's going there for the cheapness of the service. Instead, it's probably for the proximity to the Wall St. exchanges. The fun thing with that? Any datacenter which could satisfy the latency requirements for people in that business would have been deeply hit by this particular disaster, and all the places that could easily offer continuous service this time would never be able to normally compete for this particular type of business. To double the fun, the exchanges were closed for two days anyway. That's modern capitalism at work...
Blunders like this ain't an admin's fault.
Wrong. They are the admin's fault, along with the fault of others as well. Blame can be spread, but not absolved. The admin should not have let things get into a state where things could get hacked, whatever his line management said. What's worse, if things were in a management state where the admin had decided to do a private passive-aggressive work-to-rule (I've known a few admins like that; technically competent, but total dicks) then they're absolutely making things worse and are thoroughly to blame.
Mind you, I'm not absolving management here. It takes two to tango.
A vaccine is something you take prior to getting sick.
More specifically, a vaccine makes the disease a much less serious issue, as it enables the body's immune system to squish it very rapidly and with few ill effects. That is, it changes the nature of the disease as a process occurring in the body (and to our benefit); it's immune system hacking really.
Given that we're not the primary hosts for influenza, a general vaccine (if possible) will be highly beneficial. Well, provided it's restricted to people and not also used to try to partially stamp it out in the natural reservoir; that would be bad because it would put strong selection pressure on the virus to evolve into something that the vaccine wouldn't help with.
I will take the opposing view, which I call "reality". Intel is a full process level ahead and 14nm is coming in a little over a year. They are dominant in manufacturing, that helps a _lot_. Remind me what the A6X was manufactured at? Oh, yeah - 32nm. Maybe late next year we'll see 20nm ARM chips...maybe.
Your ignorance is fascinating. Intel are the biggest single manufacturer, yes, but ARM sells to nearly every other manufacturer. It's a different business model. Let's emphasize that for you: ARM are fab-less; they don't manufacture themselves. A consequence of this is that the process scales for ARM are usually a lot larger, and that's because the non-Intel manufacturers are a generation or two behind. (Intel spends a lot on staying ahead on that front.) But that's OK; the other manufacturers are usually using those ARM cores to produce SOC, that is, a CPU plus extra bits for a specific application (such as hardware for doing 4G mobile comms or video stream processing). Specialist hardware beats a general CPU in the application for which that specialist hardware was designed, which shouldn't be a surprise (it's been true for as far back as I can think).
I'll bet that ARM will only really start worrying about Intel at the point when Intel start trying to sell high-performance CPU cores for SOC use together with the right to use Intel's own fabs to make the resulting parts. Or if Intel start helping other companies to tech up to an equivalent level so as to be able to make parts at the same scale as Intel. Also known as a cold day in hell; that's totally alien to Intel's business model. (Heck, if Intel were to help other fabs to be able to make 14nm parts, I'd bet that ARM would happily produce a 14nm core to use with that process...)
Oh, and for the mobile phone market, there's Atom.
Are Intel licensing that to other manufacturers for SOC use? No? Then it's not a real player; cutting the component count at the overall device level is more important than speed to phone makers, as it's cheaper for them like that.
Concur. ARM is fucked, it's funny people don't see that. They will move back to basically providing only ultra low cost and ultra low power chips. They will see their high end aspirations kicked to the ground, and will be pushed lower and lower in the tablet and mobile phone market over the next 2 years.
ARM's core business is processor cores — CPU layouts to laymen — that other companies can take and add their own extra bits to before manufacturing. It's called System-on-Chip (SOC) and it's an area where Intel doesn't have much of a grasp precisely because it involves giving your design to other companies, letting them modify it by adding stuff, and then manufacture it themselves (or through a third-party). Now, it's hardly surprising that the high-end SOC guys want a larger addressing mode; the forces which pushed desktops also push mobile devices and the like.
What amuses me is the push to e.g. servers. Gee, can I get a server with 1000 cores that's slower in almost every operation than a 16 core Xeon server? Oh, and can you make it useless for virtualizing servers or doing anything but light load trivially parallelizable tasks?
I know a few scientists with tasks to do that are embarrassingly parallel and with far more data than you can shake a whole bushel of sticks at. Being able to stuff even more cores into a rack (where power and cooling are usually the main constraints) is going to be of great interest to them. Whether it will beat out GPUs is the real question though. I expect it will for some workloads (ones with more complex conditional processing in the individual units of processing) but not others. And Intel remains the fastest situations where raw single-threaded power is required, which frankly is a lot of code.
Supercomputing doesn't operate under the same constraints that desktop or normal server computing does. Supercomputer makers try to pack as much computing power in as small a space as possible (because delays effectively due to the speed of light are quite a significant problem otherwise). All too often, the main challenge with a supercomputer is stopping it from cooking itself and setting fire to the building...
Star Wars 7: The Search for More Money!
The "smart money" thought the same thing when the stock was at $50. Now its north of $500. The smart money aint too smart.
If you think the stock is going to go up, don't snark about it here: invest! Put your money where your mouth is...
There are no UIs in Linux.
Only if you think that the kernel is the only thing that is the OS, or if you think that the only part of a Linux-based system that should be called "Linux" is the kernel.
Everyone else just thinks you're a dimwit.
The place where something finally called a method on a null is not necessary place where the bug is. The question is why that variable has a null value at that moment. You will not find it in the stack trace.
If your logic is so complicated that you can't tell where a variable should have been assigned, your code is already an unmanageable mess. Add preconditions on the arguments to your methods and enforce them by throwing an informative exception if they are not satisfied; that helps hugely. If it doesn't, it's time to also do postconditions and invariants. If you don't understand what those preconditions and postconditions should be, that's a much more important problem than where your code is throwing a NullPointerException...
Now for your humorous AbstractSingletonProxyFactoryBean. If you're writing a webpage with some fancy graphics on the front and not much user interaction, then you'll probably come across this class and think wtf would anyone ever use it?
If you come from the data processing world with many systems working on the same data, you pretty much don't live without it.
Good Java programmers don't use that sort of class. Well, not explicitly. They have a Dependency Injection system (like Spring or OSGi Blueprint) that deals with these details for them, and lets them just write the interesting parts of the program.
Having such systems makes Java much easier to program with; you just have to remember the First Rule of Fight Club... err... Spring: nobody talks about Spring (in their code). By that I mean that you should not mention any part of Spring in your code at all (not always possible, alas); let Spring manage the configuration and setup (which it is very good at) and let your code focus on the real operational logic. This is much simpler than doing it yourself, and the more complicated the application the more this is true.
And, finally, I don't believe in "bad" people any more than I believe in "evil spirits".
They do exist. They're not that common, but they cause a disproportionate amount of harm. Usually they fall foul of the cops and the courts and end up doing a lot of jail time. Which in turn institutionalizes them, which doesn't help much, but they're definitely a small minority of inmates (and an even smaller minority of the overall population). If you're not involved in criminal justice, you probably won't have too many dealings with the real bad people.
More common is for people to be thinking that they're doing the right thing even when it is hurting others excessively. That's a much more complex case, as it usually isn't clear cut at all whether the benefits outweigh the costs.
If this is the case, then there are real concerns about the future for the US as a nation. The state will remain, but it will not govern for the interest of the citizen anymore. But perhaps it already happened?
I don't think you've really lost sight of the American Dream, the thing that drives people to believe that the USA should exist. I do worry that, as a nation, you're stoking the flames of extremism and revolution. The particular problem is the concentration of wealth into the hands of the elite who at the same time think they don't have to treat the rest of society well. The longer they continue like this, the worse it will be when the fracture happens, and I don't know whether you've got to the point yet where a non-violent resolution is even possible any more.
I worry (in part because of the US habit of sharing their troubles with the rest of the world) and I don't know what I could do even if I was a US citizen.
I would argue needing a debugger is also a sign of language flaws. Debuggers help you find issues with your code while it runs.
The biggest code smell is the lack of an ability to attach a REPL to a running program so you can poke around in it, define new things at runtime and experiment with them until they work, and then translate that back into "fixed" code in a source file. But that's not really the way you do things in Java (and a few other languages as well).
IDEs are great, but you have to admit that Java forces you to use one.
The problem is the language's social convention (for want of a better term) that long package names, class names and method names are used. Auto-completion and support for managing the imports are the features that make a Java IDE win out over an editor like Emacs (which I used to use for Java programming). Other languages use much terser conventions and make it easier to code with a normal editor with no ill-effects (though some go a bit far) so I'm sure that the problem is the very long names; frankly, typing that much stuff out by hand every time gets old very fast indeed.
The other things that IDEs tend to offer are less useful to me because of the type of code I usually write. (Security-sensitive server code that integrates a bunch of other people's code is a PITA to test and debug anyway, and I try to avoid confusing naming in the first place so refactorings aren't a problem anyway.)
Eclipse starts to get annoying type lag around 30k lines of code in a single file, as you get bigger and bigger upwards to 100k or more, it can take several seconds between characters you type.
I've emphasized your problem and it's not Java-specific at all; it'd be horrible in any language at all. Even in C, I consider 10kloc to be an excessively long file. I have one project with an 11kloc file, and I hate how long it is; it's in a module that someone else is in charge of though, so I'm hesitant to interfere; the project also has a separate file with a 6kloc function, but that can't be shortened as it is a bytecode execution core (before anyone asks, the project style is not very dense by comparison with how a lot of other people write C; different styles would be a lot shorter).
Split that code up a bit into sensible-sized pieces. Do it today. Define pieces that have sensible responsibilities and which expose sane APIs, and then don't violate those APIs. Sure, it takes a little time to do but it makes it so much easier to understand. As a side benefit, your tools will also become better able to help you, but that's not why you should do this: the greater comprehensibility to you (and your coworkers, assuming that's relevant) is far more important!
There's no global warming equivalent for earthquakes.
Except there is. Rising sea levels and changes in precipitation patterns can both alter the loading on faults, and even small changes that way can have big effects through triggering earthquakes and volcanoes (dependent on the local geology, of course). On the other hand, it's very hard to say for sure what the effects will be; you can't predict the size of earthquakes this way, nor the violence of volcanic eruptions. All we can really say is that altering the loading due to water, whether seawater or in an aquifer or in lakes and rivers, can cause the earth to flex somewhat (that's basic physics) and that can in turn trigger more violent earth movement events. (I believe that there has been research that has shown that earthquakes are more likely to happen in spring, typically associated with when most snow melts off mountains, but I could have mis-remembered that.)
It's all rather non-linear and complicated, so nobody's making any real predictions. After all, it might just cause more very small earthquakes and minor eruptions. We just don't have nearly enough data to be able to guess what the overall effect will be.
Also keep in mind that with HTTPS you cannot server multiple websites from the same IP (and the IP is not encrypted for obvious reasons), so there is no mistaking which website (or subdomain of that website for that matter) the user is visiting.
You're wrong there. Multidomain certificates just cost more and are a little more complicated to create. (They also have to either list the domains that they are for or the super-domain, depending on exactly which type of certificate they are.)