Well I have plans for today, so I'm sorry that I won't be sitting here defending my article.
However if you hit me up on twitter at the link at the bottom or email me at my listed email address I'd be more than happy to respond and debate this piece in due time.
Author here. Holy cow. Thanks for all the kind words guys! I'm primarily a back end dev interested in hardware, compilers and operating systems. As a long time HN reader I can't begin to express how amazing it is that a my first "real" web service which I started less than a week ago made the front page.
I hope that for those Clojure users among you Grimoire proves a useful resource and I welcome any feedback or other commentary you may have on the site and its usability. Stay tuned, there's plenty more in the works from me and I'm reading the feedback with interest.
Author here. After maintaining a blog built around a "real" CMS, and a "real" CMS that I built myself, I'll say that my existing blog is built atop Jekyll and Git, the same stack I chose for Grimoire. It's simply the most basic thing that could possibly work, and it doesn't demand that I run a JVM on my inexpensive DigitalOcean instance. For all that I enjoy using Clojure, a "real" Ring server with a "real" database backend simply doesn't add anything to this project beyond complicating it further. As such I don't expect that a database rewrite of Grimoire is on the cards for some time to come.
To "how you build such a site in Clojure" the answer is that the entire Clojure ecosystem shies away from monolithic web frameworks and prepackaged solutions ala rails. Instead, Clojure libraries tend to pick a single feature or some small set of fetures, cover them well, expose a simple API and make composition trivial rather than trying to solve all possible problems.
Dash integration... Dash only makese sense for languages for which the documentation isn't trivially introspected such as Java. Clojure has the clojure.repl library (http://grimoire.arrdem.com/1.6.0/clojure.repl/) which is designed to solve this problem by exposing Clojure documentation to users in their interactive development (REPL) sessions. As I explain at some length in the Grimoire announcement post (http://arrdem.com/2014/07/12/of_mages_and_grimoires/) Grimoire seeks to fill a fumdimentally different niche than Dash. Clojure already has docs, and those docs are already handy for users aware of clojure.repl. Grimoire seeks to solve the problem of documenting the various ins and outs of the standard library which do _not_ appear in the official Clojure docs and which are currently spread out across any number of other low PageRank score community sites.
Author here. I'm definitely aware that there are many pitfalls to Clojure than just the standard library docs. There's an open issue for adding a syntax guide and a macro guide, I'd be delighted to add a destructuring guide.
When the risk of of obtaining content by illegal means is not outweighed by the cost of doing so by legal means. If I can pay USD 1 or Ɖ1500 or some other small amount to watch a movie not listed on Netflix instantly I would gladly do so. The risk of getting a "friendly reminder" from the RIAA or some other entity that $UNIVERSITY is required to disclose who I am and that I've been a bad boy completely outweighs such a low cost. However if it costs me $5 or $10 or I run Linux (which I do) and can't even use any of the legal services then it becomes worth my time, effort and risk to find three proxy services which I halfway trust and run a Torrent client over some combination of them.
Correct, however if this "exact runtime bound" is what you are going for, then please use the correct notation. T(N) = 2N would be legitimate, as would \Theta(N) = 2N. Saying that O(F(N)) = 2N is misleading because the definition of the big-o notation explicitly discards all constant factors and constant annends.
"designed two processors". No. We had working A0 production runs of two chips, with a the A0 of the third generation in the post when we closed. Leaner? Not really. Sales team was three people more the executives, everyone else was engineering. Meaner? Who on earth pulls off two working A0 runs?
Writing this as a now ex-employee, I'm sure that our IP will live on. We had some really neat stuff in the pipeline, and I look forwards to seeing it hit the big time in the next few years. Whether Calxeda proper will be acquired or whether the IP will be sold piecemeal only time will tell. Personally I'm not convinced that the company in it's "entirety" will be bough out. At this point it's the IP not the assets or people that's valuable.
I also totally agree with your assessment that we had a cool idea too early. That was in fact what Barry said at today's closing down meeting. ARM in the datacenter will happen, but that we didn't have a 64 bit chip really limited our hardware offerings to say the least.
Not only are we to cheep to fly fast but we've also banned supersonic flight over most "civilized" land masses. There are only three or so US mainland airbases where it is legal to break mach 1 due to the fact that the voting public doesn't want to listen to sonic booms. Thanks to relatively new "shaped sonic boom" technology it is possible to massively reduce the acustic profile of supersonic flight but the damage is done. We're too cheap to fly fast and the technology which we need to fly fast still doesn't come cheap.
Context: At this point in history, the USA and USSR had aircraft fleets on constant patrol with tanker resupply. The concept was to simultaneously shorten the response time of strategic nuclear forces by having them "idle" nearer the target zones than their home bases and more importantly to reduce the potential losses of such strategic strike forces to a "bolt from the blue" preemptive & disarming attack. In a world where the President and SAC command would have to wait hours for B-36 & predicessor aircraft to make their way to their targets in Russia.
There were three real issues with this project: shielding weight, landing weight and politics.
1. Shot down or crashing, one of these aircraft would be a "dirty bomb" and could generate a nuclear contamination disaster. This alone made the project risky. Remeber, during the heyday of strategic nuclear bombing shootdowns were expected & ariplane to target assignments were made on the basis of the expected (and dismal) survival rate of inbound bombers. Also a single crash on US soil would have been... politically unpopular.
2. The lead, graphite and cement used to shield static nuclear facilities doesn't exactly work when trying to build an airplane, which made crew shielding dubious and reduced the loiter time of such a vehicle to the radiation tolerance of the crew.
3. A mich more minor issue was that of building landing gear that could hold the weight of the reactor on landing let alone a crash.
All that asside, a flying nuke plant is a great idea and I for one would not be surprised to see this idea resurrected for extreme loiter duration robotic aircraft :/
Ars gives the SKIF-DM's designers more credit than they deserve. Gorbechev didn't want a Soviet SDI program and was highly critical of the military's existing research efforts in that direction [1] details at great (and I think facinating length) his efforts to dismantle the Soviet military machine. The -DM launch detailed here was the designers last ditch effort to save the program due to continued failure to produce either a sufficiently powerful chemical laser or a computer system capable of controlling it as the Sary Shagan [2] and Terra 3 [3] installations are ample proof.
Disclaimer: at age 20 I was born as these events drew to a close so my knowlege of this subject is restricted to the historical material I've read in incredulity that we stood on the brink for 50 years and came out alive.