The article you cite says his disclosures did not lead to any deaths of any military sources. Many believe Manning's leaks precipitated the Arab Spring which could have a death toll over 30,000. And it certainly crippled foreign relations (with the revelations in the e-mails) and may have made the US military and diplomatic processes somewhat less effective in areas where lives were and are at stake.
Also, whistle-blower laws are not automatic, (and I don't know if they should be). The fallout of the Snowden and Manning handling of secrets emphasizes my point. You have to report the crimes up the proper chain -- merely publicizing things you think may be whistle-blower protected is the wrong way to go about it. There are explicit paths required to report something covered by the MILITARY whistle-blower protection act complaints. Releasing classified information directly to the press or anyone public is simply not protected whistle-blower activity, particularly in military circles.
Lastly, it's not clear there were any war crimes. The Apache attacks, the most-cited "war crime" of many in the Manning list, while terrible in retrospect, are difficult to prosecute, and wide latitude is given to military personnel who believe their actions are legitimate. There WERE armed combatants on the ground, and the cameramen were easily perceived from the air as carrying RPGs rather than cameras. There is extensive coverage of this all around the web, including Wikipedia of course. This certainly could have been a war crime, but Manning could not have been certain.
Manning should have known all of this. He could have followed proper whistle-blower protocol. He chose not to. I'd have much more sympathy if he had originally tried the proper channels and was rebuffed, but that's not what happened (unless I missed something -- I'd love to be corrected here). I've seen no useful analysis of the Whistle-blower mechanisms because people don't seem to actually try them -- they circumvent the laws designed explicitly to give them protection then complain or seem surprised when they don't get that protection.
I'm sorry, but your facts are wrong... this is the quote from Michele herself: "It was a confluence of magnificent proportions that led six agents from the joint terrorism task force to knock on my door Wednesday morning." (my emphasis). So yes, she mentioned the JTTF first, not the guardian.
We also now know that Michele was never the target, so knowing anything about her would not have helped the police remove her from suspicion; she was never suspected! It was her husband who was accused by a private company due to activity on the computer he used for work (no feds looking through their personal computer), who was for reasons unknown recently no longer employed by that company.
I'm amazed how much misinformation there is about this situation. I think we need to have sane limits in place and sane conversations about these issues... basing any conversations on incorrect facts does not help anyone.
Yep... more coverage seems to have filled in the gaps. I remain crow-free... http://www.wired.com/threatlevel/2013/08/pressure-cooker/
Suffolk County Criminal Intelligence Detectives received a tip from a Bay Shore based computer company regarding suspicious computer searches conducted by a recently released employee. The former employee’s computer searches took place on this employee’s workplace computer. On that computer, the employee searched the terms ‘pressure cooker bombs’ and ‘backpacks.’
After interviewing the company representatives, Suffolk County Police Detectives visited the subject’s home to ask about the suspicious internet searches. The incident was investigated by Suffolk County Police Department’s Criminal Intelligence Detectives and was determined to be non-criminal in nature.
JTTF denies it. FBI denied it was involved but said it was Nassau and Suffolk county police, but Nassau has denied involvement and Suffolk is trying to confirm that they were not involved (I'm guessing they don't want to say they weren't involved and later have to recant). It's peculiar at best:
The article doesn't even say that... it quotes the FBI as saying it was the Nassau and Suffolk County Police, but according to this article at the gothamist, Nassau Police aren't aware of it.
Meanwhile, confusion reigns at the press offices for Nassau County and Suffolk County police. A press liaison for the Nassau County Police Department told us his phone's been ringing nonstop with inquiries. "I am trying to find out what's going on with this," he told me. "I was told that Nassau County police had absolutely no involvement in this whatsoever. I called the FBI field office in Melville and they knew nothing, the Joint Terrorism Task Force said they knew nothing. But a press rep for the FBI in NYC said Nassau County was involved, so I have to go up the chain to bigger people."
20 minutes later, another spokesperson for the Nassau County police department told me, "We contacted all our commands within the Nassau County Police Department. We did not visit this woman, and we do not know what police agency did visit her." The Suffolk County police department spokesperson said she was still trying to determine whether they were involved. The FBI press office did not immediately respond to a request for comment.
Besides that, it was only speculation on the woman's part that her search results were related, due to the crock pot comment. I'm open to all the government criticism and even the rare conspiracy theory, but seriously this story has an odor... no corroboration, no evidence of cause or intent (even if we assume the visit happened)... it's a bit much to swallow.
If I eat crow later, that's fine, but I'd like more coverage.
Yeah, I agree with mugnyte: there is no problem here. Move along.
Can you (siliconbits, or anyone) define the problem space better? What's wrong with the way they work now? Twitter Hashtags annoy some but work great for twitter. Everyone you listed has a different solution in place for tagging so... what's the issue? Why does there have to be only one solution?
Do you want a common HTML/RSS/W3C/whatever standard to define tags? Do you want centralized curated lists of tags that people must choose from? Do you want to make it somehow easier (than just typing "#", or typing a word in a box) to tag?
If you really look at good semantic web implementations -- such as Semantic wiki, you'll see some good ideas around a more "complete" semantic mechanism than tagging, but the two are basically mutually exclusive. What basic tags allow that a full semantic implementation does not is hyper-fast user-entered semantic content. This is not a shortcoming of tags, but their primary feature. It's one of the things that makes twitter so valuable (although one could argue it would still work without tagging)... people actually create and use tags all over the place.
Which actually is an interesting problem. Bug legs are notoriously small, stiff and designed to stick to things... precisely the opposite of what you want going down your throat. Not insurmountable... as with bones in chickens it's going to come down to preparation (boneless) and making good choices (don't eat chicken bones).
And I don't know how I feel yet about getting wings stuck between my teeth like popcorn kernels.
I played ET for days trying to figure out WTF was going on. I still don't know. But I did, oddly, enjoy playing it and trying to figure it out.
Actually, that's something I liked about SC2 as well -- I lost the first time I played, after many hours of game-play. By the time you figure out you've lost in SC2, a salvageable save-game was so old as to be basically useless, since one forgets all the places they hadn't visited or what they had and had not yet done.
FWIW, I actually wondered if someone would mention ET when I made that post. Thanks.:-)
In complete agreement -- Star Control II was the best game ever. I normally don't fan-spam on/. but dagnabbit I just had to chime in.
Of course, someone should take odds on whether or not a reboot can come close to doing as well as the orignal (the original #2 that is.. StarCon was a fine but simplistic game and StarCon 3 did not exist. IT DID NOT EXIST I TELL YOU). Still, I'll play a sequel just on the chance it comes close.
Total Annihilation was one of my faves as well... along with absolutely everything Atari did in the 80s. How the mighty have fallen.
Of course it's pollution. The first google'd definition is: "The presence in or introduction into the environment of a substance or thing that has harmful or poisonous effects." (wikipedia's entry explicitly calls out light as a pollutant).
First, light is clearly a thing, and we've added it to an environment in which it would not have otherwise been. Second there are lots of studies that bright, constant lighting at all hours is harmful to the otherwise indigenous or natural ecosystems: light pollution has been linked to changes in melatonin production, problems with bird migration, sleep cycles in nocturnal animals, the ability of vulnerable animals to hide at night during normal foraging times. Here are a few links:
There are many many more. Sure some human benefits of illumination may outweigh these, such as safety, but with more options becoming available (more efficient, dimmer, more focused lights), those benefits can be had with a lower polluting impact. It's not just a problem for astronomers, although I would like to see the stars a bit better!
You can get LED lighting fairly simply these days, and I think it's a lot better for outdoor use. Basically, think christmas tree lights but more subtle. You can get tubes or flatter strips that you can put pretty tastefully wherever you actually need to see. Consider lining walkways with dim LED strips rather than blasting everything with an obnoxious bright light. It's easy to attach them to deck rails or gutter lines. On a dark night they're enough to see what you're doing and where you're going and on a well moonlit night, well, you shouldn't need them.:-) You can light up a pergola well enough that you can sit and hold conversations quite comfortably... to me the softer lighter light feels more natural than a single bright beacon on a pole.
They also have the advantage of being long-living and low cost (typically as they're overall lower wattage than huge floods).
Search amazon for "rope light" or "led strip light". Pre-strung ropes with plugs are the simplest, but you can get long strips of light that you can daisy-chain which require special ballasts (AC adapters).
Oddly, I think you are correct but for the wrong reasons. The court seems to hold that Treason can only happen with "enemies" when war has been levied. Since the US is not at war with Russia or China (or the UK for that matter), Snowden is probably in the clear on Treason. If they were, however, providing classified information to them could qualify as giving "aid". As Snowden continually seems to consider himself an American, "adhering" is probably not going to stick in any case as well.
Still, the U.S. has not formally been at war since WWII, I believe, although congress has authorized military action since then, and it's unclear if those actions would qualify someone as an "enemy", for purposes of Treason. If it could be shown that Al-Qaeda, (for example, or someone with whom we're in military conflict, or someone who has declared war on the US even if we did not reciprocate formally), received this information and made use of it, would be the only plausible path I can see for a charge of Treason, which I suspect the courts would eventually deny. "Lesser" (than treasonous) criminal charges, on the other hand, are far more likely to succeed.
So, yes, I think he is in the clear, legally, on Treason.
WSJ recently had a good article on it: http://online.wsj.com/article/SB10001424127887324688404578543410828226862.html
I think you're confusing feature-creep with a comment that was meant to be about edge-scenarios. Allowing someone to configure parameters that were never spec'ed to be configured is feature-creep (gold plating, extra coding, call it what you will), and I agree should be avoided and adds unnecessary (or not obviously necessary) "complexity".
Handling an edge criteria that was implied but not explicit in a specification is what is typically meant of "corner case", and is not the same thing you described. Recognizing that the customer asked for something logically impossible (they want two data sets to reconcile, but they are at unexpectedly incompatible cardinalities), or something that, upon investigation while building an app, wasn't precise enough (they asked for this to be their standard green, but their standard list only includes red and blue).
It's nearly impossible to specify all of those prior to coding, which is why the typical "waterfall" development techniques have fallen out of vogue. You're always going to learn things while coding, and this is one of the main contributors towards apparently unnecessary complexity. If I design version 1 of a program perfectly, and customers have new requirements for version 2, it's unlikely that the "simplest" implementation of version 1 will be the one that is most conducive to an upgrade. You end up with a choice between refactoring completely or sacrificing some efficiency and simplicity to graft the new features onto an otherwise good version 1.
I think Dr. Dobbs is nitpicking, though. There are definitely many ways to address, measure, or understand simplicity, and I agree that it should not be THE goal in and of itself. But the idea of making code easy to read, easy to understand both in the micro and macro sense, and just generally "simpler", has many merits.
If you're worried about the lineage of a binary then you need to be able to build it yourself, or at least have it built by a trusted source... if you can't, then either there IS a problem with the source code you have, or you need to decide if the possible risk is worth the effort. If you can't get and review (or even rewrite) all the libraries and dependencies, then those components are always going to be black-boxes. Everyone has to decide if that's worth the risk or cost, and we could all benefit from an increase in transparency and a reduction in that risk -- I think that was the poster's original point.
The real problem is that there's quite a bit of recursion... can you trust the binaries even if you compiled them, if you used a compiler that came from binary (or Microsoft)? Very few people are going to have access to the complete ground-up builds required to be fully clean... you'd have to hand-write assembly "compilers" to build up tools until you get truly useful compilers then build all your software from that, using sources you can audit. Even then, you need to ensure firmware and hardware are "trusted" in some way, and unless you're actually producing hardware, none of these are likely options.
You COULD write a reverse compiler that's aware of the logic of the base compiler and ensure your code is written in such a way that you can compile it, then reverse it, and get something comparable in and out, but the headache there would be enormous. And there are so many other ways to earn trust or force compliance -- network and data guards, backups, cross validation, double-entry or a myriad of other things depending on your needs.
It's a balance between paranoia and trust, or risk and reward. Given the number of people using software X with no real issue, a binary from a semi-trusted source is normally enough for me.
"Not sure about the OpenVMS vs PDP comparison"... Since one is software and one is hardware, the confusion makes sense, but the comparison was basically valid:
The PDP-11 was 16-bit and gave way to the 32-bit VAX-11 (except, apparently, in nuclear power plants). The operating system developed to run the VAX-11 system was VAX-11/VMS (later just VMS). As the OS matured and Digital Equipment Corp (DEC)'s hardware moved to the Alpha CPUs, VMS matured along with it until HP eventually ported it to Itanium as OpenVMS.
While all of those hardware platforms ran multiple systems (early UNIX variants even ran on the PDP-11), VAX/VMS were tightly integrated to anyone that worked with them, and the PDP/VAX lineage was well established. In that way, comparing the lifecycle of PDP-11 to OpenVMS makes a lot of sense (and, honestly, I'm very surprised by which lasted longer!).
Parent got it right; it's about problem solving. I have dual math and cs degrees, and while most of the actual math escaped me decades ago (I couldn't solve half the diff-EQs or integrals now that I could in college), the practices and thought processes have (IMnsHO) made me a better programmer. Programming is about efficiency as much or more than it is about knowing any specific language or being able to execute a particular task. Most importantly, I think is the ability to have faith that your code is correct and complete... proofs in linear algebra and number theory were immensely helpful for that. Testing edge cases and knowing that your loops will terminate properly flex the same muscles as proofs by induction. I think of Pollard's rho more doing database programming than I did in math classes, but I'm glad someone pointed it out to me there.
Math can also be directly applicable depending on what you're going into. Visual and game programming is full of geometry and trigonometry. Artificial Intelligence, Big Data, Data Mining all require statistics, hashing algorithms, efficient tree traversal, and all sorts of things that span the boundary between CS and Math. In the end, though, all of programming is just implementing algorithms, and all algorithms are just math problems. The two complement each other brilliantly.
My dad brought home a commodore and I subscribed to Compute's Gazette (I think that's what it was called) -- a magazine with a lot of commodore stuff in it. One thing they had was pages and pages of bytecode that you had to type in with no debugger or syntax to speak of. I learned a LOT from that, and from the built-in basic the OS had. The first thing I really remember programming to completeness was a Julia and Mandelbrot set generator... in Commodore basic. It was not fast; I could see the program drawing pretty much every pixel. Good times.
I ended up with a degree in computer science, but I'd say that was more an opportunity to practice than it really was how I "learned" to program. Algorithms and Operating System classes had some concepts that I hadn't run across, and every class was an opportunity to learn or find new snippets of knowledge. But the formal things I learned like "Bresenham's circle algorithm" and topological sorts, or anything from the Dragon Book, the volumes of Knuth (ah), or the Numerical Programming books were important conceptually... probably good to make efficient code, and great ways to not recreate the wheel. But the only way to "learn" to code is to code.
Military still seems "proprietary" to me. If they meant "commercial", I could see a difference. I also considered "embedded" or "firmware" style code that, while software, is more closely tied to a physical hardware implementation. All of those still seem either "proprietary" or "open source", though, and you're right (@stillnotelf) that these would raise rather than lower industry averages.
It could include things like javascript that is just out-in-the-wild. If you were to strip programmatic pieces from websites that were one-offs... things that were neither marketed nor sold, and not really managed as software, just put out there, code quality would probably drop. I'm thinking of websites with funny animations or just hand-coded scripts to do navigation or whatnot. These wouldn't be "open source" in the sense that there's no statement of open copyright, and they wouldn't be "proprietary" in the sense that noone is marketing or working to save or publish or reuse the code, and while copyright may exist noone is really worried about projecting it (due to the one-off nature). Still, it's a weird statistic.
I wonder if they meant a "standard" as in a target or an accepted limit that is somewhat arbitrary rather than an "average" (which the article actually uses) of real-world code. This would make sense since the average they cite is exactly 1.
Wow, yeah, I posted an almost identical sentence myself. Eerie. (Although I didn't have a Wobegon reference... sorry). But yeah, it seems like an odd sentiment. Internal use software is still either "proprietary" or "open source"... isn't it? But good point. If someone calculated the bugs in my excel macros as if they could be used for general purpose computing I'd be in sad shape. (ObNote: I use excel macros as rarely as possible, and normally only at gunpoint).
I agree with most posters that the logic in the post is hugely flawed (predicting something about the future by arguing that we can't know enough to predict it is inane). But more constructively: our constant access to information hasn't sated our desire for more information. Information collection is driving the recent knowledge boom as much if not more than ease of access. Besides, no matter how much time passes, if we haven't visited another world we won't have the information about that world at our availability. You have to collect information before you can use it... that's WHY further exploration will always be a goal (unless, you know, we obliterate ourselves somehow in the mean time, or find something similarly more important in any given short-term).
I said it before and I'll say it again. Taking something that exists and making it digital (or on the internet or on your phone or any "just-add-technology" change) doesn't make it new. Prior art should still apply...I refer you to my comment on Tuesday
I completely agree, but I think that was my point (and I reply largely because I took umbrage with the "Um, no" while really I think we agree)... design patents are very narrow in scope intentionally, and I'm arguing that software patents should be similarly narrow to specifically avoid the problems with the current patent system about which we're both talking.
I used the shopping cart example because of recent news that such a patent has been awarded, and upon reading the patent it does not appear to be a specific implementation at all; rather a very generic implementation that highly parallels an existing physical concept (a shopping cart). It's not that specific implementations shouldn't be patentable (although I may argue that copyright instead of patents should apply in most cases, when the differences are more aesthetic rather than functional, but thus my comparison to design patents), I'm just trying to find a reasonable testable limit to what should qualify.
As you say, patenting the entire store is not what patents are about. I think patenting shopping carts is simliar (unless they have a "novel" feature). Things that work well in the physical world are quickly gaining internet-based analogues.
You're also right about of inevitability, of course, but I think there's a difference between inevitable, and obvious or novel. Lending digital objects (case in point) is an interesting example. A narrow patent on a particular combination of encryption and centrally controlled tracking and limiting methods on how many times something could be shared probably could be patentable, and makes sense. But in this case, the patent has grown to include practically any conceivable implementation, which seems wrong. The limiting factor I suggested was whether there is a physical analog or not. There IS a physical analog for lending, so no matter how long it takes for the first person to build and market code for that should, IMHO, remain unpatentable. I'm not aware of a physical analog for lending something only a specific number of times, so I'm OK with that (although I'd be glad to be corrected).
Definitely an interesting conversation; I think we agree on the salient points.
Slashdot Mirror
The article you cite says his disclosures did not lead to any deaths of any military sources. Many believe Manning's leaks precipitated the Arab Spring which could have a death toll over 30,000. And it certainly crippled foreign relations (with the revelations in the e-mails) and may have made the US military and diplomatic processes somewhat less effective in areas where lives were and are at stake.
Also, whistle-blower laws are not automatic, (and I don't know if they should be). The fallout of the Snowden and Manning handling of secrets emphasizes my point. You have to report the crimes up the proper chain -- merely publicizing things you think may be whistle-blower protected is the wrong way to go about it. There are explicit paths required to report something covered by the MILITARY whistle-blower protection act complaints. Releasing classified information directly to the press or anyone public is simply not protected whistle-blower activity, particularly in military circles.
Lastly, it's not clear there were any war crimes. The Apache attacks, the most-cited "war crime" of many in the Manning list, while terrible in retrospect, are difficult to prosecute, and wide latitude is given to military personnel who believe their actions are legitimate. There WERE armed combatants on the ground, and the cameramen were easily perceived from the air as carrying RPGs rather than cameras. There is extensive coverage of this all around the web, including Wikipedia of course. This certainly could have been a war crime, but Manning could not have been certain.
Manning should have known all of this. He could have followed proper whistle-blower protocol. He chose not to. I'd have much more sympathy if he had originally tried the proper channels and was rebuffed, but that's not what happened (unless I missed something -- I'd love to be corrected here). I've seen no useful analysis of the Whistle-blower mechanisms because people don't seem to actually try them -- they circumvent the laws designed explicitly to give them protection then complain or seem surprised when they don't get that protection.
I'm sorry, but your facts are wrong... this is the quote from Michele herself: "It was a confluence of magnificent proportions that led six agents from the joint terrorism task force to knock on my door Wednesday morning." (my emphasis). So yes, she mentioned the JTTF first, not the guardian.
We also now know that Michele was never the target, so knowing anything about her would not have helped the police remove her from suspicion; she was never suspected! It was her husband who was accused by a private company due to activity on the computer he used for work (no feds looking through their personal computer), who was for reasons unknown recently no longer employed by that company.
I'm amazed how much misinformation there is about this situation. I think we need to have sane limits in place and sane conversations about these issues... basing any conversations on incorrect facts does not help anyone.
Yep... more coverage seems to have filled in the gaps. I remain crow-free... http://www.wired.com/threatlevel/2013/08/pressure-cooker/
---Chip
JTTF denies it. FBI denied it was involved but said it was Nassau and Suffolk county police, but Nassau has denied involvement and Suffolk is trying to confirm that they were not involved (I'm guessing they don't want to say they weren't involved and later have to recant). It's peculiar at best:
http://gothamist.com/2013/08/01/li_woman_says_she_was_investigated.php
The article doesn't even say that... it quotes the FBI as saying it was the Nassau and Suffolk County Police, but according to this article at the gothamist, Nassau Police aren't aware of it.
Besides that, it was only speculation on the woman's part that her search results were related, due to the crock pot comment. I'm open to all the government criticism and even the rare conspiracy theory, but seriously this story has an odor... no corroboration, no evidence of cause or intent (even if we assume the visit happened)... it's a bit much to swallow.
If I eat crow later, that's fine, but I'd like more coverage.
Yeah, I agree with mugnyte: there is no problem here. Move along.
Can you (siliconbits, or anyone) define the problem space better? What's wrong with the way they work now? Twitter Hashtags annoy some but work great for twitter. Everyone you listed has a different solution in place for tagging so... what's the issue? Why does there have to be only one solution?
Do you want a common HTML/RSS/W3C/whatever standard to define tags? Do you want centralized curated lists of tags that people must choose from? Do you want to make it somehow easier (than just typing "#", or typing a word in a box) to tag?
If you really look at good semantic web implementations -- such as Semantic wiki, you'll see some good ideas around a more "complete" semantic mechanism than tagging, but the two are basically mutually exclusive. What basic tags allow that a full semantic implementation does not is hyper-fast user-entered semantic content. This is not a shortcoming of tags, but their primary feature. It's one of the things that makes twitter so valuable (although one could argue it would still work without tagging)... people actually create and use tags all over the place.
So yeah... what, exactly, is the problem again?
http://www.nydailynews.com/news/national/bug-eater-choked-death-article-1.1208649
Which actually is an interesting problem. Bug legs are notoriously small, stiff and designed to stick to things... precisely the opposite of what you want going down your throat. Not insurmountable... as with bones in chickens it's going to come down to preparation (boneless) and making good choices (don't eat chicken bones).
And I don't know how I feel yet about getting wings stuck between my teeth like popcorn kernels.
But, you know... tradeoffs. ;-)
I played ET for days trying to figure out WTF was going on. I still don't know. But I did, oddly, enjoy playing it and trying to figure it out.
Actually, that's something I liked about SC2 as well -- I lost the first time I played, after many hours of game-play. By the time you figure out you've lost in SC2, a salvageable save-game was so old as to be basically useless, since one forgets all the places they hadn't visited or what they had and had not yet done.
FWIW, I actually wondered if someone would mention ET when I made that post. Thanks. :-)
In complete agreement -- Star Control II was the best game ever. I normally don't fan-spam on /. but dagnabbit I just had to chime in.
Of course, someone should take odds on whether or not a reboot can come close to doing as well as the orignal (the original #2 that is.. StarCon was a fine but simplistic game and StarCon 3 did not exist. IT DID NOT EXIST I TELL YOU). Still, I'll play a sequel just on the chance it comes close.
Total Annihilation was one of my faves as well... along with absolutely everything Atari did in the 80s. How the mighty have fallen.
Of course it's pollution. The first google'd definition is: "The presence in or introduction into the environment of a substance or thing that has harmful or poisonous effects." (wikipedia's entry explicitly calls out light as a pollutant).
First, light is clearly a thing, and we've added it to an environment in which it would not have otherwise been. Second there are lots of studies that bright, constant lighting at all hours is harmful to the otherwise indigenous or natural ecosystems: light pollution has been linked to changes in melatonin production, problems with bird migration, sleep cycles in nocturnal animals, the ability of vulnerable animals to hide at night during normal foraging times. Here are a few links:
http://www.plosone.org/article/info:doi/10.1371/journal.pone.0056563
http://physics.fau.edu/observatory/lightpol-environ.html
http://en.wikipedia.org/wiki/Ecological_light_pollution
There are many many more. Sure some human benefits of illumination may outweigh these, such as safety, but with more options becoming available (more efficient, dimmer, more focused lights), those benefits can be had with a lower polluting impact. It's not just a problem for astronomers, although I would like to see the stars a bit better!
You can get LED lighting fairly simply these days, and I think it's a lot better for outdoor use. Basically, think christmas tree lights but more subtle. You can get tubes or flatter strips that you can put pretty tastefully wherever you actually need to see. Consider lining walkways with dim LED strips rather than blasting everything with an obnoxious bright light. It's easy to attach them to deck rails or gutter lines. On a dark night they're enough to see what you're doing and where you're going and on a well moonlit night, well, you shouldn't need them. :-) You can light up a pergola well enough that you can sit and hold conversations quite comfortably... to me the softer lighter light feels more natural than a single bright beacon on a pole.
They also have the advantage of being long-living and low cost (typically as they're overall lower wattage than huge floods).
Search amazon for "rope light" or "led strip light". Pre-strung ropes with plugs are the simplest, but you can get long strips of light that you can daisy-chain which require special ballasts (AC adapters).
Oddly, I think you are correct but for the wrong reasons. The court seems to hold that Treason can only happen with "enemies" when war has been levied. Since the US is not at war with Russia or China (or the UK for that matter), Snowden is probably in the clear on Treason. If they were, however, providing classified information to them could qualify as giving "aid". As Snowden continually seems to consider himself an American, "adhering" is probably not going to stick in any case as well.
Still, the U.S. has not formally been at war since WWII, I believe, although congress has authorized military action since then, and it's unclear if those actions would qualify someone as an "enemy", for purposes of Treason. If it could be shown that Al-Qaeda, (for example, or someone with whom we're in military conflict, or someone who has declared war on the US even if we did not reciprocate formally), received this information and made use of it, would be the only plausible path I can see for a charge of Treason, which I suspect the courts would eventually deny. "Lesser" (than treasonous) criminal charges, on the other hand, are far more likely to succeed.
So, yes, I think he is in the clear, legally, on Treason.
WSJ recently had a good article on it: http://online.wsj.com/article/SB10001424127887324688404578543410828226862.html
I think you're confusing feature-creep with a comment that was meant to be about edge-scenarios. Allowing someone to configure parameters that were never spec'ed to be configured is feature-creep (gold plating, extra coding, call it what you will), and I agree should be avoided and adds unnecessary (or not obviously necessary) "complexity".
Handling an edge criteria that was implied but not explicit in a specification is what is typically meant of "corner case", and is not the same thing you described. Recognizing that the customer asked for something logically impossible (they want two data sets to reconcile, but they are at unexpectedly incompatible cardinalities), or something that, upon investigation while building an app, wasn't precise enough (they asked for this to be their standard green, but their standard list only includes red and blue).
It's nearly impossible to specify all of those prior to coding, which is why the typical "waterfall" development techniques have fallen out of vogue. You're always going to learn things while coding, and this is one of the main contributors towards apparently unnecessary complexity. If I design version 1 of a program perfectly, and customers have new requirements for version 2, it's unlikely that the "simplest" implementation of version 1 will be the one that is most conducive to an upgrade. You end up with a choice between refactoring completely or sacrificing some efficiency and simplicity to graft the new features onto an otherwise good version 1.
I think Dr. Dobbs is nitpicking, though. There are definitely many ways to address, measure, or understand simplicity, and I agree that it should not be THE goal in and of itself. But the idea of making code easy to read, easy to understand both in the micro and macro sense, and just generally "simpler", has many merits.
If you're worried about the lineage of a binary then you need to be able to build it yourself, or at least have it built by a trusted source... if you can't, then either there IS a problem with the source code you have, or you need to decide if the possible risk is worth the effort. If you can't get and review (or even rewrite) all the libraries and dependencies, then those components are always going to be black-boxes. Everyone has to decide if that's worth the risk or cost, and we could all benefit from an increase in transparency and a reduction in that risk -- I think that was the poster's original point.
The real problem is that there's quite a bit of recursion... can you trust the binaries even if you compiled them, if you used a compiler that came from binary (or Microsoft)? Very few people are going to have access to the complete ground-up builds required to be fully clean... you'd have to hand-write assembly "compilers" to build up tools until you get truly useful compilers then build all your software from that, using sources you can audit. Even then, you need to ensure firmware and hardware are "trusted" in some way, and unless you're actually producing hardware, none of these are likely options.
You COULD write a reverse compiler that's aware of the logic of the base compiler and ensure your code is written in such a way that you can compile it, then reverse it, and get something comparable in and out, but the headache there would be enormous. And there are so many other ways to earn trust or force compliance -- network and data guards, backups, cross validation, double-entry or a myriad of other things depending on your needs.
It's a balance between paranoia and trust, or risk and reward. Given the number of people using software X with no real issue, a binary from a semi-trusted source is normally enough for me.
Is "average user ID" actually calculated? That would be a fantastic metric.
"Not sure about the OpenVMS vs PDP comparison"... Since one is software and one is hardware, the confusion makes sense, but the comparison was basically valid:
The PDP-11 was 16-bit and gave way to the 32-bit VAX-11 (except, apparently, in nuclear power plants). The operating system developed to run the VAX-11 system was VAX-11/VMS (later just VMS). As the OS matured and Digital Equipment Corp (DEC)'s hardware moved to the Alpha CPUs, VMS matured along with it until HP eventually ported it to Itanium as OpenVMS.
While all of those hardware platforms ran multiple systems (early UNIX variants even ran on the PDP-11), VAX/VMS were tightly integrated to anyone that worked with them, and the PDP/VAX lineage was well established. In that way, comparing the lifecycle of PDP-11 to OpenVMS makes a lot of sense (and, honestly, I'm very surprised by which lasted longer!).
Parent got it right; it's about problem solving. I have dual math and cs degrees, and while most of the actual math escaped me decades ago (I couldn't solve half the diff-EQs or integrals now that I could in college), the practices and thought processes have (IMnsHO) made me a better programmer. Programming is about efficiency as much or more than it is about knowing any specific language or being able to execute a particular task. Most importantly, I think is the ability to have faith that your code is correct and complete... proofs in linear algebra and number theory were immensely helpful for that. Testing edge cases and knowing that your loops will terminate properly flex the same muscles as proofs by induction. I think of Pollard's rho more doing database programming than I did in math classes, but I'm glad someone pointed it out to me there.
Math can also be directly applicable depending on what you're going into. Visual and game programming is full of geometry and trigonometry. Artificial Intelligence, Big Data, Data Mining all require statistics, hashing algorithms, efficient tree traversal, and all sorts of things that span the boundary between CS and Math. In the end, though, all of programming is just implementing algorithms, and all algorithms are just math problems. The two complement each other brilliantly.
My dad brought home a commodore and I subscribed to Compute's Gazette (I think that's what it was called) -- a magazine with a lot of commodore stuff in it. One thing they had was pages and pages of bytecode that you had to type in with no debugger or syntax to speak of. I learned a LOT from that, and from the built-in basic the OS had. The first thing I really remember programming to completeness was a Julia and Mandelbrot set generator... in Commodore basic. It was not fast; I could see the program drawing pretty much every pixel. Good times.
I ended up with a degree in computer science, but I'd say that was more an opportunity to practice than it really was how I "learned" to program. Algorithms and Operating System classes had some concepts that I hadn't run across, and every class was an opportunity to learn or find new snippets of knowledge. But the formal things I learned like "Bresenham's circle algorithm" and topological sorts, or anything from the Dragon Book, the volumes of Knuth (ah), or the Numerical Programming books were important conceptually... probably good to make efficient code, and great ways to not recreate the wheel. But the only way to "learn" to code is to code.
The source code is zipped. For a 254 byte program. This just tickles me for some reason.
Military still seems "proprietary" to me. If they meant "commercial", I could see a difference. I also considered "embedded" or "firmware" style code that, while software, is more closely tied to a physical hardware implementation. All of those still seem either "proprietary" or "open source", though, and you're right (@stillnotelf) that these would raise rather than lower industry averages.
It could include things like javascript that is just out-in-the-wild. If you were to strip programmatic pieces from websites that were one-offs... things that were neither marketed nor sold, and not really managed as software, just put out there, code quality would probably drop. I'm thinking of websites with funny animations or just hand-coded scripts to do navigation or whatnot. These wouldn't be "open source" in the sense that there's no statement of open copyright, and they wouldn't be "proprietary" in the sense that noone is marketing or working to save or publish or reuse the code, and while copyright may exist noone is really worried about projecting it (due to the one-off nature). Still, it's a weird statistic.
I wonder if they meant a "standard" as in a target or an accepted limit that is somewhat arbitrary rather than an "average" (which the article actually uses) of real-world code. This would make sense since the average they cite is exactly 1.
Wow, yeah, I posted an almost identical sentence myself. Eerie. (Although I didn't have a Wobegon reference... sorry). But yeah, it seems like an odd sentiment. Internal use software is still either "proprietary" or "open source"... isn't it? But good point. If someone calculated the bugs in my excel macros as if they could be used for general purpose computing I'd be in sad shape. (ObNote: I use excel macros as rarely as possible, and normally only at gunpoint).
I agree with most posters that the logic in the post is hugely flawed (predicting something about the future by arguing that we can't know enough to predict it is inane). But more constructively: our constant access to information hasn't sated our desire for more information. Information collection is driving the recent knowledge boom as much if not more than ease of access. Besides, no matter how much time passes, if we haven't visited another world we won't have the information about that world at our availability. You have to collect information before you can use it... that's WHY further exploration will always be a goal (unless, you know, we obliterate ourselves somehow in the mean time, or find something similarly more important in any given short-term).
I said it before and I'll say it again. Taking something that exists and making it digital (or on the internet or on your phone or any "just-add-technology" change) doesn't make it new. Prior art should still apply...I refer you to my comment on Tuesday
Obvious, Novel, and Prior Art aren't just digital
I completely agree, but I think that was my point (and I reply largely because I took umbrage with the "Um, no" while really I think we agree)... design patents are very narrow in scope intentionally, and I'm arguing that software patents should be similarly narrow to specifically avoid the problems with the current patent system about which we're both talking.
I used the shopping cart example because of recent news that such a patent has been awarded, and upon reading the patent it does not appear to be a specific implementation at all; rather a very generic implementation that highly parallels an existing physical concept (a shopping cart). It's not that specific implementations shouldn't be patentable (although I may argue that copyright instead of patents should apply in most cases, when the differences are more aesthetic rather than functional, but thus my comparison to design patents), I'm just trying to find a reasonable testable limit to what should qualify.
As you say, patenting the entire store is not what patents are about. I think patenting shopping carts is simliar (unless they have a "novel" feature). Things that work well in the physical world are quickly gaining internet-based analogues.
You're also right about of inevitability, of course, but I think there's a difference between inevitable, and obvious or novel. Lending digital objects (case in point) is an interesting example. A narrow patent on a particular combination of encryption and centrally controlled tracking and limiting methods on how many times something could be shared probably could be patentable, and makes sense. But in this case, the patent has grown to include practically any conceivable implementation, which seems wrong. The limiting factor I suggested was whether there is a physical analog or not. There IS a physical analog for lending, so no matter how long it takes for the first person to build and market code for that should, IMHO, remain unpatentable. I'm not aware of a physical analog for lending something only a specific number of times, so I'm OK with that (although I'd be glad to be corrected).
Definitely an interesting conversation; I think we agree on the salient points.