C++, it's time to go - <AUTHOR> http://blog.irukado.org/2013/10/c-time/ <comment><USER2> These posts have been around ever since I started to learn how to program. When I was a wee little lad, everyone told me that C++ was going the way of the dinosaur and no one would ever need to learn it.

That was 10 years ago. It still hasn't happened. Meanwhile, blog post after blog post is written about how C++ is dying when it simply isn't. Maybe it will happen sometime in the future, but as of yet no language solves the same problems that C++ does. Not D, not Rust, not Go. Every single one of these arguments is colored by the specific problems the author has spent their life solving. If none of those problems benefit from C++, then they will inevitably come to the conclusion that C++ is useless, and then yet another "C++ is dying" or "C++ considered harmful" blogpost is written. Meanwhile, reality doesn't care.

<comment><USER3> "Meanwhile, reality doesn't care."

True. What reality cares is that the programs run where they need to run and it's "portable"

And as much as I would want all programs to run on Linux/Mac OS only and not care about a user interface, there are still programs that need to do that.

Do a cross platform desktop software that runs in Windows/Linux/MacOS. I know three possible answers: Python, Java and C++. Mono maybe a choice as well, but it requires installing Mono.

Now, how to do a software that runs on an embedded linux device.

<comment><USER4> There are a hell of a lot more options. Also, Python and Java require runtimes just like Mono.

</comment></comment></comment><comment><USER5> > OO with class hierarchies is a broken model.

I can't agree more with you! As a matter of fact, someone famous said:

 _I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people._

This someone is Alexander Stepanov the author of the STL (the C++ Standard Library).

C++ is much more about generic programming.

> Algebraic datatypes and pattern matching have been around for years, and > have clear advantages.

Try this keyword: "template".

> Parallel programming has been around for years, and is becoming CRITICAL for > modern applications.

Whether this is the job of the language or the job of a library is debatable. Efficient parallel programming in C++ is done with the latter (Intel TBB for example).

> C++ has a RIDICULOUS amount of boiler plate.

Maybe. This is one of the philosophy of C++ is "don't pay for what you don't want".

> Headers shouldn't exist in the language:

Yes, but as you said it will be addressed in C++ 14. You should appreciate that C++ has enablee the industry to move forward thanks to its support of C headers. This may be less obvious now, but 10 to 20 years ago this was really a big deal.

> The same problems that make highly-parallel code a nightmare in C++ also > make it an unsuitable language for security-critical, or mission-critical > projects.

You are naive if you think the weak link of security is the compiler. The problem is behind the keyboard and the chair. According to you, programs written in Java or .NET should be more secure. That's not the case.

Some of the most secure programs ever written are written in C which offers even less compile-time checks than C++.

<comment><USER6> _" I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people."

This someone is Alexander Stepanov the author of the STL (the C++ Standard Library)._

Authority doesn't make it true ;) : How about Qt? Or Cocoa?

OO was overhyped. It doesn't fit every problem domain. That doesn't mean the opposite is true. There are domains where OO with class hierarchies is quite a good model, such as GUI toolkits.

 _Try this keyword: "template"._

Templates are a compile-time construct. Algebraic data types are not. I think you are confusing ADTs with parametric polymorphism.

 _According to you, programs written in Java or .NET should be more secure. That 's not the case._

Proof it. I think it is reasonable to assume that Java code produced by the average programmer is safer than C++ code produced by the average programmer. Java does not have pointer arithmetic, does bounds checking, etc.

<comment><USER7> > Templates are a compile-time construct. Algebraic data types are not. I > think you are confusing ADTs with parametric polymorphism.

You keep saying that word. I do not think it means what you think it means: [http://en.wikipedia.org/wiki/Algebraic_data_type](http://en.wikipedia.org/wiki/Algebraic_data_type)

</comment></comment></comment><comment><USER8> > OO with class hierarchies is a broken model.

If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs.

I think C++ is not going "to go" anywhere and is here to stay for a long, long time, and have it's place in programming language "pantheon" similar to C. C++ gives programmer freedom, which is too much to handle for many. Restrictive language is a good way of preventing bugs, but in C++ you can just select what language features you are gonna use and have similar result.

<comment><USER9> _If this is true, there is nothing that forces you to write classes in C++. You have all the freedom to write only in functions and structs._

Except that abstract classes are pretty much the only way to implement type- checked interfaces and they are, well, classes.

<comment><USER7> Not at all. You can use CRTP, you can use structs, you can use SFINAE, etc.

UPDATE: And for the record, inherence of pure interface classes works just fine in C++. The stuff where it gets ugly is when you try building a deep inheritance hierarchy of behaviour. It can work, but usually not terribly well.

</comment></comment></comment><comment><USER10> This is so adorably naive.

<comment><USER11> I was going to write a rant, but I guess this sums it well enough.

</comment></comment><comment><USER12> > Standing on a raft in the middle of a lake.

Water, it's time to go. We don't need water anymore!

> Standing in the middle of a desert.

It would be great if we had more water!

This is literally what these arguments for or against C++ sound like. Please, before you decide some language needs to go, take the time to understand the context in which it should or should not be used.

</comment><comment><USER13> I think this is confusing.

If C++ has to go because the paradigm is wrong, because it has to be replaced by say more functional languages, OK. But then so does Java, C# and so on.

Now, if C++ has to go because of some _language aspects_ , I disagree. There is no point. The language is good enough and can still be improved.

When I choose C++ over other languages I don't do it because I like the language, I do it because it generates native code, because of manual control of the memory management, because templates can be useful to solve some problems elegantly, etc.

</comment><comment><USER14> I'm not the world's biggest C++ fan, quite the opposite. But this guy hasn't really realized yet that any attempt to build something as expressive and powerful as C++, and just as fast, without any of the things he dislikes in C++ will hit any number of walls, problems, and challenges that nobody out there has overcome. Objective-C gives you almost as much performance as C++ except in the critical cases where message passing can degrade overall performance due to objective C run-time message send overhead.

Performance, Compatibility, Ecosystems, Existing Running Code In Production. Go ahead and rewrite your piddly little apps in Anything You Like. C++, and any other language you hate (Java, C#, whatever) will still be used and significant and powerful tools that people use to get stuff done.

Me I love Delphi, and I'm used to people considering it dead. (It's not dead.) I consider it a better language than C++, but that's just a subjective opinion of my own. I've spent years hating on C++, but I'm done with that. C++ 2011 is a great step forward for the language, and when they finally get modules (2020?) they'll have caught up with TurboPascal (1984). Awesome.

</comment><comment><USER15> hey facebook, please replace all your core c++ infrastructure with haskell/rust/D/ruby because this guy had decided that its time for c++ to go.

all those high frequency trading systems too. you need to replace everything. gc pauses are nothing compared to the elegance of other languages.

as you can clearly read its just not the right language for parallelism, and all those headers make 3m lines of code harder to read not easier. also all those bloody class hierarchies..

</comment><comment><USER16> Not sure what is meant by "research".

It would be nice to justify statements. To write something in upper cases isn't a justification and doesn't make sense.

Each new programming language seems to be better and so on. But if we are looking to the hottest shit on the planet of the past year like java, ruby, python, etc. we can say that we didn't know their problems at the beginning.

<comment><USER7> > To write something in upper cases isn't a justification and doesn't make > sense.

YES IT DOES! ;-)

</comment></comment><comment><USER6> _OO with class hierarchies is a broken model._

I am not sure whether C++ is a good target for this criticism. The most frequently used libraries (STL and Boost) don't use class hierarchies extensively.

Also, some domains are easily modelled using class hierarchies, such as GUI widgets, where more specialized widgets override or extend behaviour (or painting) of more general widgets. I have programmed Qt for years, and the class hierarchy model works exceptionally well there.

 _Algebraic datatypes and pattern matching have been around for years,_

They come with advantages and disadvantages. E.g. adding a constructor potentially requires you to update every pattern matching case. This can get quite ugly quickly if you add a constructor to some commonly-used library.

I do like them in cases where you know up-front what constructors there will be. E.g. lightweight error handling with Maybe/Either. Or when their visibility is limited.

 _Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn't EASILY support it, it sucks._

Luckily, parallel programming is _very_ easy in C++ using e.g. OpenMP or Intel TBB. In the case of OpenMP it is usually a matter of adding pragmas to your embarrassingly parallel loops. It is _concurrency_ that is more of a problem. C++11 has standardized lot of 'old-world' constructs for threading, but it's not as if you can find a mature technology like Erlang's OTP or Akka on top of C++.

 _C++ has a RIDICULOUS amount of boiler plate._

