ColinDabritz

Alfie Kohn has some good commentary on the topic of 'grit' as an educational philosophy: http://www.alfiekohn.org/article/downside-grit/

It's not just overrated, it can be actively harmful.

He goes further on this and other topics in the book "The Myth of the Spoiled Child"

Certainly, but the borders aren't so obvious to me. Is any language going to last 100 years without changing so much it feels 'nothing like' it's origin point?

Even if it hasn't changed in name, it may have changed in spirit. Some languages that promote themselves under very different names are substantially more similar than other cases where new language versions are dramatically different.

What 'essence' makes it the 'same language'? An interesting problem.

Regarding LISP, perhaps the perspective that does count LISP and its descendants as one ongoing evolution of a similar language family is the same perspective that will allow that lineage to last 100 years?

I feel that the systems that change over time have the best chance of weathering it.

Perhaps if the feature requires continuous observation by the driver, it should require a continuous 'hold' of the button to operate?

On the editing experience side, OmniSharp brings a richer text-editing experience to dot net development on many existing platforms and editors, including command line classics like emacs and vim.

http://www.omnisharp.net/

I had a similar reaction. I like the joke the site is making, it's well done. I had a good laugh the first time I saw it, and I've shared it with friends. Jokes are often huge exaggerations though.

QR Codes definitely have valid use cases, and I'm wondering if they aren't also somewhat 'ahead of their time'. They are useful ways to transfer contexts in the physical world. VR, and especially AR (Augmented Reality), is about combining the physical world with the digital one.

I'm imagining a future where not very many people "see" QR codes, but rather have AR devices like we have cellphones now, and they simply see the relevant content in place over the QR code or similar. I think of use cases like glancing down the street at a bus stop, seeing live updates of a NCAA bracket on a poster on the wall, those sorts of things.

I think a lot of the problem with QR codes is simply the friction of using them. I could see them used much more if you could simply open a website by literally pointing a phone at them (e.g. without any setup, opening apps).

When we have persistent AR at all times, the friction could be non-existent, you already see the information in place.

There's also the possibility that location and motion tracking are good enough that they can always be virtual, but I feel like the real world reference and 'binding' cues are important. We'll see how things unfold.

Wow, those videos are mesmerizing. Impressive work, feels like the future!

I ran across a related issue working on a project that I think helped me understand the broader issue better. I'll relate it here and see if it helps.

We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched.

Phone numbers were restricted information for some users, and we didn't display them in the search results. But you could search by those fields, if you already knew the value.

It turned out we left 'partial matching' available in the phone number field.

If you knew the name of a particular person, you could do the following:

Enter their name to confirm a single match shows up.

Then enter the same search, but put a single digit in the phone field, say "0". If no result came back, you knew that their phone number didn't start with that digit. So you try the next, 1, 2, 3... when you hit, say 5, you get a result. Now you know their phone number starts with a 5.

So you start on the next digit. 50-, 51-, 52-... and you get the next digit. Eventually you can reveal their entire phone number, and it was fast enough to do manually.

It wasn't super critical for the internal system, so we changed the phone numbers to exact match only and that was fine. but let's continue.

Let's say we had a REALLY slow system, and it checked each digit one at a time, taking one second per digit, and sent back a failure when it hit a non matching digit. We aren't leaking information DIRECTLY, you get no records back for partial matches. But we ARE leaking information indirectly. The attack now works roughly like this:

Do the same verification search to get a record.

Now do the same digit by digit search, start with 0. Carefully time the delay when you submit the question, and when the error shows up. If it's almost instant, you know the first digit failed. If it takes about a second to give you an error, you know the first digit worked.

You then continue to the second digit. One second fails, two seconds verifies.

Using only the timing you can determine each digit, and reveal the entire number. This is not the main information channel, the timings are what they call a side channel. The service that gives you this information by responding with an error and varying the time is an 'oracle' because it answers your questions.

