copper

Well, you do get vacuum tubes that operate up to a terahertz - they don't count as solid-state devices, though.

Well, it does go on to say:

> This observation, which has a significance of 5.9 standard deviations, corresponding to a background fluctuation probability of 1.7x10^-9, is compatible with the production and decay of the Standard Model Higgs boson.

Technically it could be another particle with a 126GeV mass, though that's hopefully something more experiments will show one way or the other.

sigh, tell me about it. Writing to info@yc doesn't seem to help either.

I think Fravia+ would have actually liked what you have here - its a really nice search engine.

Late reply, sorry. I never even knew they had the option of an XMPP server. For what it's worth, I find the mail experience to be both reasonable, and pretty much fat-free, which I guess is all I really need.

fastmail's non-free service, maybe? I got it a very long time ago, mainly for the .in email address. It's been no-frills, fast, and (mostly) reliable. I'm still not sure I'd recommend it to a gmail user, but its been a good email account to have.

For what it's worth - and not to distract from your real point - Exponential (or the more general Lyapunov) stability are a better explanation of instability. Stiffness is more a property of the method used to solve the ODE, rather than of the ODE itself.

Email threading has worked for longer than I care to remember in mutt, for whatever it's worth :)

Bridge might qualify, depending on how you play it, but otherwise you're right.

If I remember correctly, I (reluctantly) had to switch to t-bird back in the day because it didn't do STARTTLS+IMAP. It was perfect, otherwise. I'm yet to see a faster way to search through mail.

Wow, there are a lot more EDA programmers on HN than I'd expected, some of whom I even recognise by name.

On topic, it's probably easier to embed Lua than Tcl, though you may miss some of the libraries. The language is cleaner (in some sense). For an EDA application, the only real problem is what your customer is supposed to do with 20+ years of scripts that they've written that are specific to their flow :)

Um, no argument either way - I just believe a lump of crystalline carbon can collect dust equally well in one museum as another.

More seriously, given that pretty much all of history is rife with examples of transfer of wealth from one place to another. it's better to (try to) not make the same mistake again, rather than fixing the past.

Roughly, when you're receiving an AM signal, you use the rectifying effect of a diode coupled to a low-pass filter. The idea is that the envelope is all you really need to pass to the speaker, if the signal itself is powerful enough.

http://en.wikipedia.org/wiki/Envelope_detector

It still exists, and it's still relevant /if/ you're in the situation Dave above describes - and you have sufficient clout to get stlport included in your code. In almost every other situation where you can actually use the stl, it's probably a better idea to use the libs that come with the compiler.

> maybe we do owe them all an apology and some hard cash.

I would think this is a terrible idea. For example, my government might actually take it into its head to ask (yet again) that we get the Kohinoor diamond back :)

I do hope you didn't miss this gem :)

> Brogrammers are mostly Silicon Valley / Harvard type douchebags who got into programming. YCombinator drop outs. Years of experience in managed and web languages, but who have no idea how to setup a build system nor work in native code.

That's true. I'd say that time is pretty much the only thing that can heal outrage about such things, though.

I imagine her main gripe would be that the free food was treated as a component of her compensation, and then withdrawn for the perfectly rational (but unrelated) reason of cutting costs.If someone did that to my salary (and it's happened a few times, for various reasons), that would generate a certain amount of ill-will.

"Your projects" does have a rather wide applicability, I guess :)

That said, I'm wondering what a /proper/ license for a colour scheme should be. If it's a css file (or even an emacs theme), that doesn't seem to be so hard to imagine.

Stupid question: wouldn't the ND ("You may not alter, transform, or build upon this work.") part of the license basically mean that you can't use these colour schemes?

Don't forget the high-end FPGA's, too - that's where ARM's licensing gives them a decisive advantage (not least because if you're using one of them to prototype something, you will end up producing your ASIC with licensed components from ARM anyway.)

For what it's worth, the WCCC's Rule 2 seems to be a lot like a university honor code (if you do borrow code or ideas, make sure you cite it.) I don't believe that's too hard to follow. Maybe someone should fund a kaggle competition to design the best chess-playing program, with the final requirement of making the code open-source after :)

Given that most of what you'd implement a computer chess engine is pretty much available online (at most,behind a paywall), and digging through the source code of GNUChess and Crafty would give a lot of insight into the scoring function, so, yes, the score function would be pretty much similar in most parts unless someone comes up with a radically new way of doing things.

> Sci-Fi basically didn't exist before 1940.

Um, seriously? What genre would you place either of The War of the Worlds or 20,000 Leagues under the Sea, then? That the books manage to get a lot of things wrong doesn't really alter the fact that they were early, very popular examples of science fiction (and there were a lot more dating back to before WWII, when SF really took off.)

There are quite a few open-source Ada projects, though I'm not sure how many of them qualify as quick-moving:

http://www.ohloh.net/p?sort=users&q=language%3Aada

Well, Handshake did make an asynchronous ARM core not too long ago, and Achronix has a nice business in async FPGAs, so the idea isn't dead. That said, I'm not sure (though I'd love to be proved wrong) that the idea will really go big again. Synchronous chips are still easier to reason about.

By far the most expensive real estate on a typical processor is on-chip RAM, and that really does need a clock. Sure, clock-tree synthesis is complex enough that you may even still be able to start up a company selling a tool for it, but it's still possible for a few reasonably competent engineers to do within some weeks.

Indeed - I don't think this happens very often. I was a small beneficiary of this kind of deal, and even at the time it struck me as an excellent deal. Mind you, I attributed it to working with really good VCs and founders.

Speaking from experience, this kind of thing might - just - also be a clerical error. Not so long ago, a place I used to work for got one of these notices because the Tax Department didn't agree with how we had calculated tax. Accounts did manage to sort it out, in the end.

Another detail from about the 70s, would be that some of the people doing the programming may have been (extremely good) EEs: Intel switched from making memories to making processors, PARC was being ridiculously productive, and so on.

About the only thing I'd add to roel_v's excellent sugegstions (to which I cannot reply) is the use of ccache, distcc, and if you can use it, the gold linker. For larger projects, they make compile times bearable. In fact, I usually complain about time spent in linking, rather than compiling.

Personally, I find Tanya Khovanova's explanations (also linked to by the article) much easier to read: she's discussed this and related problems quite a few times.

http://blog.tanyakhovanova.com/?p=221