Americans are struggling to pay off their auto loans - <AUTHOR> http://nypost.com/2017/02/16/americans-are-struggling-to-pay-off-their-auto-loans/ <comment><USER2> Americans are also foolishly suckered into believing they need a new car every few years. It's not a phone. A car should last 10 years and there is absolutely no reason to buy new unless you have money to burn.

My truck is going on 10 years old (bought used) and has low mileage < 100k. Paid a fraction of the cost of a new one (roughly 35% of the sticker price when it was 5 years old).

<comment><USER3> Unless, of course, people want newer engines that are more efficient, want newest technology (carplay / android auto), and want newest safety equipment.

At this point it's maybe not so much that they _need_ one, but that they _want_ one. I for sure don't want to keep cars forever.

Maybe I misread your comment, but keeping a car for 10 years may not be for everyone.

<comment><USER4> >newer more efficient engines

Losing a bunch of money as depreciation for a marginally more efficient car doesn't really make accounting sense.

>android auto /carplay

These are accessories that car manufactures generally do a worse job of producing than 3rd parties.

<comment><USER5> Some cars are very difficult to retrofit. My 2012 Accord simply _cannot_ get a CarPlay-compatible head unit without redoing the entire dashboard. That's a multi-thousand dollar job that also compromises safety (airbag placement). Not worth it for a minor feature (though I do really like CarPlay).

Same deal for my 14 Ram 1500. Fortunately, UConnect is pretty decent as it is.

</comment></comment></comment></comment><comment><USER6> >"The average monthly car payment in the fourth quarter rose above $500 for the first time"

I literally cannot imagine paying $500 a month for a car payment, even as a young single person making $100k. People are insane.

<comment><USER7>
      I literally cannot imagine paying $500 a month for a car payment

Why not? Consider: I got a Subaru Forester with $0 down and 0% interest which I pay off over 4 years. With options, it's $650 monthly. Again, no upfront costs.

<comment><USER6> To each his own I guess. I'd rather just write a check for $5k and get a decent used car than worry about making a payment every month for 4 years.

</comment></comment></comment><comment><USER8> Based on my experience working at drivemotors.com, many people with low credit are totally fine with entering into loan agreements with very high interest (9-12%) for 72 months or longer with little to no down payment.

<comment><USER9> The instant gratification nature of a large portion of our society drives them to recklessly undertake high interest loans on depreciating assets like cars and furniture from places such as Rent A Center, pay day loans, etc. Seems there are quite a few ways to keep the poor, poor.

</comment></comment><comment><USER10> "The average monthly car payment in the fourth quarter rose above $500 for the first time"

That's frightening.

And if anyone is wondering about the duration,

"Average term for an auto loan: 68 months — this is the longest average term ever seen by Experian."

