On the role of GRBs on life extinction in the Universe - <AUTHOR> http://arxiv.org/abs/1409.2506 <comment><USER2> Sounds like an answer to the Fermi Paradox if I ever heard one.

It's not an answer I like. But then, that's probably true for most potential answers to that particular question.

<comment><USER3> Manifold: Space by Stephen Baxter covers this conjecture, for anyone interested in a fictional treatment.

<comment><USER4> One of his best novels, in my opinion. Fantastically huge ideas, and yet has pretty well developed characters for an SF novel. The ending is incredibly poignant.

Diaspora by Greg Egan also has a first-hand depiction of a gamma-ray burst hitting the Earth.

<comment><USER5> If you're interested in Physics and Cosmology, Baxter is a very, very fascinating author.

I just find his style a bit dry. But it's worth it for the mind-bending ideas.

</comment></comment></comment></comment><comment><USER6> This paper makes a lot of assumptions about the nature of life. Just off the top of my head, it takes as given that:

a) organisms are sensitive to UV radiation

b) atmospheric ozone is the mechanism that protects the host planet against excessive UV radiation

c) the planet's atmosphere contains lots of nitrogen

d) the planet has large oceans of water (since the paper notes the main significance of high UV flux would be to kill off marine plankton)

These all hold true for Earth, but not for places like Europa or Titan, let alone more exotic environments.

<comment><USER7> From the paper: "While life can take numerous other forms and could be much more resilient to radiation than on earth, we make here the conservative assumption that life is rather similar to the one on Earth. This common assumption is the basis for searches of Earth like exoplanets as places that harbour life. "

<comment><USER8> There are creatures that are resilient to radiation already on the earth.

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

<comment><USER9> Right, but these are the exceptions for a reason. Something life is exposed to only every hundred(s) millions of years or so is so infrequent that evolution selects against so long as it introduces inefficiencies (and nothing is free). Evolution is an extremely dumb optimization process, and will simply drift away from rad-protecting features as soon as the event is over.

<comment><USER10> True, in places where the only sources of radiation are rare events like GRBs. But I imagine there must be hospitable exoplanets somewhere in the universe that are, for one reason or another, subjected to more intense radiation constantly, in which case rad-protection would have a strong impact on evolution

