Japan Seeks to Squelch Its Tiny Cars - <AUTHOR> http://www.nytimes.com/2014/06/09/business/international/japan-seeks-to-squelch-its-tiny-cars.html?ref=asia <comment><USER3> This makes me sad.

I lived and worked in Japan for 6 years, returning to my native Scotland almost 2 years ago, after struggling for the few years after the M9 quake (lived in Koriyama, Fukushima prefecture and lost my job after the quake).

We bought a new Suzuki Wagon R Limited back then, and I loved that car. Its apparently small outward appearance is deceptive; inside, there was loads of space - a high roof height, and when you folded down the rear seats you could comfortably fit items such as chests of drawers, fridges, and the like.

The engine; 0.6 litre - but that was augmented by a turbo, so there was plenty of power available, plus it sipped fuel. The automatic gearbox provided 4WD in first gear, which was awesome during winter - we lived in rural parts of Fukushima and the roads frequently iced over. Once during winter we went for a drive up a mountain road covered in about 3 inches of fresh snow and made it to the top of the Katasoniyama mountain because of the 4WD+studless tyres. Our Wagon R Limited also had niceties such as aircon, electric windows, and a minidisc(!)/radio.

All in all, a fantastic vehicle, and I wish we had sent it over to Scotland when we moved as the equivalent Wagon R's available here are made in Europe and just aren't the same standard of equipment and features, sadly.

The silly thing about the move by the Japanese government is that these Kei cars are an ideal solution to crowded cities as they require less space on roads and for parking, as well as being (or were) an extremely economical choice.

As others here have commented, I suspect there has been lobbying by the makers of large gas-guzzlers to make Kei cars less desirable. I think this decision by Abe's government will inevitably impact Japan's struggling economy - <USER2> politics is notorious in Japan, something which contributed to the design and layout flaws of the Fukushima Dai-ichi nuclear plant.

<comment><USER4> >>All in all, a fantastic vehicle, and I wish we had sent it over to Scotland when we moved as the equivalent Wagon R's available here are made in Europe and just aren't the same standard of equipment and features, sadly.

Well, I am glad you enjoyed it in Japan, but I am very happy that cars which do not meet basic NCAP safety standards are not allowed to be sold in the EU.

<comment><USER5> Because you need the government to decide what is safe for you or not?

I've never understood safety standards for consumer goods. If you want to drive around in a horrible death trap of a car... why should the government stop you?

