Why Bezos' rocket is unprecedented–and worth taking seriously - <AUTHOR> http://arstechnica.com/science/2016/09/did-the-fourth-richest-human-just-tease-plans-to-colonize-the-moon/ <comment><USER2> Bezos' ambition is space manufacturing/mining, contrasted with Elon's dream of Mars colonization. It will be interesting to see how that affects the way things play out.

Elon's greatest contribution is to raise the bar for everyone else. I hope Bezos accomplishes great things in space too.

<comment><USER3> It's highly probable that if the space mining operation succeeds they will be an invaluable supplier for the Mars colonization project. It's much cheaper to transport materials from space to Mars than from Earth to Mars.

<comment><USER4> BTW I have ordered 100,000 tons of iron on prime.amazon.com.mars and it still in status "pending", they even didn't charge my SolarPay account.

<comment><USER3> I've heard they're having drone delivery problems because of unusual solar flare activity and probable sabotage from the AI running Uber Shuttle as protest against stricter limits on the sorts of cargo that service can carry.

Apparently the solar system government is damage that needs to be routed around.

</comment></comment></comment></comment><comment><USER5> Interesting that Bezos new rocket will be using Liquified Natural Gas, LNG. Cheap and I suspect inherently safer and eaiser to handle than Kerosene or Hydrogen, though slightly less energy dense. Safer because is same temp as Liquid Oxygen, SpaceX may I think have caused reliability problems for themselves using super cooled Oxygen.

