jcbeard

and this is why I have three giant books upstairs in the attic, with every order, leave request, expense report that I've ever made. Soldiers are used to it. We've come to call them "I love me books" ( http://www.ezarmypoints.com/army-i-love-me-book/ ). They shouldn't be able to come back after that many years for a signature, that's insane.

moral agency? scrutiny? these Soldiers were likely lied to by recruiters desperate to increase recruiting numbers in the longest war the US has fought. I suspect the churn in personnel was enormous, and the pressure was on. Sure, likely the details were buried somewhere in 30 pages of paperwork that each Soldier signed...and likely would have been caught if there were a lawyer looking of it. But these Soldiers don't have lawyers when signing up typically. I guess re-enlistees could have consulted JAG, however this isn't the norm. Recruiters are usually trusted. Somebody in the recruiting chain of command should have been been monitoring the numbers. They're the ones who should be at fault, not the Soldiers who've already served in good faith based on promises that weren't supposed to have been made.

Sometimes you don't have a choice, as you so blithely put it. Many people join the military because they would otherwise have no other career, or because they need a leg up, or health insurance (pre-affordable care act). So if someone offered you an extra years salary that would allow you to put your kids through college for doing something that you feel serves the people of your country, wouldn't you take it? How about if your kid had cancer, and you and your wife after working 3 jobs couldn't make a dent in the 150K medical debt created through our medical industrial complex? Wouldn't you take a change at giving your family a better life if you had no other way to do so? Not sure where you're getting the idea of "combat tourism," but please be my guest and sign up...enjoy!

They're excellent. You should read both, critically. You should likely throw in the Fountainhead as well....and for good measure should likely also read Exodus, 1914, The Service: The Memoirs of General Reinhard Gehlen, and likely more fun stuff like the Federalist and Anti-federalist papers. The history, passion, and often hypocrisy found are enlightening. Ayn R. had wonderful insights into the human condition...as a previous author had said, the solutions were often a bit twisted. If you want really interesting, dig into Beyond Good and Evil. I read all of Nietzsche while I was in officer basic a long time ago. Very interesting stuff. I guess my point is, don't discount literature because you disagree with it.

"But the toll on your own people has real consequences that you can prevent. Killing someone is the sort of thing that makes you question your own right to life."

Agreed. We never consider the toll this takes on the executioner. How about the cost to society? The people that have to witness death will have long term psychological issues. How about the cost to society when we realize we've executed the wrong person? The downsides to our barbaric practice of executions are huge, and quantifiable.

What's not quantifiable is the motivation for keeping the death penalty. The only justification after debunking all other reasons is belief. People "believe" that killing is the only punishment that fits the crime. We should not be in the practice of making life or death decisions based on belief.

Exactly. I no longer use an IDE unless I have to (mostly a vim person), but if I were to choose one I'd take Netbeans. It's always been the most "put together". Easy to install, very focused, and the layout just makes sense. Despite my preference of non-JVM for execution (mainly b/c I go for performance vs. ease of coding), I like that Netbeans basically can run with almost identical look and feel on almost any platform with a functional JVM. I was always impressed that they were able to get the GUI to feel the same cross-platform, which even on Java isn't always easy to do. I hope Netbeans is able to keep its mojo intact. I was worried about the Oracle custodians...and now we might have to worry about a committee which could be just as dangerous.

Totally agree. It'd be relatively trivial to automate converting this script into a distributed application. Haven't checked Manta out, but I will. For ultimate performance though right now you could go for something like OpenMP + MPI which gets you scalability/fault-tolerance. In a few months you'll also be able to use something like RaftLib as a dataflow/stream processing API for distributed computation (almost ready to roll out the distributed back-end). MPI though has decades of research in HPC to make it the most robust distributed compute platform in existence (though not the most easy to use). You think your big data problems are big...nah, supercomputers were doing todays big data back in the late 90's. Just a totally different crowd with slightly different solutions. MPI is hard to use, Spark/Storm is much easier...but much slower.

Nah, I was first :). Well, technically we published papers around the same time. My first works were centered around mathematical modeling formalisms for stream processing systems though which means the actual framework papers trailed the modeling papers that mentioned the Raft Language and Raft Library. I suspect that lag accounts for a lot of the name recognition....although I'm finally higher up on the Google search results.

