The fact that they only used creative commons images suggests there's an actual legal issue with proprietary images, but why? If I save an image from a website to my hard drive, without sharing it, does that make me a criminal? I've been training my brain on face recognition with proprietary images for decades. I've even occasionally indirectly made money from the viewing of proprietary images, as has everyone else.
Should I pay a royalty every time I imagine a proprietary image I've previously seen?
I've asked this question of at least three different IP Lawyers. And for once I got exactly the same damned answer. If you aren't redistributing the images and are just using them as training data and the images can't be reproduced somehow from the result of the training you did not infringe copyright.
So as far as I can tell it does not really matter what the copyright status of the images are with respect to using them for machine or deep learning. It seems reasonable to me that you could rip all the _Star Wars_ episodes and use those images for training and you wouldn't be at any legal risk. Now if you ripped them and redistributed the training set as images you would of course have a problem.
is security, then that would be just an example of security hy obscurity.
Three examples where I think open-sourcing software used by the government would be insane:
(1) Offensive cyber weapons. If they are even allowed to exist at all, I don't want my government supplying script kiddies with scary dangerous zero-day exploits.
(2) Software used in weapon systems. Why should we make it easier for adversaries to clone our tech? And why should we make it easier for them to come up with countermeasures for those systems?
(3) Some software used in the criminal justice, law enforcement, and federal court system. This is a bit more ambiguous, but it is plausible to me that someone could use that software to either game the court system and make sure their cases only came before judges who would rule more favorably towards them, or could use them to make it more difficult for law enforcement to detect and combat criminal activities.
I'd add that a lot of the skillset that the article criticizes is often desperately needed.
That "theorem-proving" mentality is extremely handy if you are writing subtle code. It will at least make that code easier to debug.
Understanding data structures is very useful when you are tackling a representation problem. And understanding when you have a representation problem and how to deal with the tradeoffs that inevitably happen is a big chunk of most programming projects.
Being exposed to different programming languages can give you more intellectual tools to describe a problem.
TFA didn't really mention it, but CS is also useful when you need to design an algorithm. And also for recognizing when you need to design an algorithm.
That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.
My first observation about C++ is that the best examples of clean, well-written code in C++ tend to use a very constrained subset of the language.
My next observation is that over the years many of the features added to C++ seem to be very obscure and seem to address odd corner cases. I suspect this is because of some deep design flaw in the language.
C++ tends to reward a programmer who can design clean, graceful interfaces that can successfully evolve over their lifetimes. And C++ mercilessly punishes programmers who cannot do that. Unfortunately, the vast majority of programmers cannot design clean, graceful interfaces. And very few programmers can do so all the time.
So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.
Personally I think Rails killed (or is still killing) Ruby. Largely because Rail apps scale poorly and beyond a very basic level become hopelessly unmaintainable.
I agree that Python is quickly becoming dominant in the scripting language space. Largely because of libraries like scikit. And bluntly, this isn't the 1980's anymore. Back in the day you coded in C except where you had to jump into assembly for a bit of speed. But these days I think the right design slice is to do the performance-critical parts in C (or maybe C++ or something similar) and use a scripting language as the glue code.
There are a lot of things about Ruby that I think are awesome and much better than comparable languages (my favorites is how the pattern-matching operator ties into switch/case statements and exception handling). But the world is moving on and sadly, Ruby is likely to be left behind.
Citation needed on the "engineers wanted a higher seawall" claim, too. And more than just one or two random people - show that there was any sort of serious belief among the engineering team responsible for the plant that the seawall wasn't high enough.
"Warnings: Finding Cassandra to stop Catastrophes" by Richard A. Clarke and R.P. Eddy has an entire chapter (Chapter 5) discussing what might have prevented the Fukushima disaster. From Chapter 5:
A Stanford study in 2013 concluded that any one of three key improvements could have mitigated or prevented all this from happening at Fukushima Daiichi: plant elevation, seawall height, or the relocation of the plant’s backup generators. Higher seawalls would have prevented the tsunami’s waters from spilling over into the plant, even situated where it was and at the elevation it was. Alternatively, higher plant elevation would have prevented the tsunami from damaging key components, such as the backup generators. Even just elevating and waterproofing the backup generators, or not installing them in the basement in the first place, would have made a major difference and could have potentially averted the crisis altogether. Okamura had suggested all three things in 2009.
Clarke, Richard A.. Warnings: Finding Cassandras to Stop Catastrophes (p. 89). HarperCollins. Kindle Edition.
I'll add that during the construction of the Fukushima plant the site was lowered by eighty feet to make construction more convenient. So elevating the site was definitely a possibility and probably quite feasible.
I think the historical analogies have a lot of weight, though.
Probably the most pertinent, and controversial at the time, was the enormous land grants given to transcontinental railroads. The land grants worked out to approximately ten square miles of land for every mile of track. That was on top of generous subsidies for actually laying the track. When the land grants were extended to mineral rights as well it became an even better deal for the Union Pacific. Plus, there was a requirement that these railroads be built with American steel -- which was a boon to Andrew Carnegie and others.
A little bit later, the early electric lighting companies, most notably Edison's, were given generous contracts by local governments to provide lighting for their cities. Much later on, the federal government got into the game and subsidized a great local public power companies.
Early development of aircraft was largely subsidized by nearly every government who could get into the game, Aside from the obvious military applications there was enormous demand for mail service and to a lesser extent for passenger service -- largely supported by governments.
You could argue that the early (post WWII) computer industry was largely subsidized by the US government.
I just have to conclude that the article referenced here sets some kind of world record for abysmal ignorance and willful blindness. It doesn't surprise me that thehill.com would publish such tripe.
No. what I'm afraid of is that if they are trying to find large-scale voter fraud they are asking for the wrong data. The data they are asking for looks (to me) like the kind of data you'd want for a voter-targeting database.
All you need to find voter fraud is first name, last name, zip code, and which of the last dozen or so elections they voted in.
If you want to look for undocumented immigrants voting illegally, look in zip codes that (according to the US Census) have a high proportion of undocumented immigrants. Look for changes in voter turnout in those zip codes. If voter turnout in those zip codes is persistently and significantly increasing, you need to collect more data and look more closely, because you might have found evidence that undocumented immigrants are voting.
For multi-voters and dead voters, use the Social Security data. If Social Security only knows about 15 living Gertude Higglesteins but 21 Gertude Higglesteins voted, you have a problem.
Note that a better statistician who had more time could come up with better tests. The point is at this point we need to place upper and lower limits on the prevalence of fraudulent voting. I'm all for an independent look into that. And we can easily do it without creating a big fat juicy database that someone could steal and use for nefarious purposes.
Power is energy per unit time. And pumping unleaded into your Toyota represents about 15MW of power. If you have an electric car charging setup that charges as quickly as you pump gasoline, you will have approximately the same power transfer.
So what is the connector going to look like? Are you going to want to be anywhere near it while your car is charging?
Which leads to another question. Charging a battery is not one hundred percent efficient. Even with very efficient designs you are probably going to have ten percent power loss. That would represent approximately 1.5MW of waste heat. Enough that you could easily use the passenger compartment of your car as a kiln. Where would that waste heat go? And how do you keep your car from melting?
All relationships (e.g. inheritance, type) would automatically be dynamic. A framework for doing static typing and inheritance would be provided as part of the runtime.
Similarly, all components could be naturally and transparently distributed with little or no additional code complexity. That infinite speed could be kept busy making sure there are no race conditions.
Finally, no control structures in the language itself -- all control structures would be part of the runtime and it should be straightforward (if not easy) to add new ones (think Smalltalk or Ruby).
There are hellacious unknowns here. Some of them probably can only figured out by running an experiment on the only planet we currently have.
Evidence from volcanic eruptions indicates that producing cooling effects this way depends dramatically on where you distribute the dust (high latitudes don't seem to work as well, and seeding the area from Indonesia to the Philippines seems to produce more cooling than similar latitudes in South America). There is also probably a pretty strong upper limit on how much climate forcing you can produce with this method, and you'd probably rapidly get into a diminishing returns situation -- simply put, beyond a certain point putting more stuff into the stratosphere won't produce more cooling and might actually make the stuff you've got in the stratosphere precipitate out more quickly. The effects probably change dramatically depending on the state of the ENSO cycle as well.
The follow-on effects would be mind-bogglingly complex. You might cause drought in some areas (e.g. India, western North America) and insane rainfall in other places.
Presumably you tagged the sources that went into the build that went to your customers?
If you did, when you make bug fixes you need to check out against that tag, not to the bleeding edge code where new features are being added.
Depending on how many fixes there are and how complex and messy the source tree is, you can either try to merge the changes into your bleeding edge code base or make the changes twice. In general, if the bleeding edge is being vigorously refactored or otherwise aggressively reorganized, you'll probably end up making the changes twice. Something that isn't often brought up when refactoring is how you will handle merging bug fixes.
It is best to have one developer who drives the source control system and knows how to do merges.
If you didn't tag the sources you released to customers, you and your entire team needs to be shot.
In the 1960's and 1970's compilers, and particularly COBOL compilers, were very expensive. They could easily cost more than a decent home.
This produced an interesting business model where a few programmers who happened to own a compiler would write custom software for various businesses. When the business wanted their software modified, they could contact the original authors and pay them to make the changes. Nice business model with a nice lock-in, The problem was that sometimes the software writers would quit, get real jobs, or otherwise be unavailable. Or the business would be too cheap to hire them again.
So rather than modify the COBOL sources they would just patch the binary. Many compilers of that era also had options to allocate "patch space" in the binary to make that patching easier still (I use the term "easier" in a relative sense). Lather, rinse, and repeat for three decades and you have a situation where there isn't any reasonable source code to port or edit.
From the perspective of someone who wrote BBSes during the 1980's (Stonehenge, &c) what I find interesting is that the social problems associated with message systems are still largely the same (twits, trolls, spammers, and those who shout lies louder than those who speak truth). Every now and then I read about someone in the modern era who has a "new idea" (e.g. "selective invisibility" for obnoxious trolls) which was invented thirty years ago (and probably before that) by multiple folks working independently.
I remember the biggest struggle was making sure that networked messages didn't just circulate forever. Given the limited memory and mass storage and slow processing speeds I ended up with a primitive-but-effective combination of hop counts, expiration dates, and a use window. None of that is of much practical use today but the struggle to make it more or less work was an important experience for a then-larval coder. Actually, a lot of the interesting problems of that time were making relatively cheap and primitive hardware do something useful in a reasonable amount of time.
I suspect strongly that the universe does have a clock.
Consider the Cosmic Microwave Background. The average temperature of the CMB is a function of the age of the universe, and should be pretty close to the same for any given reference point. Yes, I'd agree it isn't a very accurate clock, but it is indeed a clock.
Similar arguments work with the distance to the cosmic horizon.
... The scientists will sit back in their air-conditioned offices and say, well I guess we were wrong about that but at least we advanced science by performing this experiment.
Probably the biggest experiment that we'd be conducting is about pollination. Mosquitoes (and other flies) do pollinate quite a few plant species.
Sometimes pollination is incredibly fussy and sometimes only one species specializes in pollinating a given plant. So one of the unintended consequences here might be the disappearance of one or more plant species. Of course, something else absolutely critical to the ecosystem will depend on one or more of the plants that are no longer pollinated...
It is obvious that mother nature loves to write spaghetti code.
Positive examples are good. So are negative ones. I'd recommend giving a novice ownership of a large, ugly, very messy, but heavily used hunk of software and have them "clean it up". The ones that don't kill themselves will become professional programmers.
If they require a special character and uppercase in their passwords, I usually add something like ";DROP TABLE users;" to the end of my password -- that'll show 'em.
I still haven't figured out why somebody's blog needs 16-character passwords with a dozen rules and the IRS settles for a five-digit PIN code....
Yes, as a completely fabricated story without any basis in fact or proof. This was a democrat talking point and was denied by Assange multiple times.
The DNC attack used twitter and photos posted to algorithmically generated accounts to exfiltrate data. The algorithms and encryption keys were identical to other attacks attributed to the Russians, most notably the JCS and White House Executive office attacks.
The attackers honored Russian government holidays and working hours compatible with people working in Moscow or St. Petersburg.
Word documents provided by Wikileaks were produced on a machine with a version of MS Word registered to the Russian Government. Later Word documents provided by Wikileaks had that provenance sanitized before release, along with mac addresses and IP addresses of the host where the document was produced.
I am often struck by the way that the current debate about intermittent renewable power is strikingly similar to the arguments between net heads and bell heads two decades previously. The funny part from a historical standpoint is that both were kind of right.
You also miss an important point. The other factor that is important in power generation is if it is dispatchable. By dispatchable I mean can she adjust the power generated quickly to meet demand. Current nuclear and coal plants require long startup times and current nuclear plants can't throttle their power output very well, which makes them much less valuable in a world with a lot of renewables. Combined-cycle natural gas, on the other hand, is easy and quick to start up so it is very dispatchable.
There are a few other factors that somewhat mitigate the intermittent nature of solar and wind. The first one, kind of obvious, is that you know more or less in the near future how much power you will be able to produce from these sources (we know when the sun rises and sets, and weather forecasts 24 hours out are fairly accurate -- especially if you just want to know if it will be sunny or windy). The other is that if we have a larger geographical distribution for solar and wind, the intermittency problem is somewhat mitigated -- it is unlikely to be cloudy and windless everywhere at the same time. Finally, there are other ways to store energy than batteries. If you have an old-style hot water heater rather than an on-demand system, you are essentially storing energy in the hot water tank -- and it would be plausible to have a system that would heat your hot water when the sun is shining or the wind is blowing. You can do similar things with heating and air conditioning systems in buildings, and even to a lesser extent in refrigerators or freezers.
You will still need some storage, but probably not as much as you think.
There are reasons to go solar that don't necessarily correlate to economies of scale. My own story is a case in point. I broke down and installed an 8kw array on my roof, mainly as backup power. Where I live we've had a few catastrophic power outages in recent years (caused by fires). When I worked out the cost on a generator, piping from the propane tank to the generator, and a shack to put the generator in, it came out within a MacBook Pro of what that 8kw array, inverter, and installation (I admit I got a deal on the panels, but not much of one) cost. Maintenance is a wash -- either hire a high school kid to shovel snow off the panels a few times each winter and wash the panels a few times each summer or pay some dude to drive out a hundred miles to service the generator once a month. This isn't even considering how much propane costs to run the generator (a lot) or the fact that I can sell surplus sun watts back to the grid.
The thing is that the costs of solar are plummeting. We've seen exactly that cost curve before, in everything from megabytes of ram to gigabytes of disk space and megaflops. But with solar it is for watts. Since there are no moving parts in PV solar (well, except for electrons and holes) the costs per watt will likely asymptotically approach zero over time. Very quickly we are approaching a situation where the dominant part of the costs to go solar are installation costs.
Slashdot Mirror
https://www.youtube.com/watch?...
The fact that they only used creative commons images suggests there's an actual legal issue with proprietary images, but why? If I save an image from a website to my hard drive, without sharing it, does that make me a criminal? I've been training my brain on face recognition with proprietary images for decades. I've even occasionally indirectly made money from the viewing of proprietary images, as has everyone else.
Should I pay a royalty every time I imagine a proprietary image I've previously seen?
I've asked this question of at least three different IP Lawyers. And for once I got exactly the same damned answer. If you aren't redistributing the images and are just using them as training data and the images can't be reproduced somehow from the result of the training you did not infringe copyright.
So as far as I can tell it does not really matter what the copyright status of the images are with respect to using them for machine or deep learning. It seems reasonable to me that you could rip all the _Star Wars_ episodes and use those images for training and you wouldn't be at any legal risk. Now if you ripped them and redistributed the training set as images you would of course have a problem.
This!
I'd also add Demarco & Lister's Peopleware: Productive Projects and Teams. Another oldie but a goodie.
is security, then that would be just an example of security hy obscurity.
Three examples where I think open-sourcing software used by the government would be insane:
(1) Offensive cyber weapons. If they are even allowed to exist at all, I don't want my government supplying script kiddies with scary dangerous zero-day exploits.
(2) Software used in weapon systems. Why should we make it easier for adversaries to clone our tech? And why should we make it easier for them to come up with countermeasures for those systems?
(3) Some software used in the criminal justice, law enforcement, and federal court system. This is a bit more ambiguous, but it is plausible to me that someone could use that software to either game the court system and make sure their cases only came before judges who would rule more favorably towards them, or could use them to make it more difficult for law enforcement to detect and combat criminal activities.
This.
I'd add that a lot of the skillset that the article criticizes is often desperately needed.
That "theorem-proving" mentality is extremely handy if you are writing subtle code. It will at least make that code easier to debug.
Understanding data structures is very useful when you are tackling a representation problem. And understanding when you have a representation problem and how to deal with the tradeoffs that inevitably happen is a big chunk of most programming projects.
Being exposed to different programming languages can give you more intellectual tools to describe a problem.
TFA didn't really mention it, but CS is also useful when you need to design an algorithm. And also for recognizing when you need to design an algorithm.
That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.
My first observation about C++ is that the best examples of clean, well-written code in C++ tend to use a very constrained subset of the language.
My next observation is that over the years many of the features added to C++ seem to be very obscure and seem to address odd corner cases. I suspect this is because of some deep design flaw in the language.
C++ tends to reward a programmer who can design clean, graceful interfaces that can successfully evolve over their lifetimes. And C++ mercilessly punishes programmers who cannot do that. Unfortunately, the vast majority of programmers cannot design clean, graceful interfaces. And very few programmers can do so all the time.
So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.
I've used both Python and Ruby for years.
Personally I think Rails killed (or is still killing) Ruby. Largely because Rail apps scale poorly and beyond a very basic level become hopelessly unmaintainable.
I agree that Python is quickly becoming dominant in the scripting language space. Largely because of libraries like scikit. And bluntly, this isn't the 1980's anymore. Back in the day you coded in C except where you had to jump into assembly for a bit of speed. But these days I think the right design slice is to do the performance-critical parts in C (or maybe C++ or something similar) and use a scripting language as the glue code.
There are a lot of things about Ruby that I think are awesome and much better than comparable languages (my favorites is how the pattern-matching operator ties into switch/case statements and exception handling). But the world is moving on and sadly, Ruby is likely to be left behind.
Hmmmm...
I don't think you could fit California, Utah, Oregon, Massachusetts, Florida, or Quebec into that mold.
Citation needed on the "engineers wanted a higher seawall" claim, too. And more than just one or two random people - show that there was any sort of serious belief among the engineering team responsible for the plant that the seawall wasn't high enough.
"Warnings: Finding Cassandra to stop Catastrophes" by Richard A. Clarke and R.P. Eddy has an entire chapter (Chapter 5) discussing what might have prevented the Fukushima disaster. From Chapter 5:
A Stanford study in 2013 concluded that any one of three key improvements could have mitigated or prevented all this from happening at Fukushima Daiichi: plant elevation, seawall height, or the relocation of the plant’s backup generators. Higher seawalls would have prevented the tsunami’s waters from spilling over into the plant, even situated where it was and at the elevation it was. Alternatively, higher plant elevation would have prevented the tsunami from damaging key components, such as the backup generators. Even just elevating and waterproofing the backup generators, or not installing them in the basement in the first place, would have made a major difference and could have potentially averted the crisis altogether. Okamura had suggested all three things in 2009.
Clarke, Richard A.. Warnings: Finding Cassandras to Stop Catastrophes (p. 89). HarperCollins. Kindle Edition.
I'll add that during the construction of the Fukushima plant the site was lowered by eighty feet to make construction more convenient. So elevating the site was definitely a possibility and probably quite feasible.
All good points.
I think the historical analogies have a lot of weight, though.
Probably the most pertinent, and controversial at the time, was the enormous land grants given to transcontinental railroads. The land grants worked out to approximately ten square miles of land for every mile of track. That was on top of generous subsidies for actually laying the track. When the land grants were extended to mineral rights as well it became an even better deal for the Union Pacific. Plus, there was a requirement that these railroads be built with American steel -- which was a boon to Andrew Carnegie and others.
A little bit later, the early electric lighting companies, most notably Edison's, were given generous contracts by local governments to provide lighting for their cities. Much later on, the federal government got into the game and subsidized a great local public power companies.
Early development of aircraft was largely subsidized by nearly every government who could get into the game, Aside from the obvious military applications there was enormous demand for mail service and to a lesser extent for passenger service -- largely supported by governments.
You could argue that the early (post WWII) computer industry was largely subsidized by the US government.
I just have to conclude that the article referenced here sets some kind of world record for abysmal ignorance and willful blindness. It doesn't surprise me that thehill.com would publish such tripe.
No. what I'm afraid of is that if they are trying to find large-scale voter fraud they are asking for the wrong data. The data they are asking for looks (to me) like the kind of data you'd want for a voter-targeting database.
All you need to find voter fraud is first name, last name, zip code, and which of the last dozen or so elections they voted in.
If you want to look for undocumented immigrants voting illegally, look in zip codes that (according to the US Census) have a high proportion of undocumented immigrants. Look for changes in voter turnout in those zip codes. If voter turnout in those zip codes is persistently and significantly increasing, you need to collect more data and look more closely, because you might have found evidence that undocumented immigrants are voting.
For multi-voters and dead voters, use the Social Security data. If Social Security only knows about 15 living Gertude Higglesteins but 21 Gertude Higglesteins voted, you have a problem.
Note that a better statistician who had more time could come up with better tests. The point is at this point we need to place upper and lower limits on the prevalence of fraudulent voting. I'm all for an independent look into that. And we can easily do it without creating a big fat juicy database that someone could steal and use for nefarious purposes.
Power is energy per unit time. And pumping unleaded into your Toyota represents about 15MW of power. If you have an electric car charging setup that charges as quickly as you pump gasoline, you will have approximately the same power transfer.
So what is the connector going to look like? Are you going to want to be anywhere near it while your car is charging?
Which leads to another question. Charging a battery is not one hundred percent efficient. Even with very efficient designs you are probably going to have ten percent power loss. That would represent approximately 1.5MW of waste heat. Enough that you could easily use the passenger compartment of your car as a kiln. Where would that waste heat go? And how do you keep your car from melting?
The language should allow full introspection and reflection as well.
All relationships (e.g. inheritance, type) would automatically be dynamic. A framework for doing static typing and inheritance would be provided as part of the runtime.
Similarly, all components could be naturally and transparently distributed with little or no additional code complexity. That infinite speed could be kept busy making sure there are no race conditions.
Finally, no control structures in the language itself -- all control structures would be part of the runtime and it should be straightforward (if not easy) to add new ones (think Smalltalk or Ruby).
There are hellacious unknowns here. Some of them probably can only figured out by running an experiment on the only planet we currently have.
Evidence from volcanic eruptions indicates that producing cooling effects this way depends dramatically on where you distribute the dust (high latitudes don't seem to work as well, and seeding the area from Indonesia to the Philippines seems to produce more cooling than similar latitudes in South America). There is also probably a pretty strong upper limit on how much climate forcing you can produce with this method, and you'd probably rapidly get into a diminishing returns situation -- simply put, beyond a certain point putting more stuff into the stratosphere won't produce more cooling and might actually make the stuff you've got in the stratosphere precipitate out more quickly. The effects probably change dramatically depending on the state of the ENSO cycle as well.
The follow-on effects would be mind-bogglingly complex. You might cause drought in some areas (e.g. India, western North America) and insane rainfall in other places.
Presumably you tagged the sources that went into the build that went to your customers?
If you did, when you make bug fixes you need to check out against that tag, not to the bleeding edge code where new features are being added.
Depending on how many fixes there are and how complex and messy the source tree is, you can either try to merge the changes into your bleeding edge code base or make the changes twice. In general, if the bleeding edge is being vigorously refactored or otherwise aggressively reorganized, you'll probably end up making the changes twice. Something that isn't often brought up when refactoring is how you will handle merging bug fixes.
It is best to have one developer who drives the source control system and knows how to do merges.
If you didn't tag the sources you released to customers, you and your entire team needs to be shot.
Actually it is much, much worse.
In the 1960's and 1970's compilers, and particularly COBOL compilers, were very expensive. They could easily cost more than a decent home.
This produced an interesting business model where a few programmers who happened to own a compiler would write custom software for various businesses. When the business wanted their software modified, they could contact the original authors and pay them to make the changes. Nice business model with a nice lock-in, The problem was that sometimes the software writers would quit, get real jobs, or otherwise be unavailable. Or the business would be too cheap to hire them again.
So rather than modify the COBOL sources they would just patch the binary. Many compilers of that era also had options to allocate "patch space" in the binary to make that patching easier still (I use the term "easier" in a relative sense). Lather, rinse, and repeat for three decades and you have a situation where there isn't any reasonable source code to port or edit.
From the perspective of someone who wrote BBSes during the 1980's (Stonehenge, &c) what I find interesting is that the social problems associated with message systems are still largely the same (twits, trolls, spammers, and those who shout lies louder than those who speak truth). Every now and then I read about someone in the modern era who has a "new idea" (e.g. "selective invisibility" for obnoxious trolls) which was invented thirty years ago (and probably before that) by multiple folks working independently.
I remember the biggest struggle was making sure that networked messages didn't just circulate forever. Given the limited memory and mass storage and slow processing speeds I ended up with a primitive-but-effective combination of hop counts, expiration dates, and a use window. None of that is of much practical use today but the struggle to make it more or less work was an important experience for a then-larval coder. Actually, a lot of the interesting problems of that time were making relatively cheap and primitive hardware do something useful in a reasonable amount of time.
I suspect strongly that the universe does have a clock.
Consider the Cosmic Microwave Background. The average temperature of the CMB is a function of the age of the universe, and should be pretty close to the same for any given reference point. Yes, I'd agree it isn't a very accurate clock, but it is indeed a clock.
Similar arguments work with the distance to the cosmic horizon.
... The scientists will sit back in their air-conditioned offices and say, well I guess we were wrong about that but at least we advanced science by performing this experiment.
Probably the biggest experiment that we'd be conducting is about pollination. Mosquitoes (and other flies) do pollinate quite a few plant species.
Sometimes pollination is incredibly fussy and sometimes only one species specializes in pollinating a given plant. So one of the unintended consequences here might be the disappearance of one or more plant species. Of course, something else absolutely critical to the ecosystem will depend on one or more of the plants that are no longer pollinated...
It is obvious that mother nature loves to write spaghetti code.
Positive examples are good. So are negative ones. I'd recommend giving a novice ownership of a large, ugly, very messy, but heavily used hunk of software and have them "clean it up". The ones that don't kill themselves will become professional programmers.
Two factor authentication is a thing.
If they require a special character and uppercase in their passwords, I usually add something like ";DROP TABLE users;" to the end of my password -- that'll show 'em.
I still haven't figured out why somebody's blog needs 16-character passwords with a dozen rules and the IRS settles for a five-digit PIN code....
Yes, as a completely fabricated story without any basis in fact or proof. This was a democrat talking point and was denied by Assange multiple times.
The DNC attack used twitter and photos posted to algorithmically generated accounts to exfiltrate data. The algorithms and encryption keys were identical to other attacks attributed to the Russians, most notably the JCS and White House Executive office attacks.
The attackers honored Russian government holidays and working hours compatible with people working in Moscow or St. Petersburg.
Word documents provided by Wikileaks were produced on a machine with a version of MS Word registered to the Russian Government. Later Word documents provided by Wikileaks had that provenance sanitized before release, along with mac addresses and IP addresses of the host where the document was produced.
Nope, no evidence at all.
I am often struck by the way that the current debate about intermittent renewable power is strikingly similar to the arguments between net heads and bell heads two decades previously. The funny part from a historical standpoint is that both were kind of right.
You also miss an important point. The other factor that is important in power generation is if it is dispatchable. By dispatchable I mean can she adjust the power generated quickly to meet demand. Current nuclear and coal plants require long startup times and current nuclear plants can't throttle their power output very well, which makes them much less valuable in a world with a lot of renewables. Combined-cycle natural gas, on the other hand, is easy and quick to start up so it is very dispatchable.
There are a few other factors that somewhat mitigate the intermittent nature of solar and wind. The first one, kind of obvious, is that you know more or less in the near future how much power you will be able to produce from these sources (we know when the sun rises and sets, and weather forecasts 24 hours out are fairly accurate -- especially if you just want to know if it will be sunny or windy). The other is that if we have a larger geographical distribution for solar and wind, the intermittency problem is somewhat mitigated -- it is unlikely to be cloudy and windless everywhere at the same time. Finally, there are other ways to store energy than batteries. If you have an old-style hot water heater rather than an on-demand system, you are essentially storing energy in the hot water tank -- and it would be plausible to have a system that would heat your hot water when the sun is shining or the wind is blowing. You can do similar things with heating and air conditioning systems in buildings, and even to a lesser extent in refrigerators or freezers.
You will still need some storage, but probably not as much as you think.
There are reasons to go solar that don't necessarily correlate to economies of scale. My own story is a case in point. I broke down and installed an 8kw array on my roof, mainly as backup power. Where I live we've had a few catastrophic power outages in recent years (caused by fires). When I worked out the cost on a generator, piping from the propane tank to the generator, and a shack to put the generator in, it came out within a MacBook Pro of what that 8kw array, inverter, and installation (I admit I got a deal on the panels, but not much of one) cost. Maintenance is a wash -- either hire a high school kid to shovel snow off the panels a few times each winter and wash the panels a few times each summer or pay some dude to drive out a hundred miles to service the generator once a month. This isn't even considering how much propane costs to run the generator (a lot) or the fact that I can sell surplus sun watts back to the grid.
The thing is that the costs of solar are plummeting. We've seen exactly that cost curve before, in everything from megabytes of ram to gigabytes of disk space and megaflops. But with solar it is for watts. Since there are no moving parts in PV solar (well, except for electrons and holes) the costs per watt will likely asymptotically approach zero over time. Very quickly we are approaching a situation where the dominant part of the costs to go solar are installation costs.