[http://www.cnbc.com/2016/06/02/us-borrowers-are-paying- more-...](http://www.cnbc.com/2016/06/02/us-borrowers-are-paying-more-and-for- longer-on-their-auto-loans.html)

No wonder people are driving their cars for 12 years+ now. They can't afford not to.

</comment><comment><USER11> 797 vehicles per 1000 people [https://en.wikipedia.org/wiki/List_of_countries_by_vehicles_...](https://en.wikipedia.org/wiki/List_of_countries_by_vehicles_per_capita)

<comment><USER12> > 797 vehicles per 1000 people

Some people have more vehicles than they need.

My father has three old cars: a 2001 truck (to haul gravel/etc), a ... 1997 Nissan Pathfinder (4wd needed for 4 months/year), and the 1998 civic my passenger gave me in trade [1] (so he doesn't have to put miles on his truck, and to save at the gas pump).

[1] [http://www.taxiwars.org/2016/09/the-perpetual-quest-for- dece...](http://www.taxiwars.org/2016/09/the-perpetual-quest-for-decent- fares.html)

He could easily buy a new car, but doesn't see the point of dropping all that money on a depreciating asset. Maybe when he retires...

</comment></comment><comment><USER13> Those Americans are struggling if they're struggling to pay a car loan

<comment><USER14> No, they're mostly making bad decisions. Taking a loan with an average of $500/mo for 68 mo (yes, those are the current averages) on a hunk of metal that's losing value wether you drive it or not? If you're struggling with that, it's not income inequality or evil banks - it's bad decisions.

</comment></comment><comment><USER15> On top of this is insurance. If you live in NYC it's like paying for a second car.</comment>


Show HN: Clockies, trouble of deciding what to do? - <AUTHOR>

Pls check out http://www.clockies.com. Discover & share interesting future happenings with friends. It is really cool. It's like a time machine when you have a lots of friends on it. <comment><USER2> I was reluctant to enter my facebook details when I don't really know what the app does, so I didn't do it.

Also, discovering and sharing future happening with friends sounds like something that facebook already does well.

<comment><AUTHOR> I promise we do it in whole new different way of sharing. YOu can follow TV Shows, NBA, Movies. and share the events that are the most interesting to your friends. So you will get recommendation of what to do from friends. Like for instance I got a recommendation that 2 1/2 are airing next week

<comment><USER2> Ok, just to be clear. It isn't _me_ you need to tell but everyone. No one will sign up to something, no matter how good it is if they don't know anything about it. So my suggestion is to explain your service. This might be with text but you could also use videos or screenshots.</comment></comment></comment>


Ask HN: Versioning API URL vs. Header + MIME Type - <AUTHOR>

Hi,
I'm developing a RESTful API and one of the requirements is that it has to be versioned.
The usual solution is to add the version in the URI, http://example.com/api/v1/resource
But it doesn't feel completely right. The resource probably will be the same in another version just its representation or the parameters will change.
Then, I thought about using the Accept header with vendor specific MIME types to specify what API version to use. This way the resource will never change and it will be unique.
A simplified example of usage would be: GET http://example.com/resource Accept: application/vnd.example-api-v1.text+json
Update: formatting. <comment><USER2> You could even use something like "Accept: application/vnd.text+json;api- version=1". Personally, I'd go with the custom Accept header, using the same type, but different "accept-extension" (see <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html> for details).

<comment><AUTHOR> Good point, actualy Zend is doing it exactly like this: [http://files.zend.com/help/Zend-Server-Community- Edition/api...](http://files.zend.com/help/Zend-Server-Community- Edition/api_versioning_negotation.htm)</comment></comment>


NoSQL, Heroku, and You - <AUTHOR> http://blog.heroku.com/archives/2010/7/20/nosql/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+heroku+%28Heroku+News%29 <comment><USER2> I've been a little wary of the MongoHQ option because it's a separate service and I was worried about latency. But, I guess if it's all hosted on EC2 that doesn't matter as much...?

Does anyone have any experience using MongoHQ on Heroku?

<comment><AUTHOR> Yes, we are running MongoHQ with Heroku and so far, it's been great. Tool- wise, not great, but been told that it will get better.

</comment></comment><comment><USER3> I have been waiting for someone to explain the advantages of the different NoSQL solutions - this article is certainly a good start. I'd be curious to hear, from people who know the technologies well, if Adam's views on which each NoSQL solution can be used for are correct.

<comment><USER4> EngineYard did a series of 6 that goes a bit more in-depth, their blog nav sucks though so just use this:

[http://www.google.com/search?q=site:engineyard.com+%22key- va...](http://www.google.com/search?q=site:engineyard.com+%22key- value+stores+part%22)

Honestly there aren't any really great comparisons because the people with the really in-depth knowledge about one db or another tend not to have the same depth in the others. Plus there's the fanboy quotient adding to the hype, which initially was really turning me off to the whole NoSQL meme.

More recently though I've decided that I can't let the ignorant hype distract me from discovering the real value. In general I still think most apps probably need some kind of relational database (and generally I consider a relational DB a nice hedge against changing requirements), but I'm also spending quite a bit of time on optimizing my own app and it's amazing how certain alternative data stores offer primitives to billiantly pick off real world bottlenecks cropping up in a traditional SQL DB.

So for me the best way to approach it has been by looking through the prism of real world problems.

</comment></comment><comment><USER5> Has anybody here used AllegroGraph? <http://www.franz.com/agraph/allegrograph/>

</comment><comment><USER6> For more in depth information on this topic I highly suggest Adam Wiggins' talk at QCon. The video can be found here <http://www.infoq.com/presentations/Horizontal-Scalability>

I really like how he treats the topic in a balanced and well reasoned way. Makes it great to learn more about the topic at hand.

</comment><comment><USER7> dup: <http://news.ycombinator.com/item?id=1530812>

<comment><USER8> I don't think people consider it a dup when this one has the votes and the other one doesn't. I do agree it is bizarre when a story is submitted multiple times and the latter of the two (or more) "makes" it.

As far as the write-up goes, very good overview of NoSQL choices and some high-level ideas of when to use each option.</comment></comment>


Indistinguishable from Magic: Manufacturing Modern Computer Chips - <AUTHOR> https://www.youtube.com/watch?v=NGFhc8R_uO4

<comment><USER2> This excellent talk was linked at the bottom of the CPU backdoor article ([https://news.ycombinator.com/item?id=8999507](https://news.ycombinator.com/item?id=8999507)). Worth a watch, though unfortunately the slides appear to be offline.</comment>


In praise of callbacks - <AUTHOR> https://gist.github.com/erikpukinskis/bf800c365e74bcba9f6f <comment><USER2> I have to agree with the author here. In the promises example and the callback example, you end up declaring three functions. When you break all the callbacks into the same scope like the author did in the callback example, you end up with the same level of nesting as you would have had when you use promises.

You can also name your functions so you can have a better idea right away what that piece of code would do without having to follow the call chain, and then just pass the function name as the callback. You could use function names with promises too, but at that point why not dump that extra boilerplate code and use callbacks?</comment>


A manifesto from Jimmy Wales - <AUTHOR> https://tpo.com/about

<comment><USER2> Not enough detail before the login wall. Can't tell if this is all talk or something that might go places.

Even the shop requires a login.</comment>


Ask HN: Who are the next FAANGs? - <AUTHOR> <comment><USER2> Samsung, Huawei, Alibaba, Tencent. They're already there when it comes to revenue, just not in market cap.

</comment><comment><USER3> Next FAANG in what sense?

If you're talking about "next technology-first unicorn that's going to make it big in the next 10 years", good luck. That's what everyone and their mother has been looking for in the past 10 years. These tend to get eaten up by an existing FAANG if it looks like there's a good fit.

There are also plenty of other companies that have FAANG-levels of name recognition but probably won't get to the same size. These are your VC-driven, trying-to-dominate-a-market-but-it's-hard (ex. Ubers/Lyfts, bikeshare-of-the- week) and doing-well-in-a-niche-but-not-as-large (ex. Square) companies.

<comment><AUTHOR> Companies who are big but not FAANG big... not super early stage, companies that have potential to be FAANGs one day. I get everyone is looking for it, I'm looking mostly in the sense of job prospects etc.

</comment></comment><comment><USER4> FAANG will buy out or try to choke out anyone who looks like they might be a competitor. I'd look for new multibillion-dollar companies in places where they have less power: Asia, Africa, Europe outside the EU.

[https://medium.com/chingu/africans-can-build-billion- dollar-...](https://medium.com/chingu/africans-can-build-billion-dollar- companies-ycombinator-visits-lagos-nigeria-a274d781f246)

[https://www.forbes.com/asia200/list/](https://www.forbes.com/asia200/list/)

<comment><USER5> Unlikely, earlier upcomming antitrust laws will shred them. Somehow IBM, HP or Microsoft allowed for FAANG to grow. New FAANGs will be so different in spirit to current ones that they won't be subject to such buyout. However I agree the new giants may come from non-US markets.

</comment></comment><comment><USER6> I had a similar question. What is today's equivalent of the internet of the late 90s?

<comment><USER7> Maybe blockchain or virtual reality?

<comment><USER6> Maybe Blockchain. Is the adoption as much as the internet? I don't know if there's anything useful coming out of it.

Virtual Reality seems like a safer bet.

<comment><USER8> "Virtual Reality seems like a safer bet."

Out of curiosity, can you explain why you think so? I'd think block chain has the bigger potential, but I don't keep myself up to date on VR.

</comment></comment></comment></comment><comment><USER5> Whoever knows that already will be insanely rich.

</comment><comment><USER9> zenefits

docker

twilio

X github (gone)

<comment><USER10> none of those

</comment></comment><comment><USER11> I prefer to focus on the problems of the current debt-based economy, where bubbles like that are common and are fueled by debt.</comment>


Ask HN: Is anyone working on a replacement for email? - <AUTHOR> Email's defining characteristic is how it's decentralized—no single company has control over the protocol. This has been both a blessing and a curse, and for better or worse, email is mostly stuck in the 80s with a little bit of HTML sprinkled in.
I hear Slack get thrown around a lot by people wanting to replace email with instant messaging, but it not only isn't decentralized but also doesn't serve many of the purposes (authentication, a universal identifier, etc) that email has come to serve.
Are you working on something to replace email? Are there any projects that are starting to replace email for you? <comment><USER2> Email doesn't need replacing.</comment>


Solidarity Forever - <AUTHOR> https://logicmag.io/tat-solidarity-forever/ <comment><USER2> The most essential argument:

"I would like for our industry to be more like librarians. Librarians have a sense of who they are as a profession. They have a central ethical code around patron privacy. The current Librarian of Congress fought John Ashcroft and was ridiculed by him for the idea that people have a right to read what they want to read without it being reported to the FBI. When you go to library school, you absorb this. If you violate it, you're shunned by your profession. And no one's bringing in Ukrainian librarians to circumvent it—it's not like they're going to offshore library science to get around patron privacy.

You see this in other fields. Doctors say do no harm. Journalists—in theory, at least—are trying to speak truth to power. But we in the tech industry don't have anything like that. We need some kind of professional identity about who we are and why we do what we do. It can't just be about "moving fast and breaking things" or not being evil. "</comment>


The Tumbler — A simple physics simulation / meditation / relaxation experiment - <AUTHOR> http://andrew-hoyer.com/experiments/tumbler/

<comment><USER2> Fun!</comment>


Lightweight Static Guarantees - <AUTHOR> http://okmij.org/ftp/Computation/lightweight-static-guarantees.html <comment><USER2> > Morris' old ideas do indeed work. Why don't we use them?

Because we are lazy or overworked?

The last time I wrote C, I had asan and ubsan and valgrind running in CI.

</comment><comment><USER3> I'm a big fan of giving more feedback to developers at compile-time. A while back I wrote a Java library that makes it easy to add static checks that would otherwise be runtime errors. Link in case someone finds it useful: [https://github.com/overstock/annotation- constraints](https://github.com/overstock/annotation-constraints)

</comment><comment><USER4> The verification question is somewhat handwaved in the linked article, but in fact we are now in a position to verify some of this stuff mechanically. Unsurprisingly, the "branding" techniques work, but in type systems that have any amount of subtyping the argument for why they work is subtle and they may not work in all cases.

</comment><comment><USER5> Also based on the idea of lightweight static checks and dependent types in existing ML languages: [https://notebooks.azure.com/allisterb/projects/sylvester/htm...](https://notebooks.azure.com/allisterb/projects/sylvester/html/Sylvester.Tensors.ipynb)

</comment><comment> awinter-py there are lots of properties app devs & library authors want to verify statically and languages aren't doing a good job of making this easy

JS (for example) has a bunch of 3rd-party type checkers (typescript, flow), and they're _huge_ projects. And flow is even written in ocaml.

I've written static verification of non-type properties when my team absolutely needed it and it's never easy -- even things like AST walking can be rough and non-standard.

Would def try a language that had BYO static checks as a first-class concepts. Code generation is the closest thing to this IMO in widely used languages and even that is clunky in most places (go:generate, I'm looking at you).

<comment><USER6> Not really a language feature since it's compiler specific but you can relatively easily write static checks using clang-tidy which is a code analysis tool for C++.

[http://blog.audio-tk.com/2018/03/20/writing-custom-checks- fo...](http://blog.audio-tk.com/2018/03/20/writing-custom-checks-for-clang- tidy/)</comment></comment>


British Government Wants Private Firm To Monitor Super Database Of Every Person In Britain - <AUTHOR> http://www.infopackets.com/news/censorship/2009/20090106_british_government_wants_private_firm_to_monitor_super_database_of_every_person_in_britain.htm

<comment><AUTHOR> Great. Another multi-billion pound disaster project on the way.

You'd think they might have learned from the utter disaster that was the NHS Programme for IT...

<comment><USER2> What do you mean disaster? Politicians got contributions, consultants got paid, docklands flats got bought, civil servants got directorships. And the ground work was laid for the requirements of the next system to fix all the problems of the current one.</comment></comment>


Apple is now run by a guy who is more like John Sculley than Steve Jobs - <AUTHOR> http://recode.net/2016/05/03/apple-is-now-run-by-a-guy-who-is-more-like-john-sculley-than-steve-jobs/ <comment><USER2> Nobody was like Steve Jobs. So if that's the complaint against Tim Cook, well, take a number. You could say the same thing about 7 billion other people.

Tim Cook has a few things over John Sculley.

A big difference is that Tim was at Apple for decades before taking over as CEO. He joined Apple in 1998 as an SVP, which means he was part of Steve Jobs' leadership team for the entirety of Apple's resurgence. The article says:

> Jobs obviously saved the company years later with the iMac, iPod, Macbook, > iTunes, iPhone and iPad.

Tim Cook was part of the Apple leadership team for every single one of those products. There hasn't been a "Steve Jobs era" followed by a "Tim Cook era." There was a "Steve Jobs + Tim Cook era" and now it continues as a "Tim Cook era."

And other people too, of course. Ctrl-F in the article for "Ive"\--no results. An article about the past and future of Apple that doesn't mention Jonathan Ive? Looks like another in a long line of "cult of personality" articles that ascribe all success--or failure--to a single person, the CEO.

There are many other differences from Sculley. Tim Cook has been Apple CEO before--this is his 2nd turn at it. He's a believer and defender of Apple's culture. He personally understands computer engineering. He has personal principles that he advocates for. Etc.

Apple has always had an ecosystem of second-guessers telling it what it should do differently. The greatest strength of Tim Cook as CEO is that he, like Jobs, doesn't listen to those folks.

<comment><USER3> >An article about the past and future of Apple that doesn't mention Jonathan Ive? Can someone explain this to me. I keep hearing about how big Jonathan Ive is in relation to Apple and I think I've even seen a book that claims he is _the_ genius behind Apple. But from what I see and understand he is mostly a designer who executed on Steve Job's ideas (it's hard to think of the very quirky and exacting design of Apple Products not having some major input from the quirky and exacting Jobs) and I've even read somewhere that his major contribution to the original Ipod (arguably the product most responsible for Apple's comeback) was the white color of the earphones. Are you sure you're not just replacing the cult of Jobs/Cook with the cult of Ives. I genuinely would like to know why a product designer gets so much praise/credit for Apples success since great design is only one of many reasons (and probably not even the most important) for the great products they make

</comment></comment><comment><USER4> Sculley was a success at Apple: he took annual revenues from $0.98bn in 1983 to $8.00bn in 1993. After Steve Jobs's Macintosh flopped, Sculley saved it with the Mac II.

Jobs rejoined Apple in 1997 when turnover was $7.078bn, after which turnover declined to $5.36bn in 2001 before recovering to $8.28bn in 2004.

So Apple did better when Sculley was in charge ($0.98bn in 1983 to $8.00bn in 1993) than in the next decade, when he wasn't ($8.00bn in 1993 to $6.02bn in 2003).

What Sculley didn't do was successfully introduce non-Mac products (iPod, iPhone, iPad), which Jobs did. The jury is out on whether Cook can do that too.....

<comment><USER5> To me there's a fascinating story there. Sculley was working for the _today_ and Jobs for the _tomorrow_. Doing either by itself is disastrous: living for today means the company doesn't innovate and once its market momentum slows down it'll die (RIM, Nokia?), and thinking too far ahead mean they cannot polish their products and get the most they can of the current market either.

Apple without the return of Jobs wouldn't exist - it wouldn't have innovated in anything. But without Sculley to give it some solid ground for a few years, it would probably have gone bankrupt.

Next few years will be interesting.

<comment><USER2> Remember that the Newton--which as a product concept was far ahead of its time --was developed and launched under Sculley. So was OpenDoc, the Apple "Advanced Technology Group," Quicktime, Quicktime VR, etc.

So I would not say that Apple failed to think about the future under Sculley. It's not easy to understand or describe why Jobs succeeded as wildly as he did in his 2nd tour at Apple. If it was, everyone would be doing it. :-)

One thing I rarely see discussed is the importance of the time in which Steve Jobs succeeded. The success we ascribe now, in hindsight, to Jobs' incredible leadership, might be in part the result of just a good match between what Jobs could do, and what could succeed in the market at that time.

His principles did not really change that much, actually--he always believed in owning as much of the tech stack as he could, and in producing integrated products with custom hardware and software. That approach was too expensive and inflexible to compete against Microsoft PCs the first time he was at Apple. It failed at NeXT. But it succeeded wildly the second time around, at Apple.

Would Apple be doing much better now under Steve Jobs' leadership? I don't think it's entirely clear. Some aspects of Apple's success continue to match up with Jobs' vision, but the areas in which Apple seems to have the most challenges--services and interoperable ecosystems--were never really Jobs' strong suits.

<comment><USER5> To your last point, I think it's less of a factor of the person in the lead or his ideas, and more about what was expected of that person.

Sculley was more of a manager, Jobs was a dictator. Once Jobs was back, he was somehow able to lead the company in a near-authoritarian way, and despite many flukes, it allowed the company to try many things that would not be readily accepted by an all-powerful committee.

One authoritarian that is wrong half the time is better than a committee that is not-wrong 100% of the time. The former tries a bunch of stuff, the latter doesn't really try anything. (And to me that's what got RIM and Nokia killed).

<comment><USER2> I don't know that I would agree that Apple is not trying anything. The Apple Watch, Apple Pay, Swift, HealthKit and ResearchKit, HomeKit--potentially a _car_... if anything, the critique against Cook seems to be that Apple is trying too many things and losing focus.

I agree that Jobs was a special talent who could command the organization. I think Cook is emphasizing collaboration because he knows he can't lead Apple the same way Jobs could. Probably no one can.

</comment></comment></comment></comment></comment><comment><USER6> A personality like Steve Jobs's would never tolerate having another Steve Jobs around, so this is what I always assumed. Steve was always laser focused on a small number of elements to create buzz (one button, really thin, it's a cube...) and a small number of products (goodbye old model, here is new model, it's not compatible).

Tim Cook has been adding blur from the first moment.

I also see an odd parallel in another corporate transition... even though it's the same leadership, is the new re/code more than a shadow of the old All Things D?

<comment><USER7> Tim Cook is an operations guy, Steve Jobs was a product guy. Tim Cook hasn't been "adding blur" to anything. CEOs have an executive role but whatever they do beyond the usual management and delegation stuff is more a function of their personal interests than explicit responsibilities that are part of the job description. It's very unusual for CEOs to micromanage product design, and in most cases it's an organizational antipattern when they do.

</comment></comment><comment><USER8> I remember an anecdote in the Steve Jobs biography where the first thing he did when he came back to Apple was severly cutting down a confusing and overlapping matrix of products. Now that he's gone, that matrix is creeping back up. I've lost count how many different types of iPhones and iPads there are now.

<comment><USER9> The iPad lineup in particular has gotten pretty bad. There's the iPad Pro 12.9-inch, the iPad Pro 9.7-inch, the iPad Air 2 (which also has a 9.7-inch display), the iPad mini 2 and the iPad mini 4.

Why would I get a 9.7-inch iPad Pro over a 9.7-inch iPad Air 2? What's the difference between an iPad mini 2 and an iPad mini 4, and what happened to the iPad mini 3?

They ought to just have three iPad models, distinguished by size: iPad Pro (the 12.9-inch model), iPad Air (the 9.7-inch model) and iPad mini (the 7.9-inch model). That would make it much easier to tell the difference and decide which one you want.

<comment><USER10> The 9.7 Pro and Air are nearly identical. The naming is unfortunate. If the 9.7 Air is v1 the 9.7 Pro should be v2 of the same name. But the product itself is the iPad, there's isn't a competing iPhone XXL. The Pro/Air is just a sub configuration on price and specs.

<comment><USER6> whoosh! you provided a Tim Cook response to a Steve Jobs comment.

<comment><USER10> If OP is actually Steve Jobs commenting I missed my opportunity, I have more important questions than iPad models

</comment></comment></comment></comment></comment><comment><USER11> How about dialing down the "growth" expectations? How big do you expect Apple to be for $deity sake? They are big. Much bigger than ever. Now it's not about big "growth" anymore, it's about staying big.

Edit: whoever wants to give some meaningful arguments can maybe use some comparable company as an example.

AAPL Mkt cap: 531,84B

MSFT Mkt cap: 382,79B

<comment><USER12> If "no more growth" is going to be Apple's story to investors, the company needs to start paying a much bigger dividend.

<comment><USER13> If you exclude the cash horde (edit - the zombies hired to protect the vault full of cash), Apple's P/E ratio is running at around 5 right now. IBM is 10. Microsoft is about 35 if excluding their much smaller cash pile.

Apple is ridiculously "undervalued" compared to any peer in the industry. It is a money printing colossus.

Having said that, the market seems to get shivers around $600B, and that psychological barrier imposes a friction that makes the rules of the game change. No one can stay above that for long, and in the case of Apple its profoundly out of scale numbers makes everyone simply put it in a different universe of valuation.

<comment><USER14> Is that really the whole story ? [http://www.marketwatch.com/story/apple-isnt- really-sitting-o...](http://www.marketwatch.com/story/apple-isnt-really- sitting-on-216-billion-in-cash-2016-01-26) I honestly don't know and am interested in what you think of this article.

<comment><USER13> That is an interesting article, but the meat of it contradicts, in a common sense, the title.

For instance, no one thinks that Apple has a big vault with hundreds of billions in it. Like all rational players, they hold most of their negotiables in short term securities. For tax reasons they also have been taking on debt in some areas rather than liberate cash from elsewhere.

But they have an enormous, enormous amount of wealth sitting virtually at a standstill. They have announced that they're going to spend a lot of it to buy back shares (boosting the value of the remaining shares), but they've been doing this so slowly they're adding to their pile quicker than they're spending it.

</comment></comment></comment></comment></comment><comment><USER15> There are many things in this article I feel compelled to attack or nitpick about. But just to highlight one: the assertion that "the big problem is that Apple's last hit product, the iPad, came under Jobs and launched six years ago".

That ignores the Apple Watch, which has basically created a new product category and proceeded to immediately account for _more than half_ the total sales in that category. The Watch has outsold the iPhone during its early days, as well. For any other company, this would be reported on as a great triumph. Unless you have wild fantasies that Apple is supposed to magically produce an iPhone-sized business every two years, even though no other company in the history of money has ever produced an iPhone-sized business even one time. Double-digit millions of units of sales, first year, for a brand-new product that nobody's ever spent $400+ per unit on is pretty good.

<comment><USER16> >> ...which has basically created a new product category...

What?

<comment><USER17> How many smartwatches did you see announced before the rumors of the Apple Watch emerged?

<comment><USER16> How many examples of a particular technology has to exist before someone can't boldly claim that Apple created the category?

<comment><USER17> I think the gist is that smart watches existed before Apple announced their watch, but as soon as Apple announced the Apple Watch, a bajillion were announced, created and put on sale even before Apple started selling theirs.

Did they invent the smart watch? No. Did they innovate and start a new chapter of the category? I think so.

<comment><USER16> I totally disagree. There were smartwatches before Apple's, therefore the category already existed. It may not have been a high profile category in some people's eyes, but that doesn't mean it wasn't there.

Also, I disagree on the bajillion number, for reasons other than the obvious. There were quite a few viable smartwatches on the market and many in the pipeline before Apple's. Plus, the watches not counting after the rumor of an Apple watch is a silly claim as well. There are numerous rumors of Apple working on a new product; for instance, that logic dictates Apple created the smart TV category.

Why isn't it good enough that Apple entered the market with a nice product? Why do people have to give more credit than what is due?

</comment></comment></comment></comment></comment></comment><comment><USER18> This oversells Jobs' execution. Let's not forget that he once held a whole media event to announce...an ipod dock. And Apple forecast the iPhone as possibly eventually capturing 1% of the phone market.

The iPhone is an extra-extraordinary product, but even in retrospect it wasn't considered as amazing when it came out. The watch reminds me of the iPod in terms of when it entered the market (somewhat early, after others had probed and validated it a bit) and under-the-radar adoption rate.

If you ignore personalities, the question really is: can the machine continue to pump out extraordinary products. Not "can the machine pump out another iPhone".

</comment><comment><USER19> there's a limit of how many shiny things you can sell. it's not tim cook's fault.

apple is diversifying, if the car rumors are true it means that they are trying something totally new. its just that building a revolutionary car takes a lot more planning and effort than creating a new iteration of iphone.

</comment><comment><USER20> It has been a long time since the metaphor comparing apples to oranges was more apt.

</comment><comment><USER21> John Sculley sold sugar water and never did anything worthwhile after that. Tim Cook is running the world's most valuable company with more cash than most of the world's countries put together. He's not Jobs, no one is. It's like complaining if you are not Einstein there is no point in being a physicist because you won't change the world forever.

<comment><USER22> So? As the article says, from Cook's position many executives would have made a capable run of the past five years; the question is what Apple is going to do in the future.

<comment><USER23> My money is on self-driving cars. They have AI (Siri), Maps, Location (through Yelp and partners) the only thing left is a physical car. Their Carplay SDK is just them dipping a toe in. I expect, like the Moto Rokkr, it's going to go from a partnership to an all out race.

</comment></comment></comment><comment><USER24> I never worked for Steve, but do work with a lot of people who did. I never heard once heard someone say: Man, I sure wish Steve was still here instead of Tim.

Not that Steve isn't missed, of course. It's just that Tim is also great.

</comment><comment><USER25> I've been saying this for years. Everyone always defended him as if he were actually responsible for Apple's success</comment>


Microservices – Not a free lunch - <AUTHOR> http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html <comment><USER2> See also:

      - Subroutines - Not a free lunch
      - Libraries - Not a free lunch
      - Client-Server - Not a free lunch
      - OO - Not a free lunch
      - Multiprocessing - Not a free lunch

Many of these arguments apply to these, too. The main difference is that of scale. Latency and call overhead are way larger than for the examples I gave.

Improved tooling can bring both down, but not by that much. That's why you will not see many micro services that are truly micro. You won't see (I hope) a 'printf' micro service, or not even a 'ICU' micro service. A regex service might make sense, if the 'string' it searches in is large and implicit in the call (say a service that searches Wikipedia), but by that time, it starts to look like a Database query. Is that still micro?

<comment><USER3> (My company loves microservices, so I'll weigh in at a really high level.)

The author speaks of the complexity in managing and coordinating processes in a distributed system. By designing a microservice, you trade simplicity of software design for increased operational complexities. There's a shift in terms of problem solving too--it migrates from the cross functional engineers to the DevOps and distributed systems engineers.

Don't get me wrong--I think microservices are brilliant and make reasoning about application design easier. But be prepared to bring in some heavy engineering talent to coordinate all the things. Until there are open source frameworks for handling the difficult bits, it might be unwise for a start-up to go the microservice route. Microservices are purposed for scale (since reasoning about traffic is easier with a simpler service and there predictable traffic patterns from a microservice's clients).

Edit :

In terms of the examples you mention, I you may have the wrong idea. Think about fulfilling a specific goal or class of functionality, and make that a microservice: email gateway microservice, user/session microservice(s), SMS gateway microservice, etc. Each is a component that responds to various request types (you really should use RPC instead of REST for deadlines, retries, cancellation, pooling, etc.), but they all sit within a single domain of purpose. The service could be stateless or not, but you try to make the requests idempotent to aid client reasoning.

To again cite your example, several services may use regex, but there might be only one authority on "normalized input" (eg. addresses, etc.). Or maybe there is a client lib for that.

This brings up another point. Services at the periphery (dependency graph- wise) are coordinated by interior services. That can get complicated...

</comment></comment><comment><AUTHOR> On a related note, is anyone aware of any tool(s) to declaratively describe an application architecture and automate its deployment on something like AWS or in a single virtual machine + docker? For example "I want 10 replicated microservice1 processes and 5 replicated microservice2 processes in front of a nginx load balancer. Also, throw in a Redis and a PostgreSQL database." This would be immensely useful for (one man show) developers who don't necessarily have the time or experience to "properly" setup and fine tune infrastructure. I think what I'm describing is known as "Infrastructure as code" in DevOps parlance.

Edit: Since this question is getting many replies, I'll be a bit more specific in what I am looking for. Is there a tool that would let me describe the infrastructure and deploy it on a given cloud provider _but also_ have the ability to deploy the same infrastructure on my local machine (using VMs/docker) for development purposes.

<comment><USER4> > Edit: Since this question is getting many replies, I'll be a bit more > specific in what I am looking for. Is there a tool that would let me > describe the infrastructure and deploy it on a given cloud provider but also > have the ability to deploy the same infrastructure on my local machine > (using VMs/docker) for development purposes.

Seems like the [https://www.hashicorp.com/](https://www.hashicorp.com/) guys would have something, perhaps Terraform/Atlas?

I have not done this yet obviously but am in the same boat as you for our company goals this year

<comment><USER5> What I liked most about Terraform was the explicit separation of planning and execution.

</comment></comment></comment><comment><USER6> I'm really happy to see DevOps, CD, and Microservices take off, although, as usual, I'm a little perplexed as to why we need new slang. But hey, if it works to get the message out, I'm all for it.

These things are not new, but like so many other ideas, they're just old ideas re-appearing in a context that had forgotten about them.

Traditionally, many of the potential problems the author relates have been solved by architectural conceits. For instance, standardize on a programming language and datastore, then share all persistence-related files. (I'd strongly suggest a FP language, preferably used in a pure manner). Then you've decreased the "plumbing" issues by a couple orders of magnitude, lowered the skill bar for bringing in new programmers, and you can start talking about using some common testing paradigms to work on the other issues.

I'm a huge fan of microservices, but it's good to talk about the bad parts too, lest the hype overrun the reality.

<comment><USER7> It's just a technology cycle. Microservices have serious disadvantages as well, which will cause their elimination in, oh, 5 years if they're lucky.

1) They're not really simple. If you take essential functions like a key-value store, that'd be a microservice. Simple ? Yeah right. Business logic ... simple ? Yeah right.

2) It's slower. You can wine all you want, but when it comes right down to it, there's a reason people avoid crossing the network, and the microservice approach essentially comes close to crossing the network every single time you cross module boundaries. You'll be spending 50%+ of your cpu time marshalling and unmarshalling and waiting for transmission, even on the same system.

This also manifests in all these "no-sql" datastores. They have all the problems of sql datastores, but they have one more. There's no way to have indexes. So in a table indexing all your sales by "id", the only way to find sales of product "X" is by going through each and every record (you can build indexes yourself, but it's not easy and it's sure as hell not flexible. Plus I guarantee you'll do it wrong the first 10 times). This means that retrieving 10 sales records takes the exact same amount of time as generating the yearly sales reports. In other words : you won't be doing it, because it takes too long.

3) There's just so damn many of them if you want to achieve anything useful. Every single one of them needs to be sufficiently well-designed to operate like an individual web server. So (d)dos-resistance, fairness, anti-slowloris, anti-starvation, autoscaling, resource exhaustion (like maximum number of file descriptors ...) correct sharding, access control (not too tight, not too loose, ... correct caching of security credentials, ...), and load testing, you've thought of all that for that "really small and dumb" service that basically copies information across the payment/non-payment firewall right ? If you haven't ... prepare to be surprised.

A related problem here is the shear amount of diagnostic monitoring you'll need.

4) They are inflexible, and don't deal well with different data types (this is one of the things object oriented programming solved). They work well when they deal with strings, or with company-standard datatypes. Only companies don't like to have company-wide standards. Yeah, I know Sun and to a lesser extent Facebook succeed at it, but does your company ? Last time I consulted at a bank they had systems interoperating using every interchange format from fixed-width fields (old cobol code), 5 different kinds of xml, and of course json and a dozen binary formats. Microservices can't work in such an environment. It destroys the flexibility of individual actors. The argument here, of course, is that that is a good thing, and I'd say you're right, but you've just created yourself a hell of a lot of enemies, some of them powerful.

5) It's extremely hard to orchestrate integration across multiple microservices. The first thing this will manifest in is testing. How do I test one service ? The answer is "unit tests" or "a system test". But this is the result of a fundamental misunderstanding. As a company, or even an IT department, you don't really care if unit tests and/or system tests succeed for a microservice. You care that if you connect a -> b -> c -> d -> e -> f -> g (and usually this is a network of microservices, not a sequence) that you can sell gizmos on your website.

Testing if that works requires throwing up three dozen services. Now first, having watched the netflix talks, they do this. Congrats. That's can't be easy. They also talk about the disadvantages : they have 3 teams doing nothing other that making that work, and it eats a significant part of their AWS resources. They can't do it on developer's workstations, nor even on a number of them.

The second thing this will manifest in is the cross-microservice redesign. Say a new law comes in. With a payment we now need to have a scan of the driver's licence of the buyer (say "gizmos" are treated like alcohol). So we simply need an extra image field going through the payment system. Oh-oh. The payment system is 8 microservices, and therefore around 64 interfaces to the rest of the system. Let's be generous ... only about 30 need to be redesigned. There is nothing to help. Refactoring, or even type checking doesn't work across microservice boundaries.

This presents 2 problems.

First is that it's a hell of a lot of work, even though most services only do basic things and don't care about the new data. But they still copy the data, save it, ... each of them needs logic to deal with missing data (historical data for instance), and the copy from one json dict to another needs to be implemented. And as you'll find every microservice has it's own methods for dealing with said datatype, you'll be checking up to 8 libraries for marshalling problems.

Second is testing. Any error you make won't come up unless you're testing multiple of those services simultaneously. If you manage to have just a bit more complexity in your system, those problems won't come out until the massive full-system integration test. You know, the one you can't do yourself, and even your whole department can't do. Oh-oh. That's an awfully long feedback loop to find those 3 dozen places where you forgot to copy that field across.

<comment><USER6> Your comment was in some ways better than the original article! Thanks.

But, as you know, many of these problems are either solved or non-existent in Big-Monolithic-App-land.

So -- take the things that worked there and use them. Like I said, a common set of shared source code that handles all persistence means all apps can talk to each other using the same code. Changes don't break the chain. Stuff can be fixed in one spot. And so on.

The orchestration and testing pieces deserve special attention. I think you're going to end up with as many folks writing test/monitor/break code as you are microswervices. And that's probably a good thing. But you need to plan for that.

As far as the hype cycle, I've seen this over and over again. As far as I can tell, the driver is over-specialization of developers. Some new buzzword comes out, people teach and train around that, and suddenly you've got somebody called a "DBA" that can't write a web service. So then you need a "Front-end" guy, and so on. This industry is constantly labeling things, over-developing them, creating work silos that lead to poor performance, then going back and relabeling things again. There's some magic number of developers where you need specialists, but it's not 10, or even 40. The longer you put off creating silos, the better the entire effort is.

EDIT: In fact, I'll just say it: if you want to swim in the ocean of nirvana that is microservices, use pure FP and share all the source code that involves persistence.

<comment><USER8> There's been a drive towards "full stack developers" lately: [http://www.laurencegellert.com/2012/08/what-is-a-full- stack-...](http://www.laurencegellert.com/2012/08/what-is-a-full-stack- developer/)

That said, most of human history has involved specialization, modularity, and abstraction driving greater productivity.

So on one hand, you have work-silos, on the other you have the power of modularity. I think difference with software is that most of the productivity constraints happen at the interfaces. Teams need people that can integrate. They can be generalists, or specialists in a few areas.

Earlier in your post you suggest:

"But, as you know, many of these problems are either solved or non-existent in Big-Monolithic-App-land. So -- take the things that worked there and use them. Like I said, a common set of shared source code that handles all persistence means all apps can talk to each other using the same code. Changes don't break the chain. Stuff can be fixed in one spot. And so on."

IME, multiple teams using the same library can be helpful (if voluntary) or a complete disaster (if forced). The incentives of the library maintainers are not always that of every team.

</comment></comment></comment></comment><comment><USER9> In my opinion the article does not put enough weight on lack of transactions in a microservices architecture. Of course you can add distributed transactions, but doing so makes the architecture much more intertwined and much less error-proof.

<comment><USER10> It's always fun diagnosing rarely occurring race conditions in a system with many services, work queues, some eventual consistent components, and various databases with their own transactions.

</comment></comment><comment><USER11> > _Implicit Interfaces_

This is a crucial point. 'We use microservices' does not say much unless you can describe how you design consistent and granular service interfaces. Otherwise you most probably just produce microservice spaghetti.

</comment><comment><USER12> I was prepared to be convinced, what in our field does bring nothing but benefits? I didn't see much to worry about here though;

* who cares if you're deploying 20 services or 1 when you run your deploy script? * who doesn't have an operationally focused dev team? * who isn't already dealing with interfaces even if not micro services? * since when do micro services have a monopoly on distributed architectures or asynchronicity?

I can't agree testing is harder either. Too much fluff in this article to read much value into it.

<comment><USER13> Regarding interfaces, dealing with an in-process, code level interface is just on the surface simpler than dealing with an external interface like a JSON endpoint. If you're working with a statically-typed language, the comparison isn't even worth making - a contract that needs to be extensively tested turns into a compile error. Even in a dynamically typed language, the tooling to test that methods are being called correctly are much more mature and developed than determining that two independent services are conforming to the same contract.

<comment><USER14> Just wondering out loud: maybe it's possible that tooling for this just hasn't been written yet?

Something along the lines of declaratively stating what a JSON endpoint should be like and having a tool automatically assert that the services conform to that interface doesn't look impossible.

<comment><USER15> F# could do this with type providers. Or, something like Google Protocol Buffers could be used.

<comment><USER12> Or Java with JAX-RS. Or one of probably hundreds of alternatives.

</comment></comment></comment></comment></comment><comment><USER16> I enjoyed the article. As ever, there are tradeoffs and your milage will vary using different approaches.

This doesn't seem like an entirely fair comparison:

 _" It seems to me that all three of these options are sub-optimal as opposed to writing the piece of code once and making it available throughout the monolithic application."_

There's a different scenario that could have played out with how to share a library between different services. You could have written the bulk of your application in the same language, like a monolithic application but split into several services. In that case you could create a library for your tax calculations and use it freely within your services.

For me, I split my application into a small number of services and, as much as possible, split things out into libraries to make reuse simple (more libraries, thiner applications).

Sometimes I use different languages, but when I do, I consider very carefully whether the (rather large) tradeoff that presents will be worth it in the long run for what I'm getting in the short term.

A question: when people talk about microservices, how small are they talking?

<comment><USER17> The OP addresses this as one of the three options:

 _The final option is to share resources such as a tax calculating library between the services. This can be useful, but it won 't always work in a polyglot environment and introduces coupling which may mean that services have to be released in parallel to maintain the implicit interface between them. This coupling essentially mitigates a lot of the benefits of Microservices approaches._

<comment><USER16> I rambled a little - my point was that by avoiding te polyglot language situation you make things easier (and closer to the monolithic application). I take the other point though, parallel releases are harder.

</comment></comment></comment><comment><USER18> Listing the difficulties on microservices is useful, but let's not forget the difficulties encountered in monolithic big applications, which are the reason for splitting into smaller pieces.

In the big app 1) a single syntax error breaks everything. 2) simply loading all the app takes a huge part of ram, and tests are very slow. 3) there is a gigantic dependency tree, as when you depend on a module you also depend on every ones of the module dependencies. 4) Almost no one knows everything about the app. 5) it is impossible to split the company into separate services without getting fights about shared code and architecture decision.

<comment><USER19> It's a false dichotomy. The split isn't about no abstractions vs. services, but about whether the abstractions should be behind a network boundary. Let's look at these one at a time.

1) A single syntax error will _still_ break everything in a microservices architecture if the service in question is any essential service. In my experience, most services are essential. In a dynamically linked architecture, the failure occurs when you try to pull in the library. In a well-designed dynamically linked architecture, you can opt to not pull in optional components.

2) If you're an idiot and build everything monolithicly. A well-designed non- services architecture has many independent and independently testable libraries. Integration testing does require the whole system, both with and without services. In this case, both the resource usage and startup time is much lower without services.