This seems clear at a one-second time scale and obvious when it's explained, but it turns out that even over public networks with enough tries you can determine very small time differences, on the millisecond or less scale.

It turns out there are a lot of variations on this, some of them are very complex, and secure systems need to work very hard to run in the same amount of time ("constant time") for any query to avoid leaking information this way. The timing exploit described above is a very simplified form of the root of the described vulnerability.

This situation helped me understand 'timing attacks' and 'oracles' in a more mundane coding context, and hopefully it will help others.

Oh, I agree. I don't mean that the weakness created the vulnerability entirely, thank you for clarifying. I appreciate the excellent research and security investigation done here. It was excellently articulated and presented, and we need to keep improving our publicly available tools and finding these issues.

What I mean is that, today, many many years since the creation of the suite, the single-target cost has dropped to 'only' $440 per target for non-weakened ciphers. I love the money-to-execute-attack metric.

That's still high enough to slow down the viability of broad attacks for most attackers. What about in the past? How much was that back when the suite was created? Much higher. How much sooner did the weakened version make the attack efficient?

I don't mean that the government is the source of all crypto flaws, I mean that we have a specific example of a government mandated crypto 'back door' weakness causing a specific harm, making exploitation of a security flaw substantially easier. This is direct evidence of the harm caused by undermining security, which the government is currently adamant can be done "safely". The security and hacker communities know that this is not true, and this is a timely counter-factual example.

This is direct evidence that weakening cryptography, including back-doors, and special "one time" access fundamentally cause harm by undermining the security of cryptography for everyone.

From the article: "For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s."

The bearing of this on the ongoing "backdoor" and "just one device" discussions is critical. This is direct evidence of real harm done by weakening encryption.

I love these insights, they have strong echoes of "A Mathematicians Lament" by Paul Lockhart, another excellent essay on the topic.

https://www.maa.org/external_archive/devlin/LockhartsLament.... [PDF]

I enjoyed the article, although I disagreed on some minor points, some of the broad strokes seem solid to me. Very thought provoking.

I think it's interesting to contrast the thrust of the article with Ward Cunningham's original definition of technical debt: https://www.youtube.com/watch?v=pqeJFYwnkjE

Wards definition is much more about the differences between the current implementation of the software and your understanding of the problem, particularly as your understanding changes over time.

He explicitly says that "tehcnical debt" is NOT an excuse to write known-to-be-poor code, which is why I disagree with the //TOBECLEANED approach.

This change in perspective shifts the point of view quite a bit. In some ways this problem defines a startup, your biggest problem is that you don't understand your problem. It's somewhat likely that you won't even have the same problem you'll successfully solve later. The first points are salient here, focus your engineering efforts on the things you don't understand yet, and the minimum support it needs to be viable. Shorten your feedback loop as you navigate the things you do not yet understand.

In this light, a startup is actively SEEKING technical debt, because it represents gaining understanding about a problem, and exploring that space quickly. This doesn't mean you have to "cut corners" and do things you know to be flawed, but it suggests focusing on small 'forays' into the unknown, gaining understanding quickly, and being willing to throw away your exploration for a new one if it isn't working. Then once you find a problem you start to understand and seems like a viable direction, you have a body of 'technical debt' that is the work you need to do to bring the software to your new growing understanding.

It seems like being willing to throw away the exploration if the direction isn't working out is a key advantage of a startup, along with the quick iteration times and lean support for explorations. This is why I dislike the suggestions of writing known-bad code. You're slowing your exploration down, but you aren't gaining understanding of the problem. It's junk debt, not technical debt. You can carefully minimize the supporting infrastructure your exploration requires, and avoid writing extra code, but you can't just slap it together.

It's not enough to flail around building as fast as you can, you have to deliberately learn and explore problems and understanding as you go, and evaluate which ones to put more exploration into and which to abandon. To me, this is the core work of a startup that differentiates it from established companies who are executing on a reasonably well understood problem. The (sometimes gradual) transition happens when you stop exploring, and start focusing on clearing the technical debt from your current exploration.

