If I lived in a country like Russia (or Canada, Norway, Finland, etc, for that matter), I'd be an enthusiastic supporter of anything that might even possibly tip the balance of the climate towards Global Warming for exactly these sorts of reasons
Then you're an idiot. Speaking as a Canadian, agriculture and forestry are extremely important to our economy, and global warming threatens to destroy both, thanks to drought and the advance of the pine beetle.
When someone gets sued or fired for an offhand remark, in any medium, our response ought to be, "That's not right!" rather than, "Deal with it, that's the way it is."
Interesting. And I would claim the precise opposite: that it's unreasonable for a person to feel they can publish a letter in a newspaper with absolute impunity, let alone a comment on a website. Remember, the first amendment outlines limitations on the government, not private employers or individuals.
Now, that's not to say that I believe the employer has a right to terminate the employee based solely upon comments posted outside the workplace. At best, that's an awfully fuzzy situation that probably depends on the nature of the job and the nature of the material that was published. But it's certainly not a black-and-white situation, and I believe that's true irrespective of the medium. The advent of the Internet just means a lot more people will find themselves grappling with this very issue.
But with respect to this particular issue, the difference isn't -- or shouldn't be -- all that great.
Except, of course, that it is. And why? Specifically because it's easier. Most people I know have never once in their lives written a letter to the editor. Why? Because it's a pain in the ass and not worth the trouble. Not only do you actually have to break out a pen and paper (or god forbid a computer) and write the damn thing out, you actually have to get an envelope and a stamp and send it. People who would go through that trouble a) actively make a choice to have their opinions heard, and b) understand that, in having such a letter published, they are, in effect, becoming amateur journalists.
We should apply the same standard to online communication as we do to printed and hand-written
But that's the whole point. People don't. At least, the people doing the writing don't. And the reason is simple: the web has made it possible for a stupid, off-the-cuff comment to be published online in mere seconds, available for the whole world to see. The difference in ease isn't just substantial. It's revolutionary. And it opens the door for people to embarrass themselves publicly in ways they never would have in the past, as the low barrier of entry means people a) don't think before they publish, and b) don't think of hitting "Submit" as an act of publication in the first place.
So, does the difference in medium change the legality of the situation? No, of course not. Publication is publication. But it substantially changes the sociological and psychological factors which feed into the decision to publish or not publish something.
There is nothing about social networking to distinguish it from previous publishing modalities except that it is faster and easier to publish something far and wide than it ever was before.
So, there's no difference, in the same way that the printing press was really just a minor improvement over scribes. Yup, no big deal at all!
Python is better than Perl because for beginners would takes weeks just to learn all the different possibilities of IF branches in Perl.
Because, when teaching a language you have to teach the *entire* language? Well, sucks to be a C++ programmer.
Seriously, that's the dumbest anti-Perl argument I've heard yet...
It is not as hard-core as lisp or smalltalk
Hard core? What? Smalltalk is *dead easy* to learn, and syntactically extremely simple and consistent. It's certainly no more difficult than any other OOP language, and as a plus, you don't have to worry about compilers, IDEs, and all that other garbage. Heck, Squeak + E-Toys is *explicitly designed as a learning environment*.
Because <my language> is better than <your language>! And here on Slashdot, we need few reasons to enjoy a good language war. So go away with your "reason" and "logic"! We've got a pointless battle to fight!
And for the record:
1) Java and C# suck because they require N levels of nesting before they can type "Hello World".
2) Assembly/C sucks because they're too low-level.
3) C++ sucks because it's horribly byzantine.
4) Scheme/Lisp/Haskell sucks because they're confusing.
5) Python/Perl/Scripting language du jour sucks because they're garbage collected and hide too much from the programmer.
6) Every other language sucks because it's not my favorite language.
As soon as you start adding files, network connections, etc. into the mix then you start having to do manual memory management in Java
So don't use Java. C# has using blocks which call Dispose() on your object when they're exited, whether that be through normal program flow or abnormal exit.
In short: don't assume all languages with a GC suck just because Java does.
Yes, if you need to grow your business and all you can hire are dumb@$$3$ then yes, stick with Java (or C#).
Wow, so all the programmers you hire are perfect little automata that never make mistakes? Impressive! Where did you find such miracles of science?
And how much of a hit in performance are you taking when garbage collector turns on? How many times a minute does it fire and what happens to all those threads that are blocking?
Depends on the GC. There's a reason Sun provides a bunch of alternative implementations which have various performance characteristics that are better for different workloads.
On the flipside, how often do you see a crash because of a bad pointer reference, or worse, a security hole available to the world because of a buffer overflow in the code your perfectly little automata hacked up?
There was a time when people expected computers to be fast.
They also expect them to be stable and secure. Hint: speed isn't the sole requirement for most applications, and in fact isn't even the top one most of the time.
1) java failed to support variables in stack, and the whole VM/GC thing is horrible.
Uh, variables on the stack isn't required to build "correct programs". Meanwhile, I would argue that a GC *helps* you do just that.
haskell failed in supporting for-loops
Haskell failed because of *for-loops*? WTF?
Heck, even if that made any sense (which it doesn't, at least to my feeble brain, as, AFAICT, for-loops aren't even necessary, let alone a deal-breaker), how is mapM_ not perfectly sufficient?
4) python failed when it's performance is not very good
Also not "required" for making "correct programs". Is Python necessarily suited to all application domains? No (although it's strong FFI means you can probably use it for most). But it's still a perfectly fine language when used appropriately.
5) C# failed because it's from microsoft
ROFL, how does that stop you from building "correct programs"? Oh right, it doesn't. It's just blind dogma.
Frankly, it sounds to me like you're just looking for feeble excuses so you can slink back to the comfort of C++.
Whatever happened to SaaS? Oh, still not really here is it?
a) What do you think "cloud computing" is, exactly? That's right... SaaS.
b) What do you think gmail and the rest of the Google app suite is?
No, SaaS, as a concept, is alive and well. Will it grow and turn into an actual money-making endeavour? That I don't know.
Or "Web Services?" In the end, its just another way to move data around... nothing really revolunatary.
Funny, given there's web services *everywhere*. Amazon exposes their API through a web service. Facebook exposes their API through a web service. The list goes on. In fact, web services have been wildly successful in exactly the way intended: they've provided real, portable API-level integration between web applications.
And that's ignoring all the *other* applications that are exposing their data and APIs through web services.
So, revolutionary? No, of course not. Who said they would be? A further evolution of the web, and a successful one? Absolutely.
1) Flexibility: difficult to mold SaaS solution to your specific business operations.
I'm not sure I've seen anyone proposing replacing in-house or custom built software with SaaS. It's for things like Word or other "stock" applications that you'd otherwise mass-deploy.
2) Reliability: requiring a connection to the internet adds an additional point of failure.
Well, I think in today's day and age, with large volumes of corporate inter-communication occuring over the internet (I get a lot of my correspondence with outside consultants and corporations done via email), a company's internet connection is *already* an SPF. And that's doubly true for organizations that are geographically dispersed and use internet connectivity to connect their sites (sure, you can try and replicate services, etc, but in the end, if that internet connection goes down, it's a big problem).
3) Speed: easy to get 40mbps internally. Internet connect is more likely to be 1.5mbps split 50 ways.
Sure, if your provider sucks.:) Either way, the real question is, how much bandwidth is really needed? A well developed web-deployed application does an awful lot of work client side. I mean, do you really think the Google Spreadsheet is constantly hitting the server? No, of course not.
It's an interesting question, though... I wonder if anyone's done any bandwidth studies to see how much bandwidth, say, 100 users using Google Apps would actually take up.
4) Cost: from what I have seen, SaaS is not especially cheap.
That's absurd. Compared to, say, a large scale per-seat licensing of Microsoft Office, I can't see how SaaS can be anything *but* cheaper. Add in the savings in deployment and upgrade costs, and I'd be shocked if it wasn't cheaper in the long run, too.
5) Security: debatable.
Yes, it is. Let's see, you can have thousands of users running an application littered with holes, or you can have the applications centralized in a hardened facility. 'course, the flipside is you're entrusting your data to a third party.
6) Vendor-lockin: if you need something changed on the server side, you only have one choice for the developers.
Oh, I know. When I needed to get something changed in Office, I have all sorts of alternatives!:)
In short, I think your mistake is in thinking that SaaS is out to replace either home desktop applications or custom in-house software. Personally, I just don't see those as being the marketplace for SaaS (unless the applications are extremely cheap or free, as in the case of the Google App suite). Where I think it'll win is in replacing COTS software that's normally rolled out in business deployments -- things like word processors, spreadsheets, email, calendaring, and so forth.
Perhaps you're referring to the footprints in the Apollo 14 image?
Shoot, yes, you're right, I was referring to the Apollo 14 markings. Regardless, if the Apollo 14 markings are visible, it's quite reasonable to assume the Apollo 11 site is also fairly pristine.
Those footprints go quite a long ways away from the LM and due to the pixelation of the image it's hard to tell just how well-preserved they might be that close to the descent stage.
Certainly true, which is why I phrased my language in the form of speculation. I never said the prints were definitely preserved. I'm simply saying they could be, as the descent stage may have protected them.
You are aware that most (if not all) of the footprints were obliterated by the rocket that took the astronauts off the moon, right?
Uh, no they weren't. In fact, you can see the tracks of the astronauts in the latest images of the Apollo 11 landing site returned by the Lunar Reconnaissance Orbiter.
Aldrin's famous first footprint exists only as a photograph.
That's not at all obvious. When the rockets of the ascent stage were fired, thus beginning the return to rendezvous with Columbia, the surface of the moon may have been shielded by the components of the LM that were left behind.
Marschaling is still required, but you don't need to think about being restricted to a schema, columns, types, to define identifiers for everything, to do explicit joins, etc. Just store your objects as they are in memory.
Well, that's all very interesting, but it doesn't sound any different than your average OODBMS, something which has been around for a *long* time (I worked with Versant nearly a decade ago doing exactly what you describe). Heck, the Smalltalk world has had intelligent object databases for years (Gemstone comes to mind, among others). So, again, what's the big deal?
As an aside, I'm also not convinced that being forced to a define a proper schema for one's data, that's separate from the overlaying object model, is necessarily as bad a thing as you seem to think. Nor is it that difficult, given how intelligent ORMs are these days. But, when it comes down to it, that's as much a philosophical argument as anything else.
When what we want is just to retrieve a record, calling get(id) is way easier and more secure than building an SQL statement, and way cheaper than using an ORM.
"Cheaper" in what sense? You can't mean cost, as I'm not aware of ORMs introducing any cost overhead. So presumably you mean the cost of marshaling the data between SQL and your object model.
So, how, pray tell, do these new magical DBs convert the stored data to/from objects that your software can consume? Do they not marshal at some level? And if so, how is it that they're any cheaper than an ORM layer built over a relational database?
It's a *cycle*. While it's true that we're climbing out of a particularly deep minima (and it's not really *that* deep... just deeper than usual), we've still had, what, ten or so perfectly normal peaks since noctilucent cloud formation began to climb. If the latter was attributable to the former, then cloud formation would increase and decrease with the solar cycle, but that hasn't been observed, so sun spots (and hence the solar wind) can't be the cause.
Yes, congratulations, you're cognizant of the fact that we're on the way out of a solar minima on the way to the next peak, as part of a regular 11-year sunspot cycle. Good for you.
So how, exactly, can that explain a century-long trend? Oh... that's right... it *can't*. Which was my entire point. It's not like the solar wind has been gradually declining in intensity of decades, as his theory would imply. It's simply on the downward end of a decade-long swing.
Unless, by "recently", he meant decades, his post makes absolutely no fucking sense (and given his followup responses, it's clear he has no idea what he's talking about), as a 5-year dip in the solar wind clearly bears no relationship to a century-long trend.
Hence my criticism. Either he meant the last 5 years, in which case his post makes absolutely no sense, or he meant a longer timeframe, in which case he's simply wrong. Either way, his little theory is demonstrably false.
Do we have data on the solar wind for prior to 25 years ago
Indirectly, yes. NOAA makes available the Sunspot record from 1874 - present, and given you freely admitted that sunspot rates and the solar wind are directly correlated, you can use the former to infer the intensity of the latter.
Sunspots themselves don't generate the solar wind, but a reduction in sunspot activity correlates with a decreased solar wind.
So you understand this, yet you don't understand the concept of sunspot *cycles*? Odd...
And yes, the solar wind is at a record low.
No, it *was* at a record low. Last September, during the depths of the solar minimum. It was not at a record low 5 years ago, during the height of the sunspot cycle. And it's on it's way back up as the current sunspot cycle begins to ramp back up.
Meanwhile, noctilucent cloud formation has been on the rise for decades (as the article posits, potentially for the last one hundred years). Now, tell me, can you see the contradiction between your theory (a link to sunspots, which *cycle* every 11 years) and this fact? Come on, you can do it!
OOC, is it confirmed that Australia's issues are actually due to GW? Because, as I'm sure you already know, AU is supposed to have regular drought cycles as a consequence of the ENSO, as well... 'course, the one may very well be exacerbating the other.
city lights bouncing off these high altitude clouds.
ROFL, thus proving you have no fucking idea what you're talking about.
Try learning about what noctilucent clouds actually are before shooting your mouth off and making yourself look like an idiot (hint, city lights probably aren't going to reflect off clouds that are 75km up and hundreds of km north).
Since up until very recently there's been a sunspot drought, this might indicate a cause.
Uh, no, there hasn't. Unless, by recently, you mean the last 4-5 years or so, since the peak of the previous sunspot cycle. Heck, there've been numerous sunspot cycles over the past 100 or so years, while the frequency of noctilucent cloud formation has steadily increased. Furthermore, this particular minimum isn't that much longer than previous ones (longer than average, yes, but not excessively so when compared to previous minima).
Honestly, do you normally just make up facts to support your opinions?
Slashdot Mirror
If I lived in a country like Russia (or Canada, Norway, Finland, etc, for that matter), I'd be an enthusiastic supporter of anything that might even possibly tip the balance of the climate towards Global Warming for exactly these sorts of reasons
Then you're an idiot. Speaking as a Canadian, agriculture and forestry are extremely important to our economy, and global warming threatens to destroy both, thanks to drought and the advance of the pine beetle.
When someone gets sued or fired for an offhand remark, in any medium, our response ought to be, "That's not right!" rather than, "Deal with it, that's the way it is."
Interesting. And I would claim the precise opposite: that it's unreasonable for a person to feel they can publish a letter in a newspaper with absolute impunity, let alone a comment on a website. Remember, the first amendment outlines limitations on the government, not private employers or individuals.
Now, that's not to say that I believe the employer has a right to terminate the employee based solely upon comments posted outside the workplace. At best, that's an awfully fuzzy situation that probably depends on the nature of the job and the nature of the material that was published. But it's certainly not a black-and-white situation, and I believe that's true irrespective of the medium. The advent of the Internet just means a lot more people will find themselves grappling with this very issue.
But with respect to this particular issue, the difference isn't -- or shouldn't be -- all that great.
Except, of course, that it is. And why? Specifically because it's easier. Most people I know have never once in their lives written a letter to the editor. Why? Because it's a pain in the ass and not worth the trouble. Not only do you actually have to break out a pen and paper (or god forbid a computer) and write the damn thing out, you actually have to get an envelope and a stamp and send it. People who would go through that trouble a) actively make a choice to have their opinions heard, and b) understand that, in having such a letter published, they are, in effect, becoming amateur journalists.
We should apply the same standard to online communication as we do to printed and hand-written
But that's the whole point. People don't. At least, the people doing the writing don't. And the reason is simple: the web has made it possible for a stupid, off-the-cuff comment to be published online in mere seconds, available for the whole world to see. The difference in ease isn't just substantial. It's revolutionary. And it opens the door for people to embarrass themselves publicly in ways they never would have in the past, as the low barrier of entry means people a) don't think before they publish, and b) don't think of hitting "Submit" as an act of publication in the first place.
So, does the difference in medium change the legality of the situation? No, of course not. Publication is publication. But it substantially changes the sociological and psychological factors which feed into the decision to publish or not publish something.
There is nothing about social networking to distinguish it from previous publishing modalities except that it is faster and easier to publish something far and wide than it ever was before.
So, there's no difference, in the same way that the printing press was really just a minor improvement over scribes. Yup, no big deal at all!
Python is better than Perl because for beginners would takes weeks just to learn all the different possibilities of IF branches in Perl.
Because, when teaching a language you have to teach the *entire* language? Well, sucks to be a C++ programmer.
Seriously, that's the dumbest anti-Perl argument I've heard yet...
It is not as hard-core as lisp or smalltalk
Hard core? What? Smalltalk is *dead easy* to learn, and syntactically extremely simple and consistent. It's certainly no more difficult than any other OOP language, and as a plus, you don't have to worry about compilers, IDEs, and all that other garbage. Heck, Squeak + E-Toys is *explicitly designed as a learning environment*.
Because <my language> is better than <your language>! And here on Slashdot, we need few reasons to enjoy a good language war. So go away with your "reason" and "logic"! We've got a pointless battle to fight!
And for the record:
1) Java and C# suck because they require N levels of nesting before they can type "Hello World".
2) Assembly/C sucks because they're too low-level.
3) C++ sucks because it's horribly byzantine.
4) Scheme/Lisp/Haskell sucks because they're confusing.
5) Python/Perl/Scripting language du jour sucks because they're garbage collected and hide too much from the programmer.
6) Every other language sucks because it's not my favorite language.
Yeah, fuck those filthy crooks at the EFF!
As soon as you start adding files, network connections, etc. into the mix then you start having to do manual memory management in Java
So don't use Java. C# has using blocks which call Dispose() on your object when they're exited, whether that be through normal program flow or abnormal exit.
In short: don't assume all languages with a GC suck just because Java does.
Yes, if you need to grow your business and all you can hire are dumb@$$3$ then yes, stick with Java (or C#).
Wow, so all the programmers you hire are perfect little automata that never make mistakes? Impressive! Where did you find such miracles of science?
And how much of a hit in performance are you taking when garbage collector turns on? How many times a minute does it fire and what happens to all those threads that are blocking?
Depends on the GC. There's a reason Sun provides a bunch of alternative implementations which have various performance characteristics that are better for different workloads.
On the flipside, how often do you see a crash because of a bad pointer reference, or worse, a security hole available to the world because of a buffer overflow in the code your perfectly little automata hacked up?
There was a time when people expected computers to be fast.
They also expect them to be stable and secure. Hint: speed isn't the sole requirement for most applications, and in fact isn't even the top one most of the time.
1) java failed to support variables in stack, and the whole VM/GC thing is horrible.
Uh, variables on the stack isn't required to build "correct programs". Meanwhile, I would argue that a GC *helps* you do just that.
haskell failed in supporting for-loops
Haskell failed because of *for-loops*? WTF?
Heck, even if that made any sense (which it doesn't, at least to my feeble brain, as, AFAICT, for-loops aren't even necessary, let alone a deal-breaker), how is mapM_ not perfectly sufficient?
4) python failed when it's performance is not very good
Also not "required" for making "correct programs". Is Python necessarily suited to all application domains? No (although it's strong FFI means you can probably use it for most). But it's still a perfectly fine language when used appropriately.
5) C# failed because it's from microsoft
ROFL, how does that stop you from building "correct programs"? Oh right, it doesn't. It's just blind dogma.
Frankly, it sounds to me like you're just looking for feeble excuses so you can slink back to the comfort of C++.
Whatever happened to SaaS? Oh, still not really here is it?
a) What do you think "cloud computing" is, exactly? That's right... SaaS.
b) What do you think gmail and the rest of the Google app suite is?
No, SaaS, as a concept, is alive and well. Will it grow and turn into an actual money-making endeavour? That I don't know.
Or "Web Services?" In the end, its just another way to move data around... nothing really revolunatary.
Funny, given there's web services *everywhere*. Amazon exposes their API through a web service. Facebook exposes their API through a web service. The list goes on. In fact, web services have been wildly successful in exactly the way intended: they've provided real, portable API-level integration between web applications.
And that's ignoring all the *other* applications that are exposing their data and APIs through web services.
So, revolutionary? No, of course not. Who said they would be? A further evolution of the web, and a successful one? Absolutely.
1) Flexibility: difficult to mold SaaS solution to your specific business operations.
I'm not sure I've seen anyone proposing replacing in-house or custom built software with SaaS. It's for things like Word or other "stock" applications that you'd otherwise mass-deploy.
2) Reliability: requiring a connection to the internet adds an additional point of failure.
Well, I think in today's day and age, with large volumes of corporate inter-communication occuring over the internet (I get a lot of my correspondence with outside consultants and corporations done via email), a company's internet connection is *already* an SPF. And that's doubly true for organizations that are geographically dispersed and use internet connectivity to connect their sites (sure, you can try and replicate services, etc, but in the end, if that internet connection goes down, it's a big problem).
3) Speed: easy to get 40mbps internally. Internet connect is more likely to be 1.5mbps split 50 ways.
Sure, if your provider sucks. :) Either way, the real question is, how much bandwidth is really needed? A well developed web-deployed application does an awful lot of work client side. I mean, do you really think the Google Spreadsheet is constantly hitting the server? No, of course not.
It's an interesting question, though... I wonder if anyone's done any bandwidth studies to see how much bandwidth, say, 100 users using Google Apps would actually take up.
4) Cost: from what I have seen, SaaS is not especially cheap.
That's absurd. Compared to, say, a large scale per-seat licensing of Microsoft Office, I can't see how SaaS can be anything *but* cheaper. Add in the savings in deployment and upgrade costs, and I'd be shocked if it wasn't cheaper in the long run, too.
5) Security: debatable.
Yes, it is. Let's see, you can have thousands of users running an application littered with holes, or you can have the applications centralized in a hardened facility. 'course, the flipside is you're entrusting your data to a third party.
6) Vendor-lockin: if you need something changed on the server side, you only have one choice for the developers.
Oh, I know. When I needed to get something changed in Office, I have all sorts of alternatives! :)
In short, I think your mistake is in thinking that SaaS is out to replace either home desktop applications or custom in-house software. Personally, I just don't see those as being the marketplace for SaaS (unless the applications are extremely cheap or free, as in the case of the Google App suite). Where I think it'll win is in replacing COTS software that's normally rolled out in business deployments -- things like word processors, spreadsheets, email, calendaring, and so forth.
Perhaps you're referring to the footprints in the Apollo 14 image?
Shoot, yes, you're right, I was referring to the Apollo 14 markings. Regardless, if the Apollo 14 markings are visible, it's quite reasonable to assume the Apollo 11 site is also fairly pristine.
Those footprints go quite a long ways away from the LM and due to the pixelation of the image it's hard to tell just how well-preserved they might be that close to the descent stage.
Certainly true, which is why I phrased my language in the form of speculation. I never said the prints were definitely preserved. I'm simply saying they could be, as the descent stage may have protected them.
You are aware that most (if not all) of the footprints were obliterated by the rocket that took the astronauts off the moon, right?
Uh, no they weren't. In fact, you can see the tracks of the astronauts in the latest images of the Apollo 11 landing site returned by the Lunar Reconnaissance Orbiter.
Aldrin's famous first footprint exists only as a photograph.
That's not at all obvious. When the rockets of the ascent stage were fired, thus beginning the return to rendezvous with Columbia, the surface of the moon may have been shielded by the components of the LM that were left behind.
Marschaling is still required, but you don't need to think about being restricted to a schema, columns, types, to define identifiers for everything, to do explicit joins, etc. Just store your objects as they are in memory.
Well, that's all very interesting, but it doesn't sound any different than your average OODBMS, something which has been around for a *long* time (I worked with Versant nearly a decade ago doing exactly what you describe). Heck, the Smalltalk world has had intelligent object databases for years (Gemstone comes to mind, among others). So, again, what's the big deal?
As an aside, I'm also not convinced that being forced to a define a proper schema for one's data, that's separate from the overlaying object model, is necessarily as bad a thing as you seem to think. Nor is it that difficult, given how intelligent ORMs are these days. But, when it comes down to it, that's as much a philosophical argument as anything else.
When what we want is just to retrieve a record, calling get(id) is way easier and more secure than building an SQL statement, and way cheaper than using an ORM.
"Cheaper" in what sense? You can't mean cost, as I'm not aware of ORMs introducing any cost overhead. So presumably you mean the cost of marshaling the data between SQL and your object model.
So, how, pray tell, do these new magical DBs convert the stored data to/from objects that your software can consume? Do they not marshal at some level? And if so, how is it that they're any cheaper than an ORM layer built over a relational database?
Yes, "is". It's too early to say that we're climbing out of it just yet
Incorrect. The next sunspot cycle has already begun.
It's a *cycle*. While it's true that we're climbing out of a particularly deep minima (and it's not really *that* deep... just deeper than usual), we've still had, what, ten or so perfectly normal peaks since noctilucent cloud formation began to climb. If the latter was attributable to the former, then cloud formation would increase and decrease with the solar cycle, but that hasn't been observed, so sun spots (and hence the solar wind) can't be the cause.
Yes, congratulations, you're cognizant of the fact that we're on the way out of a solar minima on the way to the next peak, as part of a regular 11-year sunspot cycle. Good for you.
So how, exactly, can that explain a century-long trend? Oh... that's right... it *can't*. Which was my entire point. It's not like the solar wind has been gradually declining in intensity of decades, as his theory would imply. It's simply on the downward end of a decade-long swing.
Unless, by "recently", he meant decades, his post makes absolutely no fucking sense (and given his followup responses, it's clear he has no idea what he's talking about), as a 5-year dip in the solar wind clearly bears no relationship to a century-long trend.
Hence my criticism. Either he meant the last 5 years, in which case his post makes absolutely no sense, or he meant a longer timeframe, in which case he's simply wrong. Either way, his little theory is demonstrably false.
Do we have data on the solar wind for prior to 25 years ago
Indirectly, yes. NOAA makes available the Sunspot record from 1874 - present, and given you freely admitted that sunspot rates and the solar wind are directly correlated, you can use the former to infer the intensity of the latter.
Sunspots themselves don't generate the solar wind, but a reduction in sunspot activity correlates with a decreased solar wind.
So you understand this, yet you don't understand the concept of sunspot *cycles*? Odd...
And yes, the solar wind is at a record low.
No, it *was* at a record low. Last September, during the depths of the solar minimum. It was not at a record low 5 years ago, during the height of the sunspot cycle. And it's on it's way back up as the current sunspot cycle begins to ramp back up.
Meanwhile, noctilucent cloud formation has been on the rise for decades (as the article posits, potentially for the last one hundred years). Now, tell me, can you see the contradiction between your theory (a link to sunspots, which *cycle* every 11 years) and this fact? Come on, you can do it!
OOC, is it confirmed that Australia's issues are actually due to GW? Because, as I'm sure you already know, AU is supposed to have regular drought cycles as a consequence of the ENSO, as well... 'course, the one may very well be exacerbating the other.
city lights bouncing off these high altitude clouds.
ROFL, thus proving you have no fucking idea what you're talking about.
Try learning about what noctilucent clouds actually are before shooting your mouth off and making yourself look like an idiot (hint, city lights probably aren't going to reflect off clouds that are 75km up and hundreds of km north).
Since up until very recently there's been a sunspot drought, this might indicate a cause.
Uh, no, there hasn't. Unless, by recently, you mean the last 4-5 years or so, since the peak of the previous sunspot cycle. Heck, there've been numerous sunspot cycles over the past 100 or so years, while the frequency of noctilucent cloud formation has steadily increased. Furthermore, this particular minimum isn't that much longer than previous ones (longer than average, yes, but not excessively so when compared to previous minima).
Honestly, do you normally just make up facts to support your opinions?