3) Ditto for services, if you do integration work. Not so for independent libraries, if you do not.

4) Question of where you put the abstractions, not how you make them.

5) Again, question of where you put the abstractions, not how you make them.

The key reason for services is isolation, failover, and independent deployability.

There are a bunch of programmers out there who were only taught one way to make abstractions (be that services, objects, or what-not), and assume everything else means abstractionless spaghetti code. That's simply not the case. Structured, functional, and other modes of programming have the same quality of abstractions as OO. Likewise for whether you link statically, dynamically, or over a services boundary.

<comment><USER20> Not to mention the big performance hit of marshaling data, and the waste of resource when running separate processes.

Another important performance hit has to do with scheduling and multithreading, as crossing IO boundaries (even on the same machine) coalesce all threads into one (and then multiplex the work again on the other end).

</comment></comment></comment><comment><USER21> Not a fan of microservices myself - IME it pushes the complexity that exists in any application into implicit interfaces and dependencies between microservices. The difference is that we have better tools for managing this complexity at the application level than we do at the operation level.

Still a big proponent of SOA generally, though. I think the granularity when defining "service" is ultimately going to vary from application to application, however, leaving the sweet spot slightly larger than e.g. Amazon's microservices.

<comment><USER8> I'm not sure I understand this.

SOA == microservices, basically. Arguably one could say that Microservices = SOA minus ESBs, which is what necessitated the new term. IOW, don't hide your mess of dependencies in a black box, expose and manage them where they're needed.