I agree that there is a lot of boilerplate. But then the author goes off ranting about constructors. I don't find it that convincing. There used to be a lot of boilerplate in iterator and <algorithm> use, but C++11 makes things much more compact with auto et al. IMO one of the biggest sources of boilerplate in C++ is writing libraries such that you have ABI compatibility. You usually end up using PIMPL for every class, maintaining two versions (PIMPL and actual) of each class.

Then, there are other languages that come with a lot of boilerplate, such as Java, but the difference is that Java is much easier to parse, process, and incrementally compile. As a consequence, Java IDEs tend to be much better at code generation and refactoring than C++ IDEs.

 _The same problems that make highly-parallel code a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects._

Yes, it is extremely easy to blow your foot of. Forgetting a 'virtual' keyword can lead to subtle, difficult to find bugs. You can read or write beyond bounds by accident. Etc. These are well-known critiques. Use C++ (or another unsafe language) when it's necessary to trade off safety for performance. Rust will probably bring performance while sacrificing less safety. But it's not there yet.

</comment><comment><USER17> > C++, it's time to go

No it's not.

</comment><comment><USER18> When will it be time for Go to go?

</comment><comment><USER19> But... but... speed</comment>


Analyse Asia 58: Building Relationships Thru LinkedIn in Asia with Vicky Skipp - <AUTHOR> http://analyse.asia/2015/09/08/episode-58-building-relationships-thru-linkedin-in-asia-with-vicky-skipp/ <comment><AUTHOR> Synopsis: We interviewed Vicky Skipp, Head of Sales Solutions in Asia Pacific and Japan, LinkedIn. From Vicky's experience in sales from Adobe to LinkedIn over the past 15 years and building her own personal board of directors to guide her career journey, we discuss how the sales process in Asia have changed from a wide broadcasting approach to targeted social selling and the importance of relationships in sales and business in Asia. Vicky provided a primer to how LinkedIn sales solutions helped companies such as SAP to build up their existing and new sales pipelines in Asia. Last but not least, Vicky provided some tips for executives in how they can build their personal brand on LinkedIn.</comment>


Fifty-three year old nuclear missile accident revealed - <AUTHOR> http://rapidcityjournal.com/news/local/communities/belle_fourche/fifty-three-year-old-nuclear-missile-accident-revealed/article_653347a4-04e8-5c29-a778-3a6a6c3cfd84.html#tracking-source=home-latest-1 <comment><USER2> I recently finished Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety [0]. I can't recommend the book enough for how eye opening it really is into how blasé we have been with nuclear weapons.

We've been reckless and by all accounts it is a miracle we haven't had a serious accident (there have been a few, just not on our own soil). The number of close calls is just astounding.

Further the book, at one point, talks about America's position on Russia and the attempts to keep them from getting "the bomb". It is exactly what has played out and will continue to play out with North Korea and Iran. History is repeating itself and we sure haven't learned from it.