</comment></comment></comment></comment></comment><comment><USER11> It's hypothesized that the Ordovician–Silurian extiction (end of trilobites) may have been caused by a GRB. This was ~450-440 million years ago. Here's to a 1 in 500 million year event! [http://en.wikipedia.org/wiki/Ordovician%E2%80%93Silurian_ext...](http://en.wikipedia.org/wiki/Ordovician%E2%80%93Silurian_extinction_event#Gamma_ray_burst_hypothesis)

<comment><USER12> I had a paper published on a model for the GRB that would have caused that event!

[http://arxiv.org/abs/astro-ph/0504158](http://arxiv.org/abs/astro-ph/0504158)

When the GLAST (now James Webb Telescope) data came in, it pointed to a small (~1%) anisotropy of UHE GRBs toward high metalicity galaxies. Our model was completely isotropic. Unfortunately, we didn't have time to rework the anisotropy into our model's assumptions before our funding fell through.

... and that is the story of my brief experience as a scientist.

</comment></comment><comment><USER13> Maybe this is a dumb question, but what about life on the other side of the planet from where the GRB hits?

<comment><USER14> Not a dumb question! It's answered in the GRB wikipedia article:

"Life surviving an initial onslaught, including those located on the side of the earth facing away from the burst, would have to contend with the potentially lethal after-effect of the depletion of the atmosphere's protective ozone layer by the burst." [https://en.wikipedia.org/wiki/Gamma- ray_burst#Rate_of_occurr...](https://en.wikipedia.org/wiki/Gamma- ray_burst#Rate_of_occurrence_and_potential_effects_on_life_on_Earth)

<comment><USER15> That was my first question after I learned about GRB. According to wikipedia you linked, atmosphere might be sufficient to protect from gamma rays, unfortunately at a very high cost to stratosphere.

"The greatest danger is believed to come from Wolf–Rayet stars, regarded by astronomers as likely GRB candidates. When such stars transition to supernovae, they may emit intense beams of gamma rays, and if Earth were to lie in the beam zone, devastating effects may occur. Gamma rays would not penetrate Earth's atmosphere to impact the surface directly, but they would chemically damage the stratosphere."

</comment></comment></comment><comment><USER5> > _When considering the Universe as a whole, the safest environments for life > (similar to the one on Earth) are the lowest density regions in the > outskirts of large galaxies and life can exist in only ~ 10% of galaxies. > Remarkably, a cosmological constant is essential for such systems to exist._

Wow. That's an interesting side-effect.

<comment><USER16> If you are referring to the cosmological constant, not really: You still need rest of physical laws & constants for life to exist. Changes in the others could compensate for changes in the cosmological constant (for instance, strength of gravity).

<comment><USER5> I just thought it seemed a bit arbitrary to link the existence of life on that seemingly-unrelated constant.

I'm aware of all the rest of the "fine-tuning" (please mind the quotes, yadda- yadda).

</comment></comment></comment><comment><USER17> When we talk about mass extinctions, we're mostly talking about marine life. Mass extinctions are dominated by a reduction in marine biodiversity, simply because that's what dominates the fossil record. (Beyond that, there's no land life for the first of the 5 major extinction events, and little data for land life for the next two.)

However, marine organisms would be sheltered from gamma radiation.

From a geological viewpoint, this seems very unconvincing as a significant cause of any the major mass extinction events. It's interesting for extraterrestrial life and future society in general, though.

<comment><USER18> Many deep-water marine ecosystems are dependent on their neighbors in near- surface environments.

<comment><USER17> Sure! They're tied to the shallow marine ecosystem. Most marine productivity is within the photoic zone, as well. Marine ecosystems are typically not tightly tied to land life, though. (Sediment input, etc, is a different story, but while it's biologically mediated, it's not controlled by biologic factors.)

However, even a fraction of a meter of water will form a very effective barrier to gamma radiation (One meter reduces it to ~2e-17 times it's original intensity).

Even if it were to kill off everything in the upper few tens of centimeters of water, it wouldn't decimate marine productivity. Most of the productivity in the oceans is tied to the ecosystem in the photoic zone, but not to the upper few centimeters of the water column.

Edit: I just realized they're mostly referring to the effect of increased UVB radiation _after_ the gamma ray burst removes the ozone layer, rather than the effect of the gamma ray burst itself. Because UV radiation is much longer wavelength, it would have an effect on the upper few meters of the water column, rather than the upper few centimeters, which could be significant. I'm still unconvinced that it's a "good" explanation for mass extinctions, given that we have several others (e.g. long-term sea level fluctuations), but it makes more sense than I thought at first.

</comment></comment></comment><comment><USER19> Is there really no way to find whether Earth got hit by gamma-rays? Nothing geologists can find, we have to guess?

<comment><USER20> One possibility is to look for evidence of neutron irradiation in rock layers that were exposed at the time. The signal would be weak:

1) The gamma ray spectrum from GRBs looks like it has a long high-energy tail: [http://www.mpa- garching.mpg.de/lectures/ADSEM/WS0304_Kienlin...](http://www.mpa- garching.mpg.de/lectures/ADSEM/WS0304_Kienlin.pdf)

2) For gamma energies about about 8 MeV, you start producing neutrons from gamma-nucleus interactions (this is why cancer patients who are treated with high-energy beams are very slightly radioactive for a while after each treatment: high energy photons blow neutrons out of a few of their nuclei, leaving short-lived daughter nuclei in their place.)

3) For an extinction-level gamma-ray event the GRB fluxes are estimated as ~10 kW/m^2 as the top of the atmosphere and 160 W/m^2 at the surface of the exposed side of the Earth. That's 160/1.6E-13 = 1E15 MeV/s.m^2. If 10E-6 gammas generate a neutron (totally ballpark guess, but the spectrum is only down by about 1E-3 from peak at around 10 MeV, and neutron production cross- sections at around 10 MeV are on the order of a milli-barn for nitrogen and some heavier elements, so a 1E-3 fraction going into neutron production is not unreasonable) that's 1E9 neutrons/m.s. Given GRBs last for a couple of seconds, therefore, one would expect to see a layer of neutron-activated rock that was exposed to a fair neutron flux.

4) But... all rock is exposed to a background flux of a few neutrons per second, so over a few hundred years there would be a background signal that swamped this burst signal.

Ergo, it is unlikely that this mechanism could be used to detect a signature of GRB extinction events on Earth. The additional neutron activation signal would be completely swamped by the natural background signal in almost any reasonable circumstances.

<comment><USER21> I know little about this, but having said that could a very high burst produce affect elements that are mostly stable against the normal background radiation levels, but then decay into other elements when exposed to particular levels of gamma rays? So while general "rocks" might not have clear data, detecting the signatures of particular ratios of elements outside the normal baseline in a certain type of geological formation might provide evidence. Locating similar formations around the world could even triangulate to which side of the planet was hit.

<comment><USER19> dnautics commented on this thread that a gamma ray burst would suddenly convert free O2 in the atmosphere into NO, which would further react into nitric acid. Maybe this is detectable, either by the direct effects of HNO3, or by a sudden spike in nitrogen levels and the organisms that consume it.

</comment></comment></comment></comment><comment><USER22> > Amongst the different kinds of GRBs, long ones are most dangerous.

So what effect would a long, direct GRB have on earth? Are we talking scorched, molten earth and boiled seas, or put extra sunscreen on for a week?

<comment><USER6> "For [UV-B] radiation with a wavelength of 290 nm, the intensity at the top of the atmosphere is 350 million times stronger than at the Earth's surface." That's due to ozone ([https://en.wikipedia.org/wiki/Ozone_layer](https://en.wikipedia.org/wiki/Ozone_layer)).

So we would need some really solid sunscreen. Also the oceans would turn into a big vat of plankton chowder, which would make for an exciting last few years for all of us.

<comment><USER23> It would (eventually, once the bacteria recovered) smell bad, but is this a human extinction event? The natural processes that form ozone wouldn't cease, and human action could supplement that. The specific types of plankton in a recovered ocean might be different, but surely we don't think all plankton would die out entirely over the entire earth?

<comment><USER24> I believe the conceptual problem most people are stuck on is the couple second at most gamma burst by itself is quite harmless to life on the surface. The guys on the ISS are likely totally screwed. Anyway massive radiation spike in the upper atmosphere has a rather well understood and very unfortunate chemical effect on the ozone layer, where its basically eliminated for about a calendar season.

A demonstration can be provided COTS from marine reef tanks, you can buy UV sterilizers which continuously zap flowing water with UV, quite effectively killing all floating algae and pretty much anything else floating in the water.

The problem in the ocean is for some months they'll literally be nothing for plankton to eat at all, and the sheer level of rot and rot byproducts would be pretty spectacular making life really difficult. And the recolonization process once UV levels drop enough to make it possible will result in some really weird blooms, and algae blooms lead to busts so the oscillations will likely be pretty exciting after the initial crash. A few million years later they'll be a lovely layer of petrochemicals to mine.

On land, the couple month UV hit would be very much like hitting the entire surface of the planet with defoliants. You might survive the lack of food, but no clean water for awhile and no harvest this season and everything green pretty much just died and started washing away in the rain might be a bigger mess. In a way the best place to hang out might be a desert. All the cacti will die, but there won't be many mudslides. A forest might be a good place to chill out too, all the leaves will die and the trees themselves might die but the roots won't rot for a long time, keeping dirt in place. Grassland areas will be pretty much screwed.

<comment><USER2> Don't dead plants and animals fail to rot in sterile environments?

</comment></comment></comment></comment></comment><comment><USER25> Whoa. In an odd way, it could turn out that destroying our natural ecosystems is the fastest way to prepare for a post-GRB environment. So maybe if our responsibility is to preserve intelligent life, the best route is to destroy the planet ASAP in a controlled manner, and learn to become completely self- sufficient without eco-system services... :/

<comment><USER15> While idea is remotely plausible, I think chance of that is really small. Destroying ecosystem will likely destroy human civilization, as we are still major part of that ecosystem.

<comment><USER26> The main reason species go extinct when the ecosystem collapses is the fact that most animals can't adapt to the new normal. Humans are among the most adaptable life forms imaginable, our civilization has a much better chance at surviving ecological collapse. Poor people might all be eating jellyfish stew, and certain economic sectors might disappear, but we should be just fine.

</comment></comment></comment><comment><USER5> TLDR - this universe is seemingly hospitable to life, but in reality it's quite hostile.

<comment><USER27> It's intrinsically difficult to argue about the probability of life on a sample of one, and so I can't adjudicated between the Rare Earth hypothesis and the Common Life hypothesis any more than the next guy. But I do think I can say that the sneering dismissal of the Rare Earth hypothesis I've sometimes seen is unsound. The Copernican Principle that "we are not special" may have carried us a ways, but it is ultimately _only_ a heuristic, not a scientific law, and it may have limits.

<comment><USER28> The Rare Earth hypothesis as explained in the book only mentions conditions required for past events leading up to the ascent of humans to occur, and of course this paper adds to the rarity required, but the hypothesis could also extend to conditions required for humans to colonize the galaxy. There's enough rocks out there with gravity large enough for humans to build sealed- city civilizations on, scattered at greater and greater distances away from earth so as to provide incrementally increasing challenges to get to them: the Moon, Mercury, Mars, the 4 Galilean moons of Jupiter, Saturn's Titan, and Neptune's Triton. Then there's the closest, Venus, which is uninhabitable even for sealed cities but provides the challenge of terraforming. When humans can successfully terraform Venus, they're ready for a one-way trip to the stars. And the paper suggests it will be _outwards_ down the Orion spur.

<comment><USER27> Just to be clear, I speak more broadly of the idea in general that conditions are perhaps not right for life everywhere, rather than the specific claims of a particular book.

In particular because it both easy and tempting for some people to overspecify the conditions for life and for others to underspecify. On the one hand it is trivially easy to get odds as long as you want by overspecifying exact details of human ascent. On the other hand, looking up into the sky it's hard not to notice that if life were really so easy and abundant it really shouldn't look like that up there. (Or Great Filter handwave handwave. But anyhow, _something_ is up, and the general idea of Rare Earth is still in the running.)</comment></comment></comment></comment>


Ask HN: Outlook down, but the status page is reporting everything OK - <AUTHOR> Receiving and sending of E-Mails does not work. But if i look at the status page it says everything ok.<p>https://imgur.com/a/3I9e2 https://imgur.com/a/NN6YX <comment><USER2> They have added new mail server to mx records: MX 5 outlook- com.olc.protection.outlook.com Haven't seen that before.</comment>


StickK To Your Commitments [Steven Levitt] - <AUTHOR> http://freakonomics.blogs.nytimes.com/2008/01/21/stickk-to-your-commitments/ <comment><AUTHOR> It's funny he mentions donating money to the Nazi Party as a means of motivating yourself. I'm planning to do a startup this summer and am saving to get the starting capital. I'm always worrying about not having good enough skills, not knowing enough, etc. So to force myself to start, I made a big deal out of it to tell everyone that I'm going to start this summer, and if I won't start, I'm going to donate the money - about E8000 = $12000 - to the Storm Front or something. Everybody says I'm crazy and if I don't start I should donate the money to a good cause, but the extreme social embarrassment associated with the original setup virtually guarantees I will start this summer :-)</comment>


American Hackers Helped UAE Spy on Al Jazeera Chairman, BBC Host - <AUTHOR> https://www.reuters.com/investigates/special-report/usa-raven-media/ <comment><USER2> If I was a journalist covering any sort of geopolitical stuff I'd 100% have my phone reviewed by infosec experts regularly and change devices frequently. And ideally use separate phones for external work related contacts, day-to-day in- office work, and personal life.

<comment><USER3> IIRC most of these exploits require either physical access, or clicking a link in an email or text.

I'm not sure anyone will burn a no interaction zero day on a human rights journalist. I suspect that kind of thing is hoarded by the big boys for when life and limb are on the line.

<comment><USER4> The article mentions the no-interaction exploit used:

> The attacks utilized a cyber weapon called Karma. As Reuters reported in > January, Karma allowed Raven operatives to remotely hack into iPhones by > inputting a target's phone number or associated email address into the > attack software. Unlike many exploits, Karma did not require a target to > click on a link sent to an iPhone, they said. Apple declined to comment.

<comment><USER3> Wow. Sorry, I didn't see that part.

I'm surprised it's still circulating then, it sounds like a very serious bug. It's still not known? (No CVE?)

<comment><USER5> It's been patched. There may be others currently in use, or that will be found and used in the future, but this specific bug was killed.

</comment></comment></comment></comment></comment><comment><USER6> I wonder how many of these hackers "just liked to solve interesting problems" for work.

<comment><USER7> Too many. Your comment probably sounds like snark to a lot of people but touches on a very real problem.

</comment></comment><comment> munk-a Hey America, do you think you might find a bit of time to persecute these Americans that are being such obviously terrible actors?

Sure, the crime wasn't on US soil and so-and-so but... I feel like in the modern world it'd really help America's cred to actually try and take action against these terrible actors. The fact that these folks were former three- letter probably means there's some contract somewhere out there where they signed away all their rights forever.

(Also, I get that America is probably fine with this sort of hacking, given that it targeted "the evil" but why not just prosecute these folks for the image of it)

<comment><USER8> If you read their earlier investigation, the employees aren't any more terrible than the average NSA rep, and the firm is mostly careful about making an Emarati operative actually perform the attacks on people from the US making prosecution difficult. The FBI was investigating as of January at least.

<comment><USER9> I would think running your own foreign espionage operation as an American citizen would get you 25 to life. Or should.

<comment><USER8> That isn't what happened here, and why would your companies location make the acts worthy of more or less prison time?

</comment></comment></comment></comment><comment><USER10> It's probably a lot more lucrative to work on such projects than may be working for the NSA while doing the exactly same things but aren't there laws that prevent ex-spies and hackers to work for foreign governments ?

<comment><USER11> If governments / law makers cared, they would react.

I remember when the French government learnt that all the top officials of the country where tapped by the NSA, including the President ([https://fr.wikipedia.org/wiki/Espionnage_de_l%27%C3%89lys%C3...](https://fr.wikipedia.org/wiki/Espionnage_de_l%27%C3%89lys%C3%A9e_par_la_NSA)).

France did absolutely _nothing_.

<comment><USER12> > _France did absolutely nothing..._

...that we know about.

<comment><USER13> Sure, but doing nothing publicly does mean a lot.

</comment></comment></comment></comment><comment><USER14> And they are bleating about China and Huawei.

</comment><comment><USER15> When I was a kid I did dream of being a cyber-mercenary. Given that the US recognise cyberspace as being a battlespace, would being a hacker for another country count as being a mercenary. Would that make you a combatant?

</comment><comment><USER16> Why isn't it illegal for Americans to hack into phones in other countries?

</comment><comment><USER17> Can we not turn HN into /r/politics? Or, if we are, be very up-front about HN supporting political 'news' and gossip?

<comment><USER18> This report is not scare-quoted news or gossip.</comment></comment>


Ask HN: ReasonML, ClojureScript, Purescript or Elm? - <AUTHOR> I was just hoping that some people who might have made this decision could speak a bit about their reasoning behind the decision. Specifically, if you could mention your use-case, as well as what language features you needed (or wished for) and finally the pros/cons you used to make your decision. <comment><USER2> I'd choose Elm but that's because I have the most experience with it. It's closed ecosystem (interop with JS libraries is more ceremonious than with other alternatives here), but it's wonderful (compiler-as-assistant, elm- format etc.). Honestly writing Elm just makes me happy :)

ClojureScript is nice but my last experience with was before the Spec arrived. I've had a Slack bot running in Clojure, didn't look at it for three months and when I needed to fix a bug, I couldn't remember what shape the data was in, and kind of burned out trying to get back into it. That made me try something strongly statically typed. I reckon my experience would be different with Spec now.

Purescript is like Elm, just with less hand-holding and more advanced everything. Might suit you if you like Haskell?

No experience with ReasonML.

Edit: speaking more generally, I'd take anything with algebraic datatypes. Thankfully most modern languages do have them nowadays.

</comment><comment><USER3> ClojureScript is mature, has great tooling, and embraces the host platform making interop mostly painless. My team has been using it for nearly four years now, and we're very happy with it.

This workshop runs through all the basics of building a small app from start to finish [https://github.com/ClojureTO/JS- Workshop](https://github.com/ClojureTO/JS-Workshop)

</comment><comment><USER4> I'm working on a few Elm sideprojects and am having a blast. The IDE integration (elm-format, type checking hints) is a miracle. the `style- elements` library is an absolutely wonderful DSL for writing predictable/flexible/fluid/decoupled layout code. And the file sizes with 0.19 are miniscule (my app previously minified down to 100kb, but now it is about 20kb)

</comment><comment><USER5> I wanted algebraic datatypes, purity, safe JS interop. Elm satisfied all of those nicely. I've spent a year on an Elm side project and a few months on production Elm and am more convinced than ever that it's the language/ecosystem I prefer for front-end.

</comment><comment><USER6> You may want to take a look at Fable[0] if you haven't seen it yet. I'm considering using it for an internal tooling work project in the near future.

[0] [http://fable.io/](http://fable.io/)

</comment><comment> a-saleh For side-projects I like to play around with PureScript.

Mostly because I really like things like simple-json, where it can parse a json string based just on the type you are expecting.

It looks powerful, and i.e. Halogen framework has decent examples, documentation, and seems to be designed in a way, that provides you plenty escape-hatches for your components, once you need to do something more complicated.

If you need even more escape hatches, the FFI is quite un-assuming.

On the other hand, I haven't shipped anything with it, never used it in anger, but I still like it.

I like to use Justin Woo's reference when looking for purescript library recomendations. [https://purescript- resources.readthedocs.io/en/latest/](https://purescript- resources.readthedocs.io/en/latest/)

I did use clojurescript in previous job (4 years ago). If you like lisp's it is nice. I did. I liked the libraries, and this was the first time I seen the "All the state of the app will be changed with atomic updates, there is only one state-var" pattern. I never did anything too complicated with it, and never used ffi.

</comment><comment><USER7> On the _surface_ , Elm has _fewer_ features than the other the languages mentioned in the OP's question, that turns out to be a _really_ good thing.

Having more language features just leads to more ways of doing the same thing which is more to "reason about" maintain and train new people to understand.

If you are building a small web app that needs to be Embedded in an existing/other web page, use Elm the resulting app will be _much_ smaller.

If you are building a larger app that requires lots of JS "interop", use Elm and listen to the Elm-Town Podcast on Ports.

We @dwyl have been using Elm for the past 2 years on project ranging from small Progressive Web Apps (which load much faster than their React/Angular/ReasonML equivalents) to full e-commerce websites built by teams of 30+ people.

Elm _shines_ in all the situations we have used it. In some situations where we have JS server-side code we have used PureScript which some people consider more "full featured", but all that _really_ means is: "I don't know how to do this in a simpler way, so I need the "advanced" language features..."

If your use-case is a (Web App Mobile-focussed or Desktop) and you want to "move fast" (without breaking things!), you will not find a better launch-pad than Elm.

Given the release of v0.19 last week, now is a _great_ time to dive in!

<comment><USER8> > but all that really means is: "I don't know how to do this in a simpler way, > so I need the "advanced" language features..."

I disagree with most of your comment, but I want to respond to this one section in particular.

I enjoy using PureScript in place of languages without the "advanced" features because it lets me express things that are otherwise _not expressible_. That doesn't make the language more complex, or less "simple" if you prefer, but it _does_ arm its users with the tools necessary to create more powerful abstractions, should they need them.

Will some of these abstractions end up introducing more complexity? Perhaps. However, one can write simplified code in a language that admits more powerful abstractions while the reverse _is not true_.

When someone decides that they don't want to use higher kinded types or typeclasses in PureScript, they can _choose_ not to use them.

When someone runs into a problem that would be made easier with higher kinded types or typeclasses in Elm, they _cannot choose at all_.

Nowhere is this point driven home more clearly than when deriving JSON encoders and decoders. The last time I checked, users were advised to codegen complex JSON codecs using a web app [0].

Compare this with PureScript, where the language's features can be used to automatically derive JSON codecs from a simple type alias that looks nearly identical to the JSON itself [1].

And these are just two features that are directly comparable. A few months back, I gave a talk on how these "advanced features" can be used to construct functions that can be combined to create complex pieces of input validation logic. These functions can be safely mixed, matched, and extended with strong guarantees that any and all failures will be propagated back to the caller in the form of typed error messages [2].

Anyway, I'm sorry if this rant was just the result of me having read farther into that one part of your comment than you intended. I don't think there's anything wrong with people using Elm, and I'm glad that there are more avenues into strongly typed, functional programming than just Haskell and PureScript.

I just see this line of "Elm is simple" brought out in response to these other languages, and feel that it entirely misses the point of why those languages added the features in the first place.

[0] [https://noredink.github.io/json-to-elm/](https://noredink.github.io/json- to-elm/)

[1] [https://github.com/justinwoo/purescript-simple- json](https://github.com/justinwoo/purescript-simple-json)

[2] [https://www.slideshare.net/JosephKachmar/lc2018-input- valida...](https://www.slideshare.net/JosephKachmar/lc2018-input-validation- in-purescript)

</comment></comment><comment><USER9> for my personal hobby project, i migrated it from elm to js-of-ocaml [[https://ocsigen.org/js_of_ocaml/](https://ocsigen.org/js_of_ocaml/)] + lexifi's ocaml-vdom library [[https://github.com/LexiFi/ocaml- vdom](https://github.com/LexiFi/ocaml-vdom)], and have been pretty happy with it. i did not go with bucklescript (i'm guessing by reasonml you mean reasonml + bucklescript, since that's the combination that has the community around it) because i wanted to make both a desktop app and a webapp from the same codebase, and js-of-ocaml fit that use case better.

if i primarily had to interop with javascript rather than with ocaml, i would give bucklescript (either with or without the reasonml frontend) a more serious look.

</comment><comment><USER10> Elm</comment>


Mueller Used Bitcoin to Catch Russia - <AUTHOR> http://lite.cnn.io/en/article/h_4257e917945d6897b59d5e2b5d6fbb3c <comment><USER2> Regardless of your politics, I think most would agree that being in charge of a two-year investigation resulting in a 400+ page report and understanding anything about Bitcoin is pretty impressive for a 72-year old man. I'm sure there were plenty of smart people working under him, but I still think it's impressive.</comment>


California needs to rethink urban fire risk after wine country tragedy - <AUTHOR> https://theconversation.com/california-needs-to-rethink-urban-fire-risk-after-wine-country-tragedy-85966 <comment><USER2> [http://mcvoy.com/lm/fire-WEEDS.pdf](http://mcvoy.com/lm/fire-WEEDS.pdf)

is a good read for DIY types that want to protect their homes.

tl;dr: circular nozzles all the way around the building spraying out. Why out? Because wind is always the problem and the wind will blow the water back on the house. Tested and proven to work better than gel.</comment>


Another Case of Obscure CPU Nondeterminism - <AUTHOR> http://robert.ocallahan.org/2017/06/another-case-of-obscure-cpu.html <comment><USER2> rr := [https://github.com/mozilla/rr](https://github.com/mozilla/rr)

rr is a lightweight tool for recording and replaying execution of applications (trees of processes and threads).

<comment><USER3> Wow, only learned about rr today - an amazing project! Google for instance reported a sizable number of "flaky tests" which tend to pass but sometimes fail. Always running tests under rr would take care of that (since each failure would be reproducible.)

This is a huge deal. While I prefer the Cilk approach (automated debugging pinpointing places which can theoretically execute non-deterministically), it's not always applicable and isn't always or even often applied where applicable. This is definitely the next best thing, and in absolute terms, it's pretty damn good.

<comment><USER4> " Always running tests under rr would take care of that (since each failure would be reproducible.)"

That's not actually the hard part :)

It honestly really wouldn't help that much, even if it wouldn't be infeasible for other reasons (increased resource usage, even of their cited 1.2x, is a _ton_ , etc).

Even if you could completely reliably restore the state to a random _other_ machine than the one it ran on (IE possibly different arch/memory/etc configuration), and you met all the requirements, the main part rr helps you with is reproducing the failure, which, most of the time, google could actually do anyway.

The hard part is _figuring out what went wrong_. Remember Google already has asan, ubsan, and tons of other stuff running. So the trivial causes are pretty much not occurring. It's not like people look at the flakes and say, welp, i messed up this one variable and that was that!

It's usually torturous debugging of trying to understand the set of conditions that have occurred.

IE The reason there are so many flakes is because there's so much that can go wrong. Not because people can't reproduce the failures.

Also note that in Google's world, RR would probably not be compatible with how the tests are run anyway (RR wants fairly exclusive to the perf counters, but the tests may be getting sampled), and for a set of flakes, perturbing the performance counter settings will change things enough to make them less flaky!

<comment><USER5> OTOH, what rr also brings to the table is reverse debugging, and _that_ makes these kinds of torturous debugging an order of magnitude easier.

So not only are you able to reproduce the error, but you're also able to go backwards to find _how_ it happened!

I, for one, barely use gdb anymore because reverse debugging with rr makes debugging _so_ much easier (well, technically, I still do use it, since rr is not an entirely new debugger, you still end up in with a gdb prompt).

FWIW, one of the first things I tried when I first used rr was to debug a crash I had debugged years earlier, that was due to a miscompilation by GCC. As that had happened years earlier, I didn't remember the details of what code was miscompiled in what particular way, but I do know that debugging that took a long time, and I had only figured it out by chance because valgrind pinpointed to related code. With rr it only took minutes to find the root of the crash.

<comment><USER4> "So not only are you able to reproduce the error, but you're also able to go backwards to find how it happened!"

For some (and i'd guess a bunch of the people i mentioned in the parent comment), they definitely find this easier, but just to present a contrarian position: i actually don't. I admit to being weird - in a former life, i was a gdb maintainer.

I also was trained by people who believed the right approach was not to immediately try to find the sets of conditions and variables that caused your problem and declare victory, but to go and meditate upon the code and think about it until you understood it well enough to understand why this might happen even when you think it couldn't. That will often enable you to understand the code well enough to see what else is wrong.

(Again, i don't claim it's better, i just claim that's why i tend not to care about RR. The hard part for me is the thinking about the code, not the finding the sets of conditions and variables that caused a particular set of errors)

It's definitely the case that, personally, when i follow the "find conditions, fix bugs" approach, i tend to write much buggier code (even with good testing strategies) than when i follow the other way.

<comment><USER6> This reminds me of Linus Torvalds' distaste for debuggers.

I think eschewing debugging is fine for code you understand pretty well and when you already have significant information about the failure. But when those conditions aren't met, debuggers are very useful. (NB, if you use logging code and think "I'm not using a debugger!", you're just using a bad one.)

It's true that a good debugger tempts one to think less deeply about the code than one should, but that temptation can be overcome.

</comment></comment></comment></comment></comment></comment><comment><USER7> _commodity CPUs running user-space code really are deterministic in practice, or at least the nondeterminism can be efficiently detected and controlled, without restorting to pervasive binary instrumentation. We 're mostly winning that bet on x86 (but not ARM)_

I'm curious about that mention of ARM --- since I always thought it was a far simpler and more rigidly defined architecture with fewer edge-cases/undefined (more like implementation-defined) behaviour than x86.

<comment><USER8> [https://github.com/mozilla/rr/issues/1373](https://github.com/mozilla/rr/issues/1373)

This disappoints me, as I'd love to see rr ported to PowerPC, which is another LL/SC architecture that I suspect might run into this issue.

</comment></comment><comment><USER9> The story is that Intel later introduced XSAVEOPT etc to speed up XSAVE by only saving modified state.</comment>


PineTime Is a $25 Smartwatch / Companion for PinePhone Linux Phone - <AUTHOR> https://www.cnx-software.com/2019/09/15/pinetime-smartwatch-companion-pinephone/ <comment><USER2> A bit OT, but related: there are no cheap, simple, FOSS mp3 players. It used to be that you could get a Sansa which was flashable with Rockbox¹, had a decent battery life, cost around US$30 and would take SD cards. Those options have now disappeared and been replaced with devices that do not have enough memory to be flashed with Rockbox. The default OS on these is terrible compared to Rockbox.

Would love it if someone would make a simple player which was controllable by the user.

1\. [https://www.rockbox.org/](https://www.rockbox.org/)

<comment><USER3> I have the exact same problem: two (Rockboxed) Sansa Clip Zips I've taken everywhere for years, from snowy mountains to the beach; one is already dead and one about to take its final breath. They're not available anymore for purchase and the few used ones remaining in still good condition are sold ridiculously overpriced. To me there's only one solution: Either develop a a player from scratch or port a subset of Rockbox (no games, FX, etc.) on a small SBC plus added display, DAC, SD and LiPo circuitry. The SBC could well be the ESP32 which would add wireless functionality; *Pi and other Linux boards would be tremendously overkill for the task. Shouldn't be that hard for skilled developers, and it would surely sell among those of us who don't want to use a cellphone.

<comment><USER4> Why don't you want to use a cellphone? Privacy/surveillance and/or stimulation addiction? I miss my old mp3 players and RockBoxed iPod classic, and I've been meaning to get rid of my cell phone as well. Really I'd prefer a pocket computer to a cell phone, surprised there isn't anything like that for sale.

<comment><USER3> "Why don't you want to use a cellphone? Privacy/surveillance and/or stimulation addiction?"

Pretty much all of this, plus not risking a device that I have to rely on for communications. Each of my Sansa players fell like a dozen times without getting a single scratch because they were very light and the screen was small and sturdy; had I used a cellphone I would probably have destroyed at least its screen multiple times or ruined it from prolonged exposition to salty air at the sea. Also I don't use smartphones due to the above points, and I still have to see a traditional phone with a decent player (and a decent camera, but that's another story).

The PinePhone might change this, however. Silently waiting for it to hit the market.

<comment><USER2> That's pretty much it on all points for me: light and small with a sturdy plastic case meant that dropping it was not disastrous.

Am definitely interested in the PinePhone, but suspect that its dimensions will mean that I shall be restricted in not using it while running/cycling and (more importantly for me) as a cheap audiobook player that I fall asleep to in bed and occasionally drop out of the bed onto the floor or sleep on top of.

<comment><USER3> A hint for the folks at pine64: please take into consideration the PinePod :)

<comment><USER5> Check on my response :-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Why isn't e-ink perfect here? A watch is perfectly usable in monochrome and is used in bright daylight which would favor high contrast and viewing angles. Plus battery life is good. Turns out there has been a few on the market but nobody really wanted them. Strange.

<comment><USER7> I use Garmin Instinct with monochrome display. It has so many features, even a simple navigation system, and it's battery goes 2 weeks. I love it.

I can't understand why people want to have color, fancy screens on a watch. Do we need colors to see the time? A calendar notification? Heart rate ?

A watch should serve information without distracting, and most importantly, I should be able to go out without thinking about battery life of my watch. It should be reliable enough to carry it in the arm.

<comment><USER8> To you it makes zero sense, to a ton of other people it does. I love the value having statuses conveyed to me in color, it allows me to quickly process information.

<comment><USER7> Right, changed my comment

</comment></comment></comment></comment><comment><USER9> Nice! Multi-day battery life and an NRF52 sounds like a great starting point.

I really miss Pebble, which this sort of evokes. Their 'Time' series of watches were incredible, with awesome battery life and a great C SDK.

How has Pine's recent hardware and software support panned out? I remember people saying that the original PineBooks bordered on unusable, but I'm sure they've made a lot of progress since then and I keep meaning to try one of these libre hardware platforms.

<comment><USER10> The nRF52 is quite good in terms of the vendor's software support, I can't wait to try and turn the watch into a U2F key.

</comment></comment><comment><USER11> [https://aliexpress.com/item/32933638584.html](https://aliexpress.com/item/32933638584.html)

(from [https://www.reddit.com/r/linux/comments/d3y87q/is_pine64_sca...](https://www.reddit.com/r/linux/comments/d3y87q/is_pine64_scam/))

<comment><USER12> Why doesn't this come with a reasonable open sdk ? Why none of the Chinese smartwatch companies offer that ?

Seem like a big opportunity.

What's different in the Chinese business culture - that nobody tries this opportunity ?

<comment><USER13> At the risk of sounding Nationalist or Jingoist... it seems that innovation isn't something that comes easily to many Chinese companies. Innovation is done by American/Western companies, and many Chinese companies piggyback off of Western innovations. Since many Western companies produce their products in China, it's easy for that factory to just keep the production lines running. When Apple asks for 1,000 products to be made, the Chinese factories can make the 1,000 products for Apple and then 5,000 products for sale on Alibaba at basically no additional cost.

When you're selling hardware at-cost and copying OSS software to run on it, it's not really profitable to add additional software maintenance costs like producing an SDK or offering English-language software support. I'm 100% sure there are Chinese companies who offer software and English-language support, but I am also 100% sure those Chinese companies charge similar prices to Western companies, negating the benefits of Alibaba products.

You certainly do have Chinese companies who attempt this: Huawei and Xiaomi come to mind. But their products sell at prices very comparable to Western companies. For the true "Chinese prices" companies who only sell on Alibaba etc... if they're offering Western support and Western innovation, there's no way they're selling at Chinese prices.

<comment><USER14> There's tons of innovation occurring in the Chinese hardware market. For consumer devices, I'd say there's much more innovation happening in Shenzhen than in San Fran.

The issue is that they have their own ecosystem for software that doesn't really play nice with western IP, so you sort of get stone walled if you come in talking English. [https://www.bunniestudios.com/blog/?p=4297](https://www.bunniestudios.com/blog/?p=4297)

<comment><USER13> From skimming your article... is it really innovation if the research and development is stolen from Western countries?

>very small teams of engineers can obtain complete design packages for working phones

They can obtain complete design packages for working phones because those design packages were stolen according to Western laws and customs.

>we also feel that shying away from reverse engineering simply because it's controversial is a slippery slope

It might be controversial in China, but it's illegal in many Western countries.

>Unfortunately, queries into getting a Western-licensed EDK for the chips used in the Chinese phones were met with a cold shoulder

So instead they decided that stealing the work of Western companies would not and could not be punished in China, so they just stole it.

"Doesn't play nice with Western IP" sounds an awful lot like theft with a fancier name.

<comment><USER14> For context, the blog post is written by an American born MIT graduate who tries to embody the classic MIT hacker ethos. His is a remarkably western perspective in it's axioms.

</comment></comment></comment></comment></comment></comment><comment><USER15> I think I had one of these kicking around and gave it to my mother in law.

I'm developing a smart watch product. I'm working with a Chinese company that does the firmware dev.

If there's someone out experienced with SWD etc and might be interested in collaborating on this device please drop me a line. As far as I'm concerned the more open the hardware the better.

<comment><USER16> > If there's someone out experienced with SWD

There seems to be no way to contact you other than something called "twitter" as per your profile here?

<comment><USER17> Pine64 has email, irc, discord, telegram and matrix

I only know it's #pinetime:matrix.org

</comment></comment></comment><comment><USER18> This looks pretty similar to the Amazfit BIP, which gives about 45 days (DAYS not hours) of battery life with an always on e-ink screen.

What the Amazfit is really missing is an open SDK or way of running apps on it, then it would be pretty much perfect.

</comment><comment> yjftsjthsd-h At that price point, this has a pretty good chance of growing a good community around it, which would be really nice.

</comment><comment><USER19> This is a for-sure buy for me. I have everything from OpenMoko to Creative Zii, to Pandora and back again in my 'utility drawer', and if .. someone .. who is not the Oscilloscope Watch guy .. will make a nice smart watch, without all the bloat and fancy spy'ing, and with 100% open source, then I am _IN_.

It just seems like a no-brainer. A Linux Watch. Please won't someone just make it. (Bonus points if it has probe inputs...)

<comment><USER20> Me too. I just want a hackable smartwatch. I want to customize it so that when I press one of its hardware buttons, it'll start recording a memo, and later syncs it to my laptop when in the same network.

I need the recording to start in sub-second time, so there is no barrier to start, which makes my use-case unsuitable for Android-level "hackable."

<comment><USER21> This thing has 512/256 KiB Flash + 64/32 KiB SRAM. It most probably doesn't even has a mic.

</comment></comment></comment><comment><USER22> If this thing is a hackable watch, I'd be more than happy to even pay $1000 for it. I miss my Pebbles, and being open makes me exited to not be chained to Apple or Google

</comment><comment><USER23> The watch housing is almost exactly like a Fitbit Versa. Kinda curious if the housing is made by the same manufacturer.

<comment><USER24> Is there a difference if another manufacturer got hold of the exact same tooling?

</comment></comment><comment><USER25> Is there a similarly priced smartwatch that works with Android?

<comment><USER26> [https://aliexpress.com/item/32933638584.html](https://aliexpress.com/item/32933638584.html)

(shamelessly stolen from the other comment)

<comment><USER25> interesting, thank you!

</comment></comment></comment><comment><USER27> Has anyone come across good smartwatch hacks to add a hackable microphone to your wrist?

<comment><USER28> better yet would be a mic array. I don't think this Nordic chip can have multiple i2s inputs

</comment></comment><comment><USER29> Anyone here use a pinebook? I've been thinking about getting one of the 11" 1080p models @ $99, but really want to see one in person first. It seems very likely to just be e-waste on arrival.

</comment><comment><USER30> I was hoping it ran the Pine email client.

</comment><comment><USER31> Ah yeah, 2019 the year of the Linux Phone.

<comment><USER32> Every year is the year of the Linux Phone because Android exists :)</comment></comment>


TypeScript Roadmap 2019 - <AUTHOR> https://github.com/Microsoft/TypeScript/issues/29288 <comment><USER2> I dream about typescript becoming statically compiled language. Or hybrid language similar to dart and flutter, which in dev mode is interpreted for fast reload times and in production it gets compiled to native code.

<comment><USER3> It is only statically compiled. You run the _tsc_ command to compile the TypeScript code to JavaScript output.

<comment><USER4> I think the OP meant that it should compile to native code, which is not supported today.

</comment></comment></comment><comment><USER5> Most people do not care about types, they care about smart intellisense and detecting errors such as a misspelled property.

<comment><USER3> I disagree. Perhaps I am in the minority on this, I don't know. I care about types and don't care about intellisence. I write lots of atomic algorithms that are super-independent, independent of each other but also compensating for the changes by each other, and make heavy use of scope. It is very important to my code that things execute efficiently and accurately.

<comment><USER5> I do not understand what you mean. But it sounds like you are into functional programming !? Which works fine without type annotations. For example:

const sum = (number, number) => number+number

Where type annotations becomes unnecessary verbose.

<comment><USER3> True. Consider this example:

        props.removes[cc] !== props.last.margin

TypeScript's strict types will see the error if the those are not the same data type. A TypeScript aware editor will yell at me before I compile the code. Perhaps what I really wanted is:

        props.removes[cc][0] !== props.last.margin

In JavaScript I would have to execute the code. If the code doesn't throw an error then I would have to examine the output to see if the resulting data structure matches what I expect. If not I have to run tests and track down the error. Then once the error is found and resolved I have to write unit tests for this scenario.

<comment><USER5> You can use an auto-generated intermediate format when running the tests, that check each member object, give test coverage, etc. Eg. a tool that parses the code and inserts a bunch of checks above each member access. So you start with plain JavaScript, and you ship plain JavaScript.</comment></comment></comment></comment></comment>


College Student in Queens Is Charged with Conspiring to Support ISIS - <AUTHOR> http://www.nytimes.com/2015/06/17/nyregion/college-student-in-queens-is-charged-with-conspiring-to-support-isis.html

<comment><USER2> lets break it down:

1) Posts views on twitter that are controversial to say the least, e.g., 'Al Qaeda was "getting too moderate,"'

\-- Not illegal, but will definitely put you on the Gov radar, it's probably at this point he had some surveillance on him (through web or otherwise)

2) On two consecutive days in March, a Port Authority police officer saw Mr. Saleh walking on the George Washington Bridge and looking around.

\-- Circumstantial at best

3) evidence that he was "translating ISIL propaganda into English."

\-- Not illegal that i know of, though they don't specify if he's not a native speaker. If he could read it already in Arabic why is it a big deal that he's translating it?

4) receiving laboratory training in electrical circuitry at his college

\-- he's a student..."honing skills that the complaint called 'useful in the construction of an explosive device.'" Conjecture and profiling

5) conducted extensive online searches for materials for an explosive device, the complaint says, including Crock-Pots, beads, propane, vacuum cleaners, lamps and watches. A watch was the only one of those materials that the complaint says he bought.

\-- In my embedded systems class in undergrad we made a 'movie-prop bomb', had a countdown timer, monitored wires, display, etc. Fun project, i'm sure a lot of my searches during that time got me on a few lists.

6) walk into a spy store in Queens that sells microphone detectors and hidden cameras, though he left without any bags. He later searched online for disguises, including beards and wigs.

\-- as the article states he was being followed by agents, i'm sure that's enough to make anyone paranoid

7) conversation between a confidential informant and Mr. Saleh in May, during which Mr. Saleh said, "Well I'm in N.Y. and trying to do an op,"

\-- this is probably the most damning piece of evidence, but it relies pretty heavily on the quality of the informant

8) agents saw Mr. Saleh and two unnamed co-conspirators try to elude a surveillance car in their green Jeep Cherokee by speeding through a parking lot with their lights off and pulling over. Later, around 4 a.m., near the Whitestone Expressway in Queens, Mr. Saleh and one of the co-conspirators got out of the Jeep and ran toward the surveillance car

\-- he was being followed and got scared, could have been running toward it in an effort to confront whoever it was to tell them he'd had enough

I'm not saying there isn't a case here, but a lot of it seems shaky, a few pieces got him on their radar and after that, well, if you search hard enough you'll usually find what you're looking for</comment>


Show HN: A simple wind speed and direction probability model (Jupyter Notebook) - <AUTHOR> https://github.com/cqcn1991/Wind-Speed-Analysis <comment><USER2> This is really impressive and the probability distribution plots are excellent. I recommend adding a lot more explanation text (Markdown/Latex maths) as this would help people like me who have never done any calculations with wind and might help yourself in the future.

Will you understand what you have done in 2 years time?

<comment><AUTHOR> Thanks for the suggestion, and that's why I'm still working on the paper and related documentation.

Additionally, my Jupyter Notebook is getting too long. I'm thinking how can I decouple it into several parts while still make it easy to use. That's the main reason I haven't add any text in the it. The notebook would get even longer, making it extremely hard to read.

</comment></comment><comment><AUTHOR> I'm not sure if this is the right place to post it. It's just a simple probability model of wind speed and direction, that I made using Jupyter Notebook. This is my master thesis (And I'm still working on the paper).

</comment><comment><USER3> This is awesome – I've been passively looking for someone to do this and finally you have. I'll have to take a longer look at it (and respond in more breadth/depth), but great work and good luck with your thesis!

<comment><AUTHOR> Wow, didn't expect there would be a guy with similar research interest. That's interesting.</comment></comment>


Starting to explain P vs NP - what do *you* find confusing? - <AUTHOR> http://www.penzba.co.uk/cgi-bin/PvsNP.py?FrontPage

<comment><AUTHOR> This is very much an early stage, but as with startups, if you're not embarrassed by it then you waited too long to launch.

My intention is to go through enough of the details to show that there really are problems that are NP-Complete, and to give enough of the details that someone truly interested in the topic has a handle on the concepts, terminology, and what to look for to get more details.

I'm interested to know what you think needs expanding or better explaining.

Let me know!

 _Added in edit: To whomever is trying to edit, feel free to email me for a login._

</comment><comment><USER2> For me, P vs NP is a very clever bit of theory, and proofs of NP-completeness are actually kind of fun, but the more interesting question that it skirts is this: _How do we talk about the speed of different algorithms?_ That's a much bigger topic, but usually a lot more relevant. If you're someone with code who's in a hurry, you benchmark as realistically as you can manage and hope you didn't flub the implementation, and that your data collection was statistically okay. If you're Donald Knuth, you define a simplified but somewhat realistic processor model and derive expressions for how much time your algorithm takes, and there's your answer. This is nice, but a lot of work, and it becomes positively nightmarish if you want accuracy on modern processors. If you're an Intro to Algorithms class, you look at the asymptotic complexity -- mergesort is O(n lg n), the (NP-complete) 3SAT problem is O(2^(n^k)) for some constant k, and so on. This gives good intuition a lot of the time, but not always. Insertion sort typically beats mergesort for small n, there are a lot of 3SAT problems that can be solved very easily, caches are all the time doing crazy stuff, and in general the world is complicated. We're interested in getting computers to solve problems in a reasonable amount of time; what are we to do?

I know this isn't exactly an answer to your question, but I really wish that people had said more about this in college, and I wanted to talk about it.

</comment><comment><USER3> When we discuss solving whether P=NP, are we talking about a theoretical shortcut that allows us to not have to calculate everything? Or is it quantum computing that simply allows us to efficiently just compute everything because no shortcut is likely to be discovered?

<comment><AUTHOR> Thanks for your response, but I'm having trouble making out what your actual question might be. Let me set the scene:

The class _P_ is those problems that can be solved in polynomial time.

The class _NP_ is those problems such that an alleged solution can be checked in polynomial time.

Every problem in _P_ is also in _NP_.

We don't know if there are any problems in _NP_ that are not also in _P_. That's what we want to know.

So given that, what was your question?

<comment><USER4> This was kind of a strange way to answer the OP's question, although I think you did answer it. I believe he was asking whether "solving NP" means "finding polynomial time solutions to NP problems" (the traditional way to "solve" P?=NP) or "creating machines that through quantum magic can simply plow through NP problems despite not having a polynomial time algorithm for them".

I think the OP assumes that a quantum computer would indeed be able to do this, but I don't know whether that premise is true or not. I have heard this question phrased often times as "Does P=NP still matter in a world of quantum computers?". As I am not an expert on either P=?NP or quantum computing, I have no idea.

So, given that, it seems you are affirming that you are referring to just the P?=NP question and not the "practical" question of whether we can get around this through other means (such as quantum computing).

Edit: revised first sentence since I now think you answered his question.

<comment><AUTHOR> It certainly wasn't intended to be condescending, I just genuinely don't understand the question.

      > When we discuss solving whether P=NP,
      > are we talking about a theoretical
      > shortcut that allows us to not have
      > to calculate everything?

I can't find any way to answer this question. We are asking whether there is an algorithm that solves a problem in NPC in polynomial time. I don't understand the question about a "theoretical shortcut," nor what it means not to have to "calculate everything." I am assuming there is a sensible question in the OP's mind, but it's not expressed in a way that makes sense to me. That's why I tried to state the question clearly and succinctly, to provide a basis for a follow-up question from the OP.

      > Or is it quantum computing that simply
      > allows us to efficiently just compute
      > everything because no shortcut is
      > likely to be discovered?

We're not talking about quantum computing, we are talking about classical algorithms.

Does that help?

<comment><USER4> I made a few edits to my original post as upon further reading (before you posted your reply), I did not find it condescending and in fact thought you did kind of answer him.

Also, I feel a little weird replying here since it was indeed the OP's question and not mine, but I'm kind of curious about this too now, so just know that this obviously just represents my own thoughts:

The OP's question was simply phrased in a non-mathematical way (something you will have to get used to if your goal is to teach this to people who are not familiar with this problem ;) ). By "talking about a theoretical shortcut that allows us to not calculate everything", I believe he means "finding an algorithm that allows us to not have to check every possible solution in the solution-space". Kind of how binary search is a "clever theoretical shortcut" to not have to check every index of an array. A lot of problems are exponential time because you end up having to check "basically" every possible permutation. So I think he's getting at "finding a polynomial algorithm" for the problem.

The second part then proceeds to ask whether you are considering the implications of quantum computing to this problem. I guess the answer you provided is "no", but now I would like to push you a little further as you want to write a website regarding this problem, and you seem to know a lot about it, and this is certainly a question I have heard a lot. Perhaps the answer is simply "quantum computing would not affect NP problems in any practical way", or "we just don't know", both of which would be perfectly satisfactory answers.

<comment><AUTHOR> Thank you - useful feedback. I'll be looking to make changes to take your comments into account. It also gives me an excuse to get in touch with a friend who's working on quantum computing.

It's kind of a shame that it didn't get more upvotes, and hence the chance to be seen by more people. This feedback is exactly the sort of thing I was looking for. Oh well, never mind.

</comment></comment></comment></comment></comment></comment><comment><USER5> Yes sorry, realised just before you posted that this was HPP, not the TSP subset I'm familiar with where all cities are connected by their Euclidean distance. [I deleted my original post which asked why the TSP problem was described as _a_ path, rather than the shortest.]

</comment><comment><USER6> Not P vs NP so much, but I have a hard time keeping straight how all of the complexity regions are laid out in the global complexity space. If you could explain how they relate and make a nice picture you'd be a hero.</comment>


6 Ways You Can Create a Referral Program That Works - <AUTHOR> http://ssqt.ch/1xu1d1U

<comment><AUTHOR> Referral marketing isn't easy.

Some companies like to think it's a solution they can build themselves but the truth is, referral programs are complex.

They take a ton of effort to implement and maintain just like any other marketing platform would need.

At the same time, you know your company needs a referral program. So where do you start?

We're here to help you out with some best practices that we've picked up in our day-to-day so you can start to understand the approach you should take to implement and improve your referral marketing strategy.

Read more: [http://www.referralsaasquatch.com/6-ways-create-referral- pro...](http://www.referralsaasquatch.com/6-ways-create-referral-program-that- works/#ixzz3FfY7Qgwj)</comment>


Early employees take the most risk today - <AUTHOR> https://medium.com/@tikhon/founders-it-s-not-1990-stop-treating-your-employees-like-it-is-523f48fe90cb#.c6u481pwn <comment><USER2> Great, great article.

I'd like to add: This, I think, is one of the big reasons why startups prefer hiring young people (ie, recent grads) - young people just don't know any better. They have the barest idea (if any) what dilution, ratchets, preferred participations, etc does to their already minuscule equity package.

"OMG I'm getting 70,000 shares!" is what I thought about my first startup. Wasn't even offered (and didn't bother to think about) anything else.

Perhaps I'm projecting too much of my ignorance back then on newly minted grads now, but it's safe to say that lack of experience in the myriad of different ways things can (and most likely, 99% chance) will devalue the work I'm willing to put into a company at 80+ hour weeks.

The most inane argument I hear from founders nowadays is "we just got funding, so we're de-risked". Nice try. Just cause you sold someone with money to burn (VCs have a bias to action - "gotta get that IRR to our LPs in 10 years!") does _not_ mean you've de-risked anything. Proper de-risking comes from finding a real product-market fit, with achievable financials metrics that pave the way to real profitability. Anything else is just greater fool theory - hoping a greater fool comes around and buys the company's story.

EDIT: Member notacoward has a great comment about rank and file employees also not appreciating the back-end commitment usually required at an acquirer. In the highly "fortunate" event where the startup is acquired, there's usually at least a 2-3 year commitment after that fact to get liquidity. This is _assuming_ liquidity is even available! With the ever-telescoping horizon to an IPO for even the "unicorns", I wouldn't be surprised if most rank and file employees are committed to 6, 7, even 8 years to achieve full (diluted) value of their option packages.

<comment><USER3> It's fair to note there's a significant amount of risk in hiring recent grads, because largely they aren't great at actual engineering, just coding.

<comment><USER4> Isn't the armed forces model relevant here, which also happens to fan out:

      "Experienced" soldiers work on the strategy while
      new recruits work in the trenches.

<comment><USER5> If you're developing software and there's a lot of "trench work" that usually means you're doing it quite badly.

<comment><USER6> How so? Doesn't this completely depend on the actual product being built?

</comment></comment></comment></comment></comment><comment><USER7> Nice piece. Many good points, but my favorite was this one.

"they need to spend years at the acquirer for whatever the founders and m&a department decide behind closed doors."

That's an under-appreciated risk. Of the ten startups I worked at, two went this route. For one, I'm pretty sure I was the last person to leave voluntarily; I had trouble finding someone to take my resignation letter because they were all in negotiations. Some of my coworkers ended up working for Symantec. At the other one, a bunch of us ended up working for EMC. At least that worked out OK financially, but it was _not not not_ a choice any of us would have made for ourselves. Not a one. We'd all had that option before, and not taken it. Since acquisition is a far more common kind of outcome than IPO, even for "successful" exits, that's worth thinking about.

Employees have always shared more of the risk than founders and investors would like to admit. That's part of the package, and I was OK with that for a long time. Nowadays, it seems like the share of risk is even larger and the share of success even smaller. I guess it's still worth it as a career- building move, if you're that way inclined (Google doesn't look bad on a resume either), but as a way to make good money it's becoming kind of a bad deal.

<comment><USER8> I dunno about the amount of risk, but at least the risk is quite well-defined for the employees from the start. You get your salary each month, and maybe something on top of that. You might learn something in your job, or maybe not.

Founders have to start with their own savings/debt and salary in the beginning is usually zero. Of course situation changes if they get investors etc. But I would say that the risks are really not that easily comprehensible for founders.

<comment><USER9> In my experience _talented_ early employees tend to take a tremendous amount of insufficiently-compensated risk. The founders can of course lay them off at any time, dilute them, give them paychecks that bounce, outsource their jobs after a year or two, sell so much equity that employees stay underwater or barely in the money, etc. The founders take a lot of risk themselves, but they are in control, and they usually reward themselves for it. Whereas volumes could be written about early employees at successful companies who maybe got a solid bay area house downpayment out of their stock options, after working 60+ hours a week for ten years.

</comment></comment></comment><comment><USER10> I have to respectfully disagree with this article. While it may be spot on in some scenarios, it couldn't be further away in others.

As a co-founder, I didn't take a salary until a year into the startup (same with my other two co-founders). Even when we received our accelerator funding, all of it went towards our first hire's (an engineer) salary and operating expenses. At this point, our risk was significantly higher, not slightly. If the company didn't succeed, I can tell you our first hire was next in line for a cushy market job, and he was being actively poached, not us.

After we graduated the accelerator we raised a ~$1M seed round. We hired more two early team members at market salaries. Each of the co-founders were taking $33K salaries. Why? We wanted the budget to hire great people. So no, they definitely not a similar pay cut. In fact, it's increasingly hard for early stage startups to hire good talent at less than market rates because there are plenty of amazing startups hiring above market. Our risk at this stage was even higher, because failing would burn most of our bridges with our new investors (maybe a couple wouldn't hold it against us), where as if our engineers went on to start something, no investor would think twice about their history working at a failed VC-funded startup.

We didn't increase our salaries again until we were generating revenue. Even now, ~four years in, I'm taking $20K less than the starting salary for a junior person in the role I have. While I want to increase that a little more as our revenue grows, I don't think it's fair to take a market salary at our stage.

I'm not complaining, but to say being an early employee is a rotten deal is unfair. If our startup goes under, I definitely have the more rotten deal. It only looks like I had the better deal if we succeed.

And if you want to start a startup, I encourage it, that's the only way you'll know how truly hard it is.

NOTE: This comment is a rehash of a comment I made on a similar statement. I am reposting it because I feel like it addresses this and sheds a little light on the other side of things.

<comment><USER11> I think your situation differs significantly from the one the author is depicting. You sound like you treat your employees correctly, offering them market rate compensation instead of a carrot on a stick.

<comment><USER10> It's honestly an engineer's market. Nobody is forcing them to take these below-market jobs for crappy options. If they keep taking them, nothing will change. If you would rather have market salary and little to no equity, most founders are willing to accommodate. But I guarantee that years later when the startup is worth something or exits they complain that they got a shitty deal (when they weren't willing to take on the risk).

</comment></comment></comment><comment><USER12> I agree with this. I work at a well-funded startup, but despite the funding, most of us are working for below market wages. I'm employee 22 and my options are about 0.02% of outstanding shares.

It's disappointing to me to see so much disparity between the compensation for C-level and VP-level versus engineering. Without engineering, there would be no product to sell and nothing for investors to invest in. Ideas are nice, but implementation is hard.

<comment><USER13> > It's disappointing to me to see so much disparity between the compensation > for C-level and VP-level versus engineering. Without engineering, there > would be no product to sell and nothing for investors to invest in. Ideas > are nice, but implementation is hard.

It's exactly what you'd expect when programmers are willing to sell their birthright for lentil stew.

Frankly, most C-level executives at a small startups are glorified secretaries taking care of the paperwork for the people who provide most of the actual value. They get paid more because they've played the social game well enough to persuade engineers to work for them instead of the other way around.

<comment><USER14> I work at a big company, and I also consider most C-level executives here to be glorified secretaries. All they ever do is write emails, stare at some charts, and yell at engineers to write code faster. What's most annoying is that sometimes they pretend to understand engineering challenges -- they learn some jargon and start throwing it around. That makes things worse; a little knowledge is a dangerous thing.

We engineers are nothing but servants to these people.

<comment><USER15> > _We engineers are nothing but servants to these people._

Which is funny you say that because apparently the "SV elite" think quite the opposite: [https://twitter.com/sama/status/641281287660007424](https://twitter.com/sama/status/641281287660007424)

<comment><USER16> Career advice from a VC is given with the VC's interest in mind, not yours.

<comment><USER15> Exactly my point :)

</comment></comment></comment></comment></comment></comment><comment><USER15> One thing that's not discussed enough in the context of employees compensation (especially early ones) is prestige. Many people join startups because of the promise that that company will become the next Google. They see peers who follow the same logic (Marissa Mayer, the PayPal Mafia, any PM at Google in the early 2000's, etc) and see what fame, riches and following those people gain as a result of being part of the early days of a massively successful company. This is also why YC companies categorically can attract better talent, because even if the company fails, you can still tell your next potential employer you worked at a "YC backed startup". It's almost the equivalent of a Stanford degree. So, if you're an employee of a company that is already vetted by a number (i.e. amount of funding) of well-known backer (i.e. YC), you're risk is massively reduced given the insane amount of recruiting opportunities available.

<comment><USER17> Just as a quick aside of the prestige thing. It is a lot easier to get "prestige" by being a founder of a barely successful startup than it would be to be an early employee of an extremely successful one. The whole startup ecosystem is very friendly to founders in this respect.

And when it comes to recruiting, you are much better off getting a job at a large prestigious company like Google, Facebook, Amazon than you would be at a random startup. The quality of engineering at a random startup, even YC startups, is extremely low when compared to large prestigious companies. This is due to the fact that the engineering talent at startups is generally below that of employees at (Google|Facebok|Amazon|etc), and startups are incentivized to ship stuff quickly and not necessarily work on engineering quality software. If your goal is to found a startup, then maybe you are better off working at another startup to pick up a more diverse set of skills. But if your goal is to get hired as an engineer, a big prestigious company is way way better than a random startup to have on your resume.

</comment></comment><comment><USER18> > Back in the day, founders would go into debt to buy a hard drive. Some even > mortgaged their homes to keep things afloat.

I can remember my first company, Magicomm, in 1988 bought two 25Mhz 386's after we released our first BBS-based search engine and we literally went into pretty severe debt IE no paychecks for a month/living off raman, so this isn't just bullshit.

It really was that.

I still remember our first "partnership" offer (not sure what its called now)...."free" office space and $5k for 51% of the company from a local guy who owned a shady call center. I had to beg my partner not to take it, too.

My dad ended up letting us borrow a few $k and gave us a closet to work out of at his medical office.

</comment><comment><USER19> Note that the major risk for an employee isn't that the startup fails in 2, 3, or even 6 months. The risk is that 5 years down the line their stock ends up being worth 0-249k, but they gave up 250k in salary in the same time period.

We're also in the situation that we likely have no way to asses whether the risk we're taking is a good one. Especially if the company takes on investors. Especially as the years go by - it can be difficult to figure out when it's best for us to cut our losses.

An individual employee might not be taking on more risk than a founder. But in aggregate they might be.

<comment><USER20> Outside of evaluating the risk, are there an good calculators out there for doing the math on this with various exit scenarios?

<comment><USER19> Not that I know of. As a regular employee you probably don't even have access to enough information to do the calculation yourself.

</comment></comment></comment><comment><USER21> > Employees take the most risk today. Not the investors or the founders — it's > the employees.

I agree that in many places employees should be given more options and better compensation. I also agree that many founders don't realize how large the opportunity cost for talented people can be. But I also think that statement is categorically false.

Most founders I know work for several months (or years) for zero pay, and then pay themselves the minimum amount possible while the company is growing. The founders have opportunity cost too, and if the company fails they get nothing, too. Using the superlative that employees are taking the _most_ risk is often simply not true.

<comment><USER22> But is this true relative to the reward? It of course depends greatly on the individual. A senior SE who walks away from an offer at Google or Netflix to work for a startup could be forgoing as much as 100k a year in salary. Five years in that dev might have banked a half mil.

Yes the founders are giving up a lot too bit the equity they receive may be vastly higher.

It all depends on the numbers but adjusted for reward and equity? Yeah by that measurement I'd say its certainly possible that an early engineer is taking on the worst risk to reward ratio.

Lastly keep in mind that a founder who does not have strong tech skills may not be giving up as much in potential salary even if he or she works for "free". Again this all depends on the individual.

</comment></comment><comment><USER23> Or said differently, what do you bring to the table as a founder that I (as a highly talented employee) cannot immediately replicate on my own?

This gap has been getting very narrow lately.

\- Money? Not really; if we assume I'm coder #1, the cash cost of launching a product/service is <$100,000, well within the range of many mid-career folks with savings. \- Relationships? eh, Linkedin and Google can connect me with many people - most of whom would like an alternative source. \- Business model idea? Oh please, it's most likely been done before in an adjacent segment and well documented; actually, I'm not interested in a model that hasn't been. \- Technical / Process knowledge? um, that's why we're talking...

So yeah, if your goal is to take my contribution, give me 1% equity and keep 20%, it gonna be a difficult conversation...

</comment><comment><USER24> The typical founders spend maybe 6 months building a prototype on nights and weekends, then another six months full time without any pay, and then another six months at least at minimum wage. And then they usually never get beyond that, and are just out all those hundreds of thousands of dollars they would have otherwise earned.

As an early startup employee you might only get 1% as much equity as the founders, but you're also only taking 1% as much risk unless you're working for vastly less than market rates.

<comment><USER25> Source? Most startup founders pay themselves a market rate salary after funding[1] (even if it's seed).

1\. [https://docs.google.com/spreadsheet/ccc?key=0AgrWVeoG5divdE8...](https://docs.google.com/spreadsheet/ccc?key=0AgrWVeoG5divdE81a2wzcHYxV1pacWE1UjM3V0w0MUE&usp=drive_web#gid=1)

<comment><USER26> Data is the plural of anecdote:

"The founders whose companies die usually only earn small salaries. Before being admitted to Y Combinator, founders usually live off savings or taking loans. During the Y Combinator program, they use a one-off seed investment from Y Combinator of US$120,000 to pay living and business expenses15. If they go on to receive angel investment, they can pay themselves about $50,000 per year. With venture capital funding, this tends to increase to about US$100,000 per year"

(From the section on "What about the companies that died", namely, the case for most founders.)

</comment></comment></comment><comment><USER27> In the recent Square IPO, it showed that Jack Dorsey has an ownership stake worth $1.5 billion, while the (estimated) 1000 employees have an average stake of roughly $300K.

Think about what you can do with one and a half BILLION dollars. Now think how far $300K will get you in the bay area.

This is completely typical and representative of the disparity between founder and employee equity.

<comment><USER28> The math that you did in the Square IPO thread was completely and totally wrong. Any conclusions you drew from your results are based on a false understanding of reality.

1\. [https://news.ycombinator.com/item?id=10389397](https://news.ycombinator.com/item?id=10389397)

<comment><USER27> Ok, please post the correct math, then we can compare and see who got closer. Jack's percentage is spelled out in the S-1, along with the top execs, directors, and investors.

If you have any better data, including median equity and other percentiles for non-founders, that'd be very useful. Thanks.

<comment><USER28> The "13 people" you thought owned 61.5% of the company were VCs who did not own those shares as individuals but as managers of their VC funds.

<comment><USER27> I didn't mention exec/directors in my original comment above, only Jack at $1.5B and average employee at $300K. Which of those is totally and completely wrong, and why?

Are you saying that employees retained the full remaining 38.5% ?

<comment><USER28> Yes, you have massively miscalculated the % of the company owned by employees.

On a further note, even once you get that number right, it silly to talk about the average employee stake from that number. You're dealing with a power law here where talking about an average makes very little sense.

</comment></comment></comment></comment></comment></comment><comment><USER29> no, we don't.

There are plenty of reasons to argue for more equity but risk is not one of them. If you're good at what you do you can get a job tomorrow anywhere and there is near zero stigma about being associated with a failed startup unless you're on the founding side AND you've failed multiple times.

<comment><USER30> The salient point in the article is about opportunity cost. When you take a 100K startup job, and could have been making 200K somewhere else, that's a very real loss. Now, those are made up numbers, and you need to plug in real ones to make an accurate assessment, but that's his point.

<comment><USER29> right, and that is completely valid to discuss.

I think it does a disservice to the other problems and discussion points to toss everything under "risk".

<comment><USER31> But what would you call it besides risk? ie you're gambling (risk) that your opportunity cost will be made whole (and hopefully even exceeded!) via a liquidity event.

<comment><USER29> I'm not denying that it is risk, I argue that it doesn't allow for the subtleties and nuances (opportunity cost vs responsibility increase vs positive/negative association after exit/failure).

There are a lot of different variables involved and a great many of them boil down to calculated gambles on the part of the employee and employers. Those are worthy of discussion and there are plenty of discussions to be had around those. But simply calling it "risk" and saying you need more of the upside is so simplified its nearly meaningless and impossible to have a conversation about with everyone involved having the same idea about what is being discussed.

<comment><USER30> There are certainly non-monetary benefits to working at startups, as well as costs. It certainly makes sense to include those as part of the calculation, but money is not a small part of that, either.

</comment></comment></comment></comment></comment></comment><comment><USER32> Founders probably aren't able to hire because they can't get enough money from investors to pay market salaries or because their company just plain sucks. Maybe they think that because they've convinced investors that they're onto something that it means prospective hires won't know better?

Put yourself in these people's shoes. Even if your company has a chance to be worth a billion dollars, you're going to have to do better than a quarter point. After several rounds of dilutions, a seed-stage employee with a quarter point of even a $1B company would end up with ~$1.5M. You've got to be offering people a 10-100X opportunity of what they'd get working at BigCos to get good talent, not 50% more.

Corollary: if you are giving engineers at your pre-series-A company less than a point and 50% of market salary, you are probably not hiring great talent.

<comment><USER33> And 1.5 isn't that much at poptel in the UK at one point all the employees where worth around $1m each.

No if only .coop had taken off (and we hadn't been screwed by ICAN) and the coop had brought us out ;-)

I know some on just retired from BT that has over $.5 million in stock from his various share saves

</comment></comment><comment><USER34> I think it depends a lot on the market you're in, how you've funded your company, and where you live.

A founder of a bootstrapped, remote company in Iowa has far more risk than almost any engineer in NYC or SF. Relatively speaking, if you are a not- terrible engineer in SF/NYC you can have multiple jobs competing for you within a day of your company going out of business.

A non-well-off or not-well-connected founder has comparatively little opportunities to "fail up" when their company goes out of business. I'm a founder of a bootstrapped, remote company, in a non tier-1 tech city. I'm the lowest paid person in our company (of all engineers). If we go out of business, our folks will have jobs in days. I won't. Does that mean I have more risk? In a certain dimension, yes. In others, definitely not.

Of course, nothing in my post suggests that early engineers shouldn't be paid reasonable salaries or have reasonable options. They should. But I don't think risk has anything to do with it - common decency does.

</comment><comment><USER35> Makes sense to me. I have no clue why people take shit salaries in exchange for a tiny slice of a company that will probably fail and if it succeeds, still not give them a down payment on a house.

</comment><comment><USER36> What's especially troubling is the difference between early engineers and early exec type hires. Engineers tend to get marginal salaries and not enough options. Early marketing, sales, ops hires tend to get more than _all_ the engineers, even if they join post series A as person number 40.

</comment><comment><USER37> So what you're saying is that more people should start companies? Maybe you're on to something...

<comment><USER27> He is calling something out as unfair, and your response is that more people should be unfair?

<comment><USER37> I don't think that what the article describes is a balance of fairness, rather an observation that employees are taking a lot of risk! The message to me is that you should probably think twice before joining a company. This is not a one-sided battle. Employees clearly have the power to start their own company, avoid risk, and reap the same rewards that so many founders are achieving.

Over time, if enough people are starting companies, then risk will have to be shifted back in the direction of founders and becoming an employee will become more appealing.

<comment><USER27> The opening paragraph:

> Why are we still using old 1990's cap tables and the same tiny option grants > for employees as we did back then? Is that fair? To whom? Is it the right > thing to do? I don't think so.

We're talking about fairness. Not the abstract elementary-school concept, but simply that employee equity compensation should not be wildly disproportionate to their risk (and, this is not counter-balanced by their salary or perks).

</comment></comment></comment></comment><comment><USER38> I joined a startup that went IPO and experienced how those options are worthless, funny enough my options are negative with current stock price!. Now if I decide to join a startup company I would just value the options precisely $0.00

</comment><comment><USER39> Everything written about here is in relation to VC funded companies. For people building companies without outside investment, and who pay employees with money, none of this is true at all and in fact sounds nonsensical.

</comment><comment><USER40> Have you considered forming a tech workers union? Collective bargaining would be very strong.

<comment><USER41> A professional guild - like lawyers, accountants, or actuaries - is a much better structure, IMO.

<comment><USER42> Plus nerdy folk love guilds.

</comment></comment></comment><comment><USER43> Unless you're a founder, joining a startup is a terrible deal. There's no two ways about it.

<comment><USER28> Because everyone should have the exact same risk tolerance as you. And if they don't, they're wrong. There's no two ways about it.

<comment><USER43> Both the odds and rewards are much smaller than most people assume. You can take all the risks you want - if the rewards don't justify it, it's a bad deal.

<comment><USER28> I agree with you that some people probably overestimate those two things.

But I also think that other people tend to lump all startups together with the assumption that the risk is more or less the same across all of them. In reality risk/reward ratio certainly varies by at least 10x across opportunities. Consider the difference between a seed stage company with no users and a product that doesn't even work yet vs a Series B company with significant traction and 10s of millions in the bank. These can be hugely different situations.

But, even if you ignore this, I come back to the concept of risk tolerance. No matter what #s you choose, there are certainly people out there who by dint of personality, age, or financial situation are perfectly willing to take on a lot of risk.

</comment></comment></comment></comment><comment><USER44> All fair points and something that should change, especially (imo) the clause around options expiry as well as %age.

I have just one honest (not coming from a place of sneer) question: did the OP follow his own advice in the startup he founded (Parse and/or Scribd)?

</comment><comment><USER45> If that were true, wouldn't you expect real estate prices around San Francisco not to be rising as fast as they are? Something is driving up wages around the startup hot-spots, isn't that a sign that there really isn't that much risk?

<comment><USER46> Nope.

The Bay Area is home to some major tech employers (Google, Apple, Oracle, Cisco, Salesforce, Intel, etc), and is also a major outpost for other big names (Microsoft, Samsung, Sony, etc). There are also a number of major employers in high-compensation jobs (finance, bio-tech, law). Even among startups, there is a big difference between a scrappy little company of three folks and a company like Uber.

Bottom line: there is lots of money floating around the Bay Area. As much as we might like to believe otherwise, the amount in small start-ups is just not that much.

<comment><USER47> There's also a lot of overseas money being invested in real estate, driving up the prices. The same is happening in Seattle.

</comment></comment></comment><comment><USER8> > if adding a particular engineer to the team increases the company's value by > 10% overnight

Btw, how do you prove that? For me hiring seems more difficult than that, you start to grasp the value of an employee after 6 months or so.

<comment><USER48> Take the case of Instagram, they hired several Android Engineers. They added 1 million new users on the 1st day the app was released.

<comment><USER8> Yeah, take this one company and generalize it, makes perfect sense. There are bazillion of companies and only one instagram.

<comment><USER48> Wow. Pretty hostile.

Where did I generalize?

I was just giving an example that you can consider.

</comment></comment></comment></comment><comment><USER3> I think I get the point, but I really had to work to keep reading it. The tone is relatively difficult to want to absorb without already being wholeheartedly on board with the premise.

The main problem I have is that it troubles me to feel a sense of agreement when the rhetoric is so emotionally manipulative, because parsimoniously, _I 've been manipulated_ into the agreement.

</comment><comment><USER27> Ok, let's see some numbers!

Founders, post how much % you have.

Employees, post your employee # and your %.

Let's see if this disparity exists.

</comment><comment><USER49> Reminds me of a post by Sam Altman: [http://blog.samaltman.com/employee- equity](http://blog.samaltman.com/employee-equity)

</comment><comment><USER50> Huh. Well written. I've been a founder and not a startup employee, and I found myself paying attention.

</comment><comment><USER51> A lot of hyperbole in this article. The overarching message might be true but the article basically reads as one sarcastic complaint to me.</comment>


Jenkins: One Year Later - <AUTHOR> https://about.gitlab.com/2019/09/20/jenkins-one-year-later/ <comment><USER2> >Where CloudBees/Jenkins has faltered is in its instability, mainly due to the thousands of third-party plugins it supports and the maintenance headaches they cause.

This is true, but also a bit disingenuous. The Jenkins plugins ecosystem is indeed a bit like an app store: the quality varies a lot. There is stuff that is not maintained, stuff that has security bugs, stuff that is just trivial jokes ([https://plugins.jenkins.io/chucknorris](https://plugins.jenkins.io/chucknorris)) and so on. But there are also hundreds of useful plugins to integrate with everything under the sun.

GitLab "fixes" that problem by having fewer features and integrations, so it's a bit disingenuous to say it's purely a negative point for Jenkins.

That being said, it is also true that you don't need to have everything that much integrated into Jenkins. It would make sense to better separate the job scheduling from the reporting, artifacts, etc. But it's not really an argument Gitlab can use since they're going that way too and want to provide an integrated environment.

</comment><comment><USER3> Unnecessary article piggybacking on Jenkins, unless Gitlab fears something.</comment>