Unfortunately anything published at uni's like Stanford has immediate potential for faster dissemination. I'm either going to have to wait out the extinction of the Raft consensus protocol (or at least for something better to come along) or to get a better name. Stream processing systems are also synonymous with "Data-flow." They all have a history of punny names (See StreamC, StreamIt, Brook, WaveScript, FloodGate, RapidMind, even Cuda is a play on barracuda which has it's origins in stream processing from the academic Brook project). So if I were to get a better name, I'd have to find something equally punny (and likely create redirects from about 11/12 academic pubs, journal papers, etc.). If you have any suggestions I'm definitely open :).

The Raft library -> raftlib.io

Not sure if it's inspiring or not, but it's my labor of love. I kept it going after grad school. I work on it a little bit every day, and slowly but surely it's becoming what I originally envisioned as my ultimate parallel programming system.

Reading this reminded me of one interceptor variant that was canceled. Same specs as the A-12, but armed ( https://en.wikipedia.org/wiki/Lockheed_YF-12 ). The second seat was added to operate the fire control system (radar/weapons).

Very cool read though.

This is going to sound odd, but I'd go for a used macbook pro. Apple has awesome parental controls, and you can set things up remotely. I also like the programming environment for my son (7). We started off with scratch a long time ago, now he's moved on to Java (following along with examples), and I even got him a MicroBit that he can program with the MS Scratch-like interface. It was an easy choice for me since I just upgraded to a smaller MB Air for travel, and well...I stepped on his raspberry pi (he loved tux math).

Slightly mis-leading headline....bug it's direct from the register. tldr; the headline should read "Windows 10 is the only Windows OS that will support latest processors." Guess MS is tired of supporting 30 years of hardware with each OS release. Hopefully that'll free them up a bit to do more interesting stuff.

Thank you! Really like mine. As luck would have it, the distributed daemon I haven't released yet is called "oar" so it fits perfectly :).

that's crap. self documenting code sometimes works...but not always. I love people that hand me HDL and say "it's self documenting." Then you open it, and wire names are "x_1245_to_y." Happened all the time when my students would turn in assignments. That stopped after they realized I graded the documentation too :).

>The trend in programming lately seems to be less to no comments and less to no documentation

Hasn't this always been the case for young programmers? Seems you don't comment until you have to go back to code you wrote yourself a year later and make major changes....you then realize you should have documented it, either inline step-by-step or as a proper doxygen/javadoc style.

I can thank Dr. Leitner (CS 50/51) for enforcing comments in assignments. Took programming courses as an undergrad (I wasn't a CS major, but a Bio/Int'l studies one) in C, no documentation required...code was checked for correctness only. Leitner had his TA's go through and take off points for code that wasn't documented...which needless to say got me in the habit of documenting.

>It really comes down to laziness.

Not so sure. Laziness or lack of good habits? Perhaps a mixture of both.

not sure they haven't always been fairly accessible? I suppose prices are now dirt cheap vs. 2010/11 where I'd have to pay 300-400 for a mediocre FPGA (I've used digilent for years, prices on there have dropped quite fast in the last two years or so). then again, atmel had an FPGA co-processor for awhile at a relatively cheap price (can't remember the name...probably X28 with some characters), but still not really capable of running a neural network at any appreciable depth.

So what's changed that FPGA's are making a come back? They were all the rage in 2008/9...however that faded relatively quickly when people realized programming them was a hassle and that programming had direct implications to synthesizability/clock speed/area. Looks like Google Trends shows a downward spiral in interest from 2004 to present, so my intuition was close. OpenCL->HDL and Vivado's C/C++ -> HDL makes the process a bit easier, but it's still not as easy as writing optimized C code.

To get perf on an FPGA over a hard core you must go very wide (as in lots of parallelism). I suspect you could order custom hard cores from places like Tensilica and get far better perf/watt. I love FPGA's, they thrive on parallel integer/fixed point codes if enough time is put into designing the pipeline. It seems for most float heavy codes a hard core unit at a higher clock rate with a dedicated MMU is much better? Am I missing something that changes that?

this is true....and thankfully this technique is also being taught in some CS algorithms classes.

The problem is, that's not really true. There isn't a hard/fast rule that'll get you what you want given the way modern hardware is designed. Run something on a core designed for mobile workloads and that changes vs. one designed for server workloads vs. one designed for HPC. They're definitely not all the same, and the differences will kick you in the rear when trying to simplify.

I do agree teaching people that there are differences, and give them the tools to learn when algorithmic changes are necessary to optimize for the hardware.

I agree with aaronbwebber that for general use, and for teaching, that it's far easier to assume O(1) memory access. It's a decent approximation, and works until you start having applications where loads/stores dominate. It also falls apart when things like multi-threaded apps start spinning on locks, but lets not go there in a HN post, could make an entire blog out of mem issues.

Here's why we should continue to use O(1) access in general. Unless you enjoy rat-holes (I wouldn't have a job without them...so, why not). If we really wanted to, for every algorithm we could consider things like: 1) pre-fetch algorithm (assuming you know which one will be chosen) 2) associativity 3) cache size at each level (including buffering) 4) queueing depth at all levels 5) DDR controller capacity & while we're at it, do we have latency of mem controller on-chip..wait, which one? 6) bank conflicts in DDR 7) NUMAness (how about NUMA cache behavior?) 8) even worse...should we consider cost of differing mem tech. 9) TLB behavior...there's a lot there, can't list