[0] [https://www.amazon.com/dp/B00C5R7F8G/](https://www.amazon.com/dp/B00C5R7F8G/)

<comment><USER3> > Further the book, at one point, talks about America's position on Russia and > the attempts to keep them from getting "the bomb". It is exactly what has > played out and will continue to play out with North Korea and Iran. History > is repeating itself and we sure haven't learned from it.

Is it actually similar, though?

The US got the bomb in 1945.

The Russians got theirs in 1949.

Given the size of the Soviet Union, how far it is from the United States, the available spying and reconnaissance technology (no satellites, no stealth aircraft), and that the US was only four years out of World War II, I don't think there is any way the US could have made a creditable threat to use military force to stop the Russians.

Also, China and Russia were still on good terms back then. China might not have stayed out of it if the US attacked their ally and neighbor.

Compare to North Korea and Iran. In both cases the US can make a creditable military threat. From a purely military point of view, the US could easily wipe either (or both) of them out.

Furthermore, neither has any powerful allies who want them to get nukes.

With North Korea, their only powerful ally is China and I don't think China actually cares if North Korea gets destroyed as long as (1) it doesn't send a lot of refugees across the Chinese border, and (2) whatever replaces it continues to function as a buffer zone between them and South Korea because they do not want a US ally right on their border.

<comment><USER4> That's not quite an accurate read though, at least as far as NK. The US can't really make a credible military threat because of the north's proximity to the south, an important US ally and a country all but guaranteed to be mortally wounded in the event of north/USA hostilities.

<comment><USER5> Sure we can. We have the capability to totally annihilate as much of North Korea as we need in order to prevent a counter attack. The question is if we are willing to do it, and kill millions of North Korean civilians. Trump is sure trying to convince the North Koreans that he is.

<comment><USER6> > We have the capability to annihilate as much of NK as we need to prevent a > counterattack

...from North Korea

If we start launching nukes in the direction of NK, how does China know it's going to stop in NK and not hit them? Do we call them up first? Then what do they say?

Is it totally out of the question that China would panic (or reason?) and counterattack? NK doesn't exist in a vacuum, and in fact NK wouldn't exist at all today had China not intervened in the last war.

<comment><USER7> It's simple orbital mechanics to calculate the trajectory. ICBMs aren't like planes, it's not like they just fly to the target and stop. It's powered during the first minutes of flight and then it just coasts from there. The exception to this is MIRV ICBMs where warheads are deployed one at a time and the final stage changes orbit a bit before releasing the next warhead. MIRVs can't change their trajectory that much though, you can target multiple locations, but they have to be in a couple hundred kilometers of each other.

Basically if there's an ICBM flying over China and it looks like it's going to hit NK, there's no way to kill all of that horizontal velocity and significantly change its trajectory.

<comment><USER8> I've read that ICBMs are very hard to spot after the initial boost phase. That being the case, if I was an ICBM designer, I'd add a cold gas thruster to the payload stage that allowed the target to be adjusted or fine tuned while it was out of the atmosphere in a stealthy way — even a delta-V of just 100 m/s adds up to 280km when the missile takes 45 minutes to arrive.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This wasn't really that big a deal. By the Minuteman era, warheads were safe against fires and crashes. Nuclear weapons from several B-52 bombers hit the ground hard in crashes without a nuclear explosion. (Sometimes the implosion charges did go off, but not symmetrically, as is needed to get implosion.) The Minuteman missile itself had a solid fuel engine. This was nowhere near as bad as the incident described in "Command and Control". That one was a liquid- fueled missile with hypergolic propellant.

See Wikipedia's list of nuclear accidents.[1] This wasn't one of the big ones.

[1] [https://en.wikipedia.org/wiki/List_of_military_nuclear_accid...](https://en.wikipedia.org/wiki/List_of_military_nuclear_accidents)

<comment><USER10> Yep, a modern nuclear bomb takes a very coordinated sequence to actually have the confinement needed to get good utilization of the fissile fuel (i.e., be a nuclear-driven explosion), otherwise they just fly apart before any significant fission/fusion can occur.

The fuel used for a nuclear weapon is also basically radiologically inert by necessity so if it does explode conventionally there is not a significant release of radiation. It's pretty toxic chemically, but there's not a lot of it so it's not nearly as bad the fallout that would precipitate from a nuclear explosion.

<comment><USER9> "Radiologically inert" is a bit much. Both uranium and plutonium are alpha emitters. This basically means that if you can keep the stuff outside your body, you're OK. A chunk of metal is safe; breathing dust is lethal.

</comment></comment></comment><comment> le-mark There's a LOT of cold war history up there in the central plains. The Strategic Air Command museum just outside of Omaha Nebraska has really incredible displays and a surprisingly large aircraft collection (to me at least). Including an SR-71. Highly recommended for anyone interested in that kind of thing.

[http://sacmuseum.org/](http://sacmuseum.org/)

</comment><comment><USER11> >> without hitting the missile and causing an explosion. >> caused a short circuit that resulted in an explosion. >> Luckily, the cone did not do enough damage to the missile to cause the missile to explode.

To clarify: There was absolutely no chance at any point of a nuclear explosion. The article suggests that some big explosion was on the edge of possibility which, given the context, one might think would be a nuclear explosion. The warhead, the "physics package", was never really a worry. Getting those to detonate requires some careful triggering.

This was also a SOLID fuel rocket. While you wouldn't want to damage it, it wasn't full of the nasty pressurized liquids of other missiles. Getting its fuel to actually ignite would require more than hitting it with a hammer. You need something akin to a blasting cap. Shuttle used something more like a giant flamethrower. The solid retro rockets were not directly triggered by a the short circuit. I'd bet good money that their ignition system felt the short rather than the fuel being ignited by the short.

<comment><USER12> Not an aerospace engineer or anything. I think the fear was that the rocket may tip over and collapse under its own weight. I wouldn't be too surprised if that could trigger an ignition of the rocket fuel at the very least, risking nuclear contamination.

While the physics package surely has numerous safeties, I'd be concerned that the safeties would be damaged in a way that no one could really predict after falling 80 feet. They served their purpose well, but you can bet all the engineers were in the lab for the next 72 hours straight looking for various failure modes.

<comment><USER13> Any damage to the warhead would likely make it impossible to have a nuclear reaction. In order to do that, the warhead would have to explode multiple precisely shaped conventional explosives with precise timing. If any one of them was deformed, nothing (apart from the small conventional explosion) would happen, even if all the safeguards incorrectly decided to explode the warhead.

<comment><USER14> parent was concerned about

> risking nuclear contamination.

not a nuclear explosion. A conventional boom could spread radioactive materials all over.

<comment><USER13> EDIT: I was wrong. See the child for correction.

There are no radioactive materials in the warhead. In other words: there are no materials that undergo radioactive decay. What is in there are fissile materials: ie. materials that emit neutrons upon being irradiated with neutrons.

The only way the warhead might become radioactive is if it partially detonated.

<comment><USER15> Pu-239 is radioactive no? Along with impurities like Pu-240 which are slightly more radioactive.

<comment><USER13> Thanks, I stand corrected. For some reason I was considering Uranium only (which also decays, but with such a long half-life).

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> This is why nuclear non-proliferation is important. Its difficult enough for a super power to safely store and control its WMD. Each new nuclear state magnifies the risks, and all the more so because they lack the after action experience that a half century of mishaps delivers.

<comment><USER17> Arms reduction is even more important. I'd rather live in a world where 20 countries have 50 warheads each, then one where two countries have 4,000 warheads each.

A weapon detonating by accident is terrible. Thousands of weapons on hair- trigger alert is civilization-ending. It's absolutely insane that we're conditioned to believe that this is not only normal - but the best possible state of affairs.

<comment><USER18> > I'd rather live in a world where 20 countries have 50 warheads each, then > one where two countries have 4,000 warheads each.

I absolutely would not. Those 2 countries know far more about the process then those other countries, and they have the budget to do it right. You would have to duplicate labs, and computers, and other efforts 20 times in your scenario, and each of those labs will not be as good as the 2 higher funded ones.

> A weapon detonating by accident is terrible. Thousands of weapons on hair- > trigger alert is civilization-ending.

Look at it from a fear point of view: No one will detonate a thousand weapons unless they are declaring total war. So all one needs to do is read global moods and see if total war is likely (it's not). (i.e. war might happen, but not total war)

An accident on the other hand can happen randomly, you would be permanently and constantly worried about one.

<comment><USER19> Major conflicts only happen in non nuclear states. In all honesty I'll bet that's what has kept India and Pakistan from a war.

<comment><USER20> Ahem... [https://en.wikipedia.org/wiki/Indo- Pakistani_wars_and_confli...](https://en.wikipedia.org/wiki/Indo- Pakistani_wars_and_conflicts)

<comment><USER19> After 1971 it has been relatively "minor" conflicts. Granted, none of this is a long time on the world scale, but thus far it has brought a lot more restraint.

</comment></comment></comment></comment></comment></comment><comment><USER21> _Hicks said the metal of the screwdriver contacted the positive side of the fuse and also the fuse's grounded metal holder, causing a short circuit that sent electricity flowing to unintended places._

Is there some company out there making non-conductive screwdrivers designed for electrical work? I can understand that maybe the materials science to make strong plastic screwdrivers didn't exist in the 1950s, but surely they exist today, right?

<comment><USER22> Oh yeah they exist. There are ceramic ones and I have also seen plastic ones.

I've seen other fun specialized types of screwdrivers in my career:

Screwdrivers with conductive plastic in the handle, to deal with ESD requirements in the spacecraft industry. Alternatively, take a normal plastic screwdriver handle and wrap it in copper tape.

Beryllium screwdrivers (non-ferrous) for use around MRI machine bores thanks to the insane magnetic fields. You also have to wear ceramic hard-toed shoes.

<comment><USER23> Wait, isn't Beryllium toxic? I was under the impression that you don't want to be around it.

<comment><USER24> Didn't you mother ever tell you to stop putting things in your mouth?

Also, it's used in dental alloys. It seems it's only toxic if you inhale its dust.

Fun fact: Your body has no way to remove it from your body, so you accumulate it forever.

<comment><USER25> Same problem as lead, IIRC.

<comment><USER26> surprisingly it is similar for iron too, luckily we can bleed.

</comment></comment></comment></comment></comment></comment><comment><USER27> I swear I read about this in Schlosser's "Command and Control" a couple of years ago.. maybe not.

[https://www.amazon.com/Command-Control-Damascus-Accident- Ill...](https://www.amazon.com/Command-Control-Damascus-Accident-Illusion- ebook/dp/B00C5R7F8G)

<comment><USER28> This comes up on HN every few months (I've commented on it before)and that documentary is shocking and terrifying. The Arkansas one was crazy. We almost lost a rather sizeable area and the radiation zone is out to Memphis.

</comment></comment><comment><USER29> "I wasn't there," Smith said of the explosion, "but I know there were two technicians who ruined their underwear. 'Cause that ain't supposed to happen."

Best line of the story. I'm curious how close we've been to nuclear annihilation and we had no idea.

<comment><USER30> As bad as this story may seem... it's nothing to the Demascus Titan Explosion... that really could have gone off

[https://en.wikipedia.org/wiki/1980_Damascus_Titan_missile_ex...](https://en.wikipedia.org/wiki/1980_Damascus_Titan_missile_explosion)

<comment><USER31> Interesting that both incidents caused by using the wrong tool (screwdriver here, socket there). Such a tiny thing, a hand tool in the wrong place...

</comment></comment></comment><comment><USER32> I found that the side-story as to how they even got this story was pretty fascinating: [http://rapidcityjournal.com/news/local/revealing-a--year- old...](http://rapidcityjournal.com/news/local/revealing-a--year-old-secret- how-we-got-the/article_66b0ef10-10ba-5584-b582-f80cd3f275fa.html)

</comment><comment><USER33> If you happen to visit Badlands National Park, or western South Dakota in general, make time to visit the Minuteman Missile National Historic Site mentioned in the article. I toured Delta-01 last summer, and it was fascinating. The tour guide did a fantastic job of conveying the gravity of the mission and just how scary the Cold War was.

<comment><USER34> When I visited, the guide was retired veteran from that missile site. He spent a _lot_ of time discussing the living situation, and the maintenance schedule, and the phone setup. The guy had internalized that bureaucracy over his entire career, and wanted to explain in in painstaking detail.

The underground control center was amazing though.

</comment></comment><comment><USER35> Incidents like this shows us that things will inevitably go wrong with increasing frequency and gravity.

Furthermore, I fear regional conflicts involving mass scale conventional face- off (ex. dmz) are converting to a low operating cost high risk situations in the form of mutually assured destruction.

East Asia is venturing into a potential double whammy of naval and nuclear arms race--smaller countries like South Korea are entering a phase of normalization for nuclear armament with pressure mounting from the public to have a deterrence and a back up plan yet cannot have land based missile silo's, instead relying on nuclear submarines that will host the IRBMs. The cost is much higher than the "previous generation", as smaller countries will most certainly be decimated, land based silos do not make sense.

</comment><comment><USER36> oh, and [https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash](https://en.wikipedia.org/wiki/1961_Goldsboro_B-52_crash)

"The two 3–4-megaton MK. 39 nuclear bombs separated from the gyrating aircraft as it broke up between 1,000 and 2,000 feet (300 and 610 m)."

For reference, Little Boy's (Hiroshima) yield was 15 _kilo_ tons.

<comment><USER37> Using the nukemap, with a target of Faro:

[http://nuclearsecrecy.com/nukemap/?&kt=4000&lat=35.5111142&l...](http://nuclearsecrecy.com/nukemap/?&kt=4000&lat=35.5111142&lng=-77.8447581&hob_ft=0&ff=55&zm=10)

<comment><USER36> the default there is airburst, but at Faro it would have detonated at the surface which reduces the radius a lot and casualties by a factor of 3, (prolly since less of densely-populated Goldsboro is affected)

<comment><USER38> But with a surface burst there would have been a fallout plume all the way to Norfolk, VA. The area would be uninhabitable for years, if not decades.

</comment></comment></comment></comment><comment><USER39> There was a frightening number of close calls over the course of decades on the american side alone. One can just assume what must have happened on the sites of other nuclear powers that just doesn't get reported.

You can find a timeline of these almost accidents here: [https://futureoflife.org/background/nuclear-close-calls-a- ti...](https://futureoflife.org/background/nuclear-close-calls-a-timeline/)

It's certainly time to reduce the number of warheads from a nuclear-winter- guaranteeing one to an at least nuclear-deterrence-still-works-but-an- accident-is-terrible-but-no-longer-civilization-ending one.

<comment><USER40> The incident in the article isn't a "close call". There was never any danger the warhead would go off.

<comment><USER41> There have been many accidents, of a kind where even one is one too many. Given the potential damage, I certainly don't feel comfortable with your assessment that there wasn't any danger it would go off.

Likely these things happen more often than is publicly known, yet we've not (yet) seen a full-on swiss cheese kind of accident.

<comment><USER40> Nuclear bombs aren't like normal bombs. You can burn them or blow them up with conventional explosives and they won't go off.

<comment><USER41> Yes, but there are two risks to that: 1) the conventional explosive detonates and it's similar enough to "normal" operating procedures to create critical mass and the nuke detonates

2) the radioactive material is spread out over a large area, contaminating

neither are as benign as an ordinary explosive of any yield, and I'd rather not risk any of that, at all.

<comment><USER40> It's hard to imagine your #1 could happen. The compression wave in a nuke has to be just right to achieve critical mass. It's not an easy thing to pull off deliberately under the best of circumstances

#2 is sort of half true. You wouldn't get nuclear material over a large area because it's so heavy. You could get a big plume from Chernobyl, but that was because there was a nuclear reaction going on, and it wasn't uranium that got boosted into the sky by the fire.

Still an expensive mess, but a pretty localized mess.

</comment></comment></comment></comment></comment></comment><comment><USER42> The irony of calling people working underground "airmen" is strong...

</comment><comment><USER43> Well in a solid fuel missile, there was simply no way it was going to explode due to any kind of external damage (or at all, solid fuel does not explode). Good that nuclear safety of the warhead itself worked well, as none of the explosive lenses gone off.

</comment><comment><USER44> Makes you wonder what's going on right now that nobody's telling you about...

</comment><comment><USER45> This article didn't seem like that much of an incident. The warhead didn't fire, at least. SL-1 is more of what I would think would be a real .mil-sector nuclear accident.

</comment><comment><USER46> This article sounds like a recruitment effort.

</comment><comment><USER47> It's amazing we've not had a major incident because of our recklessness.

</comment><comment><USER48> We've been very lucky so far not to have had any serious incidents.

</comment><comment><USER49> In my experience it is like US nukes in Turkey.

</comment><comment><USER50> That sounds pleasant

</comment><comment><USER51> This was really a big deal

</comment><comment><USER50> its good</comment>


The dangers of eating dogfood - <AUTHOR> http://blog.downie.com.au/the-dangers-of-eating-dogfood <comment><USER2> _"Dog fooding makes you lazy, and makes you less likely to understand your customer."_

I don't understand how dog fooding makes you lazy. Using your own products doesn't stop you from talking to your customers. If the company leadership cares about what the customers think, then someone will find the time to talk with them.

And using your own products has many advantages, such as forcing you to confront bugs and annoying user interfaces and performance problems and poor documentation. It's definitely something that you should do, assuming your products can serve some useful function in your company.

 _"you never have to find the documentation, or learn how to use your API."_

Documentation is an issue you'll face even with your own products. Unless your company is very tiny, there will be employees, even developers, who aren't intimately familiar with how to use all the advanced features of your products to solve real-world problems.

<comment><USER3> fully agree. dogfooding makes especially a lot of sense if your company has more than one product. my team, which is working on a commercial app, just started using the rDMS built by our second team - and it's great as we act as beta tester _before_ our customers get it into their hands.

this is not about classic QA, this is about "design bugs", that one extra annoying step in a workflow or missing safety dialog that doesn't warn you of a irreversible change.

of course this works particularly well as that product fits into our workflow. dogfooding becomes a bit unrealistic once it is about a product only your customers will really _use_.

</comment></comment><comment><USER4> I think this article makes a good point, but the way it's worded makes it easy to disagree with. Using your own product is better than nothing, but alone it's not enough to understand the relationship customers will have with it.

Dog food is not dangerous, you just have to include other foods in your diet to complement it.

</comment><comment><USER5> The points are good, but missing the elephant in the room: when you are competing with the best companies in the world in software (where the marginal cost is 0), you simply can't afford to compete using anything less than the best stuff. You need to go 'deep' (specialist), rather than 'wide' (mass- market) when it comes to the tools you yourself use. (Even though what you're creating is probably itself wide.)

That's why Microsoft doesn't use it's own source control solution (SourceSafe) internally. It just doesn't cut it.

That's why Apple doesn't design the next iPad on an iPad.

That's why McDonald's executes don't hold their business meetings in a McDonald's, to close important international deals etc.

You just can't afford to. This guy says "At BugHerd, we build a project management tool for web projects. BugHerd is, itself, a web project."

Imagine you just wrote the first version, and you realize that it sucks. How will you track the transition to the second, non-sucky version? If you're using project management software - the one you've just written - that by your own admission sucks?

That is a formula for disaster.

But the very same argument (for not using a disastrous tool) applies for the continual marginal improvement that better tools can give you.

It makes ZERO sense to 'bootstrap' any tool using that tool except for some special exceptions.

That doesn't mean you shouldn't test it :)

\</comment><comment>--

Some exceptions:

1) The tool is the only one that exists. Even a buggy version that takes 10x longer to produce a halfway decent result would still be the only thing that exists.

Perhaps the first compiler was like this: i.e. the first time someone translated paper into a compiler, it made sense to use that buggy version to recompile itself with optimizations. But that's because it was the only one to exist.

2) if you are now the best on the market, period. So, if you so happened to create the best tool on the market, sure, go ahead and use it.

3) if you are on par with the best. This is tricky. You can learn a lot from the competition. It hink in this case you should use both. Gimp might be 'on par' wtih photoshop, but I really think that Gimp developers should use both on a daily basis. It's amazing what kind of a perspective access to being an occasional user of your competition gives you.

<comment><USER6> I almost quit a job after having to work out a solution to a real-world problem dogfooding a product that was, at that time, really shitty. The problems with that version were known and the roadmap for the next one fixed, so no value was added except that some manager could boast about dogfooding. However, my mood was very, very dark during that time and quite some time after that. In hindsight, I should have just quit, and I would in a similar situation in the future.

I thus consider all dogfooding unethical that is not done by somebody who has, or is provided with, a lot of influence on the product.

<comment><USER5> You bring up a good political point actually, glad you brought it up.

Apple doesn't use it's most mass-market product, the iPad, to develop the next iPad. But it does use Macs, probably even where they're slightly worse than PC's. If some kind of developer at Apple really needs a Laptop with 64 GB of RAM they probably can't get away with it without a very good justification.

This does, however, have objective benefits as far as company image, esprit de corps, promotion, etc.

But Apple might be a special case.

I guess it comes down to whether you're building just a tool or a lifestyle image.

If you're building a lifestyle product, then sure homogeneity or self- promotion has a huge objective value to the company.

</comment></comment></comment><comment><USER7> And that's why you only buy human-grade dog food if you care about your dog. (Yes, I read the article)

I disagree with the article and think this is one of the best ways of actually understanding your product and how well it works in the real world. Don't test it like a developer. Use it like a consumer.

<comment><USER8> > Use it like a consumer.

I think the point of the article was that that is impossible. Your real consumers have issues you yourself simply cannot have. Whenever something about the product is bugging you, you fix it. The customer is depending on you for everything.

<comment><USER7> And I simply disagree with that. Don't test it out. _Use_ it. Take the canonical to-do app. Don't create a list and just test out your features. Integrate it into your life. Use it for your home improvement projects and your shopping list. There is absolutely no reason you can't depend on it the same way your customers do.

<comment><USER9> If you are a startup writing time-reporting systems, you will never be able to use it like the big customers. No startup will ever need time-reporting system consisting of thousands of charge numbers. No startup needs to worry about government compliance of charge numbers, or tax codes across all 50 States.

Hell, you probably don't even have 50 employees, let alone a reason to have all 50 tax codes in your time charging system.

</comment></comment></comment></comment><comment><USER10> Insipid.

Myopic view of your product? Then also use competing products to see what they do. And talk to customers. A lot. Golly, understanding that all of your customers aren't you seems like it's not a huge leap.

Figuring out pricing models? Well, I'm just a dumb engineer so I assume someone else knows about that but I'd guess that "not free" is a good starting point and you can probably haggle and talk with people from there.

I would hazard a guess that everyone wants a better bug tracker/project manager/et al. I would also hazard a guess that what everyone wants is a totally different thing than what everyone else wants. We've had these technical "solutions" for decades now and they all suck.

They suck because the actual problems aren't technical. They're people problems. How should you track all tghe whatzits in a way that makes everyone happy enough to work effectively but also accountable? That's an ape problem and not a technical one. The solution is in ape-space and not tech-space. Look to Skinner and not Knuth for those answers. (And please don't look to Skinner - creepy!)

</comment><comment><USER11> By the last paragraph, I get what he's saying (too many companies build something they'd never pay for in hopes that there's an audience that will), but I think he's arguing two different - but vital - aspects of testing.

There's dogfooding and there's finding users at all levels of experience (both in internet proficiency and experience with the type of software/service you've built) who have little/no incentive to use your platform over the competition. The best apps I have come across have had their community managers leverage me and ask repeatedly for my feedback and how to make things better. What else am I seeing going on in the market? How intuitive _is_ that action? If this tool didn't exist tomorrow, where would I go and why? If a user isn't willing to take the time to answer these questions, move on to the next person.

Reaching out to the right people here means free advertising and loyalty, in addition to fixing the problems you don't come across internally.

</comment><comment><USER12>
      "would we pay for this?".... and as a cash strapped startup we said no.

Thank you! I'd come to the same conclusion myself - it's reassuring to hear someone else say it.

The important thing is to see from your customer's point of view. Dog-fooding is just one technique that helps that. There's also: listen to them (and facilitate that); imagine a day-in-the-life; work in their industry; visit them; watch them using your product.

But remember that the rare and beautiful insight is of a problem they didn't know they had.

</comment><comment><USER13> "using some small slice of functionality" Knowing when your code breaks is invaluable and trumps any potential big picture problems. You can have the big picture correct but it is worth nothing if your product doesn't exist because your code doesn't work.

</comment><comment><USER14> I totally agree with your article.</comment>


Why I Didn't Apply to Y Combinator - <AUTHOR> https://medium.com/on-startups/ebb45a310757

<comment><USER2> Reminds me of something I learned at a Startup School:

"Jack Dorsey & Ben Silberman are successful bc they don't care about the outside world...don't care about press." \- @RonConway</comment>


Show HN: New version v2 released for texthelper1, JavaScript library - <AUTHOR> https://www.npmjs.com/package/texthelper1 <comment><USER2> The endpoint, does it just ad the dot or does it check if there is already a dot?

<comment><AUTHOR> New version (v2.0.1) publish for endpoint method change. [https://www.npmjs.com/package/texthelper1/v/2.0.1](https://www.npmjs.com/package/texthelper1/v/2.0.1)</comment></comment>


Python lib to monitor CPU and Memory usage of any process - <AUTHOR> https://github.com/astrofrog/psrecord <comment><AUTHOR> Quite nice to see, easy to use, can monitor any process in a programmatic way.

Usage : from psrecord.main import monitor monitor(XXXX, logfile = "./test.log", plot=True, include_children=True)</comment>


Show HN: Fsev – OS X file event watcher under 50 lines - <AUTHOR> https://github.com/arthry/fsev <comment><AUTHOR> Hello, author here to bring a quick note. I've been using a file event command triggerer "when-changed" (requires watchdog) since long time for my dev environment. As I mostly use macos for development, I wanted to see if a solution would exist without any installations. Turns out, macos already supports file events using launchd ([https://stackoverflow.com/a/1516034](https://stackoverflow.com/a/1516034)). I've written a simple Python script to wrap around this idea. As a result, it saved the day with no deps as I was looking to execute a simple bash command only. I hope you enjoy it too! Thank you for checking out.

<comment><USER2> Great job! Farewell to [https://github.com/joh/when- changed](https://github.com/joh/when-changed) and [https://pythonhosted.org/watchdog/](https://pythonhosted.org/watchdog/)

<comment><AUTHOR> Thank you! Currently it's missing multi-paths (assuming watchpaths only support dirs) and run-on-start features compared to when-changed, but looks possible to have.</comment></comment></comment>


If Elected, Barack Obama Would Name a Chief Technology Officer - <AUTHOR> http://venturebeat.com/2007/11/13/exclusive-barack-obama-to-name-a-chief-technology-officer/

<comment><USER2> The government tends to...mess things up like this...

Just saying.

<comment><AUTHOR> You're right, of course. What I DO like about this is the fact that Obama (seems to) know enough to say that he needs someone to help his administration understand technology. I can't fault that at all.

<comment><USER3> Why would they need help? Our current president is an expert on The Google: <http://www.youtube.com/watch?v=90DKubFKwVo>

<comment><AUTHOR> My head just exploded. I can't decide if I like the infamous Ballmer video or the infamous "The Google" video better.

Always a good laugh.

<comment><USER4> I have referred to Google as "The Google" for a long time now.

</comment></comment></comment></comment></comment><comment><USER5> What a great idea. After all, we can look to the state of education in this country, which has been greatly improved by the presence of the Chief Education Officer (Secretary of Education in the Cabinet).

Yes, I like sarcasm.

I guess I don't understand which important problem this is trying to solve.</comment>


Verizon How is this even legal? - <AUTHOR> http://pastebin.com/cwBbSgCP <comment><USER2> What's funny is how long Bob goes on with the logical arguments when it has nothing to do with logic, and the CR told Bob that ("that option is not available to me"). The dropdown the CR has in front of her does not include "remove charge for router maintenance". No amount of arguing is going to change that. Bob is arguing with the wrong person. Bob asks for a supervisor. Supervisor says that it's not on his dropdown, either. Maybe they're lying, but it doesn't matter if they're keeping their stories straight and Bob's not threatening to leave Verizon.

johng has the right idea: go argue with someone that is empowered to do something about it.

<comment><AUTHOR> yeah, looking into filing an informal PUC complaint now. I did later in the conversation mention that I was going to be exploring other internet options. Of course that didn't make a difference in the conversation.

</comment></comment><comment><USER3> Clearly the maintenance fee allows them to maintain the income they would be receiving if you were renting a router from them!

<comment><AUTHOR> true! I didn't ask them what the maintenance fee is designed to "maintain"

</comment></comment><comment><USER4> 99% of people are going to call Verizon support if they have a problem with their non-Verizon router and can't get on the internet and it will take longer for customer service to fix the problem because the router options etc will be different. This makes perfect sense to me.

<comment><AUTHOR> I understand that but a customer shouldn't be force to buy hardware from the vendor, or be charged a fine for not doing so. Either work the cost of the hardware into the price of the service, or offer a way to have the service with limited support if the customer wants to take care of it themselves.

Verizon should be able to know if their service works all the way to THEIR box, after that it's my responsibility if I choose not to pay for the additional service.

</comment></comment><comment><USER5> Charge your for router if you have it, charge you for not having it... they win either way. It should not be legal. I'd contact the PUC/PRC for whatever state you are in.

<comment><AUTHOR> would this fall under the PUC? I didn't think internet was considered a "utility"

</comment></comment><comment><AUTHOR> this just makes no logical sense!

</comment><comment><USER6> Mmm... If they called it "third-party router penalty" you wouldn't be wasting all this time with this.

Obviously they want to make extra money on top of what you pay for the internet. That comes in form of renting you a router or getting the money anyway with a fee.

The naming is wrong. It shouldn't be called "maintenance fee", but it doesn't look like there's anything you can do.</comment>


The best way to make dating on top of Facebook - <AUTHOR> http://alittlewink.com

<comment><USER2> Is this any different from the other crushed-based Facebook apps? I've seen about 10 of these posted on HN and none of them stick out as unique.</comment>


The Stupidest Business Decisions in History - <AUTHOR> http://www.neatorama.com/2008/04/15/the-stupidest-business-decisions-in-history/

<comment><USER2> Snot beer. Ew. Really though, what is sad is that there are a ton of good ideas that got turned down and DIDN'T end up making it. Don't ever give up guys, even if your sick of getting rejected!

</comment><comment><USER3> I see uncle john's bathroom reader is still going strong. As a joke in college I submitted a paper whose 6 or 7 citations were all from the "bathroom reader".</comment>


Interesting Captcha (scroll down to the comments) - <AUTHOR> https://www.adafruit.com/blog/2012/05/30/v-in-transformer-winder-symbolizes-victory/#respond

<comment><AUTHOR> Originality apart, I personally think this is a terrible idea:

\- Requires Javascript.

\- Makes accessibility suffer (your colorblind users are going to be _so_ mad).</comment>


Can Recipe Search Engines Make You a Better Cook? - <AUTHOR> http://www.nytimes.com/2011/05/18/dining/can-recipe-search-engines-make-you-a-better-cook.html?_r=1&ref=global-home

<comment><USER2> Going to the web for a new, untried recipe is very hit-or-miss. I think it's more useful if you've already made something similar.

If I try something new I usually go to two or three standard sources, e.g. Joy of Cooking, Cook's Illustrated, Silver Palate or Dr. Oetker and then compare with a handful of search results from the web. That way I get a feel what the range of each of the ingredients is.

What would be really interesting to me is an app that pulls down as many recipe sources as possible, normalizes the ingredients and displays them all on a percentage scale. Doesn't really help with learning a new recipe but that would be great for experienced cooks looking for specific variations.

</comment><comment><USER3> More accurate headline:

Can Recipe Search Engines Find Recipes That Actually Taste Good And Meet Your Requirements? No Cooking Ability Required.</comment>


Internal irc-log of the tor-project reveals debate about hiring an ex-CIA agent - <AUTHOR> http://pastebin.com/WPAmqkW8 <comment><USER2> Don't want to drag up the whole Jacob Applebaum thing again, but just the way he talks in these logs makes me wonder how anyone could tolerate working with someone who keeps saying things like "I did X, I did Y".

It's surprising that it seems like only Isis really stood up to his line of questioning while the rest kind of fell silent.

<comment><USER3> He is _insufferable_! Exactly the kind of person that makes at least half of Freenode so awful to participate in.

<comment><USER4> +1, this is just typical irc behaviour.

</comment></comment></comment><comment><USER5> I honestly don't get why this is coming up now. TOR's funding never was a secret. Serious infosec people didn't need Snowden to be suspicious about the actual anonymity provided. If one was not concerned back then, what does an ex-CIA agent (or even not-so-ex CIA agent) in the tor project change?

<comment><USER6> "TOR's funding never was a secret."

Sort of. The Pando article they reference, which showed me more about them than the author, points out that they try to promote the funding as "independent" source rather than U.S. government-backed groups made by or tight with CIA. All the press around the situation would make you think it's a group for the people, by the people, and so on with some historical military connection. Whereas, the people aren't funding most of Tor: "The Man" Tor appears to oppose is. Even in this conversation, they're worried about that image situation and how to minimize exposure that one CIA person might work in Tor despite the fact that such types are funding it it. If it's so transparent, you wouldn't have so much work on that.

Who knows why it's coming up & it's not secret as you said. Yet, Tor pages I've read certainly weren't describing themselves as a tool of U.S. intelligence agencies funded by their fronts. They seem to work at avoiding that in favor of some image independent that U.S. intelligence just happens to also like and use. Which is inaccurate.

I'm curious. If we take away all U.S. govt connected funding, then how much is left for the developers and how many will that be? That should be a hint at level of independence.

<comment><USER7> "Sort of"? Tor was a project of the Naval Research Labs. Even 51% of Wikipedia editors know about its USG funding.

<comment><USER6> Your point doesn't contradict mine even if made-up 51% number was true. Selective as usual focusing on its start and fact there's USG funding. Yet, a person looking on site at "About Tor," "Core team," and "Sponsors" doesn't get a clear indicator that the vast majority of funds so far as come from groups CIA created to wage propaganda wars and act for U.S. foreign policy. That fronts allegedly separated from despite them doing basically the same jobs today funded by U.S. government doesn't reduce that concern. Readers might think instead it's a mostly for-the-people organization whose funding is spread out among many groups instead of the kind its libertarian proponents would seem to fight rather than work for. Then, we have chat logs from a group funded by CIA & affiliates worried about their image if one CIA person is in the project.

Hence, "sort of." I'll change my statement to their source of support being clear when they state such things clearly on their web site and stop the kind of smears I saw in response to the Pando article. I mean, here's people taking money from CIA and/or affiliates openly speculating that someone saying so or implying it means something must be... working for CIA, a fascist, or something in a smear job. Repeat, people paid by vicious, authoritarian regimes they claim to fight accusing someone of evil or connections to such regimes for reporting their source of funding. Unreal...

I'll be interested to see how long popular support for Tor lasts if it's marketed as a former Navy tool currently supported by CIA and State department groups. The reality probably will change the perception of it and when/where to use it _a lot_. I still support the project as realists like me know it's a double-edge sword they need to work but might try to compromise in limited ways. Hence, me pushing strong security engineering to be applied to it.

<comment><USER8> The 51% was a joke, and a good one at that.

<comment><USER6> I got it. Stepped on it in my counter. The response to Pando piece and these logs don't fit that joke or its implication at all. Plus a strawman given Tor is meant for laypeople mostly. Let's restate the Tor sponsor page differently to show what they're doing:

"A US project about helping people enable anonymity plus fight oppression of authoritive regimes, from China to US, that's mostly paid for by CIA and other US propaganda organizations along with small contributions from these other organizations."

Juxtapose that against the IRC logs for the real joke. They fear what will happen if seen as affiliated with even one CIA person. Only imagine what their image would be like if lay users, not just security experts, saw their funding spread and sourcing. Probably why they present the sponsor page and other parts they way they do. Obscuring source to maximize uptake.

Truth is that they're a tool that can be wielded for good or bad. That it's mostly US govt villians funding it is acceptable to me for greater good so long as legit software. It is so Im fine. That's realistic. This hide the CIA guy crap doesnt fit with reality if they push a genuine one.

</comment></comment></comment></comment></comment></comment><comment><USER9> I can't quite connect the dots...how is the involvement of the ex-CIA guy putting the family of one of the people in the logs in (more) danger? It's already CIA funded so any government that wants to torture people for using Tor can already legitimize that practice (but tbh why would they even bother) since they are "using CIA-software" or whatever reason you want to give. I feel like I'm missing a logical step here.

I do think ex-spies should not be involved in the project and the insistence of DaveC1 is really odd (as is joining before getting clearance to say he was CIA...why not get that first then ask if he can join). Why isn't he coming to the conclusion that it is probably a bad idea and he can get involved in other ways.

Do we know who leaked this, is it more likely to be someone on the pro or contra ex-CIA-involvement side? Logically it makes no sense for say mrphs to leak this, right?

</comment><comment><USER6> The ridiculous thing about this, if accurate, is that Tor was (is?) primarily funded by an organization connected to State and CIA propaganda efforts. Most of them receive money from US governmemt in sone way. CIA itself uses Tor for same reason Navy created it. While FBI and NSA hate it, the CIA and State love it as a tool for protecting foreign operators or dissenters. Makes it funny they're so worried about bringing CIA in.

Anyway, the right way go do security against nation-states is creating deliverables and processes that are verified by mutually-suspicious parties. As in, with high-assurance security, you assume the people are largely malicious while focusing on vetting thd product and process throughout lifecycle. Not sure what this CIA person's role is supposed to be but it's bad INFOSEC and OPSEC if he can unilaterally do lots of damage. Shouldn't be possible.

Far as image, just like my subversion-resistant build scheme, having helpful CIA rep onboard as a check American government can trust is beneficial at least for _review and testing_. Have one from each major government or institution using the service acting as checks against inserted or ignored subversions. Plus non-government groups of course. That one CIA guy can compromise either service or image again makes process or trust assessment look weak.

I say let them come onboard but with non-critical access and any actions reviewed. Even if failure, it would teach important lessons.

<comment><USER10> > Makes it funny they're so worried about bringing CIA in.

Except for the fact that the USG actually buys into the concept of NOBUS, as evidenced not only in the classification system - but also foreign policy (the proliferation of AA and AT weapons comes to mind). So the USG's use of TOR provides me with zero confidence that they wouldn't actively weaken it. That said, I agree on the issue of trust - secure software shouldn't need any. They need to decide between two very distinct paths: accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. Because one is so hard, and the inevitable failure of the other can be ignored for now - I'm guessing that we'll see no push for formal verification :)

<comment><USER6> Was looking forward to see what you'd say here. :)

"Except for the fact that the USG actually buys into the concept of NOBUS"

This is true. I considered it given a subverted, but otherwise working, Tor network would be a win-win if CIA was subjected to pressure or wanted to de- anonymize opponents. Yet, the Tor project themselves answer this one: it's vulnerable to a global, passive adversary. NSA has painstakingly built partnerships with all kinds of countries that collectively do a giant SIGINT operation. Most of them probably don't like Tor. CIA or partners can get info from NSA on these things. So, CIA can already defeat Tor for some fraction of users since their partner is outside its probability of success. On top of whatever CIA might pull.

"accept the insecurity and try to control it socially (no CIA guys), or mathematically demonstrate infallibility. "

Well, remember that there's always the path of just clearly specifying the functionality plus implementing it in the safest way possible. We used to call this medium assurance. OpenBSD is the code-only version of that. Praxis w/ Ada/SPARK is the spec + code version. Only around 30-50% premium in labor/cost added doing these things despite immunity to all kinds of shit. They aren't going to do it, though. They never do. Leading to...

"I'm guessing that we'll see no push for formal verification :)"

...no push for that or even system-oriented languages and techniques that make the service immune to memory- or interface-level attacks that make up 80-90% of vulnerabilities. Not even that.

<comment><USER10> We certainly share an interest.

> Yet, the Tor project themselves answer this one: it's vulnerable to a > global, passive adversary.

Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext.

> ...plus implementing it in the safest way possible.

I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable. It would be an improvement for sure, but you'd still have a trust requirement. I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state. At the risk of incentivizing spaghetti code, you'd incentivize the production of code that really lends itself to static analysis.

> ...memory- or interface-level attacks that make up 80-90% of > vulnerabilities.

I look forward to us getting past the memory vulnerabilities, but the next battle will be one hell of a fight - timing attacks. Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)

<comment><USER6> "Vulnerable to traffic analysis, I'm sure certain organizations wouldn't mind seeing that vulnerability include cleartext."

Well, certainly. Depends on what this guy's role is supposed to be in the organization. One can always relegate the riskier people to stuff that can't harm them much. In any case, NSA can already do what you mentioned given leaks mention active targeting. Catalog includes regular malware, 0-days on stuff, and implants. Tor is the LTD they aim at themselves with optional LGB's following from QUANTUM and such. So, it would be a matter of already- vulnerable people or services getting more so.

"I've never seen an Underhanded Ada Contest, but I'm pretty confident that a bad actor could still introduce vulnerabilities that would pass a reasonable code review and be deniable"

Well, sure. Just remember, though, that what you're saying already applies to the Tor project. Any of the contributors, maintainers, relay hosts, and so on might be malicious. That's why A1 class called for protection throughout whole lifecycle which my framework below expanded on. SAP security guides showed most areas requiring protection. Examples below:

[http://pastebin.com/y3PufJ0V](http://pastebin.com/y3PufJ0V)

[http://www.dss.mil/documents/odaa/nispom2006-5220.pdf](http://www.dss.mil/documents/odaa/nispom2006-5220.pdf)

Now, from here, we have to ask what can be done to mitigate potential exploits. Well, we know the protocol itself is subject to strong, peer review by parties more than willing to publish problems and organization that corrects them. The main problems occur in crypto libraries, protocol engines, interfaces, type checks, memory errors, parsing, handling time, and error handling. A type-safe, memory-safe, low-level language along lines of Ada/SPARK, Go, Rust, or Modula-3 plus specific libraries and guidance on aforementioned can knock out vast majority of the risk. Well, that along with parser/protocol generators already available in academia with hand-checked code and design-by-contract to encode constraints. OpenBSD people probably do considerably more work on their code than what would be necessary to take care of this in safer language while focusing on areas most likely to be hit.

So, I think we can get plenty mileage without full, formal verification. There will be flaws just as there are in protocol itself. Yet, it will work most of the time with people finding problems so long as plenty are on it motivated to do so.

" I think a good half measure would be: fully spec'd pure functions don't need human code review - just feed patches to the theorem prover and regression tester, all the trusted human labor can then focus on things that touch global state."

They still need review. You have to specify what you're going to do, what security properties it maintains, how it maintains that, and the implementation correspondence. Usually also show compiler didn't screw it up. That's tricky. Pure functions are fine but covert channel analysis means it's going to be an imperative language for final implementation. Old model was basically decomposing functional components into state machines representing every permissible state. Can check by eye that they either should work securely or fail-safe. Still keeping my eye out for CompSci tech that can derive imperative from simple, functional languages in human-readable form.

"Thought getting people to trade C performance was tough? Try getting them to intentionally delay all comparison operations... in the entire software stack :)"

Oh my god, I've been there. Mainstream INFOSEC totally ignored that problem saying it was unnecessary until recently rediscovering it under "side channel" label. Running wild with it. I called out Freenet on Schneier's blog as probably having plenty due to use of Java. Meanwhile, old methods of handling timing channels were reducing precision, fixed-rate, maximum-time, turning off caches (extra painful on Core i7), masking, and my favorite being asynchronous, randomized execution. I was going to put the latter in a CPU then found someone else already did that. Clever. Partitioned caches are another popular strategy. I just stick with Red/Black model in my designs with trusted part being dedicated chip with timing mitigation for just needed part. Still performance hit no matter what.

Anyway, I did a write-up for someone on how to secure a service like Tor here:

[https://www.schneier.com/blog/archives/2014/09/identifying_d...](https://www.schneier.com/blog/archives/2014/09/identifying_dre.html#c6678915)

<comment><USER10> > In any case, NSA can already do what you mentioned given leaks mention > active targeting.

I see it as a massive difference: dragnet scope, loss of forward security due to precomputed magic numbers, etc. While the threat is hypothetical, unlike traffic analysis and active targeting, the consequences elevate it to a point where it deserves its own consideration.

> ...on aforementioned can knock out vast majority of the risk.

I'm usually a one bite at a time sort of guy when it comes to eating elephants, but I think a language switch should bring a little bit more benefit - especially considering the unsolved compiler optimizing security away problem (outside of language subsets enforced by self discipline). It is dangerous, and it has led to the slow death of many projects, but I'd recommend some time spent on custom tooling. The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy - retaining array size metadata in function arguments instead of throwing the information away. ACSL for contract specification would be nice, or at least fix frama-c so that it isn't so awful.

> They still need review. You have to specify...

I was speaking of implementation changes to already specd functions, but after further consideration I want to double down. Any changes to code further down stream of well specified functions shouldn't need code review. That wouldn't be a very good way to go about it, one massive function specification instead of a composition, but it would still be secure.

> ...covert channel analysis means it's going to be an imperative language for > final implementation.

Yeah I didn't mean a functional language like haskell, as I've yet to write any production quality code in it after several years of trying... I was thinking more along the lines of the function __attribute__((const)). This might make my no review suggestion not work, but that custom tooling might be able to help with detecting information leaks through variable loop iteration counts. Lots of ways to tackle the problem.

> Mainstream INFOSEC totally ignored that problem...

I can sympathize, I recognize it as a problem - and I try not to think about it because it makes me very sad.

<comment><USER6> "the consequences elevate it to a point where it deserves its own consideration."

Well, it does but maybe not here. Let's remember the situation. The consideration is only applying because a person openly said they're ex-CIA. So, we apply these considerations when people say that. Result? Instead of risk going away, they just stop saying they're ex-CIA. Maybe start talking about privacy, crypto, Anonymous, blockchains, and so on. Infiltration 101 applied to Tor project. Filtering out anyone claiming to be ex-government doesn't filter out ex-government except for those specific cases. This level of consideration, if infiltration risk is high, has to be all or nothing.

"The furthest I'd suggest would be language extensions, likely implemented as external llvm modules, nothing crazy"

It's a reasonable proposition. I considered something like Cyclone, a security-aware scheme for managing heap, and with JIF-style labels for information flow. Might knock out a lot of problems while keeping code mostly the same and able for C programmers to handle.

[https://en.wikipedia.org/wiki/Cyclone_(programming_language)](https://en.wikipedia.org/wiki/Cyclone_\(programming_language\))

[https://www.cs.cornell.edu/jif/](https://www.cs.cornell.edu/jif/)

" Any changes to code further down stream of well specified functions shouldn't need code review. "

This is ambiguous. Are you saying that, with how they all interface, that any changes to lower-level functions should preserve interface invariants enough that higher-level stuff shouldn't have to be re-reviewed? If so, that would be reasonable. If not, please elaborate.

<comment><USER10> > ...a person openly said they're ex-CIA.

It was my understanding that he first misrepresented himself as a State Department employee, then for some reason came clean several years later. I think filtering that sort of behavior out has a lot more pros than cons.

> I considered something like Cyclone...

A lot of that can be done with compiler annotations, the disadvantage of course being that it isn't default behavior... which is consistent with the rest of the C universe - things are no more secure than you design them to be.

> If not, please elaborate.

That is what I'd say if I was an OO programmer, yes. But I'll elaborate anyway because... have you ever just been in the mood to write gibberish C?

       /* New unreviewed code from untrusted source */
       __attribute__((const)) /* More pure than "pure" */
       static int newfunc(char* src, int len){ return src ? 0 : len; }

       /* Imagine an incredibly comprehensive spec for this public function, right here */
       __attribute__((nonnull(1,2))) /* No Cyclone needed for null safety here */
       int pubfunc(char* a, char* b) {
         /* ... */
         if (a[0] == '4')
           return newfunc(b, 4); /* Untrusted function covered under that amazing spec you imagined */
         /* ... */
       }

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> What a histrionic, over-emotional mess these people are. With personalities like that, it's a wonder any meaningful work on Tor gets done.

<comment><USER12> Agreed on one hand. But on the other hand, these are literally (as noted in the log) people who have physical security concerns travelling to a large part of the world if their identities are public.

Only paranoia if your laptop doesn't get seized at customs every time you fly, etc etc.

</comment></comment><comment><AUTHOR> All this drama spawns a few interesting questions:

* How should Open Source Projects deal with internal drama?

* Should people who have a history of working with governments be shunned by the infosec community?

While I have no input on the first one, I can't help but notice that the connection between tor and the US government is already so strong (funding, the lead developer "arma" being a former NSA intern) that "undermining tor" would be pointless.

<comment><USER13> What gets me is once we know who the ex-government people are, they sure as hell become huge targets for people still working for the gov.

I wonder how many times arma has been approached.

I hate saying it, but I do feel like ex-gov is fruit of the poisonous tree.. at the same time I think these people specifically would understand the need for tor.

<comment><USER14> Depends on their motives for joining the gov in the first place? Leaking and whistleblowing? Awesome! Everything else? Not so much.

</comment></comment></comment><comment><USER15> Mirror, since these things have a habit of getting deleted...

[http://hastebin.com/ecuwegiven.xml](http://hastebin.com/ecuwegiven.xml)

</comment><comment><USER16> RE: Those reactions from mrphs and ioerror

Apparently TOR's reputation can be utterly destroyed and result in loss of life by something as simple as a person trying to join the team. Who knew?

They claim that just by approaching them he did damage, why didn't they think of this before? Just send agents to offer to write blog posts, watch the devs flip out and revoke their keys.

Seriously, if that's all it takes, you have bigger problems.

</comment><comment><USER17> At one point they say that the CIA would do and say anything to keep an agent's cover. If so, then why would they send an agent in who's openly admitting to being an agent?

<comment><USER18> he lied and said he was from the state department first.

</comment></comment><comment><USER19> Why are we letting USG people be involved with anything? Anyone with a current or former association with the military-industrial complex should be blacklisted. These people are nothing but trouble; they are ideologically untrustworthy and very likely beholden by both carrots and sticks to government interests. They're unfit to be involved in any project but especially those with security implications to the average person.

<comment><USER20> For one: because much of what we know of the surveillance capabilities of state actors and the ways these capabilities are being used, we owe to whistleblowers like Edward Snowden, Chelsea Manning, and Thomas Drake.

<comment><USER21> "what we know of the surveillance capabilities

Correction: What you have been told.

</comment></comment></comment><comment><USER22> There is no such thing as 'ex-CIA agent'

<comment><USER23> Correct, the title is "Officer" of the "National Clandestine Service", a part of the CIA. Source, I worked with some spooks in Iraq when I was US Army Military Intel (UAV was then changed to Aviation after I got out).

</comment></comment><comment><USER18> After reading this, I'm pretty sure I understand why Appelbaum is getting bombarded Assange-style with rape/harassment allegations: He single-handedly acted as the voice of reason in this conversation.

<comment><AUTHOR> > ioerror: I shut down the city of san francisco to stop the war

> ioerror: Once, I was deported from Lebanon for being jewish, which was > because htey said i was a spy for israel (false) > ioerror: If we have a CIA > person working with Tor, I won't get out of that next time, I fear

I sincirely hope you are being ironic.

<comment><USER18> I fail to see how your quotes discount anything I say.

Do you have evidence that he wasn't deported for being jewish, and that having CIA ties to Tor wouldn't cause him injury?

Do you have evidence that he didn't hack SF infrastructure as hacktivism?

</comment></comment></comment><comment><USER24> I like to think that most people don't expect something like TOR to protect against a determined government. That doesn't make TOR useless, since I suspect that most people are not trying to be anonymous from intelligence agencies, only law enforcement agencies.

<comment><USER7> Hasn't Tor already demonstrably failed to protect people from US law enforcement?

Tor is an important research project. But that's what it is.

<comment><USER25> Are you talking about the current FBI case? That was an exploit in the Tor Browser Bundle (could force the browser to make a request using the non-tor network), not in the Tor Network itself.

<comment><USER7> No, I was referring to the FBI hidden service de-anonymization attack from last year.

<comment><USER26> You mean the Flash based NIT exploit, as part of Metasploit? Flash which is by default off in TBB and has really nothing to do with tor, is actively discouraged by the tor project, and is in strong decline world over?

Or are the talking about the Carnegie Mellon attack that modifying Tor protocol headers? If so, is that fixed security bug enough to judge tor as failure and only usable for research? Even seatbelt, which has a fairly simple concept, had initial issues and are still being improved.

On the topic of the Carnegie Mellon attack, the tor project both addressed the protocol header bug and changed their security practices. Strange activity in the tor network has in the past been deemed safe until proven harmful, but as a result of having an research university doing attacks on users of the network, that practice has been reversed and strange activity is now deemed harmful until proven safe.

</comment></comment></comment></comment></comment><comment><USER27> Is there a breakdown somewhere of who these individuals are/what their relationship to the project is? I find that more context I'm missing might help me understand.

</comment><comment><USER28> Why are they using IRC instead of something like SILC? Or is this an internal IRC channel that's only accessible using TOR (or maybe something else?)</comment>


Machine learning-based NBA predictions, method and visual - <AUTHOR> http://efavdb.com/nba-dash/

<comment><AUTHOR> We are using a collaborative filtering algorithm, as outlined here:

[http://efavdb.com/nba-learner-2013-14-warmup/](http://efavdb.com/nba- learner-2013-14-warmup/)

Any comments on how we might improve the visual would be appreciated.</comment>


Google Science Fair 2015 - <AUTHOR> http://googleblog.blogspot.com/2015/02/google-science-fair-2015-what-will-you.html

<comment><AUTHOR> This is Google at its finest. This caught my eye because my 10-year-old is doing her third elementary school science fair next month. It's an amazing experience, watching all these children getting so excited about science.</comment>


Steal from the best, but don't steal the wrong thing - <AUTHOR> https://blog.hunter.io/steal-from-the-best-but-dont-steal-the-wrong-thing-16fd44d33b1b <comment><USER2> Just because a decision is forced by scale doesn't necessarily mean it's bad for small scale. For example, Git was created for the Linux kernel project and is designed to be performant in scale, but it's still a good decision to use it when you're a single developer.

(Also, why bash ThinkPads? They're great laptops)</comment>


A simplified variant of Tetris in fewer than 140 bytes of JavaScript - <AUTHOR> https://gist.github.com/aemkei/1672254 <comment><USER2> How many bytes would it take to make the whole game?

<comment><USER3> I don't know the precise answer, but I can tell you the lower bound</comment></comment>