brendn

The Concorde was an engineering marvel, but it was more than just increasingly cheap transatlantic fares that did it in. Noise regulations prevented it from flying over the Continental US. Maintenance became increasingly expensive as the fleet aged. (The technical problems with its air intakes and tires caused safety issues, too.)

It's easy to say it's an entirely economic issue, but it isn't. The 2000 crash of Air France Flight 4590 shattered passenger confidence, the post-bubble recession meant fewer people had the disposable income to buy tickets, and the post-9/11 slump in air travel further reduced ticket sales.

The article really only convincingly explains why we don't have a replacement Concorde, not why the Concorde went out of service. Jet fuel is expensive. Today, airlines and aircraft manufacturers spend trillions of dollars to improve fuel efficiency to keep up with rising fuel prices.

It's not that we're too cheap, it's that the the industry was more interested in advances in conventional jet efficiency so that airlines could reap the benefit across a much, much larger fleet.

There's always a desire to wrap up complex and multifaceted decisions in a neat little package. I don't think it's possible to point to a single issue (economic or otherwise) that made supersonic transport unviable.

By my understanding, yes and yes. The third-party service caches the public key (with timestamp) and the browser caches the signed certificate (with timestamp). The timestamp gives the credentials a relatively short TTL to prevent a stolen cert from being used indefinitely.

A friend of the author of QLB here, and I brought up the idea of a visual interpreter to parse the square kufic calligraphy. My understanding (limited as it is by my almost complete ignorance of Arabic) is that certain stackings of adjacent words would be ambiguous to the parser.

That's exactly what's happening in some places in Vermont. (I know, not the first place you think of when you hear 'solar.') People can buy shares of a solar co-op and get credited on their power bill for their portion of any electricity generated. It will be interesting to see how that model works in the long run.

Turing should be pardoned as a human victim of an unjust law, and his genius should have nothing to do with it. That said, there are more important fights for equality that affect living people right now than whether the British government officially pardons a dead man.

I'll have to try it out. Thanks!

I would love to see a LUA scripting framework built into this. I built an iOS app with an embedded web server, and dealing with dynamic text generation in Objective-C is a pain.

I used Mongoose [1] to do exactly that for devices that share a local network (auto-discovery and everything). So yes, it's definitely possible :)

[1] http://code.google.com/p/mongoose/

ConEd shut of power to the Financial District at approximately 7PM, but there were a number of explosions at substations including the one at 14th Street. There are over 1 million New Yorkers without power; ConEd reports most places below Midtown are dark.

They evacuated NYU Langone Hospital when its backup generator failed, so yes, consider yourself very lucky.

Most of Manhattan is without power. While some people may think it's badass to hack through the storm oblivious, the situation out here is pretty intense. I would encourage some leniency with the deadline, especially since as far as I know for NYC, things won't be back to normal for quite a few days.

I've heard (but can't find a link ATM) that it's not uncommon for people in developing countries have multiple phones or multiple SIM cards and will call on one or the other depending on that provider's current rates.

I'm curious about that issue, too. Here's a brainstorm:

- An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever)

- The IdP provides an anonymized email address to each site that the user logs into.

I'll have to read the spec a bit more to see if that's possible...

I'd like to second this sentiment. Instead of tearing down someone's significant effort to build something cool, the community should constructively communicate their issues with the project and offer suggestions for improvement.

I was personally impressed that drag actions were supported, because that's a frequently overlooked aspect when people roll their own slider toggles. Without looking at the source, I would guess that implementing mobile touch events would go a long way towards making this library cross-browser.

Could you enlighten us? I've read about fiber optic gyros, but I assume they haven't gotten small enough to fit in a mobile device. (Since they require kilometers of fiber.) I really don't know enough about how the solid state (?) gyros work.