The granularity of the service is generally determined by the size and responsibility of the maintaining team, and will vary from company to company.

With regards to tooling, I'm curious what you're referring to. Some selection of tools like Splunk, AppDynamics, New Relic, or Boundary certainly can handle both applications and microservice chains, no?

<comment><USER21> I've reconsidered what I wrote above – you're right. I'd built a mental model of what "microservice" and "SOA" meant that apparently isn't entirely in line with what others are commonly using.

I maintain that it's not a panacea, and that complexity is pulled into other places (operations) where we perhaps don't have equally effective tools at this point. I'd also argue that it's difficult to understand the correct level of granularity (and potentially expensive to fix errors in this decision). But it's not the problem I made it out to be.

<comment><USER8> I agree with the above. It's not a panacea but it seems to be worth exploring further as a way (not THE way) to manage (not cure) scale/complexity in multi- team environments.

</comment></comment></comment></comment><comment><USER22> Fundamentally, there isn't a huge difference between microservices and monotlic apps if both systems do the same thing. However, a lot of the issues of general complexity are more apparent in one approach or the other.

For example, breaking changes are breaking changes in either system. It's not an issue of architecture style, it's a matter of business needs changing, and thus protocols change. A change in protocol breaks the existing protocol.

We understand this intuitively when you are talking about a de-facto protocol like HTTP, but we seem to think our own programs are somehow different. They aren't.