Here's why we don't: YOU CAN'T. Do you realize the incredible amount of work required to get the info for the analysis? The list of things that influence memory behavior is huge. Even if you can get all of it, you work it out for one algorithm...you've now wasted a year, and figured out a cost for one architecture/OS/run-time combo. Congratulations. I'm all for including the cost of memory...just realize what you're asking before you write a post asking about it. There's no end to how detailed you want to go. And in the end you end up destroying the asymptotic bound you're trying to create b/c you'll realize that it's now a probability distribution that really doesn't lend itself to generalizable asymptotic behavior, which is what you want when considering algorithms.

When choosing an algorithm for a specific hardware, then you can choose an algorithm for that arch.....but most people don't do this, it's not necessary unless you're in HPC, Datacenter scale analytics, or in the embedded space/cyper-physical space.

How much of the perpetuity is the uncertain funding faced by researchers in the field? The same can be said of supercomputing which directly feeds fusion research. Instead of long term funding, we get 1-2 years of off and on "kickstarter" projects. Long term funding set aside for things like fusion through 5-10 year commitments could improve the outcome. You're totally right though, fresh water as you get to in the end is a direct result of power. Everything comes down to power. As we move from a factory industrial society to a additive manufacturing society this will become even more true. Those who have the power (literally, like electrons) will thrive, those that don't...will look like the middle east in 100 years.

Anybody ever wonder if we put 1/3 of the defense budget into Fusion energy research (literally a new Manhattan project, lets call it the Princeton Project) that we could have more impact than that entire defense budget? Think about it. Most of the worlds conflict arises over struggle for resources, and most of those resources are oil. If the world didn't lust for oil as a cheap energy source, could we defund dictatorships around the world? Could we start focusing on cultural and structural issues vs. the struggle for fossil fuels? Seems to make far more sense to spend a few hundred billion USD on fusion research vs. 1.59 million USD per cruise missile to fix/quell conflict that arrises from that struggle. Just a thought, but it seems fixing the cause rather than treating the symptoms is a far better approach in the long term.

As a middle school student in the early 90's we coded in basic on the Apple II. I loved it. I'm not sure fancy features like auto-indent are really necessary, nor would they detract from learning depending upon the goal. They're productivity enhancers for sure, and I suppose it depends on what you want to teach. If you're teaching algorithms through implementation, sure...might detract from the teaching process. If you're teaching people to go on to jobs right out of high school, then my goal for high school level students is to teach them to go into any environment that their employer might have. I can't tell you how many undergrads (my experience as an instructor while a grad student) I've had complain about an IDE that is unusable because it doesn't have feature X. When students show up with programming experience to college/job, I'd rather have their programming experience be transferrable to whatever editor is available (be it VIM, VI, Nano, MSVS, Xcode, whatever).

sounds like maybe the locking clutch pads were malfunctioning (pretty sure they used clutch packs vs. gear type). the hopping is never fun.

I agree with the headline, but I'm not sure I agree with the reasoning. Manufacturing is increasingly robotic, however it's also increasingly mobile, and scalable. In the not so distant future I think various forms of 3D printing will take over manufacturing. You'll have your small home units and large almost entirely automated industrial units building more complex objects. Why would this happen? Labor costs are beginning to rise in China. As are costs in other parts of the world. As costs rise, seems like the distance becomes a huge factor. Manufacture locally, distribute locally. Now the question becomes how to employ the worlds populace....