Thanks for sharing the article, I enjoyed engaging with these ideas!

This feature applies to other models, but without 3D-Touch it is activated with a two-finger scroll across the keyboard area. Very handy.

http://appleinsider.com/articles/15/06/11/first-look-ios-9s-...

This is an amazing insight into the nature of programming. It feels right to me, and will help me explain what I do to others.

I feel privileged to live in an era where many pioneers of our field are still with us. I feel the passing of that era, and their loss, keenly.

I love that the context makes "power law" sounds like anti-competitive regulation, rather than a natural phenomenon.

I think they are helpful. Sure, they are not especially detailed or accurate, but the point of the 'micromort' is to give some broader context to the scale of the risk to aid in understanding. Much like the "banana" is a radiation unit. https://en.wikipedia.org/wiki/Banana_equivalent_dose

The Micromort is not a very precise or accurate unit, but it does a reasonable job of communicating the broad 'order of magnitude' context. The disproportionate emotional response undermining rational thinking is directly countered by this frame of reference, which in turn addresses the disproportionate impacts of terrorism.

It's $5 for the cable, but you could potentially damage the USB C port on a laptop, and some rather expensive fruit branded laptops now charge solely via the USB C port, which you could argue destroyed the value of the laptop. That sounds like it might make a small-claims-court case sensible to me.

(I am not a lawyer, this is not legal advice.)

Neat! That's very good handling of "as intended". Being explicit about it, having a warning phase, then moving to "more correct" to match the intent, and missed edge cases.

I believe this refers to the difference between pre 1.0 churn as the language was being initially designed, and post 1.0 stability. Before, existing code was frequently broken by new changes as the language evolved. Now you should generally expect to see any current code run on any future 1.x versions without issue, and probably in all future versions. If any new language constructs are added in future, they should typically be backwards compatible, only extending the old system, rather than making changes. It's possible at some point they will be compelled to break something to fix a serious flaw or issue. For Rust, I'd have to imagine this would be safety based. As language designers they will try hard not to, and it would be a major version change, such as 2.0.

Python has had a lot of challenges with their changes from 2.x to 3.x, even though the language seems clearly improved. Much of the problem is converting popular existing libraries, which rely on a lot of donated time and effort. The Rust community is hoping to keep from being in a similar situation if at all possible.

See "What does it mean for Rust to be 1.0" in the release announcement: http://blog.rust-lang.org/2015/05/15/Rust-1.0.html

Stability Guarantee: http://blog.rust-lang.org/2014/10/30/Stability.html

I feel having people near this statue pause to reflect on the nature of art and beauty is some of the best use of my tax dollars in that area.

Using rhyme and meter to remember things has a rich history, back to the epic poems.

The phrasing of the title made me think of an Onion article along the lines of: They found the perfect password, it's '42Lemons?' and everyone should use it!

What they found is an excellent password scheme for humans.

The basic cat scenario isn't "interesting" yet, you're right, it's just "we don't know." Importantly you would expect this result even if the cat was observed. You'd still observe a dead cat at the end, or chances at a live cat at different points during the experiment. (The original thought experiment killed the cat randomly over a time span using radioactive decay to release poison randomly during the time).

The science part here, is that a hypothesis has been proposed about the inner workings, and the "so what?" objection is a valid question. If the "so what?" is nothing, it's just an idea.

The "so what?" part is where the science happens. In trying to promote the idea (hypothesis) as a working idea with evidence (theory) We look for side effects of the idea that are expected to be different than our existing ideas (theories). We expect to see a cat when we open the box, and it's alive or dead. That's not interesting. But let's actually ask a science-like question of the consequences. These aren't related to the quantum mechanics questions really, but it's the sort of "consequences" questions that do get asked.