(Admittedly I guess you don't want driving time bombs, but the majority of NCAP standards are related to occupancy safety).

<comment><USER4> Because as a EU citizen I want to know for certain that something that is on the market here is not dangerous to drive around.

The same as you can trust that the carrots sold at a local supermarket do not contain arsenic - there are regulations against that. But according to your logic, it would be better if there were no regulations, surely a producer of arsenic-containing carrots will naturally go out of market after sufficient number of people die, because no one will buy their carrots anymore,right?

I believe that a car with a cabin that folds like origami in a crash should not be allowed to be sold in the EU(or in fact, anywhere).

<comment><USER5> So I guess you can't buy a knife in europe? (by your own logic).

<comment><USER4> You can't buy a knife that would be dangerous to use by being badly made, or which material would contaminate food. So for example,a knife containing phthalates would not be allowed to be sold in stores. This is my logic - I do not want equipment which is unsafe to use to be sold in the EU - a car that has a cabin which folds like origami in a crash[1] should NOT be allowed on the market.

Guess what happens to the passengers of this car? I imagine their consistency is somewhere between peanut butter and freshly squeezed orange juice: [1] [https://www.youtube.com/watch?v=CRU__x5UAo0](https://www.youtube.com/watch?v=CRU__x5UAo0)

</comment></comment></comment></comment></comment></comment><comment><USER6> Just speculation, maybe this is a result of US pressure in the recent trade talks (trans-Pacific partnership?) It looks like Japan's domestic auto market is a key issue in TPP:

[http://www.reuters.com/article/2013/04/12/us-trade- asiapacif...](http://www.reuters.com/article/2013/04/12/us-trade-asiapacific- japan-idUSBRE93B09R20130412)

(edit): Here's a whole article about US TPP pressure against kei cars:

[http://www.japantimes.co.jp/news/2012/01/27/business/lower-t...](http://www.japantimes.co.jp/news/2012/01/27/business/lower- tax-rates-for-kei-cars-arent-ok-with-american-automakers/)

        "When American automakers expressed their opposition against Japan
        joining the Trans-Pacific Partnership negotiations due to its closed
        market, the U.S. makers also pressed Tokyo to end special tax
        treatment for the country's unique "kei" super-minivehicle segment."

        "The outside pressure to end the low taxation for one of Japan's most
        popular car segments has jolted the industry, which has protected the
        smaller end of the domestic car market for half a century."

        "Some industry observers point out that reviewing the tax rules for
        the super-mini segment would hit Japanese automakers hard. But others
        say a review would be a good thing because kei cars have received
        favorable treatment for too long."

Reading those two articles, I think it's credible that US negotiators got a concession from Abe on kei taxes, and we're seeing the result of that. As I understand, this kind of deal would be made in secret (like many aspects of TPP), so we wouldn't be aware of it at this point.

<comment><USER7> Or U.S. automakers could simply enter the segment. Kei cars aren't much different in size from a Smart car or a Fiat 500 (and yes, both are Euro designs). They're smaller than a Ford Ka, which is the smallest U.S. derived car I'm aware of that's in regular production (coincidentally made in Fiat factories).

They aren't rocket science, but they do stress elements of interior design efficiency that American car makers aren't great at.

TBH, I'd love to have a vibrant Kei car market in the states. Especially in and around big cities with lots of traffic.

<comment><USER8> Which is easier, innovating out of your comfort zone or using your contacts to have another country's laws changed without the informed consent of their electorate? Oh.

<comment><USER7> Depends how big you are.

</comment></comment></comment></comment><comment><USER9> This is pretty short-sighted, in my opinion. If anything, smaller-sized cars seem likely to become more popular globally, not less. A walk through any chinese city will reveal any number of hand carts and jury-rigged bicycles just begging to be replaced by space- and fuel-efficient microvehicles.

As the world moves to cities, cars get smaller. Japan should be capitalising on this trend, trying to spread the culture overseas, not trying to smother it!

<comment><USER10> I would love to buy a daihatsu copen in the states. These are just fun small cars.

<comment><USER11> I don't own my own car, I share one at the moment. But if I bought my own, I used to want a Nissan Cube. It's a hilarious looking car and the overall shape just looks so efficient. I never realised they make even smaller more efficient cars (and I have visited Japan).

If you don't want to sell these in Japan, send them over to Australia please.

</comment></comment></comment><comment><USER12> Kei cars are (were) cheap, economical, Eco friendly, favourably taxed and actually quite fun to drive. Now they are "too popular" and the government wants everyone to buy larger, less fuel efficient cars - I know someone personally who bought a larger car simply because of the new penalty taxes on Keis. Abe really has lost it.

</comment><comment><USER13> >But industry and government officials are increasingly worried that these microvehicles have become a distraction for the nation's automakers — still bastions of the Japanese economy — and are moving to wean drivers off them. In April the government took what its critics charged was a hard-line route. Kei drivers were hit with a triple whammy of a higher sales tax, higher gasoline tax and higher kei car tax, the last of which the government raised by 50 percent, sharply narrowing their tax difference with regular-size vehicles.

I feel like there's more going on than the article is saying. "industry and government officials are increasingly worried that these microvehicles have become a distraction for the nation's automakers" sounds like lobbyists for full-size cars feeding politicians what to say. I don't buy that a bunch of politicians decided it was the for the greater good of the country to increase taxes on a cheap, fuel efficient vehicle.

<comment><USER14> I tend to believe the government's version, just because all big Japanese automakers have strong kei sales. Extra tax won't help them. It may help the government collect a bit extra but that's that.

What I didn't quite get from the article is how do taxes compare. Looks like they simply got a more similar treatment to standard cars.

These cars would be much cheaper to maintain even with the same tax regime as regular cars. IMO all sales tax should be regular tax, and road tax/car taxes should just go away. They tax fuel enough to cover for all that and it makes sense to tax on usage.

<comment><USER15> > IMO all sales tax should be regular tax, and road tax/car taxes should just > go away. They tax fuel enough to cover for all that and it makes sense to > tax on usage.

Government giving up on any tax opportunity? I wish, but not in the world I know...

> What I didn't quite get from the article is how do taxes compare. Looks like > they simply got a more similar treatment to standard cars.

They seem to be removing the 50 years lasting subsidy, which makes sense to be honest - at some point it has to finish.

> These cars would be much cheaper to maintain even with the same tax regime > as regular cars.

Exactly my thoughts, if these cars are so popular, efficient, and budget saving - they shall do OK without getting government involved.

<comment><USER16> > Government giving up on any tax opportunity? I wish, but not in the world I > know...

Interestingly, the state of Georgia dropped the normal annual ad valorem tax on cars. Now, any new car purchase is covered by its sales tax (which was being paid before) for the life of the vehicle for that owner (when they sell it the new owner will owe some smaller amount, I assume, but haven't had to deal with yet). I still haven't figured out how they expect to make up that revenue, unless other taxes are just bringing in enough revenue to make up for it. Or it may have been expected/hoped that the reduced cost of ownership would encourage the purchase of newer cars.

</comment></comment></comment></comment><comment><USER17> This reminds me of Happoshu[1]: beer was expensive in Japan because malt content was taxed[2]. Brewers introduced fizzy beer-like beverages with lower malt content ("happoshu"). Beer tax revenues consequently dropped, so the tax on most happoshu was raised to parity with beer. Brewers responded by putting even less malt in their fizzy alcohol drinks.

1\. [https://en.wikipedia.org/wiki/Happoshu](https://en.wikipedia.org/wiki/Happoshu)

2\. As I have been led to understand, this was intended to dissuade rice- growing land being switched to barley: Japan seeks to preserve self- sufficiency in rice production.

</comment><comment><USER18> Kei cars make perfect sense in Japan- the density in city areas, the lower speed limits (compared to the US), smaller house driveways which could probably fit two kei cars but not two "regular" cars. At some point I saw a house (in either Okazaki or Kanazaa, I forget) that had a Ford Excursion in the driveway, and it stuck halfway into the road- that was a very rare sighting. Most people speak pretty positively of their K-car experiences. Instead of trying to pressure people in Japan into buying larger cars, wouldn't it make more sense to try to reduce the preconceptions about them and develop an export market? It sounds like this attempt will only result in more people ditching cars for scooters again, or dropping down to one car when they previously had two. Cars- of any kind- are already rather expensive to own there.

They've already had to replace most of their nuclear power with fossil fuel based sources. Pressuring people into buying less efficient cars seems like a giant backward step for a country that's generally considered to be fairly eco-conscious (when you ignore the past destruction of ecosystems for building, and the effects of concreting all the riverbeds). It's much easier to breathe in Tokyo than Beijing, it would be great if it stayed that way!

As an aside, I think Japan's regulation on diesel exhaust for large hauler trucks is actually less strict than the US. I was in Okinawa last year, and there was constant traffic from large construction trucks that were always billowing black exhaust that smelled horrific- it seemed much worse than 18 wheelers here. I also noticed it when I tried backpack from Nagoya to Osaka on a rural road in 2010- the truck exhaust seemed to hang in the air longer and felt more choking than modern truck exhaust in the US (familiar with this from doing distance runs on roadsides).

</comment><comment><USER19> This is stupid Japanese auto makers were fairing way better in this economic crises than American ones.

Why would you like your car companies to be like GM or Ford and fail at the first sign of bad economic times.

Everyone is trying to make cars more eco friendly the Japanese seem to be ahead in that regard and now their going to opposite way.

</comment><comment><USER20> Shouldn't it be up to the private automaker to make decisions about the economy of scale of its products or what is better for the private company's future? Why would the government get involved in securing the future of its automakers by taxing a class of products? The only legitimate argument for taxes might be reduced safety features. Does the US government do something like this? Imagine it adding a tax on Apple products or even American cars because of a sales demographic issue?

</comment><comment><USER21> For those wondering the definition of "squelch": make a soft sucking sound such as that made by walking heavily through mud.

<comment><USER22> That's one definition of "squelch". The title is probably using the definition that means "suppress":

      a circuit that suppresses the output of a radio receiver if the
      signal strength falls below a certain level.

[https://www.google.com/search?q=define%3Asquelch](https://www.google.com/search?q=define%3Asquelch)

[http://en.wikipedia.org/wiki/Squelch](http://en.wikipedia.org/wiki/Squelch)

</comment></comment><comment><USER23> Curses...and here I was excited that many of the best Keis are finally hitting the 25 year mark and becoming eligible for import into the US. I had my hopes high that they would catch on and actually encourage Japanese brands to bring over some of the cooler Keis.

</comment><comment><USER24> I'd buy one of these ... most of my driving is in town and the Kei would be perfect for that type of driving. (Note that our primary car is an eight passenger Sienna with just above half the city fuel economy claimed by the NT100.

</comment><comment><USER4> "Even Ford's smallest car, the Fiesta subcompact, has a substantially larger engine."

I am fairly certain that Ford's smallest car is the Ka[1], not Fiesta.

[1][http://en.wikipedia.org/wiki/Ford_Ka](http://en.wikipedia.org/wiki/Ford_Ka)

<comment><USER25> As it's the New York Times it seems likely they are referring to the smallest Ford available in the US - I don't think the Ka is available there.</comment></comment>


ODesk: Change the world, get $250 - <AUTHOR> http://seoroi.com/fun/funny-photo-fridays-odesk/

<comment><USER2> Wow, that much for changing the world?</comment>


Pagination and Http Caching (2011) - <AUTHOR> https://00f.net/2011/02/25/pagination-and-http-caching/

<comment><USER2> This is an interesting article [https://www.discovermeteor.com/blog/pagination-problems- mete...](https://www.discovermeteor.com/blog/pagination-problems-meteor/)</comment>


Programming shape using kirigami tessellations - <AUTHOR> https://phys.org/news/2019-08-mathematical-framework-sheet-material-kirigami.html <comment><USER2> Here is a link to the actual paper. The original post asks for a subscription to see the paper.

[https://arxiv.org/pdf/1812.08644.pdf](https://arxiv.org/pdf/1812.08644.pdf)

edit: Grammar.

</comment><comment><USER3> This link is a better intro than the linked abstract (contains a gif explaining the concept) [https://m.phys.org/news/2019-08-mathematical- framework-sheet...](https://m.phys.org/news/2019-08-mathematical-framework- sheet-material-kirigami.html)

<comment><USER3> To add, we discussed this at work this week, and someone tried cutting the example on our laser printer. Broke when trying to expand it, though.

<comment><USER4> What material?</comment></comment></comment>


The Problems With My Startup - <AUTHOR> http://awmf.blogspot.com/2007/09/problems-with-my-startup.html I typed this up in order to collect my thoughts, in hopes of eventually showing them to my coworkers. I am totally open to questions, comments, and suggestions, especially from YC readers. <comment><USER2> I think the solution is to get the idea guy down in the details of each idea. Bring him along for the ride and let him come up with lots of micro-ideas. It can be very useful to have two people thinking about the minute details, especially if they balance each other. Involve him in the thousand tiny decisions you have to make while implementing an idea.

Get him to stop looking at competitors. It's nerve wracking, demoralizing, and distracting. You guys probably have more than enough ideas by now, if you'd just focus on the most promising ones your competitors might start looking at you.

<comment><AUTHOR> Good comments. I think I had some of those thoughts early on (specifically referring to your first paragraph), I must have just gotten disillusioned with them. I will attempt them again.

As far as getting him to stop looking at competitors, 100% agreed.

</comment></comment><comment><USER3> Stories like this, from startups that are still struggling, are very helpful. Are you full-time, or do you still have a day job? How about the others on your team?

<comment><AUTHOR> I have a day job, for which I "telecommute", and sadly that's not working out too well. My day job folks just asked me if I would be willing to relocate, and I've been considering it. It would mean much more work from them, which would mean easier payment of bills, etc. I would be living near the job that pays me, not the other way around.

<comment><USER4> This here shows that you have huge doubts about the startup, if you are willing to leave it for a less risky decision. It saddens me to see your operation come down to you deciding to leave it for a job. To keep it business running, I would try to get another coder, tell the marketing guy to focus on current products, not future side projects. Take control of the company...basically what everyone else has been saying.

</comment></comment></comment><comment><USER5> This guys comments (first comments in the blog) ring true ~ <http://tjic.com/?p=7265>

</comment><comment><USER6> Hmmm, 4 people in the startup and only one writing code. Sounds like a top heavy organisation to me.

Reminds me of a project a collegue was involved in at work (which is at a big established firm). This had; 1 programmer, 1 manger (who requested more technical staff cause he knew 1 programmer wasn't enough but was turned down), and 2 project managers. As the project was running furhter behind schedule (due to agressive scheduling and vague requirements and mainly because lone programmer was in status meetings ever day), various high-level management were thrown at the problem.

Eventually, the programmer spent about 1/2 his day in meetings about the project, with his manager, 2 project managers, 1 VP, 2 senior VP's. Project was never finished ...

</comment><comment><AUTHOR> I typed this up in order to collect my thoughts, in hopes of eventually showing them to my coworkers. I am totally open to questions, comments, and suggestions, especially from YC readers.

<comment><USER7> Although I am very interested to read your comments, I feel that it is disingenuous to put your name on a 'secret' blog. If you want to have a secret blog, make it secret. If you want to be open and honest with your co-workers, be open and honest w/ them. Half way in between strikes me as more likely to hurt than heal.

Unless what you are trying to do is get at your co-workers, in which case I think you will succeed.

<comment><AUTHOR> Your point is well taken. It wasn't my "secret" blog, really, until I typed this particular post. I had not revealed its existence to any of my coworkers, but as you will notice, none of the other posts are particularly charged as regards business or business politics.

I do want to be open and honest with my coworkers, and I've already had one (one of the designers) have a look at what I wrote. I am going to present the ideas contained therein, to the group, ASAP--it's a matter of finding time to meet and talk about "serious stuff". I was hoping to get some feedback from YC readers because I trust their opinion and ability to perceive when someone has gone off the deep end as regards ideas, reasoning, etc. In other words, I'm hoping that if I'm smoking crack, or if all startups are this way, someone will tell me before I unveil it to my coworkers at large.

I am certainly not trying to get at my coworkers. The stuff at the top is in case it's discovered by a certain coworker who i would _rather_ heard it from me, not the blog. He's been known to read YC news once in a while, thus the precaution.

</comment></comment></comment><comment><USER8> If you are the idea guy and you are not bringing in new ideas then what are you contributing to the startup? I think it is a bad idea to have a designated idea guy.

<comment><AUTHOR> We are all idea guys in one sense. The reason I've been referring to one guy as the "idea guy" is that he's not a coder and if I were to gauge the number of ideas each of us has put forth, he would easily take the highest percentage. So because he mostly talks to clients on the phone, does other PR- related things, and brainstorms ideas, I find it easy to refer to him as the "idea guy".

</comment></comment><comment><USER9> I would take the new job and use the money to hire a coder, along with any coding you can do on your own. You have to be willing to risk everything, if you really want to make it work. No risk no reward. If it was easy everybody would be doing it.

</comment><comment><USER10> I commend your efforts. It's not easy to go through this. And it's smart of you to share and ask for help. Very smart.

You asked. I won't be bashful. Take my feedback however you want (or tell me to go to h*ll).

You do not have a startup. You have a hobby. A startup is full time. Greater than full time.

Like you, I'm a hacker. I simply cannot imagine giving up equity to a designer or an "idea man" (whatever that is). Design is grossly overrated (see Google). Ideas are everywhere. Only a fool pays for them. People should be paying you to give you ideas (more about that below).

I understand that these are your friends and that you love working with them. Nothing wrong with that. What's more important to you, the quality time you spend together or the outcome? I think you have a tough decision to make because, frankly, I don't see you having both. You don't need these guys.

I would seriously consider taking your employer's offer to relocate. This would give you a graceful exit from your current endeavor and preserve your friendships. Then I would bank every dollar I could in order to go back to my start-up full-time. You should be able to work full-time for at least 6 months, preferably a year. I would also try to pick up side jobs somewhat related to my start-up. Pick up a few extra bucks and get your ideas FROM THOSE WHO ARE PAYING YOU. These are real ideas coming from the field, not from some ivory tower. So the logic is reversed: you can pay for untested ideas, or get paid for real ones.

You don't mention whether your employment is related to your start-up in any way. If it's not, all the more reason to pick up side work.

I would also try to make connections with other hackers; maybe you can find more suitable co-founders.

(By the way, the comment about open and honest communication is spot on. Talk to your partners!)

You've got quite a few things to think about and a lot of good feedback from both places. Please - keep us posted. You never know where this may lead...

<comment><AUTHOR> Thanks for the blunt comment. It's what I was looking for, and much appreciated.

I will attempt to let you all know how this pans out.

</comment></comment><comment><USER11> In my late twenties I was brought in as the superstar on a startup. The "idea guy" was a former professor of software engineering and a former VP for a large electronics firm. Hey -- he was a teacher! And a VP for quality! What could go wrong?

I staffed a very small team and we took off. Every day my idea guy would wonder around the office, (his basement) coming up with some kind of new thing or two that was cool. It was distracting as heck.

I finally took him aside and told him that we could do a certain amount of work each time-box (which I believe was 3 weeks) but we couldn't work in an environment where we didn't know from day-to-day what we were doing. Interestingly, the other main programmer said that I was being too anal. So the idea guy and I had words and I left.

The company never did pan out. Being agile is what it is all about, but you have to actually _do_ something for that truism to work. This is like the guys who sit in the stands at major sporting events. It's easy to have some master plan that changes whenever the mood strikes when you don't have any skin in the game to make something happen. This is why it's better to have geeks who are also idea guys -- they realize the cost associated with the ideas. Just because you can say it easily doesn't mean you can create it easily.

Dude -- I'm sure these guys are your friends and you've been through a lot. But there's lots of serious, focused work involved with making a startup happen. It sounds like what you've got is more of a painful group hobby. I think it might be time to consider a better format for being productive.

<comment><AUTHOR> > It sounds like what you've got is more of a painful group hobby. I think it > might be time to consider a better format for being productive.

I think you're right, at least for my part. One problem is that the idea guy IS my friend, but I don't think he shares my point of view about this. I wrote up the blog post in order to collect my thoughts to relate them to him.

<comment><USER11> The business side of this is cold and harsh, as it always is.

But as far as keeping a friend? He's a teacher, right? Why don't you sell him on the idea about learning how other startups succeed? I'll never forget reading "A Good Hard Kick in the Ass" several years ago. It completely changed the way I understood how startups work. Perhaps you could sell him on the idea that you're feeling a little frustrated, and perhaps other teams out there have learned something that might be useful to you guys.

I also liked "Founders at Work" which I read a while ago. I wouldn't bury the guy in material -- after all, if you give him too much he'll just blow it off. But I'd find some text that made the case and _was presented by another person who is an authority_. That way, it's not a you vs. him deal, it's just a couple of friends discovering how things work.

Good luck. If he's smart and your friend I'm sure he'll see the value of a structured approach to creativity. The trick is to be non-confrontational. Let the ideas battle it out, and not the people.

</comment></comment></comment><comment><USER12> let us know how your talk with co-founders goes.

<comment><AUTHOR> Will do.</comment></comment>


The NSA intercepts its targets' electronics purchases shipped by FedEx / UPS - <AUTHOR> http://dailycaller.com/2013/12/31/shipping-companies-largely-silent-on-nsa-intercepting-packages/

<comment><AUTHOR> Schneier provides some details in this post:

[https://www.schneier.com/blog/archives/2013/12/more_about_th...](https://www.schneier.com/blog/archives/2013/12/more_about_the.html)</comment>


Ask HN: What is a good conversion rate for a landing page? - <AUTHOR>

For those of you who have done landing pages in the past, what products did you do them for, and what percentage of visitors signed up? <comment><USER2> I don't have a large enough data set or experience to declare any sort of average but in my experience the conversion rate is highly correlated to two things:

1) The message and design of the landing page. 2) The message and media used to drive traffic to the page.

Low quality on either will result in low conversion (5% of traffic).

A highly targeted campaign that points out a pain point and a landing page that is well designed and speaks to that pain converts at a far higher rate. I now frequently see 15-20%. I should note that those rates are for registered users, not for other metrics farther down the line (some sort of interaction for example).

Two pages that convert registered users at 20%: <http://www.styckyd.com/sell_race_cars>, <http://www.styckyd.com/sell_modified_cars>

Facebook ads have been the most successful generator of quality traffic for us so far.

<comment><USER3> Very nice lp's. What CMS platform do you use, if any?

<comment><USER2> Thanks. No CMS.

Everything is hand coded and designed by me from scratch. I use Rails/HAML to make things a little easier.

</comment></comment></comment><comment><USER4> Our landing page conversion is hovering around 14%, which sounds like the higher side from what I've heard. My guess for why it's higher is because we've been targeting very specific people within our community. We chose launchrock for it's simplicity, but having done more research, I'd like to try unbounce the next time around (better integration with other services, more options).

Quora has some interesting posts on the topic (<http://www.quora.com/Landing- Pages>). For reference, our landing page is <http://beta.opperator.com>

</comment><comment><USER5> Our conversion rate for <http://www.zuupy.com> is around 4%. Out of that 4%, 10% will eventually upgrade to a paid plan, which costs minimum $29.95/mo. So you can say that our conversion rate is 4% or 0.4%, depending what you mean by "conversion".

</comment><comment><AUTHOR> I've only done a couple but I've had results ranging from 0% conversion to about 15%. I'm wondering how to determine ambient conversion vs. something people really want. Obviously 0 is bad, and higher is better, but what is average (mean or median across your experiences is fine)?

<comment><USER6> For me, I go by the 1% or 10% rule, for ambient vs really want.

Ambient conversion - below 1% you're doing something wrong, above 1% you're doing something right.

Something people really want - below 10% you're doing something wrong, above you're doing something right.

This is a gross over-simplification, but these conversion rates can be applied to just about anything on the web (ad click thrus, free account signups, purchases, even % of people who will go from one page on your site to the next).

</comment></comment><comment><USER7> Traffic from Techcrunch converted 50% for us.

Regular (more random) traffic at about 20%.

It depends a lot on where the traffic is coming from (a targeted ad, article, a search, ...)</comment>


Ask HN: Is Covid-19 turning into an ad campaign? - <AUTHOR> Lately, I've been receiving a lot of emails from companies about Covid-19. Big and small, explaining what they are doing about it.<p>Are we just turning it into a huge advertisement campaign? <comment><USER2> Yes... every marketing department is sending an email saying, "We're doing all we can to protect everyone... thoughts and prayers, we're in this together! ... btw, don't forget about your business, and make sure to check out our coronavirus offers and book a Zoom meeting with us to discuss more about out amazing deals for you!"

It's like... yes, we all know there is a virus. It doesn't need to be reiterated by every single brand with your email in a newsletter-of-the-month gimmicky marketing email sent from Hubspot to funnel leads into Salesforce.

Honestly, it's like watching social media accounts trying to 1-up each other on telling a story about how they are really a better person than everybody else for chiming in on a tragedy with a self-centered post. It's white knighting a serious situation for self-gratification.

</comment><comment><USER3> Hype will trample everything, marketing is just grabbing at its fur on the way by in hopes of being dragged along. This isn't like skateboard surfing a freeway; tho. Hype is a herd of rabid buffalo on PCP.

I was joking last month about "sealing ourselves into our apartments with plastic and duct tape" but it isn't funny when people are going to be advocating that later this week.

I'm "at risk" and keeping my daughter home from school this week even though they're staying open; the social panic is worrying me far more than the disease. People are ready to accept the unthinkable already and there's voices saying "data isn't important we have to act fast!" ... that could end badly.</comment>


My favourite interview question (2006) - <AUTHOR> http://weblog.raganwald.com/2006/06/my-favourite-interview-question.html <comment><USER2> So I tried a new approach inspired by this kind of interview question. In a nutshell: it aims to simulate the interactions you'll have with the candidate when they receive their first project, without the time burn of a full pair programming day.

1) determine the system the candidate will design. It should be an internal system or an internal oriented problem, not an external thing like Monopoly or URL shortening services.

2) stack your interview team with a mixture of people who can contribute different thoughts to this problem. Engineering, UI, marketing, management, etc.

3) first interviewer of the day introduces the topic and helps the candidate understand some of the internal lingo and bootstrapping questions they'll have right off the bat. The first interviewer is pretty crucial because the candidate has to be prepared to write things down and carry information across each interview.

4) all subsequent interviewers come in and ask two questions:

* What problem were you given to solve?

* I'm an expert in technology / business area X. How can I help?

By the end of the day when they're having their likely optional interviews with more senior people, they should look disheveled but pretty happy, because now they're pitching to senior management an idea they collaborated on with a wide variety of team members.

They should have a whiteboard full of stuff, stacks of paper, whatever. You should get a good idea of how they organize themselves under pressure.

The interview team should have a good feel for how the candidate leveraged them for answers. The interviewers should have done a lot of talking! There should also be clear evidence of the candidate getting _better_ towards the end.

At the conclusion they're tasked with taking a step back to the higher level to explain the idea to management - regardless as to whether management is technical or not, they should be expected to walk away understanding the big picture. Having non-technical "business" people contribute to the interview is critical, since they help the candidate understand some of the human requirements.

I could go on and on, I'm pretty excited about how this technique has worked so far. The key element is deliberately having the candidate carry knowledge between interview teams. I'm sure I'm not the first person to think of this :)

EDIT: styling

<comment><USER3> Thank you, that sounds like a brilliant technique!

One question: Do you let candidates know ahead of time what the interview process will consist of? That sounds like an important step that many companies leave out - whatever interview process they use.

I think if I knew before arriving that this how it would work, I'd be a lot more excited about the interview and better prepared too.

<comment><USER2> Yes, the candidate should know in advance if there is a particularly structured interview technique being used, for sure.

Because it also requires a lot of mental commitment from the interview team as we'll as the candidate, I'd recommend using this technique as the final hurdle. I don't think you want to phone screen someone, then just toss them into this process. You need to have them cross some basic technical gate (like FizzBuzz, a take-home coding project, whatever), and have them meet a handful of people first, just to make sure they pass those early smoke tests.

In fact I think this technique works best when you want to seal the deal with a very strong candidate who is entertaining several options. Interviews should always be a two-way process, and if a candidate walks away from your interviews thinking "I had real trouble getting my point across to those people, I would never work there" then that represents _success_ for the interview process.

The strongest candidates tend to be the ones least influenced by money and more interested in the problems, the people they will be working with, the culture and the environment of the organization. So having your interview process structured around revealing that gives you the best possible chance of matching your team with people excited to be there.

Conversely if you're a candidate, even if the company you're applying with doesn't seem to have thought too deeply about this stuff, don't despair. Hiring is one of the hardest things to do and also tends to be done by the seat of the pants (Amazon seems like a notable exception) _You_ can impose your own structure by asking the right questions and making special requests of the recruiter. Tell them you want a chance to write code with someone! Or that you want to mock up a UI that solves a problem they have. Or you want to see what their strongest engineer thinks of your design for this service you've put together.

It doesn't matter if you're desperate for the job, or whether you wish they'd stop calling you ... this kind of stuff makes you stand out in the crowd as proactive and motivated by the right reasons.

</comment></comment></comment><comment><USER4> The problem with this question is that if you've asked someone who's played Monopoly a lot, also the old DOS version, and the latest EA versions - he/she might stick to concrete implementations and go in details how it could be done (since it's out there).

[http://www.abandonia.com/en/games/895/Monopoly+Deluxe.html](http://www.abandonia.com/en/games/895/Monopoly+Deluxe.html)

[http://www.textmodegames.com/download/monopoly.html](http://www.textmodegames.com/download/monopoly.html)

And here complete list:

[http://en.wikipedia.org/wiki/Monopoly_(video_games)](http://en.wikipedia.org/wiki/Monopoly_\(video_games\))

[http://www.mobygames.com/search/quick?q=monopoly](http://www.mobygames.com/search/quick?q=monopoly)

<comment><USER5> You would probably also get the opposite problem: I bet some people (particularly international candidates) have little to no experience with Monopoly, and the question would be unfair to them. If the goal is to start with their vague understanding of the game and see what gaps they fill in and what assumptions they make, then it doesn't work very well if you have to explain the game from scratch. It also takes quite a bit of time to explain the game if someone hasn't seen it before, which doesn't feel like a very efficient use of interview time.

<comment><USER4> Yup. Asking poker, bridge, santase, chess, etc. rules at interview is tricky.

</comment></comment></comment><comment><USER6> I would much rather hear about their past projects and have them clearly convey design decisions that they made before then have them work on a "on the fly" question. Everybody has off days, not many people have whole off years or careers. Just because I can't design Monopoly in one hour on a certain given day doesn't mean I do not have the relevant experience in my past, whether it be professional or as an undergrad.

<comment><USER7> It's not as though this is the only question by which the interviewee will be appraised. This is one more tool in the kit alongside asking about previous projects, interesting classes, career goals, overcoming tough situations, etc.

Whether or not questions like these are effective, the point of them is to engage with someone in a way that illustrates how they tackle complex, loosely defined issues: the majority of engineering problems in a nutshell. In most modern tech companies, good communication and not being afraid to ask questions are absolutely essential. Someone who will take an incomplete list of requirements and draw up an entirely incomplete product without questions or discussion is as much a liability as someone who takes the requirements and does nothing, paralyzed by indecision and not knowing what to do. And oftentimes, candidates aren't perfect but you're going to hire them anyway. Going through this process can illustrate how you would expect to interact with the candidate and where the initial rough spots will be as the candidate begins working with the team.

From another point of view, candidates are usually more than prepared to talk about anything on their resume. In some cases, this is equivalent to listening to someone give a prepared speech. Asking them free-form questions like the above can be a good way to understand how the candidate reacts in situations where they aren't fully prepared. For some positions this is irrelevant, but for others it's incredibly important to have some measure of poise and thoughtfulness when engaging with someone who doesn't necessarily agree with everything you say and is questioning your thought process.

In short, these kinds of questions aren't primarily testing your design and programming abilities, but your ability to communicate and reason with another person in a technical context.

<comment><USER6> You missed my point. People are prepared to talk about their resume, but when you dig in to their past experience and specifics that is where you get to the interesting discussions.

Case and point:

Tell me about a design pattern you used on X project?

A singleton? Ok, why did you use that?

and a long discussion about testability and architecture ensues with questions from both sides. That is WAY more like the communication that happens on the job than a contrived problem which in many cases is disconnected from real life constraints.

</comment></comment></comment><comment><USER8> I remember being interviewed in the DC area, where I was asked a question involving subway systems and routes. Being a mid-western lad completely unfamiliar with subways (and mass transit in general), I had a lot of trouble visualizing it. I would imagine that people who rode mass transit on a regular basis wouldn't have as much difficulty. Got a job offer anyway, though.

</comment><comment><USER9> Love how every time a post concerning interviews pops-up on hackernews everyone gets defensive. Like all things I think the nature of the interview should reflect the role the developer will have when hired. If the developer won't be in charge of developing an entirely new system or project on his own it seems overarching to ask this type of question. At the end of the day the core attributes that matter are intelligence, ability to learn, experience and motivation. In this case, this question really only tests experience.

</comment><comment><USER10> I once got a similar question, but with Battleship. I don't really enjoy these high-level design things, they seem silly and irrelevant to me, but I can see how someone with different interests would like it. (That particular place made me an offer, I'm not doing sour grapes.)

<comment><USER11> If you practice ALL of these questions for at least TWO passes: [https://oj.leetcode.com/problems/](https://oj.leetcode.com/problems/) , you can get a software engineer role in at least one of the famous tech companies, e.g., facebook, linkedin, google, amazon, microsoft, ...

Nowadays, very very few companies innovate in recruiting.

I've interviewed with most "hot" companies, and I can find most interview questions (>90%) from [https://oj.leetcode.com/problems/](https://oj.leetcode.com/problems/), exact same question.

<comment><USER12> I mean, yes, but if you can write passable code in two of [C++, Java, Python] for 170 problems of varying levels of complexity, I don't think it's much of a stretch to say you're a good programmer and could probably get a SE job at a company I've heard of before.

</comment></comment></comment><comment><USER13> The best interview question is "Why wouldn't we hire you?' You won't believe what people will say, in their urge to confess their sins.

<comment><USER14> "I'm going to ask for a lot of money."

True-est, and it's the perfect filter.

<comment><USER15> I've actually heard, "you can't afford me" in an interview before. (It was not technically an interview, but a meeting between my boss and someone he wanted to recruit.)

I think my boss (CEO of a mid-sized public company) took it as a challenge and gave him a very large offer -- which was politely refused.

</comment></comment></comment><comment><USER16> I generally went with a question my friend told me, "what was the last non- work, non-school program you wrote?". The theory being that a person who has used programming for something personal was probably a better candidate since they saw personal value in their profession.

<comment><USER17> In a good week I work 50 hours. In a bad week, 80 or 90 (or more). In my spare time I have family commitments, play guitar, draw, paint, hike, ride my mountain bike, and travel. Ask me that question and I'll probably find a way to wind up politely and leave.

<comment><USER18> I'm sure there are many here who would agree with you, but let me offer an alternative viewpoint. You said:

      > Ask me that question and I'll probably
      > find a way to wind up politely and leave.

The implication is that rather than opening a dialog with someone to (a) find out why they think that question is relevant, and (b) offer reasons why you'd be a good fit _despite_ not working with code outside your job, you'd simply leave?

For me, as a potential employer, that would be a good reason not to want to hire you. It makes you sound like you would not be an easy person to work with. It sounds like if someone came to you with an unreasonable software requirement you would simply shut them down without trying to find a way to deliver something that finds a good balance between what they've asked for, and what can be done.

But perhaps that's not the impression you intended. If not, could you expand further?

<comment><USER19> You have a very good perspective on what an employer would love to hear from someone, regardless of whether they code for fun on the side.

However, as an employee, such questions might be highly correlated with past companies that are looking for people who do not have family commitments, or who are willing to do unpaid extra work at home "for fun". As an interviewee, it makes me wonder, even if only fleetingly, "Will I be discriminated against for not being (young+single)?". (Are we even allowed to ask about marital status or age?)

Even if such a thing was never your intention, the interviewee might have had prior bad experiences with those who ask such a question, and view cutting the interview short as a way to ensure they don't get mistreated later.

<comment><USER18> In that case, just as an interviewer looks for indications beyond a single question, so should an interviewee. Cutting an interview short because of one indicator seems short-sighted. Surely better would be to use it as one indicator, and then start looking to see if there are more.

But I understand the point point of view, I'm just trying to give some balance, and point out that the black/white attitude this suggests is sometimes a clear indication that you are not cut out for a particular position.

</comment></comment></comment></comment></comment><comment><USER20> Am I the only one who thinks that this kind of design question is the new "how many gas stations are there in Manhattan?"

In both cases, the point isn't to get the right answer, but (allegedly) to see how the person thinks. With the estimation question, the trick is to make up some plausible-ish numbers and then multiply and/or add them to get a plausible-ish result. If someone's seen one of those before, they'll nail it for sure. If not, it's a crapshoot. In theory, you're measuring whether or not someone's able to reason well enough to spontaneously estimate something off the top of their head, but comparing the number of people who've seen those question before vs. the number of people who can answer that type of question without having ever seen it before, what you're really filtering for is people who have heard of or seen Fermi questions.

A while back, someone's interviewing experience got posted to HN and they mentioned that they got asked to design a URL shortening service maybe five times. They failed it the first couple of times and got progressively better each time. I doubt the interviewers meant to measure whether or not this person had done enough interviews to catch on to the style of questions that are currently trendy, but that's what they actually measured.

I think the most common objection to this is that the point of these questions is to drill down and figure out how the person really thinks, but in empirical studies on interviewing, they find the actual evaluation of chatty questions like this is heavily influenced by all kinds of biases. Techniques that have more clear-cut evaluation criteria, like work sample tests, and even completely non-technical interviews like behavioral interviews end up being better filters. Even then, the filtering isn't "good" (IIRC, the last time I read one of those studies, work sample tests score the best, and had a correlation of around .5 with an ideal filter), but it's better.

For these kinds of questions, even if you haven't seen the specific question before, there's all sorts of interview gamesmanship that helps tremendously. One thing in the blog post, not spending an hour on requirements gathering, is an example of that. In real life, if you're going to write an application from scratch, spending more than an hour on requirements gathering is perfectly reasonable for a lot of problem domains. But if you're playing the interview game, you know that you have, at most, an hour to sketch out the entire problem, so you have to cut the requirements gathering phase short (but not too short). The post mentions that this gets at real skills. That's true. It does. The problem is that everyone who's seen this kind of question five times is going to be good enough at the interview gamesmanship that they don't need to have good real skills to breeze through the "don't spend too long talking about requirements" sub-filter.

<comment><USER21> The paradox is that the best programmers tend to be the worst at interviewing (because they usually get hired quickly) and the worst programmers gradually get better at interviewing (after doing lots of them).

</comment></comment><comment><USER22> I don't have been to coding interviews recently but is this what it is like these days? How long do these questions generally take to complete? When I hear white boards, UML diagrams and OO-design I am thinking about investing at least a few hours.

Back in my day there were no interviews like these. You just dropped your CV, had a chat with the guy and if it clicked you got a contract with a month on (paid) trial. When I hear things like this I am thinking about all the people who are investing an (unpaid) day (sometimes even recurring interviews, what!) solving questionnaires with no real context during the job.

Is it really this bad?

<comment><USER23> Paid trials also work (for example, I was a contract-to-hire at my current job).

But many people don't want to leave the security of their current job for a temporary contract, so you would need to spend more time vetting those candidates.

<comment><USER24> New Zealand has this law, in which new jobs have a 3 month 'trial period'. (unless specified otherwise in the contract). So if someone's hired and it's clear they cannot code or interact well with the team they can be let go as long as it's within that 3 month period.

Personally... I don't like it. But I do understand the logic, and how it helps businesses from making expensive mistakes in regards to hiring.

</comment></comment></comment><comment><USER25> I just spent a few months interviewing developers in all career stages. I ask a problem in a similar vein that's designed to get both of us up in front of the whiteboard working out the design of a problem together. In those 20+ interviews I've seen all kinds of answers to the problem, some bad, some ok, and some pretty good. I can learn a ton about you as a developer with this question. And almost without fail the candidate ends the interview with something along the lines of "that was a fun problem to work on".

I combine that problem with developng a simple end to end feature together and the combination of that with a high level design problem turns out to be a really good indicator of how someone actually performs on the job.

</comment><comment><AUTHOR> Probably should have checked before posting...this was discussed 4 years ago: [https://news.ycombinator.com/item?id=2062889](https://news.ycombinator.com/item?id=2062889) (so I guess it's eligible for re-discussion)

I stumbled across it doing a Google search for "interview question elevator design"...I haven't been asked in a technical interview about how I would implement the logic for an elevator controller, but I heard about the question second-hand at a college job fair...and since then, I still think about that question. In fact, I think I've thought about it almost every time I've ever waited for an elevator in New York (that, and the story of the poor woman who was crushed while stepping into an upward-shooting elevator in Midtown a few years ago)...so...4 times a day, times 6 years...and I still haven't come up with enough optimal algorithms to cover all the edge cases and scenarios that I come across :)

The Monopoly question that the OP mentions is good, but I think is a bit problematic since not everyone has played Monopoly. And not everyone is familiar even with the standard rules. But everyone's been in an elevator before, and virtually no one thinks about how complicated an elevator's operation might be: it's one of those incredible, life-changing inventions that you take for granted after the first time you've pressed a button. So I think it's great material for an open-ended technical question.

The single-elevator logic is convoluted enough: If the elevator is going from bottom floor to 10th floor, obviously it should stop if someone on the 5th floor signals their intention to go up. But what if, after the 1st floor door closes and the elevator starts moving, a 2nd-floor person wants to go up? What's the cutoff in last-second button pushes to prevent the elevator from too abruptly stopping?

And of course, the more complicated logic is if someone on the 5th floor press _Down_ while the elevator is heading up. Then you have to implement a queue system. But simple FIFO may not be efficient...if the elevator is moving up, and someone on the 5th floor presses _Down_ , and then, someone on the 7th floor also presses _Down_...it would seem that the elevator should stop at the 7th floor first, on its way down.

And then things get really complicated with even just one more elevator, particularly with race conditions. If both elevators are moving up, and a 5th floor signal for "Down" is followed by a 7th floor signal for "Down"...ideally, the first elevator to finish its _Up_ job will take the 7th floor...Should it also take the 5th floor _Down_ job? Or let the other elevator handle that? And should that decision change if the 7th floor person signals their intention to go to the 4th floor, whereas the 5th floor person most likely just wants to go to the bottom floor?

Beyond the interruption/queuing logic, there's a lot of interesting discussion about how the elevators should be positioned during idle time. Presumably, they should return to ground floor in the mornings, and stay near the top (or at least midway) during the beginning of lunch, and the end of the day.

What I like about the elevator question is that elevator algorithms are their own science. But a lot of the complexity can be realized just by taking the time to think about all the scenarios you've encountered as an elevator user. And so given the typical technical interview situation, it's a good test of the candidate's reflection, ability to ask questions of the requirements, the ability to apply heuristics for good non-optimal solutions, and the ability to not let edge-cases dominate the thinking.

<comment><USER26> I lived in a building (6 floors) where the elevator appeared to be always in one of four states: Door opened, going to floor n, waiting for input inside elevator, waiting for input from anybody. It only remembers a single floor - where it's going now. Once it goes into the input state, it's a race among everybody who wants to take the elevator to push the buttons.

I was never quite sure whether the 'waiting for input inside elevator' actually existed, because every once in a while the elevator would get summoned by someone else before I could give it a destination when inside.

I guess this is a bit off-topic, it's just to say that even very simple logic can solve the problem, in a possibly infuriating way. ;)

<comment><USER27> Yeah I'm pretty sure the elevator, at least that old one, doesn't know if you're in it, though more modern ones will open the door as you walk up.

</comment></comment></comment><comment><USER28> I ask a JavaScript developer to debug a small problem and then come up with functional approach to solve it. Makes for good step by step exploration. Each step can be expressed in single English sentence and then coded directly into JavaScript. Much more precise than designing OO hierarchy.

[http://bahmutov.calepin.co/functional-javascript- interview-q...](http://bahmutov.calepin.co/functional-javascript-interview- question.html)

<comment><USER29> Designing a system architecture (Monopoly question) and solving a practical coding problem are different skillsets, so ideally you would ask the interviewee both types of questions.

</comment></comment><comment><USER30> related: [https://news.ycombinator.com/item?id=8399767](https://news.ycombinator.com/item?id=8399767)

actual blog: [http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/M...](http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/Making_FastPaced_Multiplayer_Networked_Games_is_Hard.php)

</comment><comment><USER31> I beg to differ, Monopoly can be done using 'simplistic' object design. An array is the monopoly map, a user is an object and the bank is a singleton. Done.

<comment><USER22> supsep, you are a great candidate but unfortunately you don't seem that great of a fit for our Abstract Enterprise Java culture. I am sure there are a lot of other companies who adhere to your mindset!

<comment><USER32> true, some of us prefer real money (enterprise money) and some startup options (monopoly money). Go figure which one will feed you :-)</comment></comment></comment>


Symphony CMS 2.2.5 released - <AUTHOR> http://symphony-cms.com/discuss/blog/entry/announcing-symphony-225/ A bug fix release for the PHP/MySQL based, XSLT-powered open source content management system <comment><USER2> it's been awhile since I've done much with PHP,so I thought this was __symfony __...are these two CMS/frameworks related?<http://www.symfony-project.org/>

<comment><USER3> These two are regularly confused due to their unfortunately similar spelling. SymPHony is the CMS, SymFony is the completely unrelated framework (capitalisations for emphasis only).</comment></comment>


Just one QUIC bit - <AUTHOR> https://blog.apnic.net/2018/03/28/just-one-quic-bit/ <comment><USER2> I was in the IETF meeting. It was actually a very civil discussion, and I think almost everyone in the room could see both sides on the issue. On the one hand, we've seen increasing problems with middleboxes making assumptions about end-to-end protocols, and this making it very hard to then deploy new end-to-end functionality. The problem is real; we measured this effect in this paper:

[http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend- tcp.p...](http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/extend-tcp.pdf)

Indeed, one of the changes the IETF group has made since taking on QUIC is to also encrypt the QUIC sequence numbers, so middleboxes can't play silly games by observing them (they were already integrity protected).

However, the flip side is that network operators do use observations of network round trip time gained from passive observation of traffic so as to discover if traffic is seeing excessive queuing somewhere. An inability to do this with QUIC may either lead to worse network behaviour, or to them using other methods to gain insight. If you're in a location where you can observe both directions of a flow, you can easily do this by, for example, delaying a bunch of packets by 200ms, then letting them go. When you see a burst of (encrypted) ack packets return, you can deduce the RTT from your observation point to the destination. I'd really like to avoid operators thinking they need to do such hacks just to measure RTT, and the spin bit lets a passive observer see the RTT.

In the end, I was not convinced entirely by either argument, and neither was the consensus in the room. It's not a clear-cut decision; there are reasonable arguments either way. Such is engineering.

<comment><USER3> Realistically, are network operators going to add artificial delay to packets going through their network? If they don't get their bit, and they start slowing down communication, it would seem like market correction would solve it.

<comment><USER4> Sarcastically: who will even notice a 200ms hiccup, nowadays, given the enormous waste of time that everybody shoves into their Javascript ad networks.

Personally, I don't want them to expose _anything_. The RTT on my packets is yet another piece of metadata capable of being abused.

In addition, I hope that the whole QUIC thing is a nice reboot of actually getting end-to-end connectivity back on the Internet so we can get some protocol experimentation moving again.

<comment><USER5> That's 200ms that could be used loading more tracking scripts.

</comment></comment></comment></comment><comment><USER6> Middleboxes have been tampering with packets and headers for way too long. It's most definitely time to move back control to the two ends of the connection, to avoid fossilisation and the same mistakes made in the past. IPv6 and QUIC are a cardinal step in this direction, and we cannot afford to let myopic decisions screw up the opportunity to fix what has been broken for so long.

<comment><USER7> "Who needs Firewalls and NAT," he loudly declares while kicking down the walls of the house to expose himself to the natural elements.

</comment></comment><comment><USER3> If you give an engineer a bit:

[https://mailarchive.ietf.org/arch/msg/quic/yQfBIAOnUEKIWjZhF...](https://mailarchive.ietf.org/arch/msg/quic/yQfBIAOnUEKIWjZhFW8CYPOcEKc)

You can kind of see how this might get out of hand and cause the discuss to digress and go in circles.

</comment><comment><USER8> There are still environments where active policies described by network operators to manage traffic flows is _required_ for users to make any productive use of the network ... I used to work on research ships — 50 people at sea for months at a time with satellite internet having only 256kbps (800ms latency).

It was abysmal to watch as over time everyone became completely dependent on internet connectivity for their computing needs as all services moved to the cloud. Trying to provide a useable internet experience in that context involved blocking as much as we could that users machines were doing (usually without their awareness) in the background that simply couldn't happen from that network — making the trade offs to try and select for things that _could_ work was a huge challenge.

It seems like QUIC offers better fundamental performance primitives but no way to solve for protecting users from themselves in this kind of environment ...

<comment><USER9> The"correct" answer there is probably to make the network limits explicit, by explicitly requiring a proxy server or organization CA installed in the client. QUIC should still work with middleware that actually terminates the connection instead of meddling from outside.

<comment><USER10> Sounds like Android at least can be told via DHCP it's on a metered connection:

[https://www.reddit.com/r/networking/comments/4wk4rw/dhcp_opt...](https://www.reddit.com/r/networking/comments/4wk4rw/dhcp_option_to_signal_metered_connection/)

</comment></comment></comment><comment><USER11> My takeaway from the meeting was that it isn't clear that the spin bit is actually useful. Leaving aside the arguments that RTT shouldn't be exposed (it is anyway, with the handshake): does the spin bit actually provide useful information?

It seems to be a fairweather metric: OK resolution when the network is operating normally, but providing no useful information when something has gone wrong (which is when you'd want it most).

</comment><comment><USER12> Nice. I especially like this bit: "Sometimes difficult choices admit to no sensible compromise between them and the process simply has to make a contentious decision one way or the other. While individuals make such decisions all the time, the collective process that enlists a large group of diverse perspectives, interests and motivations finds such decision making extraordinarily challenging."

</comment><comment><USER13> > The client echoes the complement of the last seen bit when sending packets > to the server.

Since neither the client or server care about this big, there doesn't appear to be anything that forces the client to actually implement this behavior. The client could always set it to 0 or even set it (pseudo-)randomly on each packet.

The bit shouldn't exist, but if the IETF did add it to the standard, would hostile middleware boxen actually start drooping packets if they don't see the "spin bit" change?

<comment><USER14> This was my first thought as well. I would love to see the reaction from the pro-spin-bit camp if Google announced that Chrome will never set the spin bit.

</comment></comment><comment><USER15> As someone only superficially familiar with networking, I think it would be interesting to know what impact the current packet inspection practices by the middleboxes have on network performance. After all, the article mentions that those middleboxes want to control the message flow and use that as justification. The assumption behind QUIC seems to be that there's no "global" benefit in that specific kind of network management and that it's mostly selfish interests of local network operators that motivate messing with the packets?

Basically, what are the incentives of the middleboxes to inspect packages and what do they really stand to lose?

<comment><USER16> > interesting to know what impact the current packet inspection practices by > the middleboxes have on network performance.

well, all (almost ?) current boxes can do that at line rate for minimal sized packets.

> incentives of the middleboxes to inspect packages(sic)

incentive is for charging / billing / steering packet flows etc.

<comment><USER15> I probably expressed that wrong, I was more wondering if the packet sniffing had any beneficial impact on the performance in the sense of QoS or congestion control or something like that. After all, they have to do it for a reason.

But your second points mentions it's for billing and such, so I guess that's my answer.

<comment><USER17> I don't think it's for billing most of the time. The middleboxes usually provide some kind of immediate benefit to the network, while breaking core networking assumptions and thus contributing to a weird form of technical debt.

</comment></comment></comment></comment><comment><USER18> The author states:

>"Many network operators use the IP and transport packet headers to perform traffic engineering functions, packet interception and forced proxy caching."

I'm guessing this referring to transparent hardware caches looking at Layer 7/HTTP headers?

And then:

"Various forms of middleware may reach into the TCP control fields and manipulate these values to modify session flow rates"

Does the author mean TCP flow control here? So there exists middleware which changes the ACK and RWND values in TCP headers? Does anyone know what middleware vendors do this? I'm guessing this might be done as as part of network "accelerator" hardware devices like Riverbed. Is this correct?

</comment><comment><USER19> I am not sure I understood the article to be honest.

Does QUIC encrypt the actual UDP packet (meaning from IP down, including the UDP header)? If that is the case it is not UDP anymore and there will be "problems" in getting to anywhere in the first place.

If it only encrypts the UDP payload, where does NAT come in? How would that be different from what TLS does over TCP?

Did I miss anything? Thanks.

<comment><USER20> The article only mentions NAT as a showcase of what IP packet parsing is used for. QUIC does not encrypt the UDP header.

TLS 1.3 actually run into a lot of issues due to network ossification. QUIC has been developed to bypass TCP's ossification problem and enable quicker iteration and deployment to improve latency, congestion mitigation etc.

You could argue that if QUIC's principles were in place for TCP/IP 20 years ago, middleboxes would not have made protocol revamps as difficult as they are today. Perhaps NAT would have never been developed and we'd all be on IPv6 already.

<comment><USER19> Thank you, though giving an example that does not even apply to the case is not the best approach when one wants to make a case :)

If it does not tamper with UDP I fail to recognise the issue though to be honest.

<comment><USER21> > If it does not tamper with UDP I fail to recognise the issue though to be > honest.

the problem is that if you expose _any_ kind of information in addition to just the IP and UDP headers, then _future_ middleboxes will start to use this information and will start dropping packets they can't parse.

If a QUIC packet is just random noise (aside of the UDP and IP headers), then a middlebox can't make assumptions about the inner workings of QUIC. It's a very common (but unfortunate) practice by "security" appliances to drop everything they don't understand because they treat that as potentially malicious.

Let me make a (hypothetical) example: Let's say QUIC packets had some publicly available "version" field. The implementation as it's used now is setting that to 1.

Now middleboxes start "gaining" support for QUIC and as "everybody" knows, the only widely deployed version is 1, so these middleboxes start to treat every other value of that field as a possible attack and drop such packets.

Now, years later, we want a new version of QUIC, but unfortunately, the most widely deployed (and never updated) middleboxes out there assume any version but 1 to be malicious.

Which leaves us with a "version" field that practically _has_ to be set to 1, so now we need another way to flag the new packets. Maybe a "real_version" field? Who knows? We'll have to try various things until the majority of the middle-boxes currently deployed are fooled.

Also, it will likely be impossible to fool them all, so even when we get around the majority of the boxes, we'll still exclude some people from being able to reach QUIC 2 servers. Sure - it will be a very small amount, but it won't be zero.

This isn't just theoretical. We had this problem just now with TLS 1.3. Since the beginning SSL and then TLS had version fields in order for clients and servers to negotiate the SSL version to use.

Unfortunately, because of precisely this problem, that field stopped being useable years ago where even the 1.2 negotiation had to happen using a workaround which then promptly also stopped working for 1.3.

By not exposing anything but random noise as part of a QUIC packet, the protocol designers aim to prevent this from happening. If all a "transparent" proxy sees is random noise, they can decide to not support QUIC at all or to support all of it. They can't decide on a "safe" subset and burn that into the internet for all eternity.

<comment><USER19> Thanks for the detailed response, but I am "with" you :).

The bit (no pun intended) I do not understand is why there is such a discussion in the first place? Why do they insist on a plaintext status bit?

Thats why I wondered if there was any encryption outside of the UDP payload.

<comment><USER21> The discussion about exposing the bit was to allow network administrators to detect retransmissions. The bit is supposed to flip constantly, if it doesn't, then retransmissions happen and thus something might be wrong with the network.

Because it's just one bit and it can have two values and both are valid and both values are seen with about the same frequency, a middlebox won't be able to just drop a packet if the value is either 0 or 1.

This is why there is even a discussion happening. It's felt to be reasonably safe to include to provide some actual value to tools.

The debate is though whether it's really safe and/or whether it provides enough value to go through the trouble.

If you ask me personally, in my professional life, I have been bitten by protocol ossification way more than by not being able to make sense out of a packet stream, so I personally would absolutely not expose anything.

But then again, I'm an application level developer and not a network administrator.

<comment><USER22> > The bit is supposed to flip constantly

> a middlebox won't be able to just drop a packet

You do know that someone somewhere is going to make a middlebox that just drops a packet unless that bit flipped in the precise sequence that the middlebox developer believed was the correct one, right?

Then someone proposes an enhancement to QUIC which happens to change the sequence of the flips (perhaps some multipath thing, or an enhancement in the way it treats reordered packets), and it breaks...

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> This proposal is a compromise. Wouldn't a specific metadata/heartbeat "packet", routinely dispatched by the involved parties, serve a better solution?

My personal stand is to prohibit exposing any metadata on the connection whatsoever, but given the counterarguments, I don't think the proposed solution is ideal.

<comment><USER24> >My personal stand is to prohibit exposing any metadata on the connection whatsoever

[https://grothoff.org/christian/habil.pdf](https://grothoff.org/christian/habil.pdf) Christian Grothoff - The GNUnet System [October 2017, 181 pages, PDF]

</comment></comment><comment><USER25> I disable QUIC in my network because I'm doing QoS at my router and utilize TCP flow control to slow things do to where I want them to be. QUIC makes the incorrect assumption that the network never wants to slowdown or to even allow for a configurable speed. Don't be too clever.

<comment><USER26> Just ruthlessly drop QUIC packets that are over the flow control limits. It will adapt.

Playing games with TCP settings is fun I guess, but simple RED with ECN and drop work well with fewer bad side-effects.

Every Internet protocol expects packet drops on overload. What was that about being too clever?

</comment></comment><comment><USER27> This idea of forbidding middlebox from messing up things sounds great. I have an honest question here though.

What stops a middle box from terminating all QUIC connections (and therefore get access to decrypted content)?

<comment><USER28> QUIC uses TLS, so it's pretty much the same situation as any other TLS connection.

Of course in a corporate environment you can trust the middlebox's CA on all the work machines. That's actually fine. What everyone seems to hate here is middleboxes that _don 't_ terminate connections and try to mess with them in other ways.

</comment></comment><comment><USER29> Again the solution is not to reimplement TCP on top of UDP but to make TCP like UDP:

[https://www.ietf.org/id/draft-add-ackfreq-to- tcp-00.txt](https://www.ietf.org/id/draft-add-ackfreq-to-tcp-00.txt)

<comment><USER30> A nice thing about the I-D system is that we don't have to waste RFC numbers on this sort of crank nonsense. Once upon a time the IETF would end up publishing this sort of thing as an RFC and then everybody would just ignore it, but that used up the numbers and short memorable numbers are nice, which was a shame. Now we can publish them as "drafts" which just quietly expire once their interest moves on to investigating which metal foils can be made into hats that best resist government mind control rays or whatever.

<comment><USER24> >to investigating which metal foils can be made into hats that best resist government mind control rays or whatever.

You joke, but Allan H. Frey already solved that in the 1960s, just add a 2"x2" wire mesh near the temples, over the temporal lobes. Blocks all RF interaction with the brain, no tin foil hat required.

...of course, this doesn't block 'mind control rays', the only thing it actually blocks consists of the Microwave auditory effect, and the only target audience for that consists of Radar techs walking around in front of hugeass antennas. ;)

<comment><USER31> > the only target audience for that consists of Radar techs walking around in > front of hugeass antennas

And perhaps US diplomats in Cuba.

</comment></comment></comment></comment><comment><USER32> What's even the point of this spin-bit thing? Of what use is an estimate of my roundtrip-time to intermediaries?

<comment><USER33> Network engineers can use it to monitor network performance.

<comment><USER34> Which they could presumably also do by injecting their own packets, not snooping on everyone else's?

<comment><USER33> I don't know, how would you inject packets into an encrypted end to end connection?

Passive observation of traffic is a useful network performance monitoring technique.

</comment></comment></comment></comment><comment><USER35> Just to make sure I understand this:

\- Google has been spearheading a protocol called 'QUIC'

\- It bypasses tradition TCP by using UDP to create it's own version of TCP but encrypts the data it sends

\- However it could be (is?) sending a bit and header that can make tracking the message path easier.

I would guess if that is true then and would not effect the performance the bit and header should be removed. I don't see what the fuss is about. Can't two different implementations exist along side each other and the public will choose the better one?

Correction: I misread the article and thought though spin bit was for an encryption key. Let this be a lesson to everyone: if you are going to comment at 2 am in the morning reread your article.

<comment><USER36> It doesn't make decrypting the message easier. It just exposes a bit of unencrypted information, that makes it possible to infer information like how the connection's round-trip time. And the argument is over whether exposing that information has value, and whether routers and other boxes in the middle will abuse that information.

</comment></comment><comment><USER37> IMO the article completely fails to describe the actual issue.

\- "Then there is the NAT function, where the 5-tuple of protocol, source and destination addresses and the source and destination port numbers is used as a lookup vector into a translation table, and both the IP and the inner transport packet headers are altered by the NAT before passing the packet onward."

Nice try, but if the outer layer is UDP, then NAT alters the UDP packet headers. The QUIC payload is never touched.

\- "Many network operators use the IP and transport packet headers to perform traffic engineering functions, packet interception and forced proxy caching. Various forms of middleware may reach into the TCP control fields and manipulate these values to modify session flow rates. All of these activities are commonplace, and some network operators see this as an essential part of their service."

I don't see why the people tasked with standardizing Internet protocols now have to make provisions for the jerks who literally break the Internet.

\- "This bit, the "spin bit" is intended to be used by passive observers on the network path to expose the round trip time of the connection. The management of the bit's value is simple: the server simply echoes the last seen value of the bit in all packets sent in this connection. The client echoes the complement of the last seen bit when sending packets to the server. The result is that when there is a continuous sequence of packets in each direction this spin bit is flipped between 0 and 1 in time intervals of one Round Trip Time (RTT). Not only is this RTT time signature visible at each end, but it is visible to any on-path observer as well."

I have literally no idea why a protocol should actively leak unnecessary information to a passive observer, and I have no idea what passive observers would do with the information they can deduce from this "spin bit". The payload is still encrypted, so you still can't do all the "traffic engineering, packet interception and forced proxy caching". As a passive observer you sit somewhere in the middle of the whole stream, and if you can even fish out the necessary packets (they might take different routes in each direction), you still don't know how far you are from the other end. Not even talking about the random processing delays at the server end. You're measuring garbage. How is this bit even useful for anything?

<comment><USER33> The point is that QUIC is supposed to be fully encrypted below the UDP layer. The question is why add bits in the clear on top of this to water it down and open an avenue for potential abuse.

<comment><USER38> Yes but it doesn't really say why anyone wants this spin bit. What are they going to do with it? Measure RTTs? Why? What for?

<comment><USER39> The currently top-voted comment in this thread explains it: [https://news.ycombinator.com/item?id=16696159](https://news.ycombinator.com/item?id=16696159)</comment></comment></comment></comment>


Exercism.io – Become a better programmer - <AUTHOR> http://educationware.net/exercism-io-become-a-better-programmer/ <comment><USER2> You know what'd be a cool website/application? A front end to all these 'learn-to-code' things. Like how Mint is a front end to multiple bank's websites I could have one account that interfaces into project euler, rosalind, exercism, etc grabs exercises and checks them.

</comment><comment><USER3> For anybody who wants to take a look at the types of exercises they have: all the exercises are on github [1]

[1] [https://github.com/exercism/x-common](https://github.com/exercism/x-common)

</comment><comment><USER4> exercism.io has been an amazing tool to improve my Ruby skills (I can't speak to any other languages yet) although it seems that nitpicks have become a bit on the light side lately.

I'd challenge anyone to pick a language they are semi-comfortable in or a brand new-language and do a month of exercism exercises, refactoring as you get comments, and then moving onto the next exercise.

Even 15 minutes of code practice a day goes a long way.

<comment><USER4> and I should say, don't forget to critique your peers' code as well (gently and respectfully) as the site points out, reading and critiquing code is just as useful practice in getting better at coding as writing code.

</comment></comment><comment><USER5> I practically learned Swift by doing the first available exercises. (12 or so) when I ran out of exercises I started to implement new ones by taking the test cases from the ruby track (most similar to Apple's XCTest). Check out the available tracks [http://synopsis.exercism.io/](http://synopsis.exercism.io/) Next I am exited about practicing Rust!

</comment><comment><USER6> What is up with this blog spam? Especially with that link to yet another bookmarking site at the bottom...

</comment><comment><USER7> Download some blob from the internet, then run it?

No, thanks

<comment><USER8> Fair enough. You can also build the binary yourself, since it's all open source. [https://github.com/exercism/cli/releases](https://github.com/exercism/cli/releases)

<comment><USER7> Looks like it just downloads/uploads plain data to the web service. I thought that in this age of internet technologies a web site would be enough.

<comment><USER9> What about curl, wget, httpie?

Or how about lynx or w3m?

Plenty of people want to utilize CLIs and it's definitely beneficial when learning to program to get as much experience on a command line as possible.

<comment><USER3> Yes, but what's the value in this website having a dedicated application that I either have to trust blindly or evaluate and compile?

We already have this great sandboxed environment called a browser for running untrusted code from the internet. They could still offer endpoints for curl, if it's just about using the command line.

</comment></comment></comment></comment></comment><comment><USER10> Extremely confusing website, are the exercises somewhere on the website or do I need to download an application or are the exercises on Github or what?

The screenshots make it look like CodeAcademy with messages/comments, but I can't find the exercises anywhere.

<comment><USER11> If you're just interested in the exercises without all the code review shenanigans that the site + CLI tool offer, they're all available on [https://github.com/exercism](https://github.com/exercism) (all the ones named `x$language`).

</comment></comment><comment><USER12> You know, at first I found this was really good, but after trying it for a little I just completely forgot about it. Is it as good as everyone says? From the comments so far it makes me want to try it out again.

<comment><USER13> I really enjoyed it. It was pretty fun to see everyone else's submissions and read their comments. I also like the command-line interface. No GUI or web garbage to muck with to fetch or submit exercises.

</comment></comment><comment><USER14> When I saw that you expected users to join with their GitHub accounts, I assumed that the exercises would be made available on GitHub and the submissions would also happen through GitHub (on a user specified repo).

<comment><USER15> You can find the exercises on GitHub (see [https://github.com/exercism/xhaskell](https://github.com/exercism/xhaskell) for example). They have their own workflow for the review process ("nitpicks" and "iterations") which _could_ be grafted onto GitHub issues and pull requests, but it's not necessary and might just make beginners more self conscious about their stuff being open to anyone on GitHub.

</comment></comment><comment><USER16> whats the purpose of a desktop app for this?

<comment><USER8> The CLI is easier to integrate into a normal development workflow, than clicking buttons, dragging files, or copy/pasting code to get the code into the browser.

I guess this supposes that "normal" means somewhere near the command-line, which might not be true for all developers.</comment></comment>


Ask HN: Have you switched from a MacBook to a Linux laptop? - <AUTHOR> If so, how's the trackpad? Which laptop did you switch to? Are you happy with the switch? I love the trackpad on my Mac, and have yet to find anything else remotely as good. I can't stand the keyboard or touch bar. I'd love to find a Linux laptop that: has a good trackpad, good keyboard, and 5k external monitor support. <comment><USER2> Switched to Dell XPS 15 from Macbook because I can't justify the value of Macbook Pro anymore.

It's a solid machine. Extendable. 4k OLED display.

The downside is definitely the quality of Trackpad and Keyboard. Apple has figured out that part relatively well.

<comment><USER3> > Apple has figured out that part relatively well.

I'm assuming this is not referring to their Butterfly design? That was not a well working keyboard.

<comment><USER2> Yes.

</comment></comment></comment><comment> vi-mode I switched to Windows because of WSL and I am also 90% in WSL. Trackpad (Thinkpad) is very close to a Macbook. Keyboard is way better and 5k support is also good through TB3. Hidpi support on Linux is a mixed bag, they get slowly there but it's not as good as on a Mac or Windows => hence Windows with WSL, so I enjoy a real Linux console in a hidpi environment. Besides, the Windows systems feels more responsive than my Mac, typing, moving windows, etc.

</comment><comment><USER4> Call me cheapo but I use a $150 desktop that I then maxed out with 20 gigs of RAM and two GPUs. I never have to take my environment out of my house so I can't see the reason for even using a laptop seems like another thing to lose or get stolen compared to a desktop at home.

</comment><comment><USER5> Yes I did the switch. I'm a programmer so switch didn't cause any major problems for me. I'm using HUAWEI mate book. Trackpad is good no problem whatsoever. Only issue I always face with Ubuntu is it's audio volume. It's way lower than Mac or windows

</comment><comment><USER6> Ubuntu 19.10 on a late 2015 Macbook Pro is a dream.</comment>


Freeman Dyson: No Heat Death - <AUTHOR> http://www.kk.org/thetechnium/archives/2011/03/there_aint_no_h_1.php <comment><USER2> There are gaping and blindingly obvious holes in that summary, such as the one observed in the comments that suns are burning mass to be that hot and can not continue that way forever. Part of the heat death idea is the universe consisting of nothing but iron, black holes, and radiation, with the former eventually transitioning to radiation on sufficiently large scales through either proton decay or Hawking radiation, and a relatively brief burst of stars in the universe's youth doesn't do anything to remove that. But I do see an inkling of what could be a more robust idea in there, and Dyson is known to be a smart person who could not possibly have missed this, so I assume there's a more complete and sensible version of this argument somewhere. I'd love a link, if anyone knows where to find it.</comment>


Java finally open-sourced. Does anyone still care? - <AUTHOR> http://thestandard.com/news/2008/06/20/java-finally-open-sourced-does-anyone-still-care

<comment><USER2> Yes, lots of people care. Just because it's not trendy to program in java and it doesn't get as much hype as ruby/python/etc, doesn't mean it's irrelevant.

<comment><USER3> I agree. It's irritating how idiotic people get with languages. They go from "This is the bees knees! It can be used anywhere! It's the best thing since sliced bread", to "This is irrelevant now we have our new fad favourite language"

Why can't a language just be good at some things, and not others? Do we _need_ a grand unifying language that is great for everything?

If you want a reliable, scalable, bullet proof backend, java is still pretty hard to beat.

</comment></comment><comment><USER4> I thing Java took a wrong turn with 1.5 and especially 1.6. Introduced new complexities to the language, without adressing its main drawbacks: verbosity, and lack of proper closures, and functions being first class citizens

<comment><USER5> Java 7 should add closures. And in the mean time, most of the times you would be using closures, you can use anonymous inner classes.

<comment><USER6> Yeah, closures and anonymous inner classes would really redeem Java in the eyes of the masses.

Java is going, going, ...

<comment><USER7> i think what tomjen was referencing was that java already has anonymous inner classes.

<comment><USER6> I'm aware. I was trying to take a funny jab at Java and it didn't turn out so well.

</comment></comment></comment></comment></comment><comment><USER8> Could anyone elaborate on which sections of code weren't open sourced originally? That'd be interesting to hear.

<comment><USER9> In the Sun release in May of last year, it was something like 4-5% of the code and most of it had to do with graphics stuff: font & image rasterizing, etc. which makes sense. I think that's why most of the developers didn't care much one way or the other.

</comment></comment><comment><USER10> I've been moving from doing most of my server side work in PHP to doing as much as I can in Rhino. I'd have been more anxious about doing that if there hadn't been a clear path to openness for Java, and I'm glad to see it get there.

</comment><comment><USER11> I don't make or distribute java much these days but the fact that it's open- sourced means that java developers can start to expect most desktops to have it.

And only after what... 14 years? Good going Sun.

<comment><USER12> Not sure I follow you. Most desktops are some flavor of Windows, call it +90%. What piece of technology, not present previously, became ubiquitous on Windows once it was open sourced? Open sourcing java doesn't mean much for end users on the desktop, imo.

The commercial open sourcing of java will matter on the ecosystem and it's a good thing for java developers (which, despite HN demographics, there are still millions of). Particularly, when you consider the flaws of the JCP and Sun's control to this point.

Good going Sun indeed--stick to making awesome hardware.

<comment><USER11> Now that it's absolutely trivial to distribute, developers can count on the same code base everywhere. Kind of like how everyone can count on GCC.

I don't write much Java now but at one time I supported a database library on runtimes from sun, ibm, apple, microsoft and the blackdown guys. It was crazy. Java and Python have been around for about the same amount of time. Python has about 5 different VM implementations. According to <http://en.wikipedia.org/wiki/List_of_Java_virtual_machines> Java has _10 times_ that number.</comment></comment></comment>


Projbook, a way to resolve the documentation problem in C# - <AUTHOR> https://alaindefrance.wordpress.com/2016/03/18/the-documentation-problem/ <comment><USER2> If you are interested in feedback, Projbook might make a good "Show HN".

Guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

</comment><comment><USER3> random idea. dont use XML</comment>


240k a year Rio Tinto train drivers to be replaced by robots - <AUTHOR> http://www.smh.com.au/business/mining-and-resources/paid-like-surgeons-240k-a-year-rio-tinto-train-drivers-to-be-replaced-by-robots-20131003-2utlw.html

<comment><USER2> If it's done on a small scale, gradually and over a long enough time, it may be possible.

The depth of human oversight is something these articles rarely get into.

How many remote operators are there per train?

Are these operators former actual train operators or new staff?

What situations will these trains get into because of a lack of an experienced person able to "go and see" (Genchi Genbutsu / 現地現物)? Also, what knowledge dies after a couple generations of drivers have never manually driven a train, and then what skill/s or sensory intuition would they not be aware of which could have averted a future disaster? If a sensor or measurement for mething that turned out to be crucial wasn't thought of beforehand, there won't be a way to know something went wrong until later, when the damage may already have been done.</comment>


IOS versus Android: OS Footprint is not a Proxy for Application Footprint - <AUTHOR> http://expletiveinserted.com/2011/04/02/ios-versus-android-os-footprint-is-not-a-proxy-for-application-footprint/ <comment><USER2> The first two graphs are about the phone market, not the smartphone market. It's not clear that the author realises this.

Maybe it's a very subtle and sophisticated jab about how these kind of numbers are meaningless without proper analysis. On the other hand, they may have just been desperate to create any kind of graph that shows Apple's bar as bigger than the rest. The reasoning given for showing the second graph at all certainly supports that theory.

Strange, given their closing sentence: _"Please, lift your game. Go beyond grabbing the simplest number you can find and using it as the basis for useless, potentially misleading conclusions."_

</comment><comment><USER3> I thought this was going to be about memory usage.</comment>


Google - Ultimate Money Machine - <AUTHOR> http://www.readwriteweb.com/archives/google_the_ultimate_money_making_machine.php <comment><USER2> I believe that the Wii should be in that first Unlimited Demand/Limited Supply box. ;)</comment>


Elon Musk Has Already Started Boring That Tunnel He's Been Talking About - <AUTHOR> http://fortune.com/2017/02/06/elon-musk-tunnel-traffic-boring/ <comment><USER2> This is not news... [https://twitter.com/elonmusk/status/825205236956483585](https://twitter.com/elonmusk/status/825205236956483585) and [https://twitter.com/elonmusk/status/827720686911291392](https://twitter.com/elonmusk/status/827720686911291392)</comment>


A Brief History of Random Numbers - <AUTHOR> https://medium.com/@tashian/a-brief-history-of-random-numbers-9498737f5b6c#.278un418e <comment><USER2> A nice overview of different PRNGs and their properties and performance may be found at

[http://www.pcg-random.org/](http://www.pcg-random.org/)

</comment><comment><USER3> Collapsing rand() and /dev/random down to the same "good enough for everyday" category is probably a disservice.</comment>