Architecture is about taking the essential complexity of a problem and creating components and protocols to solve a problem in a way that makes the most sense for the team trying to solve it. Monolithic apps or microservices then should be a question more of what your team is going to execute well as much as it is a question of which structure more elegantly solves the problem at hand.

</comment><comment><USER23> I've pretty much faced all of the problems mentioned in this article. An application is set of services with a certain complexity that work together. In some cases this complexity just gets transferred from service level to orchestration level.

Don't get me wrong, I love microservices and will try to use them in all my future work, but I think where people often go wrong is that they over commit to it without realising the downsides. I often see people casually using AMQP queues for pretty much everything, only when they need the worker service to talk back to the originating service that they realise they've made a wrong architectural decision.

<comment><USER24> Can you elaborate on your latter point? Why is that considered an incorrect architectural decision?

<comment><USER25> For example if the caller needs the result of a possible long running task, ie success or fail, then it has to maintain state in a way to associate the async queue message back to the task. Zeromq has the concept of request/reply to handle this, its more problematic with plain old queues, the solution ive worked with is mq for tasks, rest calls for results. Yes it sucks.

<comment><USER24> Awesome, thanks for the explanation.

</comment></comment></comment></comment><comment><USER26> Why is highavailabilty.com slower than most other websites? :>

<comment><USER11> Because it's highavailabilty.com, not highspeed.com.</comment></comment>