Yeah, I kind of glossed over the vacuum aspect of the attitude indicator because I don't understand all its intricacies. The video pretty much confirms my understanding of how the gyro is kept spinning. The original author's description of air puffs sounds a lot like how the filtered air is ducted in to the housing and vented off in quadrants. I suspect that has more to do with maintaining the gyroscopes precession (http://en.wikipedia.org/wiki/Precession) than leveling the gyro in mid-flight.

I've heard that during prolonged banks or pitches, the AI can eventually find a different "level" than the true horizon. I'm trying to find more info into that phenomenon though.

In the mean time, I've found this article that seems to be talking about the same accuracy and drift issues as the original post, but explains the issues with more clarity and also includes sensor graphs and code samples: http://myahrs.wordpress.com/2012/04/24/turning-errors-contin...

OK. I'm no expert on this myself, but for someone who claims to have just figured out how an attitude indicator works, the author certainly doesn't explain it very well. I was left with the impression that the author is uncertain of the distinction between an accelerometer and a gyroscope. An accelerometer, like he says, can be likened to a hanging weight or pendulum. Accelerometers can measure the direction of gravity of a stationary object because the only force acting on the pendulum is acceleration due to gravity. However, as soon as the object is moved, other acceleration vectors are added to the already-present gravity vector.

(Imagine an accelerometer hanging from a rope. If you swing that rope in a circle around your head, the accelerometer will report that the force vector points to its bottom, away from your head, and not down to your feet as gravity alone would indicate.)

Which gets me to the OP. Because the article does not make a single mention of angular momentum (among other reasons), I would guess that the author doesn't understand how gyroscopes work. A gyroscope is essentially a spinning disc-shaped mass that resists change to its axis of rotation. If you built a housing that allowed it freedom of motion in three dimensions (called a gimbal (http://en.wikipedia.org/wiki/Gimbal)), it would remain on its original axis no matter how you tilted its enclosure (barring the inevitable energy loss due to friction, etc.)

So, in the case of an airplane, you would set the disc spinning on level ground. Then, while you're flying, any changes to your pitch or roll would be around the gyroscope (which, remember, is allowed to move freely relative to the cabin). The gyroscope wants to preserve its angular momentum, so it will still be spinning on the same axis relative to level ground. Any difference between the gyro and the cabin therefore indicates the orientation of the plane relative to the ground.

You'd probably get a more concise explanation from the Wikipedia page on Gyroscopes (http://en.wikipedia.org/wiki/Gyroscope). The Wikipedia page on attitude indicators (the visual display for a cockpit gyro) is also quite coherent and less prone to rambling (http://en.wikipedia.org/wiki/Attitude_indicator).

[EDIT: Toned down some grumpiness. I must be tired.]

It was totally a lobbying effort to get the legislation passed. First by the tobacco industry because of fires started by smokers falling asleep with lit cigarettes, then by the chemical industry (by courting state fire marshals) to boost sales of their flame retardants. The Chicago Tribune has a multi-part series on it here: http://media.apps.chicagotribune.com/flames/index.html

At first I thought it said "mind control drone" and reached for the tin foil.

Being stabbed to death would be a less painful and drawn-out alternative to being sued for the thief's medical bills.

No, both authentication factors are required, so either losing your phone or forgetting your password would be sufficient to lock you out. However, the Google authenticator PAM plugin provides emergency access codes to use in the case that the one-time password generator is not available.

This is a repost of a backers-only email from Kickstarter. It wasn't meant to be published as a gist.

Tornado relies on its own HTTP server, but its modules for everything from templating to authentication are loosely coupled, so you can take them or leave them.

To your point, I'd be curious to see a non-Tornado server that is Tornado compatible on the backend. It could be an interesting project. I would counter, however, that any server choice has its own inertia--changing web servers is hardly ever a simple process.

The article itself says, "While this HOWTO tries to give an overview of Python in the web, it cannot always be as up to date as desired. Web development in Python is rapidly moving forward, so the wiki page on Web Programming [1] may be more in sync with recent development."

So it may not have been the best resource to present on HN in the first place.

[1] http://wiki.python.org/moin/WebProgramming

Interesting that there's no mention of Tornado [1]. (Disclosure: as a co-author of O'Reilly's Introduction to Tornado, I'm biased in its favor.) I haven't played around with Brubeck [2] yet, but I also hear many great things about it.

Needless to say, there are some great Python web servers and frameworks out there that aren't listed on that page.

[1] http://www.tornadoweb.org/

[2] http://brubeck.io/

Edit: Added links

I find the toilet analogy to be flawed. Sure you don't fix their toilets for free, but you would certainly let someone know if you used one of their facilities and found it to be clogged or otherwise malfunctioning.

As a someone who's filed a few Radar issues over the years, I understand that the lack of feedback is frustrating, but I find it absurd that the way to fix that is to withhold the bug reports that help improve the software we use and develop for daily.

Are you seriously bashing their icons based on the number of people on the team? How can you pass any kind of judgement without knowing what went in to planning, designing, testing, and deploying the change? If you think you could do something similar with fewer resources, either go do it and show us, or stop raining on someone else's parade.

My guess is that radiation's effects on solid-state technology was well-known from nuclear tests.

I think you're misinterpreting my use of "grease monkeys" in general as offensive. (I said not to project value judgements in my original comment. There are certainly developers who see "craftsmen" as aloof purists who look down on practical matters. It cuts both ways.)

I like your city analogy. I won't stoop to comparing programming languages to actual American cities, but I would counter that "PHP is like living in [a particular] big city."

Here's where I disagree: it's not enough to say "hold your nose around these parts, but it's OK because those few blocks on Main St. are worth it."

There will be flaws in any city, and sometimes due to mismanagement, the flaws will be neglected until blight sets in. Here's where the citizens of the city need to step up: they either flee the city and it continues to decay, or they acknowledge the flaws and address them. Don't just accept the downsides! Fix things. Make improvements. The city only thrives on the investments of its citizens.

The arguments in favor of PHP that I continue to hear run along the lines of "everybody's using it" or "it's not that bad if you know what you're doing" or "it's great because it's the Swiss Army knife of languages."

It's hard to argue with those sentiments. And I think the root of the argument stems from the diverging convictions of two distinctly different camps of hackers. There are grease monkeys who love tinkering and see value in a tried-and-true tool that works everywhere. And then there are the craftsmen who strive for elegant code and choose their tools carefully. (There's truth in both of those aspirations. Let's not get carried away in value judgements between the two camps.)

But hearing "PHP sucks but I like it" sounds like Stockholm Syndrome to me. There are some great aspects to PHP that other web stacks and frameworks could learn from. Yet there are some major flaws that actually get in the way of productivity. I hope we can keep the discussion constructive and learn from both camps in building the future of web programming.