Maybe we can do the experiment over a longer time, like a week. We put the cat in the box with food and water. In the original experiment the poison is released at a random time during the week. So under our existing understanding (theory) we expect, if we run the experiment a hundred times we would see that random amounts of food and water are left pretty much evenly from 0% to 100% depending on when the cat randomly actually died.

Here is a different idea (hypothesis) about the side effects: If the cat really is alive and dead as hypothesized, it will use only the part of the food the 'alive' part would use, which is reasonably predictable. It changes by percentage over the week from 100% (alive) to 0% (fully dead). This means we should always see the same, or similar amounts of food and water left at the end. This is different than the usual prediction!

Now we have a new idea, a hypothesis that relies on consequences of the first hypothesis. So we run 100 experiments, and unlike our current understanding of cat mortality, we find that in this case the remaining food and water values a grouped up at about 50%! We can even do a control where the cat is observed the entire week, and we find that under these "observed" conditions our expected spread of values does happen. We've proven that our previous idea isn't enough to explain everything, and we have tested a prediction of the new idea, so our previous theory isn't "wrong" but it isn't entirely accurate, and the new hypothesis has gained evidence to become a new more complete theory.

Now in the real world at the cat scale, we definitely would NOT expect this to be the case, and real science is much more complicated. It's easy to make errors in predictions, or have "confounding" factors that throw off our investigations. But the initial investigations into spooky action were every bit as bizarre and unexpected. We're learning how things work at the atomic scale, and it turns out that while they mostly behaved as we though they did, there are some odd edge cases that really turn things on their head. Much like we don't poison cats in our day to day life, just in thought experiments (I hope), we don't interact with spooky action in science a whole lot either. But as we learn more, it informs our understanding, and frequently leads some unexpected concequences.

For an excellent real-world consequence, under the classic model, photosythesis is too efficient. It requires quantum entanglement to explain the efficiency! http://io9.com/new-evidence-that-plants-get-their-energy-usi...

It seems like its an important thing to be able to express. They are extending their trust to the new CA. I believe this information is available to clients if they wanted to choose to reject cross signing.

You're right that this sort of broad power is scary, but I think it's being used reasonably in this context. Do you have specific concerns you are afraid of? The only problem I thought of was a compromised CA cross-signing a malicious CA, but if they are compromised, you could just issue the main CAs certs anyway.

XKCD had a wonderful color survey: http://blog.xkcd.com/2010/05/03/color-survey-results/

Plenty of good info there, but especially scrolling down to the color chart: http://imgs.xkcd.com/blag/satfaces_map_1024.png

Yes, I don't think it's any exaggeration when they say that the TPP agreement will kill people. Medicine vital to survival will be priced out of reach of some of the less fortunate, and some of them will die. This bill is not safe for public consumption.

My hope is that this particular issue will be bigger than they thought it would be due to the recent price issues around Daraprim (from $13.50 a pill to $750).

This definitely feels like a political end run, going back on humanitarian progress we've recently made such as on generic drugs. Treaties as a way around that pesky will-of-the-people thing. "Oh we can't go back on that, we signed a treaty. Sorry about your justified outrage."

This is neat to see! Reminds me of the 200 line TCP/IP stack:

http://www.moserware.com/2008/04/towards-moores-law-software...

which has a previous HN discussion: https://news.ycombinator.com/item?id=846028

What is async resource management? can you link to docs for the features you mean? I'm having trouble googling this one, maybe different keywords are used?

Tough problem for sure, especially getting users to understand. For keyboards you could use the Bluetooth pairing trust trick. Display a short random number code on the screen, and only accept the keyboard if the numbers are typed, which could be interpreted as the user vouching for the keyboard. The need for this in Bluetooth land is more obvious due to the wireless nature of it, but USB is also an untrusted network.

This does matter, perhaps pretty charts would help.

Along the lines of "are we fast yet?": http://arewefastyet.com/

perhaps we could have "are we efficient yet?"