Also related/interesting: https://www.ted.com/talks/olivier_scalabre_the_next_manufact...

Interestingly, I find that most of the time I know far more about the inner workings of the body than the docs that "treat" me. Then again, I have a bio/molecular bio/comp bio background...so that might be the cause. Seems the memorization that drives our docs in the USA forward often doesn't translate into understanding the concepts as a whole. I do agree salaries are getting out of control. Look at PhD's they contribute quite a bit to society, have an even harder time getting the PhD than an MD and yet...aren't similarly rewarded. Don't get me started on "oh, well, we have lives in our hands." You know what, so do the programmers, engineers, technicians that make the tools that make medicine possible. So...our incentive system is a bit out of whack in the USA. It wasn't this way a few decades ago, and it won't be that way a few decades from now. For the moment though, there are lots of perverse incentives skewing costs. Chief amongst them is the 3rd party payer system.

hah, I'll edit after a bit :) . Wrote while re-enacting the battle of hoth in lego form with my son...hard to do paragraphs on iphone.

This isn't always true either. 4WD can mean that you send equal amounts of power to each axle, but at that point there are things that can change the amount of power going to each wheel within the center differential casing. If you have a limited slip differential (why some 4WD vehicles can drive perfectly fine on pavement) it'll basically send a 50/50 split (lock the axles together when going straight) but allow the axles to turn at different rates when making turns (otherwise bad things would happen). Some cheaper 4WD vehicles (and many 2WD vehicles) have open differentials. Open differentials send the power to the path of least resistance (bad for traction, and also why if you're in gravel the loose wheel usually just spins while the other one doesn't). There's also a fully locking differential that literally locks the axles no matter what. These cannot be used on pavement for obvious reasons (well, think about turning a corner, the outside wheel will have to turn faster than the inside wheel). AWD vehicles have a center diff typically and also often employ limited slip differentials (but sometimes again, they have open and/or auto-locking diffs...ARB made air locking diffs at one point, not sure if they still do) at each axle as well which enables a mechanical distribution of power. Some newer vehicles have replaced the axle differential gears with anti-lock breaking systems that provide resistance to open diffs to regulate wheel spin (artificially add resistance to the spinning wheel).....sorry, before I became a computer geek I built motors and off-roaded in my 81 CJ-5, after that I drag raced for fun on the weekends at the local track. I had a limited slip in the mustang I raced and a fully locking one in my Jeep. Jeeps (and older 4WD) are interesting b/c many come with what are called locking hubs ( https://en.wikipedia.org/wiki/Locking_hubs ) which are not all that common today. Even if you do find them, they're usually auto-engaging vs. the ones you have to get out an manually turn to engage the front drive shaft.

The RaftLib C++ library (and eventually with other language bindings) aims to bring heterogeneous parallel programming to the masses. We get rid of any and all explicit thread operators, by allowing users to build applications using C++ iostream-like operators. Using our library you can build applications that are as or more performant than you could build yourself with pthreads, but with only a few lines of code. It's portable to Linux/OS X (windows support is coming).

Project Page: http://raftlib.io GitHub Page: https://github.com/RaftLib/RaftLib Wikipedia Page: https://en.wikipedia.org/wiki/RaftLib

Email is on my web page: http://jonathanbeard.io

Vote for me! We need a better logo!!

Thanks for reading. If you like it, please contribute. We're rolling out user space threading right now, next project is to build back in accelerator support.

"When Mylan bought it, EpiPens cost about $57 each."

I can concur. I have a family member I purchase these for. At first, it was like...okay, $50 after insurance. Now $100 after insurance. The thing is...nobody really seems to care until things spiral out of control. Who the hell is watching our backs in America? Is it the FDA, the FTC, Congress (likely too busy defunding AMA to care), the DoJ? No idea. I wonder if gov't agencies like the DoD who stock tons of epipens pay the same prices that we the public do? Does the DoD purchase from another market to get out of the huge sticker price? I'm curious to see how many people in the gov't get around purchasing these in the US for their own agencies yet didn't raise extreme alarm at the ballooning prices for the American consumers.