Thorium-Fueled Automobile Engine Needs Refueling Once a Century - <AUTHOR> http://www.industrytap.com/thorium-fueled-automobile-engine-needs-refueling-once-a-century/15649 <comment><USER2> Ridiculous puff piece. The key component for any of this is a working accelerator driven thorium reactor which we don't have. Once we have such a thing, energy ceases to be scarce (at least by current standards). Such reactors are like fusion, except instead of being perpetually 25 years away they seem to be 10-15 years away.

[http://en.wikipedia.org/wiki/Accelerator-driven_sub- critical...](http://en.wikipedia.org/wiki/Accelerator-driven_sub- critical_reactor)

<comment><USER3> "One benefit of such reactors is the relatively short life of its waste products, which would be in the hundreds of years as opposed to millions of years for existing nuclear reactors."

This line in the wikipedia is outright false. There's no way for a fissioning nucleus to magically know if the neutron that hit it came from an accelerator or another fissioning U atom. Neutron's can't be spray painted green to greenwash / eco brand them to magically make them better than non-greenwashed neutrons.

The rest of the article is more or less true. It misses the two most important uses of accelerator driven reactors. The first is even if you can't generate primary energy and its a net energy sink, you can still transmute elements. So if nasa needs more of specific Pu isotopes for a RTG, you can incredibly slowly create it by burning an enormous quantity of coal without having an actual reactor. Or you could make a plant that overall eats (lots of) electricity and squirts out americium for smoke detectors. The second use is obviously research, you now have a magic machine that eats electricity and while it eats electricity it creates an environment very much like the inside of a real reactor, without the costs and size and weight and security concerns of a normal reactor. Not exactly the same but probably good enough for short term materials science or other fooling around.

<comment><USER4> Um, I have no idea about how this particular tech works, but neutrons with different momenta can cause dramatically different transitions in the nuclei they strike. No magic required. Is it clear that these neutrons are supposed to have the same momentum as those produced in traditional reactors? That would be surprising.

<comment><USER3> Yes fasts and thermals generally have varying cross sections. The graph of fission products don't vary much. The "well known" ability to identify which reactor a used rod came from, is because the fission products themselves react to neutron flux, and for materials science reasons no one runs rods to more than a couple percent burnup and long enough to stabilize.

So a rod isn't just 1% used up (a vacuum?) and 99% pure and unused, its first hour of fission at a certain rate resulted in a certain random distribution of nuclei which themselves were irradiated for precisely 2345 hours of full power operation, and then hour two's fission products got irradiated for 2344 hours, repeat. Its a massive summation. What makes it even more complicated is some of the product nuclei are themselves radioactive with a pretty short half life (this is where the ten or so percent of decay heat energy comes from ...) so if you shut it down from hours 1023 to hour 1025 then the end result product will be quite a bit different because you're missing two hours of product isotopes, missing two hours of irradiation for the old isotopes, and the old isotopes decayed naturally for two hours (perhaps into different isotopes, some of which might be radioactive).

If you're really bored, and want to run a big numerical simulation, and have programmatic access to a nuclei table (or just make one up with random data?) you can have all kinds of fun simulating a reactor and summing, decaying, and reacting hundreds to thousands of isotopes under varying conditions and then seeing what you get.

Maybe a TLDR is there are a lot of ways to properly ignite charcoal for a charcoal grill, but the end result cooked steak tastes about the same in the end.

</comment></comment></comment></comment><comment><USER5> Thunderf00t explains why this is BS: [http://www.youtube.com/watch?v=568iDYn8pjc](http://www.youtube.com/watch?v=568iDYn8pjc)

</comment><comment><USER6> I will just repeat my comment from an article about the same car two years ago ( [https://news.ycombinator.com/item?id=2879219](https://news.ycombinator.com/item?id=2879219) ):

This is fake or a scam!

There are same interesting quotes in the original article: [http://wardsauto.com/ar/thorium_power_car_110811/](http://wardsauto.com/ar/thorium_power_car_110811/)

First, this is not a nuclear reactor: (at the end of the article)

> _This means no nuclear reaction occurs within the thorium. It remains in the > same state and is not turned into uranium 233, which happens only if thorium > is sufficiently super-heated to generate a fission reaction._

It says that thorium has a lot of energy, not that they can extract it: (in the middle of the article)

> _Because thorium is so dense, similar to uranium, it stores considerable > potential energy: 1 gm of thorium equals the energy of 7,500 gallons (28,391 > L) of gasoline Stevens says._

And the explanation of how it works doesn't make any sense: (at the beginning of the article)

> _The key to the system developed by inventor Charles Stevens, CEO and > chairman of Connecticut-based Laser Power Systems, is that when silvery > metal thorium is heated by an external source, it becomes so dense its > molecules give off considerable heat._

The entire story sounds very similar to the presentations of the perpetual moving machines, or the cold fusion: a promise of a lot of cheap energy, but not a working prototype that produce more energy that it consumes.

</comment><comment><USER7> One look at the website for LPS and you know it's pure BS: [http://www.laserpowersystems.com/links/thorium-car/lps- car](http://www.laserpowersystems.com/links/thorium-car/lps-car)

</comment><comment><USER8> What are security implications of Thorium fueled automobiles?

What if someone places an explosive device in it? Or two thorium fueled cars crash? What happens to reactor in these cases?

Is there mini Chernobyl everytime (let's say food/water is poisoned for a month or so) this car collides with something?

I think things like thorium fueled cars would be way more useful for inter solar travels than as cars (Less chances of causing environmental disaster).

</comment><comment><USER9> Nope not true; [http://www.youtube.com/watch?v=568iDYn8pjc](http://www.youtube.com/watch?v=568iDYn8pjc)

</comment><comment><USER10> Seems unlikely... [http://www.youtube.com/watch?v=568iDYn8pjc](http://www.youtube.com/watch?v=568iDYn8pjc)

</comment><comment><USER11> I am not a nuclear engineer, so can someone explain the safety risks in the event of a car accident?

<comment><USER3> google for accelerator driven reactor. They don't work because its too inefficient to run the accelerator, aside from the usual squared/cube issues. I'm sure the first working one will be a fixed station, the next generation will be an ocean going ship, and maybe then a car. Concept cars are a waste of time to consider.

Worst case scenario if you literally ground the car into dust you'd release perhaps ten milligrams of nuclear waste. Why you'd grind an entire car into dust is a mystery. I suppose fed into a compactor and melted and recycled without removing the probably mostly unused and valuable fissionables is possible.

So in an accident would you rather have 10 mg of waste, or 30 gallons of hyperflammable gasoline, or 1000 Kg of lithium batteries, or ...

You're probably better off in an accident with this.

<comment><USER12> 10mg of radioactive material can cause a lot more trouble than you think... especially since the hazards are of a less familiar nature than e.g. fire.

<comment><USER3> But the 10 mg of material are contained inside a ceramic rod in oxide form which won't oxidize because its already oxidized (assuming the designers are smart) and is somewhat refractory in a fire anyway, inside a thick walled steel boiler which is inside some kind of containment thingy and its surrounded by inches (feet?) of metal inside the engine compartment.

On the other hand, 30 gallons of gasoline is in a cheap tank made out of cookie cutter metal so it tears open in a minor crash and there's a puddle of it underneath the seat you're strapped into. And it burns. Really well. So a giant pool of it is currently on fire, underneath your feet. Whoops. Unfortunately this happens fairly often.

The lithium battery is more complicated to model. They burn, really well, but if properly vented they can't explode. So its kind of like driving a truck with 1000 pounds of grilling charcoal in the back... if it ignites, and you just sit there, you'll eventually be grilled like a bratwurst, but its going to take a heck of a long time, so unless you're alone and unconscious in abandoned distant wilderness for 15 minutes you're OK.

<comment><USER12> Humans are familiar with fire and heat. They are not so familiar with the effects of radioactivity.</comment></comment></comment></comment></comment>


Users in powers of 10 - <AUTHOR> http://blog.villageshelf.com/users-in-powers-of-10

<comment><USER2> Thinking about users in powers of ten is useful when designing a scalable Internet architecture.

Each order-of-magnitude change in the number of users generally requires a redesign of some part of your product's architecture. Don't worry about supporting 10 times as many users as you have now. A design that works for 100 users isn't necessarily the best for when you're supporting 1,000, _and vice- versa_ (a design that works for 10,000 users may be overkill for 1,000 users).</comment>


Building a Riak Cluster on Raspberry Pi - <AUTHOR> http://basho.com/blog/technical/2012/11/01/rasp-pi-cluster/

<comment><USER2> | Then reboot. You can just unplug it. At this point I wouldn't worry about file corruption. If the thought bothers you, you can run sudo shutdown now, then unplug.

I wouldn't recommend just unplugging it. I have corrupted more than one RPi sd card this way. Do the latter, it will save you a lot of time in the long run, especially after you spend all the time to download software and set it up -- do you really want to do that again.

This is a fun post. I've been using both technologies recently -- I'm thinking of ways I could practically apply this...hmmm

<comment><USER3> dd if=rasppi.img of=sdcard

And you are good to go, worth it regardless of how you shut down.

</comment></comment><comment><USER4> I can't really understand the idea of installing "monster" software onto tiny machines. I wouldn't be totally puzzled if this post came from some hobbyist, but it is released by Basho itself. So what's the idea?

<comment><USER5> The idea is advertising.

<comment><USER6> Besides advertising it can be PoC of running NoSQL workloads on ARM architecture.</comment></comment></comment>


Everyone hates open-plan offices. why they still exist - <AUTHOR> https://www.fastcompany.com/90285582/everyone-hates-open-plan-offices-heres-why-they-still-exist <comment><USER2> I still remember the hell of working on extremely complicated n-tiered enterprise software during the loud, daily shoot-the-breezes from nearby co- workers. The "manager" had a quiet walled office and did not care, the noise was not their problem. After a company buyout, nearly every single one of them lost their jobs. This actually happened.

</comment><comment><USER3> Every time there's one of these articles, the comments are always from one of two groups:

1\. Introverts (like me) saying that they can't work under those distracting conditions.

and

2\. Extroverts screaming, "why can't you just be social?! I love noise!"</comment>


Show HN: Open-Source JavaScript Image Editor Plugin - <AUTHOR> https://scaleflex.github.io/filerobot-image-editor/ <comment><USER2> Hey team! Where are the images stored once edited?

<comment><AUTHOR> Hi, you can use either the storage of yours or use our cloudimage.io image optimization service.</comment></comment>


Adsense Content Writing Guide - <AUTHOR> http://www.marketingfool.com/adsense-content-writing-guide.html

<comment><AUTHOR> This is an article about writing content for adsense type sites, but the advice is really pretty good for any type of writing. I especially like the "golden five" rules or writing listed towards the end of the article. As coders, we could probably all work on our non-code writing.</comment>


WizBang beta 3 released - <AUTHOR> http://wizbang.sourceforge.net

<comment><AUTHOR> Here's an update to my project that I had submitted to HN about a month ago. As always, comments and suggestions are welcome.

Thanks</comment>


Lookie, lookie, a QR Code... from space - <AUTHOR> http://www.flickr.com/photos/ericrice/5031494545/

<comment><USER2> Congrats - inverted in PS and my HTC Hero got it! Nexus couldn't though</comment>