<comment><USER6> In this context, I like this article from NASA that talks about Liquid Hydrogen as the fuel of choice for space exploration: [http://www.nasa.gov/content/liquid-hydrogen-the-fuel-of- choi...](http://www.nasa.gov/content/liquid-hydrogen-the-fuel-of-choice-for- space-exploration)

<comment><USER7> Yeah, reading that you would be surprised to learn that the lower stage of every launcher flying or in development doesn't use liquid hydrogen[1].

(1: OK Ariane 5/6 but most of the thrust is from solids)

<comment><USER8> >flying or in development

You've forgotten about ULA's Delta IV and Delta IV Heavy, NASA's SLS, and JAXA's H-IIA and H-IIB.

Delta IV Heavy is currently the most capable rocket in the world and uses liquid hydrogen throughout (no solid boosters).

</comment></comment></comment></comment><comment><USER9> I only wish Bezos success in this endeavor.

I had a chance to visit Johnson Space Center last summer and it was like a space lovers pilgrimage to witness the miracles of science and man.

The Saturn V is on display and it was so amazing taking it all in. It is massive. It is hard to imagine it can even leave the ground.

I took a few pictures (potato quality)

[http://imgur.com/a/hsr00](http://imgur.com/a/hsr00)

<comment><USER10> I grew up around JSC in the 90s and 2000s and driving by the Saturn was routine. It wasn't til 2 years ago that I actually bought a ticket, went in, and browsed the site with the Mercury, Gemini and Apollo rockets. (I know a tad bit about the space program, which is mountains more than most of the tourists there).

</comment></comment><comment><USER11> i really enjoy space movies, and i like the nasa missions of history and this excellent Blue Origin project. I wish i had studied orbital physics or something, and work at Blue Origin or the JPL. But, imagining the galactic history books of the future, I'm also at peace with the idea that the earth is the first and only home of humanity.

<comment><USER12> "Our remote descendants, safely arrayed on many worlds throughout the Solar System and beyond, will be unified by their common heritage, by their regard for their home planet, and by the knowledge that, whatever other life may be, the only humans in all the Universe come from Earth. They will gaze up and strain to find the blue dot in their skies. They will love it no less for its obscurity and fragility. They will marvel at how vulnerable the repository of all our potential once was, how perilous our infancy, how humble our beginnings, how many rivers we had to cross before we found our way." ~ Carl Sagan.

Bonus: with music [https://www.youtube.com/watch?v=oY59wZdCDo0](https://www.youtube.com/watch?v=oY59wZdCDo0)

<comment><USER13> I do like that quote ... but it did get me thinking about my own circumstances.

As someone who believes that we probably evolved/migrated out of Africa, I feel no unity or connection to that continent. I only really feel a connection for my home town (in Australia) where I was born (I've moved to a different state since then).

So I suspect, in the far future when we colonise many worlds, there won't actually be much of a connection.

<comment><USER14> I think this quote takes it sense when you consider it from a deeper perspective. "This is the place your *{great}-grandpa came from"

<comment> saiya-jin which... you can say about Africa too, just add enough "great-" words before

</comment></comment></comment></comment></comment><comment><USER15> An electromagnetic launcher seems to be the way to go. Why is everyone spending time on rockets?

<comment><USER16> An electromagnetic launcher isn't the way to go not from earth, especially if you want to put people into orbit.

Forget about the energy required, forget about the electromagnetic field and what it can do the payload even non-biological one.

An electromagnetic launcher is effectively a canon, calculate the acceleration needed to achieve orbital velocity not to mention escape velocity and you'll get to a point where you can't have anything surviving the launch. Not to mention that achieving Max-Q effectively on the launch pad is both the least effective thing you can do as well as the most dangerous one.

<comment><USER15> Acceleration over 200km will get you to orbit. The electricity required for a single launch is measured in US pennies.

An aerodynamic vehicle could be extremely safe; in the event of a failure, you could just glide back to the ground. The possibility of violent explosion would be practically non-existent.

<comment><USER17> LEO is -29.8 MJ/kg - -62.6 MJ/kg = 32.8 MJ/kg ([https://en.wikipedia.org/wiki/Orbital_speed#Tangential_veloc...](https://en.wikipedia.org/wiki/Orbital_speed#Tangential_velocities_at_altitude)) so one tonne is 32.8 GJ. At US$0.04/kWh (a common benchmark wholesale price for electrical energy in the US, usually stated as US$40/MWh) that works out to US$364, which is thirty-six thousand pennies.

What are you launching, a sparrow?

Also, doing it over only 200 km will require at least 16.7 gees. That's not survivable for people. (Or probably sparrows either.)

Calculations in units(1) format in case I got something wrong (should the delta-specific-energy really be 32.8 MJ/kg rather than, say, 24 to 30?):

        (-29.8 - -62.6) MJ/kg * 1 tonne * US$ 0.04 / kWh
        (-29.8 - -62.6) MJ/kg / 200 km / gravity

<comment><USER15>
        m=10,000kg
        a=90m/s^2
        vf=7500m/s
        vi=0

        F=ma
        W=Fd
        P=W(t^-1)

        t=(vf-vi)/a
        d=(vf-vi)^2/(2a)

        t=7500/90
         ~83.33s

        d=7500^2/180
         =312,500m

        F=10000(90)
         =900,000N

        W=900000(312,500)
         =281,250,000,000J

        P=90(281250000000)/7500
         =3,375,000,000W

         3,375,000kW * ((7500 / 90) / 3600 s/hr) = 78,125 kWh
         78,125 kWh * $0.04/kWh = $3,125 / launch

         10,000 kg/launch / 3,125 $/launch = 3.2 kg/$ = $0.3125/kg

Looks very close to your numbers. I maintain my claim.

<comment><USER18> _The electricity required for a single launch is measured in US pennies._

 _78,125 kWh x $0.04 /kWh = $3,125 / launch_

 _I maintain my claim._

The two claims above are incompatible.

<comment><USER15> $ is a unit of pennies

        $=100p

The calculation above was for a 10Mg payload. Payloads up to 3.2kg would cost under 100p under the same assumptions.

<comment><USER16> Your calculation is very very incorrect, not the math, but the concept you are missing too many variables.

The US navy actually is building railguns, their efficiency is very very low due to the resistance from inductance it seems that if we go the the equations for railguns your 200KM EM gun cannot be built.

Overall the US is designing a 64MJ railgun, this gun can't put anything into orbit, it will have a range of about 20 miles, the ship that is going to be equipped with it is going to have a 78MW power plant and while it can power a single rail gun it will not be able to power multiple ones. By the US Navy's own calculations it would require 28MW to launch a projectile at 32MJ which which means yeah.... these figures are all off by orders of magnitude.

It seems there is much more to railguns than classical mechanics.

<comment><USER15> I believe the barreled design to be fatally flawed. An earthquake or other disruption during launch could be catastrophic to the vehicle. Much better for the vehicle to ride next to the track; in failure scenarios, the vehicle can simply detach and glide back to earth.

Yes, it means you have to go through the atmosphere, but it doesn't take far to clear. That will effect the calculations some, but not much. What will really effect the calculations though, is the cost of electricity. Generation costs will surely drop below $0.04.

Further, transmission loss can be almost entirely mitigated by generating and supplying the required power on-track.

Launches in favorable conditions (moon and/or planet alignments) would probably make some launches even cheaper. Of course, if the launcher were operating continuously, the savings would be used up during unfavorable conditions.

<comment><USER17> You're suggesting that we should magnetically levitate the launch vehicle in free air above a track running along the ground? That seems like it makes the problem a lot harder — instead of having to push it through just the air between here and space, which is about ten tonnes per cross-sectional square meter, you're pushing it through another two or three hundred kilometers of air, which is about another 200 tonnes of air per square meter. You know that shroud of plasma surrounding a re-entering spacecraft? That's the power required to push an orbital-speed object through air — but in that case without even maintaining velocity, let alone rapidly accelerating, and in that case it's the rarefied air of the stratosphere. You're proposing to do that for the majority of the track. That seems like a bad idea.

Yes, generation costs will likely drop significantly below US$0.04/kWh eventually. But that's a Kardashev-Type-1 kind of event. Generating the power on-track may not turn out to be less expensive than long-distance transmission, because it depends on things like sunlight availability. Of the few suitable sites, most are pretty cloudy on one side.

No moon or planet alignments significantly reduce the energy barrier to get to orbit.

<comment><USER15> The track would not run along the ground. You'd want to get height as quickly as possible to minimize atmosphere and track length.

Originating somewhere around Mojave and launching towards Las Vegas could work.

Alternatively, you may want to launch over the ocean for safety reasons, but it seems like you may be subject to more weather concerns.

<comment><USER17> You don't want to run the track along the ground? Where then, on a dirigible at the mesopause as suggested in [http://postbiota.org/pipermail/tt/2011-August/009613.html](http://postbiota.org/pipermail/tt/2011-August/009613.html)?

<comment><USER15> Bouyant structures could be used, as well as wings, to suspend the track.

You can't run along the ground because you don't want to go too fast through atmosphere.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Makes me think of this other Ars story: [http://arstechnica.com/science/2016/09/we-love-spacex-and- we...](http://arstechnica.com/science/2016/09/we-love-spacex-and-we-hope-it- reaches-mars-but-we-spacex-to-focus/)

I'm glad these guys are making waves in getting stuff to space, but maybe they should focus on getting one or two people to LEO, which none of them have even tried to do yet, before they start thinking about colonizing other planets.

<comment><USER20> > but maybe they should focus on getting one or two people to LEO

That seems to be exactly what they're working on. The fact that they may have ambitions beyond that doesn't mean that they're not working on the immediate problems. They are not conflicting objectives.

Although if I was a private space-launch company, I don't know if I would really be working on man-rated spacecraft at all. It seems like too much risk. You can blow up a lot of unmanned payloads and nobody (other than your insurance carrier) will bat an eye; blow up a couple of astronauts and you're probably out of business. I'd want to stay in the cargo delivery business as long as possible, and leave the man-rated stuff to deep-pocketed governments, so that I could continue developing new propulsion systems without the necessary conservatism that a man-rated system requires.

<comment><USER21> Serious question: what will the tolerance be for loss of human lives when crewed flights start? While it's entirely different, government space programs have endured many [0].

[0] [https://en.wikipedia.org/wiki/List_of_spaceflight- related_ac...](https://en.wikipedia.org/wiki/List_of_spaceflight- related_accidents_and_incidents#Astronaut_fatalities_during_spaceflight)

</comment></comment></comment><comment><USER22> I really like this rocket because you can see with the naked eye that it is really stable. They designed powerful enough engines, good enough software to keep it very stable. When you watch a SpaceX landing it's like watching a sports event: you wish more than you are certain.

<comment><USER23> Your comparison isn't a proper one. The SpaceX landings that you're talking about are very, very different from the Blue Origin landings. Once Bezos starts putting things into orbit, then we can start comparing properly.

<comment><USER24> It's amazing to me that people don't understand this. Lumping all rocketry together is a rather grave mistake. Yes, it's all hard, yes they all can explode, but the current Blue Origin landings are the equivalent of tossing a dart and hitting a bullseye across the room, while the current SpaceX landings are tossing a dart, hitting a bullseye in the next room, where the board is strapped to a dog standing on a skateboard, and in the meantime having your dart deploy a second smaller dart that has it's own bullseye to hit. They're just not comparable at all.

I'm a fan of any company that wants to get people off this rock cheaply and safely, but Blue Origin has a long way to go to achieve what SpaceX is doing. I can't wait to see that thing fly though. :-D</comment></comment></comment>


How John Kasich Could End Up Picking the Next President - <AUTHOR> http://www.politico.com/magazine/story/2016/03/the-bizarre-130-year-old-law-that-could-determine-our-next-president-213645 <comment><USER2> Kasich is the last person you would want deciding this.</comment>


Steve Jobs wanted Sony VAIOs to run OS X - <AUTHOR> http://www.theverge.com/2014/2/5/5380832/sony-vaio-apple-os-x-steve-jobs-meeting-report/ <comment><USER2> 404\. Remove the last / from the URL.</comment>


Why is the education of a sushi chef so insanely long? - <AUTHOR> http://www.quora.com/Why-is-the-education-of-a-sushi-chef-so-insanely-long?share=1 <comment><USER2> Semi-related: "Jiro Dreams of Sushi", a excelent 90minute documentary movie about "Jiro", an 85-year-old sushi master is available on YouTube w/ english subs: [https://www.youtube.com/watch?v=GYN7p8dvr64](https://www.youtube.com/watch?v=GYN7p8dvr64)

Great watch, even if you never had sushi or don't like sushi. The extreme drive for perfection is admirable.

<comment><USER3> Yes, it's an excellent film. Makes you yearn for sushi, though you quickly realize that whatever sushi is in your vicinity, is not what you're actually craving; it's a taste of Jiro's mastery.

Apparently, Tampopo is in a similar vein (though fiction) [http://www.imdb.com/title/tt0092048/?ref_=fn_al_tt_9](http://www.imdb.com/title/tt0092048/?ref_=fn_al_tt_9)

<comment><USER4> Keep in mind that Sushi Jiro isn't even in the top 10 (or 20?) ranked places in Tokyo on tabelog, although the low reviews might be since Jiro is so rude to everyone who comes in, especially the foreigners.

Sushi Sawada is a 3 Michelin star place in Tokyo run by a former truck driver who's studied for less than ten years.

[http://www.andyhayler.com/restaurant/sushi- sawada](http://www.andyhayler.com/restaurant/sushi-sawada)

</comment></comment></comment><comment><USER5> Well, you could accept at face-value the self-congratulating laudatory first answer... or you could look at how apprenticeships traditionally work, the low wages, concepts like hidden equity, and the sale of restaurants to successors.

<comment><USER6> "And Jacob served seven years for Rachel", a very old and instructive tale ...

</comment></comment><comment><USER7> Maybe I'm mistaken, but when I read stories of succesfull startups (aside from the usual startup porn), I keep hearing stories of people _who didn 't know_. Sure, they had ideas, intuition, a deep intuition about where the market was -- but they didn't really know.

So they tried experiments and learned. Then they did that some more. The constant refrain is intellectual humility and seeking to understand the people they are trying to help at a deep subconscious level.

Contrast this to the way I and many others think about various skills. We take a few classes, we play around and are able to achieve some simple level of competence. Somebody then gives us a certificate or other form of public "gold star". Then we feel like we know something.

Socrates was right: true wisdom comes from understanding how little you know and using all of your energy instead to concentrate on asking better questions.

<comment><USER8> When you don't know, the fastest way to learn is to find someone who _does_ know, and ask them.

If one sushi chef likes another chef's sushi, why doesn't the one just ask the other how to make it? Because of social reasons?

<comment><USER9> They probably do, but I also imagine that a lot of things just can't be taught and instead come from experience. For example, I used to train with an Olympic gold medalist in badminton, and he would tell me that the thing I really need to bring my playing to the next level is to be able to take risks and gamble by predicting what the opponent was going to do.

The theory made complete sense: you just need to be able to guess with hopefully high accuracy what they were going to do so that you could take advantage of it and it's fine because even if you are wrong sometimes you just still end up positive. Of course, the problem is you can't actually really assign probabilities to your guesses and you might have less than a second to decide what to do.

I imagine this is the same with making sushi. You might understand that if a fish is a certain way, you need to add more rice, or vice versa, but you can't just "measure" the fish and instead go off your intuition.

Honestly I don't know a thing about making sushi but the post described having to go off intuition, and it's just not something that can really be taught easily.

<comment><USER8> I can understand part of it is muscle memory, and part is experience in the space.

To compare with welding: Seasoned welders discuss heating and cooling a weld, pulling from top or bottom, dragging this molten liquid around the narrow crack between metal pieces, and how using different techniques can fine-tune a weld, making it easier to grind and make invisible.

From another angle, at 40 hours per week, it takes over 4.5 years to hit the mythical 10,000 hours. And so 5 years is usually a reasonable benchmark for mastery of any profession of tasks.

Probably at least some of this is marketing - an 8-year sushi chef is probably only marginally better than a 3rd year sushi chef, and most non-connoisseurs would have trouble telling the differences between their creations.

<comment><USER9> I both agree and disagree. I imagine most people could tell the difference between an 8th year and 3rd year sushi chef. 3 years seems like such a short amount of time for something as complex as making sushi.

On the other hand, I also can see that when people reach a very high level of skill, it may be difficult for normal people to really see the differences in skill. But I don't know if you can really say there's only a marginal difference.

After all, if one person is 10000 miles away and another is 11000 miles away, they both are so far away you can barely see them. Indeed, I imagine they may be so far away you can't tell how far apart they are, or even which one is farther! But the reality is that one of them is 10% farther than the other: hardly a marginal difference.

Still I do agree that non connoisseurs probably would have difficulty truly appreciating the difference in skill.

</comment></comment></comment></comment></comment><comment><USER10> Can a blinded panel pick out top quality sushi? I hear sommeliers can't do so for wine, often failing to do well even at identifying red versus white. My first cynical guess for why the education is so long is that customers will pay more for it, regardless of whether or not the product itself benefits. Then again, I barely eat sushi.

<comment><USER11> > _Can a blinded panel pick out top quality sushi?_

Since fish can vary from practically tasteless to overpowering, it probably depends on the type of fish. But I've seen people can eat sushi and tell you the exact temperature based on the flavor. Or what part of the ocean the fish came from based on the flavor. Those are pretty objective metrics.

Then there's also the whole "people end up in the hospital if you screw up". If you're a poor and unclean sushi chef, you _are_ going to make people sick eventually.

<comment><USER12> That sound impressive, unless they didn't actually prove their claim. Did someone have a thermometer to stick in the fish? Did someone have evidence the fish came from that part of the ocean? They are objective ONLY if they were actually measured.

</comment></comment></comment><comment><USER13> It's only "insane" by myopic Western/American standards. Look at the martial arts of Japan (Judo, Jujitsu) where to earn a black belt--which is traditionally not the end of learning but merely symbolizes understanding of the basics--takes at least 10 years of dedicated study. Since martial arts began to be "Americanized" in the ~1980s, we now see black belts handed out to 8 year old children after a year or two of study (in fairness, Tae Kwon Do is the more common offender in that regard).

<comment><USER14> It's insane because it covers a very narrow range of topics. We make people doctors after 8 years of study, only a few of which involve actual practice.

<comment><USER15> I'm not sure if you're referring to medical education in the United States.

If you are, individuals who ultimately care for patients must complete college (4 years), medical school (>4 years), and a residency program (3+ years).

Thus, training to be a physician in the US would require at least 11 years, of which at least five (the last five) would involve extensive patient contact.

<comment><USER16> technically, an undergrad degree isn't required, only a handful of courses

whether you'd actually get admitted without one is an exercise for the reader

<comment><USER15> I'm not aware of any accredited, MD-granting US medical school that don't require an undergraduate degree prior to matriculation - do you have examples?

There are accelerated bachelors+MD programs that high schoolers can apply to; these would shave off two years of overall training time. Notably, despite being accelerated programs, these grant a bachelors degree before program participants advance to medical school.

<comment><USER17> Technically, most US medical schools don't require an undergraduate degree. However, the amount of coursework required is so large (about 3 years) that it makes sense to do a little bit extra work and get the BS anyway. It's good to have a BS degree in case you don't get into medical school.

<comment><USER15> I'm still curious about specifics - can you link to a US, MD-granting institution that doesn't require an undergraduate degree?

EDIT: I'm aware that this used to be the case but I don't believe that any schools still allow this.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> _Kaz Matsune_ 's insights on the training of suchi chefs are very insightful: [http://www.quora.com/What-is-it-like-to-train-to-be-a- master...](http://www.quora.com/What-is-it-like-to-train-to-be-a-master-sushi- chef/answer/Kaz-Matsune-1)

I was also surprised to find out how difficult it was to make good sashimi: _Does a sashimi chef really need that much skill?_ [http://www.quora.com/Sushi/Does-a-sashimi-chef-really- need-t...](http://www.quora.com/Sushi/Does-a-sashimi-chef-really-need-that- much-skill)

</comment><comment><USER18> He explains things well generally, and then lists off a bunch of different examples, but I don't think we gets specific enough.

For example, he says, "I think my nigiri is still far from perfect: could use improvement to reach the perfect fish and rice balance with firmness and texture."

Why does this take years as opposed to taking standardized pieces of fish and testing by simply adding more or less rice to it. Why would this process take years?

I get what he's saying in general, that things can be infinitely improved, but why years and decades?

<comment><USER19> I completely agree. It's just a process. The people trying to say that it takes years are just glorifying old standards

<comment><AUTHOR> Today people are still buying _hand-made_ portrait paintings. They could easily spend x10 less and take a photo or hire a digital painter. However, they still choose the old, irrational way.

The process itself is the value. The years spent mastering the little things is the sacrifice that makes it valuable to the costumer. In return, the chef follows the path to _satori_ by sticking to his chosen _kata_ , the way. Japanese work ethic is deeply rooted in the zen tradition.

<comment><USER19> I get what you are saying, and I'm just thinking about it from the perspective of a blind taste test because that's honestly all I care about. Others may love the experience of a person making it beautifully but I'm fine with a robot banging out high quality sushi for me.

</comment></comment></comment></comment><comment><USER20> Languages all seem to lack the right word for it. "Mastery", "wisdom" etc. all don't seem to quite capture the essence of it.

I'm frequently glad for Heinlein's invention of the word "grok" to finally give a name to it. I just wish it was a prettier word.

<comment><USER6> There's [http://en.wikipedia.org/wiki/Epiphany_(feeling)](http://en.wikipedia.org/wiki/Epiphany_\(feeling\)) , although it's not a verb, and would probably be rather weirded if verbed.

(That page ends up referencing, among other things, [http://en.wikipedia.org/wiki/Satori](http://en.wikipedia.org/wiki/Satori) , which may go well with sushi.)

<comment><USER20> I think Satori is translated into English as "understanding in fullness".

'Grok' has always seemed to mean to me something kind of like this, where no further epiphanies are possible.

<comment><USER21> Except grok simply means to comprehend/understand something to the level of competence.

I've never heard of anyone using grok to mean something along the lines of "mastery".

<comment><USER22> For me it's somewhere in between 'competence' and 'mastery', but really slightly different from both. I suppose that's why the term exists separate from 'competence' and 'mastery'.

I'd say 'grok' generally means that you truly understand something in a fundamental way, rather than just being 'competent' or 'masterful' at that thing. It's a crucial step on the path to mastery, but mastery might still require a lot of practice.

I find 'Your problem with Vim is that you don't grok vi [1]' to be a classic example of proper usage. It explains fundamental principles of vim's 'grammar'. Once you've read and understood it, you 'grok' vim. But even though this knowledge is crucial in being a 'master', it does not make you one. That would require a lot of practice (in this particular case, for me, a few weeks).

I've had similar experiences with functional programming. There was a point, after much reading, where I felt that I truly 'grokked' the approach, but I'm still far away from being a master at functional programming. Old imperative habits die hard.

[1]:[http://stackoverflow.com/questions/1218390/what-is-your- most...](http://stackoverflow.com/questions/1218390/what-is-your-most- productive-shortcut-with-vim/1220118#1220118)

</comment></comment></comment></comment></comment><comment><USER23> Programming should be like this. When you're in your twenties thinking you know everything you should have have an old master slapping you on the writs telling you that even if you think you are - you actually are not ready building real systems yet. ;-)

<comment><AUTHOR> Older programmers may not know the latest hip language and frameworks, but are closer to the _essence_ of their craft. Past experiences open the mind to patterns and _ways of doing_ the 20yo code monkey can't quite conceive yet.

<comment><USER19> And 20 year olds have a perspective of the world that older generations can't appreciate. Who's to say which has more value?

We shouldn't glorify youth or age, just quality.

<comment><USER24> That may simply be because they know better ;-)

</comment></comment></comment></comment><comment><USER25> I wonder how much training sushi chefs had when it was first invented during the Edo period. Sushi then was a cheap fast food you ate with your hands, and for a long time only a part-time side business for chefs who worked with other foods.

</comment><comment><USER26> I'll stop short of a comparison between sushi mastery and programming but I recognise the feeling when the more advanced your skills, the further you recognise you are from (unattainable) perfection.

</comment><comment><USER27> Part of the Japanese culture is the achievement of perfection. One will never achieve perfection in art, such as making sushi, hence the paradox.

</comment><comment><USER28> People should see the "Bite of China" series: [https://www.youtube.com/watch?v=FRHNa9qdtlw](https://www.youtube.com/watch?v=FRHNa9qdtlw)

It contains plenty of examples of amazing craftsmanship.

</comment><comment><USER29> To be able to eat Fugu and still live to tell about it?</comment>


HN via RSS is annoying, this is how it should work - <AUTHOR>

I, like many folk here I'm guessing, read HN via RSS.
And, when I wanna click through on a story have this annoying experience whereby.
a. I click through 'comments' and then have to click to the main story and then back to read the comments (sucky)
b. I click on the main story element (all too often) and miss out on the comments here
I'm not suggesting iframes, or anything ;) Oh heck, I might be... but fundamentally I'd like to have one click which gets me to the story and then follows on with the HN comments.
Any chance? <comment><USER2> Your problem has nothing to do with RSS. I have it, too, reading HN in the "normal" manner. My solution is, when I go to a story, to open two tabs: one with the story and one with the HN comments. Then I can switch between them.

Still, I would welcome a more automatic solution, but I don't know what it would look like. (The comment by bmelton on the Digg bar is quite correct.)

</comment><comment><USER3> I don't think this is an RSS-specific issue. If you read Hacker News from the main page, you would experience the same workflow.

<comment><AUTHOR> Doesn't make it any less annoying ;)

It'd be nice to have a page + comments somehow.

<comment><USER4> You're looking for something like the Digg bar, basically. There are other implementations of the same sort of thing, but by and large, people tend to hate them.</comment></comment></comment>


Ask HN: Help me find older hacker news post - <AUTHOR>

I need help with finding one of the posts that was recently here on hacker news. Unfortunately I haven't saved it on time and now I need it for one of my projects.
It's a post about an archive of entire internet crawled and available for download. It's also offered as AWS image package. I just glanced through post initially and wanted to save it for later inspection but now I can't find it in any of my bookmarks.
I tried searching like crazy but it's possible that I am trying wrong keywords since I just barely looked at it at the time.
Can someone help me with this? <comment><USER2> [http://hn.algolia.com/#!/story/past_week/0/crawl](http://hn.algolia.com/#!/story/past_week/0/crawl)

</comment><comment><USER3> common crawl

<comment><AUTHOR> Thank you! That's the one.</comment></comment>


Ask HN: Who were your first 10 hires? - <AUTHOR> Curious what roles other startups hire for in the early stages. For example, at which point did you hire a full time designer? A full time DevOps guy?
I'll start. We're in seed stage (pre-revenue) and building a B2C app. We have a CEO/"business guy", a CTO/backend developer (myself) and a frontend developer. We're planning on hiring either a designer or another backend developer next.
What about you? <comment><USER2> As our company grew, so did the roles needed to keep it on the path. Initially it was just the CEO and CTO(me). Then came the CMO. That took us to 6 months and some solid revenue. Then we needed help with raising funds, so our first financier became our CFO. Then we needed help with growing a sales team so a Director of Sales came to being. And a year from that, after hitting 10MM Rev/Yr we need a COO to manage all the customer service issues.

</comment><comment><USER3> I think it depends on the business, care elaborating what kind of business it is? Currently its just CEO/Designer plus CTO (me) and a marketing person

</comment><comment><USER4> French Startup here, created in 2016. We're developing a SaaS software for e-commerce merchants. First we hired a back-end dev, then a full time graphic designer / illustrator, because we think it's crucial to have a strong visual identity.

<comment><USER5> > We're developing a SaaS software for e-commerce merchants.

Mind elaborating? That's exactly what our SaaS platform is. :)

<comment><USER4> We're working on a module for popular e-commerce platforms that will unify referral / customer loyalty and membership rewards!

</comment></comment></comment><comment><USER6> I'm not sure I would give myself a CTO title if I were a single backend developer in a company of 3. Seems a bit ridiculous.

<comment><USER7> But technically he /she is the chief technology officer

<comment><USER6> I guess you are right. But CTO is an executive-level position. It doesn't really make sense in a company of three where.

It's like me technically being a director of a company while working as a contractor.

It is technically true but when I get asked about my previous role at interview I'd say I was a software engineer / consultant, not director.

<comment><USER8> I agree with you. It sounds pretentious. Chief of what? Yourself? Chief by definition means chief of others also in a decision making position.

Founder is enough; Founder is a big enough title to encompass the challenge, struggle and reward doing something new, independent or fresh.

</comment></comment></comment></comment><comment><USER9> This varies widely between startups: we are an AI/ML (machine vision) company, so our first hires were 2 AI/ML developers, added 1 web dev (frontend) and 1 backend engineer to build our MVP. Now are a 15 strong team (added sales, customer success members later)</comment>


Coming Next: Using an App as Prescribed - <AUTHOR> http://www.nytimes.com/2012/08/20/technology/coming-next-doctors-prescribing-apps-to-patients.html?hp&pagewanted=all

<comment><USER2> Tbh i am pretty surprised we arent' already further along in this realm. I think the integration of apps in the medical world could have served some serious purpose a long time ago if health care professionals were more educated in tech world. They need to get with the times. It's costing money and lives!</comment>


The End of Microservices - <AUTHOR> http://lightstep.com/blog/the-end-of-microservices/ <comment><USER2> I'll tell you the real reason behind microservices: developer fiefdoms. "Faux- Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie.

It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolith"), that is composed of many different libraries that have well defined interfaces which can be tested in isolation. In fact, that's how most non-web software is still written and done.

The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase and enforce their control via separate repo's, and when speaking runtime, via authentication: Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance of her service that gives a guess at how long the car has to arrive to pick poor end user Bob up.

I've seen this same thing play out countless times at large tech companies and startups alike. It has nothing to do with building scalable, or more maintainable, or more cleverly designed applications. If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. Not to mention all the issues and headaches caused by fan out of tons of API requests, complicated caching scenarios, etc. I've seen the horror of microservices architecture where no one person is responsible for the actual app, only their "service".

There are a few exceptions where its useful to scale out parts of a distributed application, but in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control.

<comment><USER3> You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing!

I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, had to be deployed pretty much at the same time, and version upgrades had to go in lockstep. Every so often, database changes were necessary, and the world would grind to a halt for months to make the system still work after the migration: It was awful.

On top of this, having everyone using one stack really meant that a council of elders got to make tech decisions, and everyone else just did what they were told. This built a giant hierarchy. People near the top would never leave, because nowhere else would give them that much power. Talented developers would take years to gain influence, so they often just left. What remained was developers with no ambitions other than getting a paycheck... it was horrible.

The alternative was to let people maintain their own stacks, as long as they provided interfaces that other people could call. By limiting how much code could talk to a database, you didn't need negotiations to change something: Teams made any change they wanted as long as they remained backwards compatible, and then had to lobby users to upgrade to newest API versions if they wanted to remove the backwards compatibility mess. It was awesome in comparison.

A gigantic place won't have those problems, because they can invest money on making whatever tech decisions they made tenable: PHP is slow? Let's build a new runtime and compiler, says Facebook! If you are tiny, you don't need any of this BS, because if your team of 8 engineers can't agree, your company will fail regardless. But when you have 200 engineers, it's giving people more control over a piece of the pie or bleeding talent.

The one thing you still need to do is make sure teams have the right size, and people have enough accountability, that the product still works. You also need silly amounts of data marshaling and error checking compared to the monolith. But the terror of a company that can't hire engineers because the only way to have any control over your daily life is to have been there for 5 years is just hard to compare. When people say they don't want to work big corporate gigs, what they really mean is that monoliths become soul sucking.

So yes, I give thumbs up to fiefdoms, just like I'd rather have inefficiency in a republic vs a theoretically efficient dictatorship.

<comment><USER4> I really value your contribution, thanks for sharing.

I give the proponents/consultants credit for proposing a practical and incremental solution to these people instead of just insulting them or saying "you're doing it wrong".

That being said, the issue I have with microservices is the fact that the below is repeatedly used as a core technical argument :

> They had built the whose system using the classic, box-box-cylinder > architecture. There were hundreds of little top tier 'services', but in > practice, they all shared the same database, had to be deployed pretty much > at the same time, and version upgrades had to go in lockstep. Every so > often, database changes were necessary, and the world would grind to a halt > for months to make the system still work after the migration: It was awful.

This is not a feature of "monoliths", this is a feature of shortsighted design (at the beginning) and cowboy design (at the end).

Let's be clear : apart for load balancing for performance critical areas (which only exist in 20% of the applications, and only cover 1% of a typical such application - or 60% if you are Google, Facebook, or Amazon or the rest of the top 10), there's nothing that microservices do better than in-memory libraries. Also, centralizing everything as opposed to having processes run on various servers creates the issue of the single point of a failure. Whole new classes of similar issues appear. It basically is buying troubles.

Adding microservices will never be a neutral operation, and incurs a real cost. This cost is the cost of distributed objects which has been known for over 20 years and has been well-documented by our fathers.

Once the above has been dismantled, it then comes to : "yes but teams can develop in different languages", "yes but dependency management becomes easier". But once again, when it comes these interoperability considerations, a solution also exists and has been created about 15 years ago. This solution is called .NET (30+ languages compiling to a single Intermediate Language, COM components, first-class library support, etc...). Even the "yes but I need to communicate with non .NET in-memory applications" is very maturely addressed by the framework. (it was one of the first-use cases addressed)

I also read in this thread : "the ability of teams to control their own destiny and not be blocked by other teams". With libraries teams can choose the version that works best for them, and a well-design in-house library would provide the extension points (Dependency Injection, Dynamic Binding...) that would allow the clients (the other teams) to specialize the behavior.

So in a gist, my main reproach for this, is that if people put the same effort they put in learning microservices to learning system and component design, they wouldn't even be a need to talk about the former. My regret is that people will always choose the hype and the new. But hey, that's how the game works.

<comment><USER5> The discussion about monoliths vs. microservices reminds me about Knuth's 10+pages of Pascal code vs. McIlroy's 6-command shell pipeline [http://www.leancrew.com/all-this/2011/12/more-shell-less- egg...](http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/)

</comment></comment></comment></comment><comment><USER6> I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it.

A core principle which a lot of people and articles ignore, though, is _reusability_. I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it.

Essentially, you build out the backend to act as a library for your front end. So we have login, storage, analytics, reporting, logging, data integrations, various forms of messaging, business-structural stuff, etc. etc. all bundled up as separate services. The front ends just use these services to build a coherent product. The front end is the monolith: The microservices are the cloud.

For example, let's say I wanted to create a new product called "Hacker News". I'd use our storage service to store links and comments. I'd use the login service to let users log in. I'd use our messaging service to send notifications about things like verifying your email or send password resets. I'd use our analytics backend to emit events for reporting. And so on. I could easily build the whole thing without writing a single line of backend code, and without setting up a new cluster, because every backend service has been designed with multitenancy from the start.

This ability to piggyback on a platform of services where I think the real utility of microservices lies. Everything else — fine-grained scalability, smaller surface for tests, language-independence, swappable implementations, etc. etc. — are secondary to that.

<comment><USER7> You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?

<comment><USER8> I also don't see how microservices are more reusable.

However, the _replacability_ is usually much better due to being forced to define sharp boundaries with clear interfaces.

<comment><USER9> But that is the thing.

It just means that instead of using the language features and creating clean interfaces across modules, they were witting spaghetti code.

With microservices they get to write spaghetti REST calls with the added fun of distributed computing failures.

</comment></comment></comment></comment><comment><USER10> Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom.

Don't get me wrong, a service-oriented architecture is the only thing that scales to large companies. Once you get to dozens of engineers and millions of lines of code you will inevitably need to have an SOA because Conway's law. Also, there is a learning curve to building microservices which improved tooling really helps with.

However the thing that really grates at me is how these articles say things like:

> _Services are now an everyday, every-developer way of thinking_

With nary a mention of the overhead. There is no way around it, distributed systems have an irreducible complexity no matter how good your tooling and boilerplate is. You have to put in extra work to decouple everything and handle failure in a way that actually reap the benefits of the distributed system. And in the end, what these articles always gloss over is the interface between these systems. If you can easily define an interface between systems that stays relatively stable as the service evolves, then congratulations, you have a good candidate for a service with minimal overhead. But for most applications, those interfaces are shifting all the time, and there is no better tooling than multiple logical services running within one binary and build system where _integration testing and validation is cheap_. This is a real fucking problem people, it's not going to go away because there's a couple billion dollars worth of venture-backed startups ready to blow their cash on you in the vain and most likely misplaced hope that they are actually going to _have to_ scale to dozens of engineers. Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now.

<comment><USER11> Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat out of reach, but that's the direction things are trending towards.

I also get the sense that a lot of purists moulded in the ways of yore are alarmed at the waning relevance of their skillset. This to me seems like a bigger problem than the evolution of software paradigms.

<comment><USER10> Oh yeah, I don't think it's bad research going into this. I mean I've been writing software professionally for almost 20 years now and I am super excited about (for example) containerization and other trendy areas. I think it's _great_ that people are pushing the boundaries of SOAs, and I think microservice is a good term describing _how_ the boundaries are being pushed. We will all benefit from the improved tooling and experience gained.

My only complaint is this ostrich mentality of declaring ubiquity and ignoring the downsides and unsuitable cases. I suppose drinking the koolaid might be necessary to really buy in and push the paradigm forward, but sometimes it feels like willful ignorance.

<comment><USER11> I agree completely. I may simply have had the luxury of so far working in environments wherein software fads aren't hailed as Swiss-Army panaceas. Here's to hoping my track record doesn't ever trend Dilbertesque :)

<comment><USER10> Me too. At this point in my career I've worked very closely with more than 100 programmers for long periods of time, and only one of them would I classify as being overly interested in fads. To the contrary, I give a ton of credit to the vast majority of programmers as always being pragmatic about the problem at hand.

I think the problem lies more in the PR, advocacy and conference circuits where there's an incentive and agenda to present things as silver bullets. It mirrors a greater problem in public discourse that everything has become so polarized that nuanced debate is drowned out by noisy, confident blowhards.

<comment><USER11> "The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt." (Bertrand Russell)

Back when I was still an employee, I strove to take a more intermediate tact that let me be more vocal about technical direction. What's surprising is how willingly people with authority will listen to what you have to say, once they realize you know what you're doing. I've also been fortunate to have had roles that enabled that in the first place. And now I'm trying my hand at entrepreneurship, which feels practically utopian :)

</comment></comment></comment></comment></comment></comment><comment><USER12> One thing I don't like about SOA is that an error does not have a full stack trace. I know Zipkin exists but it's nowhere close to what we had in a monolithic app where you could just put a breakpoint and trace back to where exactly an error is thrown.

If we can find a way of running a giant monolithic app in development and production environment without vertically scaling our machines, I would rather have that.

Every bug I'm working on is like a mystery that I have to hop to many services to find what's going.

I also think HTTP is the worst protocol for apps to talk to each other.

<comment><USER13> What's wrong with HTTP? If you're going to build an RPC protocol, you are going to need encryption, stream multiplexing, a way to distinguish RPC methods, support for extensions (e.g. auth), and compression.

Add the fact that high performance HTTP servers and clients exist in most languages, and building an RPC protocol on top of HTTP sounds pretty attractive. No wonder gRPC did exactly that.

<comment><USER14> Tons of round trip calls potentially in most RPC-style systems are one start, which Cap'n Proto addresses with its unique style of avoiding round-trips for many network transactions which can drastically reduce network chatter. Security is addressed simultaneously (but not necessarily sufficiently for many people or regulatory bodies) in Cap'n Proto at least via use of capabilities instead of building it into transport layers.

</comment></comment></comment><comment><USER15> When this year I came back from Dockercon I immediately wanted to write something very similar to what this article describes. I wanted to imagine a world where Containers and Microservices were part of the past already, and so I wrote "DockerCon 2020" [1] and how it will look like.

[1] [https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz...](https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz3pruf4)

</comment><comment><USER16> I'm sorry -- I think the author completely misses the point about why microservices were controversial at all?

Distributed systems are not the same as centralized ones, and you cannot paper over the differences between the two. It is wrong to think that distributed microservices will completely replace centralized services in some future paradise. The difference is not a tech fad; it's more like a law of nature. Distributed systems should plan for network failures, yet nobody wants to get a "503" from their CPU.

<comment><USER17> You will get 503 from your kernel if you try hard enough. Handling this is technically required in any application, but often ignored, especially when allocating memory. (Because there out is a deferred failure.)

</comment></comment><comment><USER18> I'm not totally convinced that allowing developers to build faster is really all that great of an idea. At least not the sacred ideal that seems to be accepted without any question.

Most of what I see when people are moving fast is building things as fast as they can think of them based on the first idea that comes to mind that sounds like it might get things done.

But the reality is that the first way that you think of implementing something isn't always the best. It's often just about the worst. Giving people the ability to take any whim of a design and run with it all the way to production isn't the best thing overall for software quality.

Perhaps I'm alone here, but I'd like for developers to slow down and put some thought into what they are building, and how it's supposed to work, and if it's going to be able to do what it needs to do. I see a lot of "close enough" in my line of work.

I know it's different in a startup, where testing the idea _now_ is important, and I'm not slamming that. But the vast majority of developers don't work in startups where getting a product to market before a competitor is the difference between making billions and going home broke.

We temper our desire for perfection by reminding ourselves that good enough is okay for now. I'd like us to temper our desire for speed by remembering that there is such a thing as soon enough.

<comment><USER19> What you are describing is definitively an issue I face every day but I don't think speed of development is the issue. Higher productivity is good but often what is called higher productivity is just due to carelessly ignoring design and planning in favor of get things done now mentality.

Often the worse offenders are rewarded for being highly productive and the people who end up having to cleanup, refactor and get things actually working are not acknowledge for the vital effort they put in. In my view this is the result of bad management incentives and failure to properly asses results and contributions.

</comment></comment><comment><USER20> "Microservices" are a new name for a very old concept.

This is just low-coupling, high-cohesion by another name.

Small, composable, decoupled, highly cohesive components are what "good" software has been about for decades, but it now has a new name in the server s/w world; "Microservices".

Only the name is new & hyped. The concepts have been true forever.

<comment><USER21> There is software and concepts around managing microservices that didn't exist before, and so on. Nothing can be new when you use such a vague way of comparing things. There were electric cars in the 1800s, why talk about Tesla?

<comment><USER20> ...so what is a new concept regarding microservices?

I don't see anything new... new tools, granted. Then again, there's new tools being produced every day for every architectural style.

</comment></comment></comment><comment><USER22> Another good article on this subject: [https://m.signalvnoise.com/the- majestic-monolith-29166d02222...](https://m.signalvnoise.com/the-majestic- monolith-29166d022228)

My experience with microservices has been pretty painful. My analogy of microservices is it's a bit like building a car factory on two sides of the Danube. And there's no phone line in between. You've got a factory building cars up to a certain point, but then they have to stop work and pack it all up onto a barge, figure out how to fit everything on the barge and send it away across the river for the other side to spend time unpacking & figure out how it all fits together...

As a django guy, I've tended to follow the pattern of spending time making my models nice and rich, with useful traits which will be helpful at all levels of the app down to the views. To then have to pack this all up and deliver some "dumb" json to the other side feels like a massive waste of time. With microservices I spend my life marshalling data around.

And the number of times I've realized I've just spent an hour discussing the philosophical implications of how a particular bit of the rest interface should be designed, all for an interface that we're the only consumers of and doesn't need to exist in the first place... I've found depressing.

The ramifications on testing are a further story. Do you have to test all kinds of ways you can receive your rest requests malformed if you're the only consumer and know exactly how you're going to use it? Good use of developer time?

</comment><comment><USER23> Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.

</comment><comment><USER24> I don't know about the microservices and stuff, but I've got one cumbersome monolith to deal with, and it had started to rot (you know, rely on outdated dependencies that one can't upgrade without significant effort etc etc). Splitting it to a few isolated different systems looked like the only sane choice.

Luckily, I've had to redo one logical part of the monolith anyway, because of some changing business requirements. So I made it a separate independent project, that had used all the modern currently-stable tech (rather than few- years-old one + accumulated baggage of the past architectural mistakes) and it all went quite nicely.

It took me 1.5 weeks (quite busy ones, but meh) to extract all the old code pieces that I've needed, clean them up, update with the new logic, and get the freshly-minted project ready, tested, packaged up and running in production. The only thing I've lost is ability to run cross-db queries (we just have a folder of read-only SQL query snippets to fetch some useful statistics once a week or so), because I put the data in a separate database. I hope, postgres_fdw would work when I'll need it.

Would I've tried to update the whole monolith, it would've taken me months.

So, the next time I'll work on some large-enough part, I'll probably extract it into a fresh project as well. As I see it, I'll end up with a remains of legacy project surrounded by a few small(er) monoliths. And then the legacy piece would be small enough to get cleaned up.

(I don't know about micro- scale and putting every tiny thing into a different microservice, though. I have an impression it requires a lot of extra unwanted cognitive load to manage so seems like an overkill to me.)

So, my point is: software (code) rots over time. Multiple projects (services) allow to update pieces at different pace, which is less stressful on developers.

</comment><comment><USER25> It is weird to read people write about microservices (or some other tech fad) as if it is this otherworldly thing that requires instruction and training. So many words dedicated to describing the supposedly bad old days!

All this stuff is just another aspect in the life of a practitioner of computing. A proper expert should see these things not as a fad, but as a collection of techniques that can be added or subtracted to at will depending on the prevailing need. It's silly to declare any of these fads dead or alive, they're just simply techniques that ...people... have bundled together under a common label

<comment><USER26> ...but you can write (and sell) books about, talk at conferences too

</comment></comment><comment><USER27> The title is link bait and does reflect the arguments put fourth by the author.

<comment><USER28> Not to mention it's a plug to the product he's selling.

</comment></comment><comment><USER29> Maybe a more appropriate title could be 'Microservices are the Norm'

<comment><USER30> I don't think they are. I would be surprised if 10% of new code right now was coded in microservices.

<comment><USER29> Ya, you're probably right. Its likely just my bias. It feels like its the only thing i encounter at my day job.

</comment></comment></comment><comment><USER31> I joined a company where the proof of concept had, inevitably, become the monolithic application we would work on for the next two years. Everyone on the team agreed that the monolith would be a liability so we started to share knowledge on microservices and plan for that in the future. To do this we stuck to a handful of rules. Systems should do one thing and do it well, with a well defined api and protocol. Whilst all the data may be in the same redis and MySQL instance we made the data store configurable as well its location, and made sure systems did not read or write each other's data. We wrote generic systems as libraries with no dependencies on the rest of the monolith. The results of this work, which was a lot of refactoring, is that when we decided to farm some work out to a contractor we could do so as a microservice. They worked in their favourite language with their own tools, implementing the api we wanted over a specified protocol. At any point it would be possible to split out services to scale them horizontally, but we didn't have to until we need to, because every split increases the operational costs and complexities a little.

</comment><comment><USER32> I feel like maybe the Big Idea of microservices is that web APIs provide better isolation guarantees than library calls, and now with the move to SaaS either the scale of our applications is large enough or (more likely) with virtualization the intra-server network latency is small enough that we can afford the extra overhead of web APIs relative to library calls in exchange for that isolation.

</comment><comment><USER33> When it comes to services, I think it's worth to talk about one common use case which comes with different motivations and problems: adding new features to old, probably poorly engineered, monolithic application. Features that are not tiny yet-another-crud-on-a-new-table but completely different than most of the existing functionality.

In this case, they really pay off if they are separated well which sometimes is hard. But executed well, it allows to keep moving quickly as the requirements grow. Of course, this is not an excuse to avoid refactoring monolithic application, improving testing, etc.

I've worked in such a setting in companies, and both times it was a win and helped to build important to the business features really quickly and reliably.

But is it worth to write an application from scratch in a service oriented architecture? Probably not, most of the time. Especially if 'product to market time', 'MVP' and similar concepts are very important for you.

</comment><comment><USER34> I had the feeling that microservices would add too much of complexity, but with FaaS this is canceled out by the fact that almost all server management complexity is handled by a different company.

</comment><comment><USER35> They have the word "microservice" on their homepage :D

</comment><comment><USER36> John Titor is back!!

<comment><USER37> Did he bring back the IBM 5100 that he promised?

[https://en.wikipedia.org/wiki/John_Titor](https://en.wikipedia.org/wiki/John_Titor)

</comment></comment><comment><USER38> Every generation's microlith is the next generation's monolith.

For this generation, the end of microservices will be when we can look at a cluster as one big unit, and deploy a microlithic monolith on it.

For the next generation, who knows how they will slice it up.

</comment><comment><USER39> re: "it was never the size of the services that mattered: it was the connections and the relationships between them"

re relationships I would say these are better thought of through the lens of _separation of concerns_.

imo, connections, a la protocols like http will fade into the background and be a focus of ops. A piece of code knows to write/read data to/from _________, for which it has been authorized access by address/hashname/entity.

</comment><comment><USER40> Not to seem naive but I work with a lot with microservices and I've never heard of lightstep...

... follow up, what's everyones opinion on this?

<comment><USER41> Ben Sigelman, one of the founders, is a former Googler who's got tons of domain knowledge about profiling distributed systems of services and about how to structure calls and dependencies within those systems. He gave a fun talk at the SF Golang meetup in 2014. I, personally, am very excited to see what he's up to and will be keeping an eye out for more Lightstep stuff - I guess it's his newest thing.

(if you're reading this, hi Ben! Sorry we never got together last year)

</comment></comment><comment><USER42> The Gartner Hype Cycle appears to be accelerating...

</comment><comment><USER43> nitpick: nice graph on the "information superhighway" but a label about exactly what is being measured (0.000055%, _of what_ ) would be great. Is this a word count? Or its rate of change? There's a reason our (stuffy) professors/sub-editors always insist on sources and accurate labeling. I'm only interested because the most recent data points, despite large decline, still suggest a non-negligible use of a term which I haven't heard in years other than in a small amount of anecdotes/jokes.

<comment><USER44> It's just % of bigrams that appear in Google's sample of books. [1] Not especially meaningful, I admit!

[1] [https://books.google.com/ngrams/info](https://books.google.com/ngrams/info)</comment></comment>


Why Apple Doesn't Want You to Line Up for Its Watch - <AUTHOR> http://www.wired.com/2015/04/apple-watch-try-in-stores/

<comment><USER2> I was making a similar point to a friend last night, but I think the article just slightly misses it.

Apple has always sold "premium" products, but most of them max out fairly reasonably at < $2000 for a mid line MBP

The problem now is Apple maxes out at $10,000+, which puts them on par with the Louis Vuitton and Gucci's of the world. Those people won't want to see a line at the store; won't want to deal with the store traffic; and expect to be catered to when they walk in. Apple now needs to provide a much different experience at it's flagship stores, to sell the value of a luxury product.

Conversely, I have a few pieces from LV, Gucci, etc... and would have stood inline this morning, even though I'm not dropping 10k on a watch, but own some products from similar luxury brands.</comment>


Yes, but who said they'd actually BUY the damn thing? - <AUTHOR> http://blog.asmartbear.com/customer-validation.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2Fsmartbear+%28A+Smart+Bear%3A+Startups+%2B+Marketing+%2B+Geekery%29&utm_content=Google+Reader <comment><USER2> Dup: <http://news.ycombinator.com/item?id=1587983>

Comments there already.

The duplication woud've been detected automatically if you'd trimmed the reader crap off the URL</comment>


Draft Computing programme of study - Computing at School [pdf] - <AUTHOR> http://computingatschool.org.uk/data/uploads/computing-04-02-13_001.pdf

<comment><USER2> This is fantastic. I suspect that school that implement this will see positive externalities in the form of improved scores in math and science.</comment>


Jest 19: Immersive Watch Mode and Test Platform Improvements - <AUTHOR> http://facebook.github.io/jest/blog/2017/02/21/jest-19-immersive-watch-mode-test-platform-improvements.html <comment><USER2> Can anyone explain to me why the `expect` type of assertion library caught on so much in the javascript land?

I mean how is

        expect(2).toBeLessThanOrEqualTo(3)

more readable than

        assert(2 <= 3)

Especially when we have packages like power-assert (1)

[1] [https://github.com/power-assert-js/power- assert](https://github.com/power-assert-js/power-assert)

<comment><USER3> I think it comes from the Ruby community influence where the language and tools aim to read like natural language.

<comment><USER4> This has a couple advantages:

1\. A test that reads as natural language is easy to understand. Straightforward, declarative tests are a big win IMO. 2\. This allows for better test result reporting: instead of assertion failed, the utility can tell you more (expected 4 but got 3).

</comment></comment></comment><comment><AUTHOR> After coming from the iOS world, Jest is one of the most transformative tools for me when working in JavaScript. IT's super powerful, has really really useful features and is constantly being improved.

Some of the GIFs in this post show how awesome the watcher mode in the new Jest release is, I'd strongly recommend giving them a look!

</comment><comment><USER5> Jest is so good. No additional plugins for anything you want to do.

Only part I want from jest is own .rc file.

<comment><AUTHOR> There is an open PR for this: [https://github.com/facebook/jest/pull/2445](https://github.com/facebook/jest/pull/2445) \- it may end up in the next release at this rate

<comment><USER5> Great. Would really help for bigger projects.

</comment></comment></comment><comment><USER6> I didn't realize the power of Jest (and how it made everything easy to use) till I decided to re-create the functionality with Mocha (and nyc for coverage).

Took me almost half a day to an half-assed port of sorts of such an awesome tool.

(the reason I used Mocha was because it was already a dep for my integration testing and I didn't want to introduce Jest - in the end - I introduced jsdom, enzyme and nyc as well)

</comment><comment><USER7> I've been using Jest for around 6 or so months, first because of Snapshot testing, and second because of create-react-app coming with it by default.

But an old friend who is a lot better at JS than I, still uses and loves Ava. I was wondering if anyone could come around and give me a good assessment of pros/cons between the two.

</comment><comment><USER8> Could someone point me in the right direction for mocking? More specifically, I'm trying to mock the AWS-SDK in a Serverless project. I just can't get a grasp of it from the documentation.</comment>


Sleepy in Songdo, Korea's Smartest City - <AUTHOR> https://www.citylab.com/life/2018/06/sleepy-in-songdo-koreas-smartest-city/561374/?silverid=NDU0NDI4ODQ3NzI1S0 <comment><USER2> The author believes government buzzwords about sustainability and quality of life, and completely misses the fact that Songdo was a construction project near an airport in search of a market.

> To promote walkability, developers placed venues like shopping malls and > convention centers within a 15-minute walk from Central Park.

Think about that. The "Central Park" is completely surrounded (to a walking distance of about 30 minutes) by hotels/convention centers and shopping malls. No residential. No high-density commercial. Few eateries, all chains. By some heinous oversight, no banking facilities either. (I got stuck there once without cash and without money on my transit card. It took me 3 hours to find a bank and leave.) It is quite literally a desert, designed to cater to conferences and business travellers, rather than residents.

Songdo is a culturally dead city. The building density is high (all those 30-floor apartment complexes), but the land use planning/zoning is exceptionally poor. Apartment complexes kilometers on a side need to be mixed in with commercial space; instead, shopping areas are siloed into single buildings as you can see in the article pictures. There are few public-use indoor spaces, aside from churches which have gobbled up commercial space. The result is shopping districts and living disticts, kilometers apart.

The large block designs result in distances that make walking infeasible, and don't get me started on the lack of shade. Large plazas without trees or grass (everywhere! In residential areas, commercial areas, universities) make the summer heat unbearable for pedestrians.

The article mentions that the city was struggling to attract foreign companies. One thing they did about 10 years ago was give large land grants to universities: 1~5 square kilometers, far removed from the city center. These are served by subways and busses, but unlike other college towns, the zoning nearby is for office parks. As a result you have these huge university campuses with tens of thousands of students ... who would have to walk for an hour to get to any restaurants. At which point it is almost easier to take the bus to Seoul. Of course, the universities knew this. The entire ground floor of Yonsei University's new satellite campus is a parking garage; "sustainability" was always just buzzwords, and the "smart" city is a dystopian nightmare.

</comment><comment><USER3> _> What it doesn't have: enough people._

"Build it and they will come"

I spent a couple of days in Songdo and this was my experience, quite eery walking around at night, with nearly no cars. I almost started to miss the crowds of Seoul. Hopefully in a few years it will have a sense of community, something that can't be built with the typical ppalli-ppalli fashion. Smart cities everywhere seem to be plagued by this.

<comment><USER4> For south koreans, it's all about "can I go to gangnam within 1 hour?"

Most jobs, private tutors for kids, etc - are near/inside gangnam.

Any improvements for this metric (eg. a high-speed train) will fix the issue in no time

See "Gwanggyo new town" for example. It was a ghost-town until "new-bundang- line" (a high-speed train disguised as subway) made the trip to gangnam less than 40 min.

<comment><USER5> The HK New Towns all evolved in this direction as well, to the point that sustainable local industry as envisioned in the initial New Town concept tends to be reduced in favor of bigger rail links to Kowloon and the island.

</comment></comment></comment><comment><USER6> For a modern city there is awfully lot of (extremely wide) roads…

<comment><USER7> Up to 10 lane roads is normal for Korea.

<comment><USER6> Yeah, but this was supposed to new and _modern_ development, people-centric (my understanding) so sticking to "other cities have it like that" doesn't sound too good.

And as the article (and sibling comment) mention - they have the option to turn it to something more pedestrian friendly, but they wan't people/pedestrians now so they should have started with people-friendly communication in the first place _IMHO_</comment></comment></comment>


Facebook Leads an Effort to Lower Barriers to Internet Access - <AUTHOR> http://www.nytimes.com/2013/08/21/technology/facebook-leads-an-effort-to-lower-barriers-to-internet-access.html <comment><USER3> Sad to see a lot of people being cynical about this just because Facebook is taking the lead. Facebook may have personal interest in it but if the global good is greater, we must learn to be appreciative. Most discoveries and inventions, heck even the space race dint start out of the goodness of heart; but aren't we glad they did? I am all up for anything that brings people new source of information. Atleast its better than sitting in a corner and grunting how we don't have Google Fiber or how a 1px scroller disrupts the workflow while failing to realize that 2/3rds of the world has never visited a single webpage in their life.

<comment><USER4> FB is a front for the NSA at this point. Not willingly, perhaps, but by-proxy

<comment><USER5> You might as well say the internet is a front for the NSA

<comment><USER4> Well, you're correct - however, nobody aggregates the non-US userbase better, more accurately and so cleanly as FB - with 80%++ of their users non-US-based, they are ___THE_ __goldmine for the NSA.

With the new FB policy office in DC, I am sure they are nice and comfy - <USER2> well as with their Security head from NSA-FB-NSA (along with all the other spooks FB has) -- its damn clear what is going on.

</comment></comment></comment></comment><comment><USER6> tl;dr: Zuckerberg says "Screw net neutrality, I've got dibs on billions of people for my walled garden."

> Twitter ... has struck its own deals ... in more than 100 countries to offer > some free Twitter access; ... it bundled free Facebook access with some of > its Asha feature phones.; Globe Telecom, has used free Twitter, Facebook or > Google access

> "if you can afford a phone, I think it would be really good for you to have > access to the Internet."

Yet... it seems like they're equating Twitter, Facebook and Google to "The Internet".

> Cut the cost of providing mobile Internet services to 1 percent of its > current level within five to 10 years by improving the efficiency of > Internet networks and mobile phone software.

Now how that metric is measured, I'd like to know. In countries with $10 a month plans, does that mean a 10 cent a month plan instead? Somehow I don't think so. Or do they mean to say by that that Google, Twitter and Facebook will be quota-free?

> Facebook is already working on techniques to reduce the average amount of > data used by its Android mobile app from the current 12 megabytes a day to 1 > megabyte without users noticing.

That seems like more of an incentive on carriers to make Facebook quota free as much as anything else... I mean what good is that if you aren't going to:

> tackle some thorny infrastructure issues that are huge barriers in the > developing world, particularly the long-distance transmission of data to > far-flung places.

So, this is no Loon. What is this then?

> "We're focused on it more because we think it's something good for the > world," he said, "rather than something that is going to be really amazing > for our profits."

Being the founder of a publicly traded company that had a big IPO, I'm sure the emphasis is on "really amazing for our profits". Having access to Facebook, even at the detriment of other services, being something good for the world apparently is now uncontroversial enough that even the NY Times doesn't report critically.

This is how net neutrality dies, people. This is how the World Wide Web disappears into a rapidly diminishing sea of walled gardens. This is, unlike Loon, really more about ensuring that the next billions of people on the web never consider net neutrality as natural thing.

<comment><USER7> Looks like it's more about making the internet more accessible to people without it.

<comment><USER6> > However, the Internet.org team does not plan to tackle some thorny > infrastructure issues that are huge barriers in the developing world, > particularly the long-distance transmission of data to far-flung places.

The only way this initiative will therefore accomplish access to the Internet to people without it seems to be in increasing the profit margin to the local telco. How? Through vertical integration. What does that mean? Get free Facebook with your phone. What's so bad about that? Goodbye, net neutrality in developing countries.

I'm leaving the morality judgment for others, and it's far from straightforward that this is a bad thing. But I'm rather more inspired by Google's Loon as actually having a positive impact on the developing world than this here thing.

Basically, 3G, 4G, the lot, is no good for large amounts of data. The percentage of mobile traffic of total traffic is actually dropping here in Australia - mobile data is being thrashed by fixed line services. Fixed line is growing 50% while mobile data would 10% every 6 months. And Loon acts more like a fixed line service than mobile data.

<comment><USER8> To be frank, that has a lot to do with the shifting Australian regulatory conditions, specifically deregulation. Your fixed line services, at the national level, are still relatively small. What you're referring to is what we call Last mile connectivity and competing exchanges.

In reality, there aren't very many transcontinental cables being laid right now because the ROI is greater than 30 years in most cases.

Basically my point is this: your fixed line services are growing at a fast rate because they're just now being opened to competition, but, over time, like the rest of the developed world, wireless networks will subsume your fixed line services.

Just my opinion and my two cents from talking to Aussie Telcos.

Source: I'm a telecom geek.

<comment><USER6> > like the rest of the developed world, wireless networks will subsume your > fixed line services.

[http://abs.gov.au/ausstats/abs@.nsf/Products/8153.0~December...](http://abs.gov.au/ausstats/abs@.nsf/Products/8153.0~December+2012~Chapter~Volume+of+data+downloaded?OpenDocument)

You sure about that? Plus, how are you going to transmit 1 Gbps with an acceptable level of contention, with a very very thin wall or two in the way over any distance greater than let's say a hundred metres?

Plus, this deregulation that you speak of, the national telco was being privatised starting in 1997, and deregulation happened before that even. Broadband ISPs have been around forever, and their DSLAMs for more than a decade too.

> Your fixed line services, at the national level, are still relatively small.

In some areas, we've got three networks running to the same premises. Fixed line services are near enough fully built out and have been forever.

</comment></comment></comment></comment></comment><comment><USER9> Those people probably dont have any internet, because:

1 - they dont have jobs and lack of money

2 - they are still strugling for food security

3 - their village or city have no energy

4 - they are maybe even without water

5 - they maybe have a low level education

so if they are so good and passionate about helping people all over the world, and they are insanelly wealthy people why they also dont make a bigger plan..

Thats one of the reasons i really admire bill gates right now.. he spend his fortune for a real common good..

while what facebook and others are doing is not bad at all, on the contrary can be a good thing.. what piss me off is that sort of marketing bullshit, like if we are stupid people that would buy that is "all for the common good, rainbows and unicorns"

Do it, show the good side of it, but also show the real reasoning behind it

A human being asking himself, about what he could do to help improve the life of others.. would get a lot of answers to start with but in none of those cases it would start with "extend the internet to the people that can barelly read so they can share their plate without any food in it for lunch time"

<comment><USER10> Firstly, Bill Gates is being a philanthropist with the billions he earned by running a lot of other entrepreneurs to the ground. But if he's had a change of heart, then I applaud him, even though it doesn't absolve him of what he did in the past.

Secondly, I'm under no illusions about FB's motives, but if this can bring educational resources such as Khan Academy to more people in developing countries, I'm for it. The worst thing you can do to developing nations is to give them handouts (see: Africa). There will be no permanent progress without education.

</comment></comment><comment><USER11> Correction: "Facebook lead initiative to bring Facebook to everyone."

<comment><USER12> Correction: "Facebook lead initiative to bring advertising to everyone."

</comment></comment><comment><USER13> Quite a high percentage of the people in the world without internet access live under governments with poor human rights records. In this new age of massive unscrupulous spying and data mining by governments, bringing the internet to new populations without making sure they understand the risks makes them vulnerable to unprecedented levels of tyranny.

Any initiative that tries to expand internet access without addressing these basic moral issues is suspect, and we obviously aren't going to see responsible behavior on this front from the likes of Facebook.

<comment><USER14> One could argue that even those in the USA do not understand or cannot avoid these risks, making them (as you said) "vulnerable to unprecedented levels of tyranny".

</comment></comment><comment><USER15> Google seems to be conspicuously absent.

It's terrible to be cynical, but can't help feeling like this is just a reaction to project loon. Basically a banding together of companies who might see Loon as a threat, to offer some kind of alternative that they are in control of instead of Google.

However unlike Loon, reading the entire page I can't see anything solid they will actually do - develop better compression algorithms? Introduce "business models"? That's it? It sounds suspiciously weak.

<comment><USER16> Facebook is an investor in the Asia Pacific Gateway[1], and, despite the minuscule size of the Wikipedia article, it stands to reason that the project will be very big for the SEA region.

Their interest in providing internet to as many people as possible isn't new, however Facebook's "internet for everybody" initiative is indeed unexpected.

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

</comment></comment><comment><USER17> Every one of us. Everywhere. C̶o̶n̶n̶e̶c̶t̶e̶d̶[Monitored].

</comment><comment><USER18> These proposals look too vague / generic. There's already a lot of people who build mobile apps today and try to compress as much as possible, or limit how much they download.

It's like announcing you're leading an initiative to improve the health and nutrition of children, but you won't actually be distributing any vaccines or food, but laying down a set of principles to align local supplier incentives and politicians.

Bill Gates criticized Loon because, and probably rightly so, concentrating on health of children with easily preventable measures is the biggest bang for the buck. But this initiative seems even more like Vaporware.

</comment><comment><USER19> New York Times article:

[http://www.nytimes.com/2013/08/21/technology/facebook- leads-...](http://www.nytimes.com/2013/08/21/technology/facebook-leads-an- effort-to-lower-barriers-to-internet-access.html?hp&_r=0)

<comment><USER20> It's on the page.

</comment></comment><comment><USER21> 2/3rds of the world does not have internet. It's easy for us to forget that. It's a serious issue, and Facebook is well-positioned to tackle it.

<comment><USER22> How are they well-positioned? I don't mean to sound crass, but what has Facebook ever done that makes you think they're well-positioned? They're pretty much a software/advertising company. Sure, they have their Open Compute project, but besides that, what significant contribution to technical engineering have they contributed to that suggest they have the know-how and ability to scale such a massive infrastructure project.

</comment></comment><comment><USER23> No thanks, Mark. Here's hoping that your plan to AOLify the rest of the word and violate the privacy of your future would-be users fails miserably.

</comment><comment><USER24> A detailed plan by Zuckerberg: [https://www.facebook.com/isconnectivityahumanright/isconnect...](https://www.facebook.com/isconnectivityahumanright/isconnectivityahumanright.pdf)

</comment><comment><USER25> I'm sensing a new trend: short videos in the backgrounds. Other similar site with the same trend [https://letshum.com/](https://letshum.com/)

<comment><USER26> I absolutely love videos in the background. Brings the page to life. If it doesn't lag my computer I'm ok with it.

Anyone have any links to any good tutorials to embed background videos like this?

<comment><USER27> [https://github.com/sydlawrence/jquery.videoBG](https://github.com/sydlawrence/jquery.videoBG)

Found it when snooping around some New York Times webpage code ;).

<comment><USER26> Cool I'll take a look at that. Thanks!

</comment></comment></comment></comment><comment><USER20> We're stuck with facebook for the rest of our lives. Aren't we?

<comment><USER28> facebook is literally an infinite well of data. I don't see how we could eradicate it without a truly terrible abuse of power coming to light from within the company.

<comment><USER20> Facebook isn't giving me useful implementations of my data. It's holding relationships hostage.

It being the de facto source for internet services for large populations is only going to make things worse.

<comment><USER29> IMHO solving the Facebook walled garden would be one of the most interesting startups to create today.

I've spent several months studying how to create tools that get around walled gardens (unfortunately they aren't mine and I can't open source them) but this is definitely a problem I wouldn't mind working on next. There are ways to get your information out of Facebook that would be extremely hard for them to counter, but it's a fulltime job to create something robust enough and maintaining it in the face of changes Facebook makes.

</comment></comment></comment></comment><comment><USER30> How do you create a society where organizations would have a vested interest in leading efforts to lower barriers to electricity. Even in present conditions, electricity is after-all a prerequisite to better internet access. I wonder why there are fewer juggernauts looking into electricity than internet.

</comment><comment><USER31> > _The companies intend to accomplish their goal in part by simplifying phone > applications so they run more efficiently and by improving the components of > phones and networks so that they transmit more data while using less battery > power._

Isn't it already happening for a while (or forever, depending on the companies) ? Companies who cared about performance and responsiveness already work on optimizing their apps. Because more usage means more revenue.

Mobile OS and hardware makers already care about battery life and efficiency, because these are strong competitive advantages.

The rest of the effort seems to be into getting carriers to make Facebook/other companies requests out of quota, witch is not new and belongs more to marketing/sales strategy than anything else.

This initiative feels like some generic PR move with nothing special to latch on.

</comment><comment><USER32> Frankly, it sounds like he's just recharacterizing basic efficiency plans to make it seem like Facebook is on some sort of altruistic mission. There's little to no action called for, no commitments towards altrustic ends. It's just a "hey, we should get more people online" (which only helps Facebook's bottom line) and a "we're trying to make Facebook load faster" (again, bottom line).

</comment><comment><USER33> I think this time, Facebook need not sell, it just need to propose the govt.,rest all will be a breeze as the Big boys want more data,more and more to churn, bubble and victimise each citizen possible every day.

Hail Facebook,Hail NSA and Other organised shit giving us false promise of security while churning our own data.

</comment><comment><USER34> This is all just rubbish so that they can find more eyeballs to stick into the service. They've reached almost everyone, so the next logical step is to bring Internet to the only audience they can't yet reach.

</comment><comment><USER35> Given the complete lack of security on the internet, it would seem that we want to extend this lack of security to everyone in the world. Hurrah!

Now can we fix the problems before we ship it?

</comment><comment><USER36> Great initiative, but it doesn't actually say what they're doing towards it.

<comment><AUTHOR> The rough-draft how: [https://www.facebook.com/isconnectivityahumanright/isconnect...](https://www.facebook.com/isconnectivityahumanright/isconnectivityahumanright.pdf)

</comment></comment><comment><USER37> I start hating on this scrolling design stuff. Specially with bright pink.

<comment><USER29> I didn't even try scrolling. I watched the video and then closed the page because I didn't know that there was some other action to take next. They should put a call to action at the end.

</comment></comment><comment><USER38> It is just my computer... or are they not using any CSS styling?

<comment><USER38> Weird that it doesn't work in Chrome... Surprising that wouldn't bother to test drive it in Chrome.

</comment></comment><comment><USER39> And another NSA approved frontend? >:-)

</comment><comment><USER40> tldr; Facebook need new markets to enter to keep growing at expected investor's rate.

</comment><comment><USER41> Facebook looking into ways to improve their userbase? Jokes apart, this is a great initiative.</comment>


HN:  Just Launched - Rate My Start Up - Ideas on Beating Chicky/Eggy Problem? - <AUTHOR> http://nxting.com/about/

<comment><USER2> Rate a chat roulette clone? F-

<comment><USER3> Clone my butt. Not a clone at all. nxting.com has PORN FILTERING. NO MORE SAUSAGE.</comment></comment>