The headless web - <AUTHOR> https://paul.kinlan.me/the-headless-web/ <comment><USER2> Probably the weirdest thing about the way Paul Kinlan writes and talks about "the web" and "native" is that he's really just talking about "Chrome" and "Android."

For example, see that chart in his "The table stakes" section? It clearly states that while the web "KINDA" had offline mode in 2014, in 2015 he upgraded that answer to "YES," by which he means that Service Workers became available on Chrome and Firefox.

But Service Workers aren't available on any browser provided by Apple or Microsoft. [http://caniuse.com/#feat=serviceworkers](http://caniuse.com/#feat=serviceworkers) says < 60% of browser share supports SWs today, in 2016. Apple didn't announce SWs in iOS 10, so earliest we can hope for is 2017, maybe 2018. MS will ship SWs for Edge later this year, but Edge is still a minority browser on Windows (because no one on Windows 7 can upgrade to it without upgrading to Windows 10).

Less than 70% of users will have what Kinlan thinks are 2015's "table stakes" this year.

And in the subsequent table, look at "Single click install and launch." In 2016, "Native: YES." Here, he's talking about Instant Apps for Android. But iOS doesn't support that at all. Perhaps they never will!

And did you "know" that the web just got Auth _and_ Payments in 2016? Of course you didn't know that, because it's not even remotely true. Maybe Apple will capture significant mobile-web payment share with the new iOS 10 Apple Pay API, but even Android Pay is struggling, and Chrome's new autofill APIs are even less established.

The auth story is the most fictional of all. We've had the ability to login with Facebook or Google for years, but only in 2016 did Chrome ship their Nth attempt at getting you to authenticate using Chrome APIs. So "now" we have auth? Even though nobody uses those Chrome APIs, and everybody just logs in with password or Facebook?

<comment><AUTHOR> I take your point and to some extent I am certainly hedging on the API fronts, but at this point we know it is technically a solved problem with rough consensus on the path for all browsers modulo deployment. The platform for a broad set of users has the capabilities and that is a good thing and that is something everyone can build to. I am also hedging that Apple will move towards a friction-less install model; personally I am not convinced that Instant Apps for Android _is_ the right thing but I am more concerned that the intent is there.

Are we going to wait until the platform is completely uniform until we take advantage of any of these things? Some will, some won't. We are already seeing those that build progressively in terms of taking advantage of newer parts of the stack are doing well with those elements.

I would say that the brunt of my article still holds valid even if you disagree on the platform capabilities, we are catching up with native platforms but we need excel in where the web is best, and I think that is embedability of content (although that seems like a lost art) is one core part where we need to do a better job and ease of interaction (i.e, no install).

</comment></comment><comment> jake-low I'm having trouble understanding the relationship between two pretty abstract ideas: this one, and the Richardson maturity model [0].

Are the two futures at odds? Kinlan seems to be imagining annotations embedded in Hypermedia, so that documents could be "displayed" by non-traditional "browsers" that didn't actually render the document but rather extracted data from it and displayed it in some other interface to the user.

Richardson describes a system in which web APIs can be explorable by software, so that the software doesn't need to be written to an API. In a sense, the API contains program-readable documentation about how to use it. This works as long as a set of "nouns" and "verbs" are understood commonly by the API and the client program.

I can't wrap my head around how these ideas would fit together. Are they the "read" and "write" halves of a post-browser Web? Or are they contradictory futures?

[0]: [http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html)

<comment><USER3> The Richardson 'REST API maturity model' describes how people commonly exchange HTTP payloads, how those systems can be augmented to get closer and closer to the ideas behind REST. Most people are perfectly happy with staying at levels 0 through 2, because HATEOAS is hard in the sense that you actually have to think about stuff like link relations, hypermedia mediatypes, and the semantic web. This is something most people on the 'normal web' don't even do properly, even though the 'normal web' is quite obviously hypermedia, and quite obviously an embodiment of REST. But despite its lack of deployment, Level 3 describes an API that has truly and unambiguously earned the right to call itself a 'REST API'.

In REST, these 'link relations' are extremely important, because they represent well-specified ways of relating one resource to another. They are as critical to REST as mediatypes (MIME types) are. In the graph theory sense, link relations are the label on an edge, URIs are the nodes, and mediatypes are formats that can be used as concrete representations of the nodes. The IANA maintains a Link Relations registry [1].

But since the 'normal web' is used by humans, we don't need link relations to traverse a website; we can instead use context clues, familiarity, or other techniques to achieve what we want on a website; the entire discipline dedicated to coaxing humans into interacting with websites is called 'UI/UX'.

Meanwhile, Kinlan envisions... well, to be frank I'm not entirely sure what Kinlan envisions because after mentioning 'headless web' he writes a lot about service workers, notification hooks, then points to ways we already use the web in ways that aren't out of our own volition, like in WebViews and IFrames (which he writes about in detail here [2]). I think his point is largely that every app maker wants to control the viewport around which content is surfaced, so they can add their own control and bring their own community, auth, ads [3], etc, and we're finally at a point to where the web platform has matured enough to make these websites or 'web includes' access capabilities offered by the device or the device's platform runtime, such as notifications, sensor data, and the like.

In a sense, they're not contradictory at all. The Richardson model clearly strives towards the semantic web, while Kinlan's writings predict that the semantic web has essentially failed, leaving people to write custom scripts and parsers and crawlers and bots to mash web content, some of it 'Web Platform-enabled', into other places.

[1] [http://www.iana.org/assignments/link-relations/link- relation...](http://www.iana.org/assignments/link-relations/link- relations.xhtml)

[2] [https://paul.kinlan.me/slice-the-web](https://paul.kinlan.me/slice-the- web)

[3] [https://paul.kinlan.me/rise-of-the-meta- platforms/](https://paul.kinlan.me/rise-of-the-meta-platforms/)

<comment><AUTHOR> >I think his point is largely that every app maker wants to control the viewport around which content is surfaced, so they can add their own control and bring their own community, auth, ads [3], etc, and we're finally at a point to where the web platform has matured enough to make these websites or 'web includes' access capabilities offered by the device or the device's platform runtime, such as notifications, sensor data, and the like.

I wish I had actually said that in the post. It's quite succinct.

</comment></comment></comment><comment><USER3> It's also interesting to see that technology indeed moves in cycles. In the beginning, the web was intended as a data layer, where that data was interlinked documents; but once it became popular (and commercialized), we built more elaborate 'documents' until they were graphically intensive for visuals' sake.

Then to gain interactivity we fitted an entire framework for manipulating that document's structure through imperative code (DOM), drawing arbitrary pictures (canvas), making other requests (XHR), and now we're at a point where the browser proxies nearly every feature of the OS platform for use of a website.

JS and WebAssembly aside, the VM inside the browser isn't even the new VM... rather, the integration point is the entire browser and everything that's inside of it, and this article predicts a future where we use an intelligent but headless browser to manipulate a page just to get some data out.

</comment><comment><USER3> This is a natural convergence two trends:

[1] that HTTP APIs operated by to most webapps/services do not have feature parity with their actual website, even if only in the sense that a third-party client has to implement a custom controller/view logic whereas a website already provides that courtesy of the first-party;

[2] and that the Web Platform (previously known as "those random javascript globals under 'window'") has more and more 'hooks' to functionality to what's traditionally implemented by a modern desktop/mobile OS.

</comment><comment><USER4> Technically, no problem. But who pays for the content when someone else puts your content in their presentation?

<comment><USER5> More reason to treat information as a public good and decouple access from payment.

Universal content syndication, broadband tax, universal income. _Something._

</comment></comment><comment><USER6> I completely agree. We need to separate the data layer of the internet from the presentation layer. Most spam and poor user experience is due to the data owner controlling the presentation. I also believe we won't reach true accessibility without such a decoupling.

This is what I'm building at Optik. A network focused on knowledge rather than display. The average person should be able to receive, manipulate, and publish data without understanding API integration. That will only work if we change the information providers.

The technology exists, just the mindset has to change -- so it's great to see articles like this.

</comment><comment><USER7> Another way of framing these ideas is that data is starting to look more and more like media, and the web is coalescing around shareable data (a.k.a., "Linked Data").

His description could prove prophetic, but seems a bit microscopic even though he's describing a sea change. I tend to think something more disruptive is coming.

</comment><comment><USER8> Could someone write a tl;dr version for non english readers ? (article sound nice, but hard to grasp)

<comment><USER5> From about the middle of the article:

<q>

What if everything was powered by "The Web", but you never saw a browser?

This is a big question. As an industry would we be happy with the user hardly ever seeing a web browser anymore? Or is that the one thing that is sacrosanct?

I think my original classifications: Notifications, Physical, Embedded and Integrated, were not a million miles off where I think the platform is headed.

</q>

It's a long argument / technical exploration of what a web-served world _not_ mediated by browsers, but through notifications, native apps, embedded systems, etc., would look like. More Web-as-data-back-end than Web-as-content- delivery, in one view that occurs to me.

That said: the article wanders, doesn't start with or come to a point, and is difficult to follow. It's more a thinking-out-loud exploration than clear draft IMO.

<comment><AUTHOR> > That said: the article wanders, doesn't start with or come to a point, and > is difficult to follow. It's more a thinking-out-loud exploration than clear > draft IMO.

I would say that is true, there are a lot of different threads that I am trying to pull together at the moment.

<comment><USER5> And that's not necessarily a bad exercise.

Quick off-the-cuff bits (like this comment), or things I've been thinking about for a long time, can just spill out. It's the ideas I'm still putting together which I've got to struggle with most, often with extensive notes, outlines, and graphs to organise them.

It's a joy for me to see other writers who've clearly distilled their argument. Rare, too. It takes talent, clarity of thought, and organisation.

The school of writing advice that this is just words and you've got to keep them flowing strikes me as quite flawed.

</comment></comment></comment></comment><comment><USER9> I think the effort to make a "mobile-optimized" website is quite low these days.

Contrary to this article the effort to make a "mobile-web-app" is quite big. There are multiple gotchas like 'tap-delay', cache, session-storage, distribution, you name it.

So far ( I still remember when iPhone OS introduced screen-bookmark-web-apps ) I think there is no business reason to go with a 'web-app' when you can spend that time / dev-money on a native app. Maybe cordova / phonegap still sounds like an option, although I think temporarily, until you can afford making a native one for all platforms.

<comment><AUTHOR> Just one quick one, you mention distribution is a problem. Could you expand on that a little for me?

<comment><USER9> It's about the use of the AppStore / Google Play to distribute your web- applications.

Currently the only way to install one would be to bookmark it from your browser, which is counter-intuitive to the users.

There are a couple of ways to mitigate this problem [1] , but we are not talking about pure web-application anymore.

1 : [http://stackoverflow.com/questions/1157576/is-it-possible- to...](http://stackoverflow.com/questions/1157576/is-it-possible-to- distribute-an-iphone-web-application-through-the-app-store)

</comment></comment></comment><comment><USER10> > __If you take it one step further, many of the modern search engines run a > browser behind the scenes to be able to themselves to execute JavaScript so > that the content you host using you preferred framework of choice will still > render and the data will then be indexable. __

I had been wondering for years how Google is able to discover and index new pages without explicit indexing requests from webmasters. So it is the browser.

</comment><comment><USER11> This is probably an oversimplification, but isn't this kinda just ssh wrapped up in some kind of more user-friendly package?

</comment><comment><USER12> Oh god no, the world do not need more http, html and javascript.</comment>


What the literature says about the earnings of entrepreneurs - <AUTHOR> https://80000hours.org/2016/02/what-the-literature-says/ <comment><USER2> So here's the Math for me. I recently dropped my nice fat full-time contract so that I could either "go full time on my business" or "retire", depending on how you want to interpret it.

Before: One of those Google/Facebook/Twitter "Total Comp" numbers that nobody here believes whenever Bay Area salaries are discussed. Upwards of 40 hour weeks, though I did drop down to 4 day weeks for the last year because, hey, I can live on only 80% of a fairy tale number that nobody would believe if you told them.

After: Normal Bay Area Developer money, of the sort that the other half of that discussion above make. Or maybe a bit less. But the "Hours" side of the equation is where it all gets made back up.

I just spent 3 months traveling through Southeast Asia with the kids, Rock Climbing, Surfing, Getting Married, Riding Elephants and Building Sand Castles. The biggest work week I had involved maybe 10 hours in front of the computer.

Realistically, I could coast along like this indefinitely (thus the "retired" interpretation of my current situation above), but more likely I'll go back to 5-20 hour weeks building out features in the existing products and shipping the next one.

That's what you're buying with all this "Entrepreneuring". The ability to replace your old income with a new one that doesn't necessarily require you to work full time for it.

If you like doing things other than sitting a cubicle discussing where to go to lunch, I'd highly recommend looking in to it.

<comment><USER3> > That's what you're buying with all this "Entrepreneuring". The ability to > replace your old income with a new one that doesn't necessarily require you > to work full time for it.

Time is the limited resource, not money. You can always get more money, but you can never get more time.

Many (most?) people forget that.

<comment><USER4> Cue the reference to the "time vs money for happiness" thread that was on HN a while ago.

[https://news.ycombinator.com/item?id=10860517](https://news.ycombinator.com/item?id=10860517)

</comment></comment></comment><comment><USER5> I recently registered an LLC, and opened a separate bank account. I did it because I didn't want to "cross the streams"... however it felt more like a switch was flipped in my head, and so far that's one of the biggest benefits.

Where as before when I had to spend some money for the business, it was very difficult on an emotional level. I'm not the kind of guy who doesn't spend money if he doesn't have to. However once I was spending money out of the business account, it was easier somehow. My mindset was now a matter of "will this help me grow the business? sure, let's go for it". Instead of "Can I accomplish the same goal without spending the money?"... which there is almost always a way to do.

</comment><comment><USER6> I am defiantly on the control-oriented side rather than the wealth-oriented side. The appeal for me of being an entrepreneur is I have control over my life, not the money (I am not saying that money is not great).

You only have one life and you almost certainly won't look back on your life and say "I wish I spent more time making money".

<comment><USER7> You only have control once your business steadily earns enough to employ managers to run things for you. Until then you are at the whim of your clients.

<comment><USER6> You can say no to your clients ;)

</comment></comment></comment><comment><USER8> Much more interesting is the percentage of the value they generate that is captured by entrepreneurs:

" _We conclude that only a minuscule fraction of the social returns from technological advances over the 1948-2001 period was captured by producers, indicating that most of the benefits of technological change are passed on to consumers rather than captured by producers._ "

[http://www.nber.org/papers/w10433](http://www.nber.org/papers/w10433)

<comment><AUTHOR> Yes - I'd guess entrepreneurs have more social impact than salaried workers, because they do more innovative work. We'll write more about this in the future.

Note that the paper you cite is only about technological advances though, and only a fraction of what entrepreneurs do contributes to technological advances - a bunch of its just implementing stuff that's already best practice.

<comment><USER8> AIUI implementing stuff that's already best practice - innovation driven Total Factor Productivity growth - _is_ technological advance and is included in Nordhaus' calculations. But IANAE.

<comment><AUTHOR> Good point. It still seems unlikely to me that all entrepreneurial activity contributes to productivity growth though. I'll look into it some more.

</comment></comment></comment></comment><comment><USER9> There's a bit of an implicit post hoc ergo propter hoc fallacy going on with this article. That is, if someone quits their salaried job and incorporates, then they'll make more money. I think the likely conditional for most entrepreneurs is "if I incorporate a business to do X, then I'll make more money." I think a lot of entrepreneurs have an X in mind before they start their business (which is not to say it doesn't change, but, still).

</comment><comment><USER10> I've read that incorporation isn't worth the effort and cost if the business makes less than 60k, maybe this is a hidden cost in some of these situations.</comment>


Good engineers make terrible leaders - <AUTHOR> https://invertedpassion.com/engineers-make-terrible-leaders/ <comment><USER3> I think a pair of issues are being improperly conflated here with respect to the complexity of human systems. We see a similar problem contained within software engineering (and chemical engineering): most humans, including most engineers, are terrible at analysis and engineering of complex distributed systems. Human systems are just another example of this problem domain.

Systems level engineering breaks a problem-solving heuristic that people rely on to make analysis simple: that changing a variable does not feedback into the value of that variable, which allows you to break a big problem into a bunch of trivial small problems that can be solved independently. For systems level engineering problems, you have to consider the interaction of all components simultaneously, which is a very different type of analysis (you are designing for locally stable and hopefully approximately optimal systems level equilibria). It also has characteristics that go against the way humans want to design things: the general design pattern is that you can't design for "good" outcomes per se, you can only design systems that mitigate "bad" outcomes, with optimal "good" outcomes being the natural result of efficient pathology minimization. Most people tend to design for the outcome they want, rather than minimizing the outcomes they don't want, but only the latter works.

Bringing this back to human systems, in a naive analysis you can take any variable, label it "good", and dial it up to eleven with some direct trivial changes. I almost always see it approached this way at a policy level. In a systems level analysis, it never works that way and you have less control of the tradeoffs than you might like as a matter of policy. We suck at human systems because, thus far, we haven't come to terms with the reality that a systems level analysis doesn't let you dictate the absolute values of "good" and "bad" no matter how you define them and controlling the relative values is far from trivial in a systems level analysis. We have tools for approaching this, as some types of engineering require it, but we don't apply it because it doesn't lend itself to the kind of naive analysis people understand and the tools don't allow the kinds of outcomes in human systems we wish we could engineer.

<comment><AUTHOR> >Human systems are just another example of this problem domain.

It isn't. Of course, both are systems of some sort, but there are several differences:

1\. You can simulate a systems engineering problem and if it doesn't give you an acceptable solution in the first go, change some parameters and re-run again. In human systems, you (usually) do not get such luxury.

2\. Components in an engineered system behave predictably. Humans are free agents who often act in irrational, surprising ways. You cannot simulate and analyze that. This is why there are black swans.

We cannot bundle these two systems as one and the same thing.

<comment><USER4> Your view of engineering seems too narrow. How would you classify a traffic engineering problem? Humans area a crucial component, and it certainly doesn't have an objectively correct solution (except possibly in narrow cases).

<comment><USER5> Current traffic engineering is almost a complete human problem. Swap it out to driverless cars and it becomes more like routing IP packets.

<comment><USER6> Not so simple, since driverless cars will still have to interact with pedestrians, bicyclists, etc. Not to mention that humans will still ultimately determine where the cars go, and when - even if all cars are driverless, massive numbers of people will hit the road the day before Thanksgiving.

<comment><USER5> >Not to mention that humans will still ultimately determine where the cars go

Incentives.

Right now the road network has no information on where you are going. Because of this it is near impossible to route or plan traffic beforehand other than using historical estimates. It is everyone for themselves. In a completely driverless world people could submit their driving route the day before a major event like Thanksgiving so the network has more information on what traffic will look like then. The people that plan ahead could then be given a 'queue credit' or 'queue boost' that routes their car in to the faster moving lanes, where those that did not get stuck in the slower lanes for longer.

</comment></comment></comment></comment></comment></comment><comment><USER7> I completely disagree with this for several reasons. The main reason is that the article, sells short engineers abilities.

Let's look at software engineering, because that is what I am most familiar with.

First, not every problem has a well defined solution. For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement. Instead, what is done is to use heuristics to find an approximate solution.

In addition, in software engineering, there is such a thing as a desire to write beautiful and elegant code and design. Those things don't have an objective definition, but a subjective definition. Software engineers will try to write that kind of code and will discuss and debate the various methods of achieving that (look at the whole functional programming debates).

Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences. The vast majority of people want things according to Maslow's hierarchy of needs [https://en.m.wikipedia.org/wiki/Maslow%27s_hierarchy_of_need...](https://en.m.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs). They generally want government to make sure the lowest 2 levels (physiological needs - ie clean drinking water, food, etc and security - low crime, rule of law, etc) are provided while being allowed to pursue the things higher up the pyramid.

What was described above is an optimization problem. Sure, there is no feasible and probable perfect solution. However, engineers deal with this all the time. Most code that is written does not have formal proofs. Often heuristics are used and measurements of performance in common scenarios bare taken. The same approach can also be used with social issues. Experienced engineers are also good at communicating to the rest of the team why a certain approach is a good one. This communication skills can also be used in the social arenas.

Thus don't let this article discourage you. Engineers do have the ability to deal with ambiguity and tradeoffs and communicate about them and can be excellent leaders.

<comment><AUTHOR> Author here.

> First, not every problem has a well defined solution. For example, trying to > decide what is the best way to pack a truck for deliveries is essentially > the knapsack problem and has no solution that we could actually implement. > Instead, what is done is to use heuristics to find an approximate solution.

But even if optimal solutions are not to be found, you can state it objectively and know it's an unsolvable problem and so you interpret results in the same light. In human system, you cannot even state the problem objectively.

>Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences.

If I was overexaggerating, we wouldn't have ISIS, Korea and many other cultures that pose threat to human existence every now and then. The difference of opinions is all around us, just open any news website.

<comment><USER8> Just to a reminder that there are two Koreas, and one of them probably doesn't deserve to be lumped in with ISIS.

</comment></comment></comment><comment><USER9> It's nonsense to suggest that engineering decisions are simple black and white decisions compared to other kind of problems. We may be able to calculate the properties of a particular bridge design reasonably accurately but engineering is full of tradeoffs. Some of those tradeoffs are part of even doing those calculations (which necessarily involve simplifications and imperfectly known or measurable inputs and involve cost benefit tradeoffs). There are vast numbers of complex tradeoffs in designing and engineering a bridge beyond that: costs and timelines vs quality, aesthetics and other qualities, projections of future traffic patterns... Fundamentally engineering is all about smart tradeoffs, including those involving working with limited data about the problem vs. gathering more data.

On the other side, politics is full of examples of objectively bad policies where relevant experts know better ways to achieve the stated objectives. In reality many of the problems with politics stem from the fact that the stated objectives are not the real objectives behind policy decisions.

The article is riddled with other errors and fallacies too, too many to list in detail.

<comment><AUTHOR> Author here. I'd love to get a list of errors and fallacies. I actively try to learn to think better, so it'll be great if you could point them out.

You are missing the point of the article. The question isn't about tradeoffs, it is about knowledge (or lack of such tradeoffs). In engineering problems, tradeoffs are known and in human systems, tradeoffs aren't known.

> On the other side, politics is full of examples of objectively bad policies > where relevant experts know better ways to achieve the stated objectives. In > reality many of the problems with politics stem from the fact that the > stated objectives are not the real objectives behind policy decisions.

If you read the notes (and the paper linked), that's the exact point I'm making in the article.

<comment><USER10> > In engineering problems, tradeoffs are known

Not really. In non trivial projects, you also have to "manage" the unknowns. Viewing engineering projects as completely controlled is a myth; even what we make with actual engineering practices (planes, etc.) fail every so often because of design issues. This is not because of known tradeoff, except if you twist the definition as far as pretending that the lack of infinite study and simulation is a tradeoff. Catastrophic failures often (always?) come from highly non-linear causes, you can think that kind of chaos also leads in other areas, especially among social interaction. Because of the non-linearity, even estimations of failure rates are only really estimations with absolutely no hard bounds. So said non trivial (real) engineering projects actually have to be inserted in the society as a whole, including for example insurances.

The (real) engineer also have (a moral obligation) to consider the social impact of their work.

In the end, both engineering work and leading a society is reducible to exercising reason to attempt to achieve a goal. The remaining differences are mere details.

</comment></comment></comment><comment><USER11> Engineers, like most professions, contain all the diversity of humanity. The only filter is that the portion of the populace that couldn't attain that level of education, or who can't hold onto a job, aren't included.

Sure, there's some commonality in that it's a group that has been exposed to a certain form of thinking, but if you asked people to write their thoughts on solving the poverty problem, I seriously doubt you'd be able to identify the engineers from what they wrote.

<comment><USER12> >> I seriously doubt you'd be able to identify the engineers from what they wrote.

This isn't meant to be funny, but I bet you could identify _good engineers_ from what they wrote rather quickly. What does a good engineer do when they discover a faulty resistor while debugging a circuit? Cut it out, throw it in the trash, and replace it with a working one. They never pause to consider the moral impact of suddenly removing it from the board, attempt to rehabilitate it, or try to empathize with it. They cut it out and move on.

If you apply engineering principles to societal problems, the die-hard engineer may come up with a similar result. I'm only speculating, but their line of reasoning could resemble... "these (good productive) citizens do not harm other citizens, and they support their economies through labor and taxes.... discard every other citizen that does not do this, and replace them with a working one".

Sounds like a dystopian sci-fi plot to me.

<comment><USER13> As a society, we have demonstrated a remarkably limited ability to coherently articulate what the problems are.

Now, if you can articulate a clear problem, I might be persuaded that engineers as class will solve it a specific way. But my experience is that once a problem is identified anyone could do it. Identifying the problem is the part that generates friction.

In the one-line example you came up with, you imply:

* Working is good

* Economic productivity is the end goal

* Possibly a link between morality and citizenship

* That 'replacement' based on some unknown process will be legitimate

If I am allowed to assume things like that, every human problem becomes easy and I can engineer it. But a 'landslide' in politics is 60% agreement on a subject - assumptions like this do not fly. I, for example, disagree with at least 2 of those points.

</comment></comment></comment><comment><USER14> The article seems to make two different points that don't completely fit together:

1\. Non-engineers are better leaders because they can find solutions to "wicked problems", problems with many interacitng parts where there is no predefined objectively right or wrong solution.

2\. Non-engineers are better leaders because they are better at persuading others that their shitty solutions are actually good.

I might buy #2 (for some definition of "better leaders"); I'm not so sure about #1.

<comment><USER15> #1 flows from the strange rationalization that regardless of anything else in life, studying humanities for four years in college turns one into a great abstract thinker....while studying engineering for four years permanently transforms you into a robot

amazing that people still believe that an undergrad education either turns you into Napoleon or R2D2

<comment><USER16> How odd. There is a meme in engineering circles that people who don't study math or science are somehow less able to think and reason. I wasn't aware of the sort of inverse you posit.

My personal experience on this is extremely lopsided: it's rare for me to encounter a non-techie who doesn't fawn embarrassingly at me when I tell them what my academic background is (physics) or gush over how smart and good at math I must be, etc., while on the other hand I hear from engineer peers all the time about how non-techies are dumb, incompetent, play politics, etc.

<comment><USER15> nowhere did I claim that only engineers were numerate, logical or analytical

</comment></comment></comment></comment><comment><USER17> Let's wrap it up. Confuses engineering and science. Reduces engineering activities to closed problems. Thinks science does not successfully offers models for fuzzy systems (<cough> thermodynamics, man </cough>). Puts doubts on the fact that technology enabled human progress above its animal condition. And finally, seems to ignore that the main role of an engineer is to safely /lead/ the work in factory or on construction sites. Really, I have seldom read something so inaccurate, up to the point where I suspect it may have been written on the sole purpose of annoying the HN crowd...

</comment><comment><USER18> Engineers: Know your place and stay within it.

Get those silly little ideas out of your head and back to whatever it is you do. Isn't your boss waiting?

<comment><AUTHOR> For the record, I'm an engineer myself.

<comment><USER18> Surely you've met engineers that aren't purely analytical?

<comment><AUTHOR> Yes, I have. As a clarification, by good engineers, I mean the mode of thinking that goes with good engineering / problem solving skills. People can have multiple skills.

<comment><USER15> okay, well if you really believe this...why the article?

</comment></comment></comment></comment></comment><comment><USER19> > While a leader with an engineering mindset works hard at finding at a better > solution, other leaders use their personality, power or charm to persuade > people that their solution will be in everyone's benefits, even if it > actually isn't. This is why despite his IQ, Donald Trump got elected as the > president of US.

I'm no Trump fan, but have to wonder why, in an article proposing an objective truth, I have to read the author's opinion of Donald Trump -- in this case regarding his IQ.

If the author can prove the lowness of Trump's IQ, I'd love to see the objective proof. Otherwise I would suggest the author stick with his main points and not involve his politics.

Moreover, it's sickening to me to read the veiled insult of the voters (the "even if it actually isn't" statement) who put Trump in office. Again, perhaps the author would consider sticking with his main thesis and avoid denigration of those with whom he clearly disagrees.

</comment><comment><USER20> It's absurd to believe someone can't learn a new way of thinking, even if they are not predisposed to it. Plenty of doctors are also amazing photographers. I've spent my whole career around engineers from the leadership side of the house, and I can firmly say I believe many of them could learn to be wonderful leaders. I think mixing disciplines requires you to switch to child eyes on your other skills, but that's about it. Great leaders are eternally humble (I know nothing), great engineers are eternally arrogant (I know this). There is certainly beautiful in both. :)

<comment><USER21> I think that's the key point, to learn. So many tech companies make management the only way to continue getting promoted. Then they don't offer any way for employees to learn how to be a good manager. So they're left to learn by doing.

<comment><USER20> It boggles my mind so many great engineers are willing to work for leadership teams that contains nobody who has built organizational structures at scale. It's almost like going in for surgery by the person who made the scalpel.

</comment></comment></comment><comment><USER22> > Thus anyone claiming an objective basis for a problem in society is taking a > simplistic view. And that's my issue with saying technology is causing > progress.

The author seems to create a false dichotomy between solving "wicked problems" according to a pure engineering approach and the alternative, which is not articulated.

Yes, there is probably not an engineering solution analogous to building a bridge to issues such as poverty. There is, however, a boatload of research about various facets of the problem that will inform a good solution. A good leader will become apprised of this research and use it to support a position that they advocate for. The ultimate position will of course be motivated by values, culture, etc but if it ignores evidence - gathered by science - <USER2> execution - informed by engineering, then it's not a good solution.

<comment><USER23> Fully aggree.

In fact, I'd go further: having an engeneering mindset is _necessary_ but not _suficient_ for good leadership

</comment></comment><comment><USER24> Why is this article with this click-bait title on the top of HN? A lot of leaders start off as engineers then go to CTOs, VP level, CEOs etc.

And this idea that engineers are purely scientifically minded totally ignores the endless number of articles suggesting that the best senior engineers have strong product and business sense, and in many places (but not all) having those skills are a defining quality of a senior engineer.

Engineers definitely NEED scientific background to enter the field, but this totally ignores that engineers grow business and product skills throughout their career, and need to do so to be effective

</comment><comment><USER25> China's leadership is mostly engineers, and in the US we have lawyers. Seems to be working well for China.

<comment><USER26> In general, I think it makes sense for a large percentage of the people making laws to be familiar with how laws work.

<comment><USER27> It totally doesn't make sense. When I look at my company lawyers are rarely the ones that come up with new strategies or anything innovative. They implement what others tell them to do. That's a valuable thing but I don't think being a lawyer is a good qualification for leadership. I would argue you can see this in Congress where they seem to be more interested in fighting than actually delivering something.

<comment><USER26> I'm certainly not suggesting all leaders should be lawyers, just that a fair number of the ones making laws should be. The US legal system is complex. Every time my very business-minded senator opens his mouth, there's a real good chance that he will say something dumb about the way the legal system works.

Also, I'm generally not looking for laws that are innovative. Companies are suppose to innovate and risk a lot to do so. But if a company goes bankrupt, it's rarely a big deal. Governments don't have that level of flexibility. They need good, stable policy, from people who are good at seeing both sides of whatever argument is in play. You know what kind of people are good at doing that? Lawyers.

<comment><USER27> Each member of Congress has a substantial number of lawyers behind them to write the actual laws. That's necessary. But the direction should come from people from all walks of life, not just lawyers. I think the real problem may be that Congress creates laws by lawyers for lawyers.

</comment></comment></comment></comment></comment><comment><USER28> Management is an engineering problem whether we want to admit it or not. It's about maximizing the potential of the people who are working for you. Designing a team is just as much of an engineering problem as building a large scale web service. People will argue and say, but humans are emotional, greedy etc. That to me just sounds like inputs to the optimization problem at hand. How do I get team member x, to produce y for me given that x1,x2,x3 factors? Some of the best executives were formerly great engineers. Engineering is as much a people discipline as it is a technical discipline. This author's article is all over the place and I think that they miss this point entirely. This author doesn't do a good job of actually defining what they think a "good" engineer is to begin with.

</comment><comment><USER29> _it's meaningless to say human society had made progress without stating areas that you're considering and not considering when it comes to assessing such progress_

Is it meaningless to say that some areas are more worthy of consideration than others? There are reasons why the OP chose infant mortality and education as example areas. Those reasons could be made explicit and examined objectively: for instance to see if they make sense by their own terms. For example is a society that prioritises a certain area able to _continue_ to do that well into the future, or not?

</comment><comment><USER30> Engineering isnt simply solving known problems. Research in engineering is working in exactly the situations that he describes: where there are potentially many unknowns and trying to optimize for some variable, the same as we would in a political situation. The main difference is the inputs and outputs to the system: with a lot of engineering its pieces of hardware + software where as in politics its policy + law.

</comment><comment><USER31> I'm not sure what to take away from this article. Yes, Engineers are perhaps bad at solving insoluble problems. 'Leaders' are equally bad at solving soluble problems. However, there are a few things I do know:

      Engineers can become Leaders (difficult, dicey, possible)
      Leaders cannot become Engineers (ain't gonna happen)

<comment><USER32> I don't agree with the assertion that leaders cannot become engineers. I have had leadership experience before even becoming a software engineer through my time in the Marine Corps (infantry), and it has served me well in being able to demonstrate excellence in leadership, as well as in engineering.

I have run into other Marines who have similarly succeeded in making the transition. On the flip side, some of the best managers I've had were former software engineers.

I think overly broad assertions made like in the article do a disservice. I think one's ability to be successful in either role comes down to one's own characteristics more than anythig else.

</comment></comment><comment><USER33> Some problems are engineering problems - design and estimate the cost of a highway bridge that crosses a river at point X; and some problems are "political" \- decide the point x where a bridge will cross a river. Only an engineer can decide if a problem is an engineering one or a political one.

</comment><comment><USER34> OP is conflating "method" and "mindset".

The engineer is a methodical thinker and tinkerer. I would think in fact engineers would make excellent central committee material. :)

"Salesmen" as leaders. Well, let's see how that turns out. MAGA or GAGA, tbd ..

</comment><comment><USER35> Contrast to Toyota, where, if I recall correctly, VPs are expected to be able to do personally the roles beneath them in the org chart. Also, the application of Lean principles to food banks and other service charities.

<comment><USER36> There were a couple of recent article from HBR making a similar point[0][1]. They make the point that it is important for leaders to have expertise about the domain that they are leading in.

[0] [https://hbr.org/2017/11/can-you-be-a-great-leader-without- te...](https://hbr.org/2017/11/can-you-be-a-great-leader-without-technical- expertise)

[1] [https://hbr.org/2016/12/if-your-boss-could-do-your-job- youre...](https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre-more- likely-to-be-happy-at-work)

</comment></comment><comment><USER37> This may be country-specific: [http://www.economist.com/node/13496638](http://www.economist.com/node/13496638)

</comment><comment><USER38> The title of this article is click-bait and a complete oversimplification. I'm tired of seeing shit like this in HN and can't believe people are upvoting it.

</comment><comment><USER39> Philosophers make terrible judges of engineering managers.

<comment><USER40> Laconic, I like it. (Yes that is a philosophy.)

</comment></comment><comment><USER41> Bad artical paddling completely unsubstantiated theory and making absurd claims - very likely to benefit his own career as non-engineer leader.

Author basically rides his argument on one "paper" which also makes out-of- the-thin-air arguments in similar fashion. The central point of the argument is that science is incapable of dealing with complex incompletely specified systems with uncertainties. Then author goes one step ahead and makes a sweeping statement that people who are good at scientific approach have decreased abilities to deal with this kind of problems! On the other hand, so called "leaders" have this natural "charm" to allow them to work with such systems without requiring scientific mindset. He then cites Donald Trump as proof of his argument. In my long career I have actually came across such leaders with natural "charm" and I can attest that chances of have them destruct the project is much higher than a leader with engineering background.

So the conclusion is that if person is less scientific then better chance that he would be good leader. I think author has time travelled from 500 BC and is not aware of entire fields of complexity theory, chaos, probability, statistics. He is probably also unaware that virtually every major leader from Alexander to JFK have used science to win their wars and had fairly good understanding and ability to naturally apply those methods to their problems.

No need to waste your time in reading this BS.

</comment><comment><USER42> Of course HN would be a terrible place to make an argument that "good engineers make terrible leaders".

Engineers here would just deconstruct it.

Anyone see the irony?

<comment><USER40> And leaders will ignore it as baby talk. Or posturing.

</comment></comment><comment><USER43> This did not make any sense to me. The article does not back its title in any way. Material progress for humanity achieved through technology somehow 'cannot be objectively measured'. Plus some empty statements about engineering being task-executors with no political/planning ability?

</comment><comment><USER44> >This is why despite his IQ, Donald Trump got elected as the president of US.

Has this ever been made public?

</comment><comment><USER45> This clickbait headline is leaning on a study behind a paywall so we can't argue the actual points or data. Don't bother

</comment><comment><USER46> Causality and Correlation.

</comment><comment><USER47> People who try to box engineers into some sort of hyper-rational over- simplified box to separate them from real world messy problems are silly.

I suspect the underlying reason is that once you start measuring things, you tend to learn thing fast and that typically shakes up the status quo in a way that disciplines "far away" from the hard sciences aren't emotionally ready for. You don't question their sacred cows.

Let me give you a software example which shows how basically even the "tamest" seeming problem in software engineering is pretty "wicked", requiring some of the same skills you'd use to tackle a social issue.

Is website A faster than website B? What do we mean by fast? Sure we agree we can use a clock, and to bucket relativistic effects we can talk about things on planet earth. So if you're sitting there in front of a computer with a clock, what should you measure to tell if website A is faster than website B?

The answer is nobody really knows but some answers seem better than others. The most simplistic measure is to measure the time from when a request is sent to when the last byte of the response is received. But once we have a number we have to ask what it means in terms of "faster" and if it's the right number.

Some single page apps these days are really fast by that measure. They just give you a static shell, that would sure beat the pants off just about any other webpage download. Of course for single page apps giving you a static shell, the initial download is not the end, but the beginning. They start to load css and javascript and images, etc.

We might say that page download time is a poor metric because if I'm some poor schmuck trying to visit a page, the time that the html took to download doesn't really mean anything to me.

For a while people thought time to first byte was more interesting. Of course it really means nothing, but in some cases, for a short while (streaming pages from jsps, etc) before mvc became the predominant paradigm, a good ttfb was correlated with sending some html that the browser could get to work on, allowing it to render content sooner, which seemed like a good thing.

Do you see the wickedness here? In order to even tackle the problem we have to invent measures and targets, even though this is a "tame problem" with a objective stopwatch for measuring.

We kind of "knew" the right measurement was one that the human interacting with the web page would intuitively understand as "website A is fast". How long until they could see the page, how long until they could "touch" it and interact with it?

As people started doing more javascript, the approximation of TTFB stopped being as useful. There were easy things to measure, domready and page loaded. Dom ready meant that a page had loaded enough for javascript to begin interacting with a "complete" document. So almost by definition it wasn't a good measure since it marks the beginning of the lifecyle of an AJAX app or client side mvc or single page app or whatever we're calling it next week. Content loaded often was too conservative of a measure. It didn't fire until the last image had downloaded and rendered. That could be below the fold and as they say: "out of sight out of mind".

So at this point if we want to answer the question: "is website A faster than website B?" we only know the real answer is somewhere between 2 numbers.

Of course facebook cheated. They attached event handlers to the body pre- domloaded that just appended events to a Array (queue) so that people could see a button and click on it and even though the "app" wasn't done rendering, you could say: "a customer could see the page and interact with it without those interactions being lost".

So if we want to measure "when can I see a webpage and start interacting with it?" it's a pretty tough question that might not have an answer. The best we can do is say: "you loaded a web page at time t0 and at time t1 you performed an action and it (did|did not) work. We could compare those 2 things... if the action was something you could do on both websites.

You can make videos of websites rendering and visually compare them.

I've spent my career as a performance engineer and I don't really know how to, in the general case, answer the question: "is website A faster than website B". In specific cases it's sometimes clear. For example I could visit a static html page with no buttons and say: "it was definitely loaded in 50ms" and then visit some monstrosity of a single page app that displays a loading screen for several seconds and conclude: "the static webpage was faster than the app".

But I'm sure designing a bridge is sooo much simpler and there's no ambiguity there.

Right?

</comment><comment><USER48> This is one of those 'common' knowledge things that is pushed forward by non- engineers and further backed up by other non-engineers. Since we account for ~ 1e-3 or less of the population we are so outnumbered it becomes part of the culture.

If you can program you are likely among the smartest people in the world and can do better at any analytical task than almost anyone else.

<comment><AUTHOR> > > If you can program you are likely among the smartest people in the world > and can do better at any analytical task than almost anyone else.

Designing a system for humans is NOT an analytical task. It can be supported via analytics, but it's a political task (that requires _others_ to be convinced that it is a good solution. For example, you can raise income levels, but if people get pissed off at inequality, you can't argue your way with numbers. They may or may not take it. And that was my point in the article).

<comment><USER39> Yea you know nothing about engineering management. To a man with a hammer every problem is a nail, and you love your hammer.

I'm an engineer. I've built a 45 person engineering team that shipped dozens of releases of award winning software without ever missing a schedule or compromising quality. There is nothing but analytical tasks for the engineering manager.

1\. How do you maximize developer productivity? Motivation? Job satisfaction? How do you help them make technical decisions and plans?

2\. What process best allows your specific teams to ship quality releases on time? How much planning overhead is necessary to do so, and how much isn't benefiting the process or product?

3\. How do you make your quality assurance staff most productive at finding and reporting problems? How can they best organize their testing to ensure the most useful/necessary test coverage, and how do they communicate their progress clearly?

4\. How well do all these things meet the needs of your first level customer, the product owner?

5\. How do you communicate your groups capacities to executives? How do you tell them what can be done, what can't be done, and what shouldn't be done?

Your tools, technologies and customer requirements are changing over time. Analysis never ends, you can always get better.

All the things you think are important, aren't

<comment><USER49> lol

</comment></comment></comment></comment><comment><USER50> Just another self-promoting Twitter startup bro. Who is upvoting this complete gibberish? At least that article on the cult guy was interesting...

</comment><comment><USER51> >Good engineers make terrible leaders

The entire position of lead engineer/developer seems to disagree with this.

</comment><comment><USER15> author cites the problem of motivating a sales team...anywhere I have worked, this has been the quintessential "objective" process; meet quota, get bonus. fail to meet quota thrice, adios.

<comment><USER52> Problem: It's been shown time and again that this doesn't work. (For all but the lowest simple, mechanical, repetitive tasks.)

[http://psycnet.apa.org/record/1999-01567-001](http://psycnet.apa.org/record/1999-01567-001)

<comment><USER15> counter example: the world economy, most of which is still kept running with the threat of repercussions

<comment><USER52> How is this a counterexample?</comment></comment></comment></comment>


Tierion: Record and Send Data with the Blockchain - <AUTHOR> https://tierion.com <comment><USER2> So, what's a concrete example application that this makes practical that wouldn't be possible otherwise?

<comment><USER3> Tierion Founder here. Very cool to see us on Hacker News!

Here's a real world example: We recently won the Coindesk hackathon by building an insurance claims processing application that creates an audit trail for the claims process by recording each step in the bitcoin blockchain. Our solution offered two main benefits. First, Tierion generated a blockchain receipt for the initial claim. This gives both the insurance company and the claimant a verifiable proof of the claim's timestamp and contents. Second, most insurance companies use an outside network of providers (call centers, data processors, etc.) to handle claims. By using Tierion, we created an immutable audit trail for the claims process. This gives the insurance company a record of how the claim was handled without having to integrate all of their external vendors.

An enterprise customer built a prototype that collects data from MRI machines to track its usage and maintenance schedule.

There's a list of use cases at [https://tierion.com/features](https://tierion.com/features).

We went live on September 1st. In the coming weeks, we'll be showcasing the creative solutions that we're seeing customers build.

<comment><USER2> I don't see the benefit for the insurance company. The data isn't stored in the blockchain, so they will still have to maintain their own claims database. Why would they pay for the privilege of putting proofs in the blockchain when they already have their own database that they trust perfectly well?

<comment><USER3> The insurance companies are relying on an outside network of vendors. They are currently exchanging data using FTP/email and .CSV files. The usual controls for compliance, data-integrity, and fraud prevention are not in place. Our solution gave them an easy way to build an immutable audit trail and maintain data-integrity without having to incur the expense of integrating their external vendors.

In a perfect world, the insurance company would maintain a central database of claims data and everyone would work off that data. In the real world, data is being shared in an inefficient manner.

Insurance companies spend $2billion annual on fraud and compliance. Our solution helped them reduce their costs.</comment></comment></comment></comment>


Plan9 compiler extensions in gcc 4.6 - <AUTHOR> http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Unnamed-Fields.html#Unnamed-Fields <comment><USER2> The last part is pretty cool (the first bit has been supported by GCC for years), though it would be even more helpful to be able to do the reverse concisely - convert a pointer to the contained struct to a pointer to the containing one. In my C code I invariably use (something similar to) the container_of() macro used in the Linux kernel [1]. The primary use is in callbacks associated with a particular object that can be embedded in larger structures.

Right now, say a library I'm using exposes this:

      struct lib_struct {
        int foo;
        char* bar;
      };
      typedef void (*lib_callback)(struct lib_struct*);
      extern void lib_fn(struct lib_struct* obj, lib_callback cb);

If I want to use that in one of my own data structures:

      struct my_struct {
        struct lib_struct lib_st;
        int my_own_data;
      };

      static void my_callback(struct lib_struct* lib_st)
      {
        // plan9 extension does not appear to help here...
        struct my_struct* me = container_of(lib_st, struct my_struct, lib_st);
        printf("%i\n", me->my_own_data);
      }

        /* elsewhere... */
        struct my_struct* m = /* ... */;
        // ... though it would here:
        lib_fn(&m->lib_st, my_callback);

It'd be handy to be able to condense the container_of line somewhat, while maintaining (some) type safety.

[1] <http://www.kroah.com/log/linux/container_of.html> \- I use a similar macro that preserves NULL pointers.

</comment><comment><USER3> Can somebody explain the significance of this to me?

<comment><USER4> If I understand correctly, GCC now has an extra switch to support some additions to regular C that the Plan 9 compiler offers related to the manipulation of anonymous fields in a structure. I don't think it has much significance for the vast majority of C programmers out there. I'm not sure why this is first place on the front page, to be honest...

<comment><USER2> It would have a positive effect on the readability and conciseness of our (SSDCache) code if we could actually use compilers supporting this. Unfortunately, we're stuck with older versions of GCC for the foreseeable future, and probably MSVC when we port to Windows. In hindsight I'm wishing we'd spent some time up-front getting to grips with something like SC [1] for generating C code from something slightly higher level to avoid some of the language's shortcomings that make the code overly convoluted. (some kind of usable closure-like mechanism would be fantastic, for example - callback-based asynchronous I/O isn't particularly fun in C)

[1] [http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.htm...](http://super.para.media.kyoto-u.ac.jp/~tasuku/sc/index-e.html)

</comment></comment></comment><comment><USER5> These features may be used to program in a more OO style without the notion of classes. For example, one case use the embedding of fields to have a similar effect to inheritance.

Similarly, one can pass pointers to objects that contain a type as if it was the type itself, which is the same thing that inheritance allows. Of course, here there is no difference between containment and inheritance, you can use it as you desire.</comment>


Show HN: Txtter – A messaging app making it easy to share photos with friends - <AUTHOR> I'd like to send you guys Testflight invites to check out the app and give any feedback or ask any questions. So please list your emails and I'll get the invites sent out later today. Thanks.
P.S. We have Biz Stone following us on Twitter and have been tweeted by Chris Sacca which is great news. <comment><USER2> What made you pick the name Txtter (Text being the key part) for an app that sends photos?

<comment><AUTHOR> in slang terms, here in England, we say "txt me" about photos too. Also the core of our app is texting so we wanted to focus on that. Other factors we took into account was that we wanted the .com domain available, and we wanted it to be short and cool sounding.

<comment><USER2> Makes sense. It's easy to remember as well!

</comment></comment></comment><comment><USER3> vortex [at] emergentnoise [dot] org

I specifically want to see what difference there is to Whatsapp/Telegram, given that these apps also share photos.

<comment><AUTHOR> The problem with messaging apps such as Whatsapp/Telegram is that they're very poor for sharing photos, you have to send them in conversation 1 by 1, or create a group with people that might not know each other, or broadcast list, it's an ugly experience. Txtter has a profile page where you can share endless photos instantly. No commenting is allowed on pics so it's a simple clean experience. Txtter also has usernames.

</comment></comment><comment><USER4> goharirfan94 [at] gmail [dot] com</comment>


Backyourstack: discover and sponsor your open-source dependencies - <AUTHOR> https://backyourstack.com/ <comment><USER2> > If you want to analyze non-public repositories, sign in with your GitHub > account

Do people really expose their or their employer's source code to random third party convenience services?

I do understand the convenience factor here, I just think it's dodgy to encourage developers to be so flippant with privileged access.

<comment><USER3> It also has the option to upload a package.json which is far less exposure, and can easily be tweaked to omit anything sensitive.

<comment><USER2> It's still not no-exposure, and it's still getting a developer in the mindset that just sending out files on a whim is okay.

I'm not wholly against this sort of stuff, I'm sure we've used similar links in the past for CI and coverage, but it seems to be the end of the slope, where we're handing out access to our stuff for something _so_ frivolous. This is the same sort of mechanism that got everybody and their dog's copies of Windows XP infected with trojans in the early 2000s. "Sure, I'll install that toolbar, just let me see Britney naked".

This could be a local, auditable script that fetched a static list of projects seeking funding.

<comment><USER4> To be fair, I don't think this is intentionally bad privacy-wise. I think that, uh, a lot of the JavaScript set doesn't actually know how to write code that doesn't involve uploading shit to websites. When all you have is a hammer...

</comment></comment></comment></comment><comment><USER5> Interesting project, would be great if this supported more than just JS projects, I'd be very interested to see some of the dependencies that my current business relies upon.

<comment><USER6> Kevin from [https://fossa.io/](https://fossa.io/) here.

We have an open source project just for this: [https://github.com/fossas/fossa-cli](https://github.com/fossas/fossa-cli). It currently supports roughly 20+ build systems and languages, and pairs with our web service for license and vulnerability discovery.

Would love your feedback.

<comment><USER7> You claim this is open-source, however I don't see an easy way to run this myself without relying on your infrastructure and signup up for an account there. Your "analyse locally" option requires an API key and is therefore very much misnamed.

</comment></comment></comment><comment><USER8> Can we add javascript to the title? It is a bit misleading without it.

<comment><USER9> Yup, tested it out on a few python projects I have/use and it has 0 dependencies listed which is very, very wrong.

<comment><USER10> We effectively don't support Python yet but it should not be far away. It's 100% Open Source and we're looking for contributions. [https://github.com/opencollective/backyourstack/issues/34](https://github.com/opencollective/backyourstack/issues/34)

<comment><USER11> Understandable that you're adding support for languages and packaging ecosystems as you go, and JS + PHP is as good a place as any to start, but it would be helpful if this were explicitly highlighted. For those who are unfamiliar with the ecosystems in question, package.json and composer.json are just filenames that don't actually tell you anything.

<comment><USER12> It would be helpful, and the site creator should list it. However, let's not treat this as a fault. They're offering you a free service and can't launch with every issue already resolved before being identified.

<comment><USER11> Re-reading my comment I can see it reads a bit like that - I totally don't intend any notion that I expect everything to be perfect, I'm an open source developer myself and as you say we don't expect every issue to be resolved instantly!

<comment><USER12> I was probably overly harsh and judgmental in my comment towards you. Glad we are in agreement!!!

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've been wondering whether a for-pay alternative to the open-source ecosystem could be developed.

The problem seems to be that open-source gratis software contributes nearly zero friction to a company building out its tech, so any alternative would have to compete against that near-zero friction. I just don't see each company negotiating separate prices with 100,000 package maintainers to use all of their software on a custom linux distro just for one of their internal servers or whatever. It's a tremendous amount of friction for each company to bear.

If that friction could be eliminated, while keeping a requirement to pay for use of the software, then I think a non-gratis ecosystem could dwarf the gratis software world within two or three years from its launch.

<comment><USER14> How would that be different from the regular Microsoft Ecosystem?

I can spin up a quick testserver using Windows Server, running an IIS webserver and Microsoft SQL Server, with my software stack written in C#, programmed in Visual Studio. It covers pretty much everything I could need, and involves ordering à la carte instead of negotiations.

Obviously it costs more and unless I spin up a cloud server I can't "just spin up a server" without making sure I have enough licences etc. But AWS/GCP/Azure solve that mostly.

<comment><USER13> My understanding is that Microsoft does not auto-publish+sell third-party libraries in a package repository. So the difference is basically the distinction made in the old cathedral/bazaar analogies.

<comment><USER14> They do have nuget for packages, but that doesn't have an integrated payment system. Despite this, there are plenty of paid C# packages you can buy around the web.

</comment></comment></comment></comment><comment><USER15> A similar tool with a focus on license compliance is fossology: [https://www.fossology.org/](https://www.fossology.org/)

</comment><comment><USER16> Great idea! It's nice to see an easy way to support open-source software.

Regarding funding open-source software: Companies I've worked for have all been OK with purchasing licenses for software that saves development time. They've also been careful to abide by software license terms. I'm surprised that more open-source libraries/frameworks don't require the purchase of a commercial license in order to use them commercially.

</comment><comment><USER17> I think we need less "awareness" and promotion, just more work on peoples' parts. Seems these projects are asking for a magic bullet to improve their stacks but find it's missing in their own time and efforts

</comment><comment><USER18> I tried putting in my github account on the home page just to see what would happen.

I didn't create an account or sign in, but it created a public profile on your domain using my name without my consent.

Is there any way to remove that?

<comment><USER10> In that case, it's just reading the public data from GitHub on demand, there is no account, nothing stored.

<comment><USER18> Ah ok, it looked like maybe it was created and cached and then publicly accessible at backyourstack.com/foo since that's the URL it forwards you to.

You might want to anonymize that URL for accounts who don't sign up just for clarity.

</comment></comment></comment><comment><USER19> This is a great tool, and going to keep tabs on it for future use. I appreciated the package.json upload for my private repos. Kudos to whoever built it!

</comment><comment><USER20> « 56 repositories depending on 0 Open Source projects. »

Well, that's not true. Maybe you could indicate which package systems you actually are able to analyze?

<comment><USER10> You're right, it's a common feedback we have, we even have an issue opened for that [https://github.com/opencollective/backyourstack/issues/57](https://github.com/opencollective/backyourstack/issues/57) We explain what we support in the FAQ but that's not enough. What languages / packages managers are you expecting?

<comment><USER20> Common ones, I suppose! I have projects involving Java, Python, and Clojure. Of those, I would expect the first two to be covered by a generic dependency analyzer.

(It's fine if it doesn't, but it would be nice to know up front.)

</comment></comment></comment><comment><USER21> The site offers to analyze your composer.json file, but doesn't seem to identify even popular libs like Monolog and Doctrine

<comment><USER10> Monolog and Doctrine should be properly detected. After that, we need to match detected dependencies with fundraising strategies (today Open Collective, in the future Patreon and others). Maybe this is why they're not appearing in the "Projects Requiring Funding" section. Feel free to submit an issue on GitHub and we can look at that in details.

</comment></comment><comment><USER22> This is a really good idea! I assume support for more languages / package managers is coming?

</comment><comment><USER23> It would be nice if you could paste package-lock file for private repos.

<comment><USER24> You can do that! Check out the section below the button.

</comment></comment><comment><USER25> This is absolutely amazing!!</comment>


Facebook drops "Clear Chat History" - <AUTHOR>

Along with several other visual updates to their chatting box. They seemed to have dropped the clear chat history feature. <comment><USER2> I guess they want to make sure that there is a permanent log of everything. Yet another reason not to use Facebook.

<comment><USER3> With programs and ideas like these ( <http://www.buffalonews.com/city/article201702.ece> ) there is a permanent log of everything. I'm tempted to think that companies are hoarding all possible data to be mined so they'd look more appealing for revenue from the government.

I think it's yet another reason not to use anything on the Internet without some sort of alternative vpn network.

<comment><USER4> facebook isn't free, you're the product

<comment><USER5> no matter how many times I read this, I'm always slightly caught off guard. The image many people seem to engender of fb is one of a public service -- ie they only "see" their friends on fb, not some abstract CEO.

With that reasoning, it makes sense that people pour so much blind faith into the Web site as they do -- they simply do not see a corporate structure to their giant online playground.

<comment><USER2> I expect Facebook to archive my profile and everything I've ever posted there or publicly. I don't really expect them to archive my private chat and not give me a way to delete it.

</comment></comment></comment></comment></comment><comment><USER6> [http://www.facebook.com/pages/Put-clear-chat-history- back/14...](http://www.facebook.com/pages/Put-clear-chat-history- back/148861775155334)

Technical directions on how to clear chat history in the new Facebook chat is in the Discussions and Notes.</comment>


The Plague Shawl: 1878 - <AUTHOR> https://thevictorianbookofthedead.wordpress.com/2020/01/29/the-plague-shawl-1878/ <comment><USER2> Vaguely reminds me of the TNG episode where Data has amnesia(!) and sells radioactive metals to a pre-industrial town. Hilarity does not village.

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

<comment><USER3> It's a great episode. It discusses empirical reasoning, peer review, mob mentality, and more. It's written very intelligently.

<comment><USER4> At the risk of being a Connie Contrarian, I don't think it is. Data makes wild, un-evidenced leaps of assumption that are only "empirical" because we the audience understands what he's saying is correct. But in-universe his ideas are ridiculous and unjustified. More-over Data invents a 'cure' for radiation sickness pulled directly from his butt, with no testing of safety or efficacy before he administers it to a large population.

The B-plot is also a great illustration of the fact that the writers have no idea what to do with Troi. The character was included on the show literally just for sex appeal, and by season 7 the writers were scrambling to justify her existence in a way that didn't openly acknowledge the fact that she was only included because Roddenberry was a womanizing horndog.

Meanwhile if the show had written her as an actual person from the start, she'd have already proved herself a thousand times over. An empath on a ship whose primary missions are diplomatic and exploratory is INSANELY useful:

(a rock monster appears on the view-screen)

"Lower your shields for cultural exchange."

"Counselor, opinion?"

"Despite the strangeness of this species and their lack of outward emotional cues, I sense only curiosity and openness coming from them. We should comply"

<comment><USER5> >Data makes wild, un-evidenced leaps of assumption that are only "empirical" because we the audience understands what he's saying is correct. But in- universe his ideas are ridiculous and unjustified.

Same with Spock, he presents "logical" conclusions where the priors are not knowable from where he stands.

Maybe it is just a popular caricature of logic, that if you are just not purely "emotional", then you are the opposite: logical.

Don't tell people that Spock is not logical though. You'll get an emotional response.

</comment></comment></comment></comment><comment><USER6> I have read of this transmission method being used deliberately to depopulate regions of South America in recent decades, and of North America in times earlier.</comment>


A deaf girl who found her voice after brain surgery - <AUTHOR> https://www.bbc.co.uk/news/health-47974844 <comment><USER2> One day these implants are going to be so sophisticated that we may very well evolve to not have bio-hearing at all. I have friends with implants, and one of them regularly just keeps it switched off to focus on writing. I am deeply envious though of course, at present the bit-depth is not very good from what I understand about the tech, and his brain even after 20 years of having the implant isn't good at differentiating between background and foreground sounds, making conversation difficult for him in noisy places. It's great that kids are getting these early so they have a chance to learn how to adapt. I'm excited to see what superpowers they will glean from having powered-brains.

<comment><USER3> 2045 hackernews headline: "Senses capable of spying should have hardware switches"

<comment><USER4> 2080 hackernews headling. Google shut down hearing senses on half the population due to a software error.

<comment><USER5> 2081: A hearing aid startup runs out of VC capital and shuts down the centralized server that everyone's ears are dependent on, and publishes a blog post titled "the next step in our hearing journey."

</comment></comment></comment></comment><comment><USER6> "...can finally tell her parents she loves them"

... and perhaps you have seen those teary videos on Youtube, too, where a toddler hears the first time after a surgery and reacts to sound?

I am afraid that these pieces are at least somewhat disingenuous.

Usually they avoid to put into primary focus two important things:

\- that even with surgery the child needs lots and lots of speech therapy (BBC said at least "...years of therapy...")

\- and that it doesn't always work out.

These failed experiments are truly tragic: these children never learnt to communicate in a human language and will be mentally limited for their whole life: it's an effect of language deprivation.

The best way to approach a deaf child to minimize risks is a two-pronged approach: The parents should accept that they need to learn a Signed Language and the child should grow up bilingually: both in a Signed Language and in a Voiced Language. This prevents language deprivation if surgery didn't work out optimally.

So, in short: the girl should have been able to tell her parents she loves them long ago!

Disclaimer: I am Deaf myself and opinionated about this subject.

</comment><comment><USER7> How long can these implant last? Do they need replacement? Do they run on batteries?

</comment><comment><USER8> It's remarkable how some people in life, were destined to be forever deaf and without any control about it. Yet people preach at any age how we have control instead of teaching how reality really is and where people wouldn't be labouring under delusion. /hard determinist

<comment><USER9> > how reality really is

Well the deaf girl can hear now, so it is clear that sometimes people do have control over natural conditions.

<comment><USER8> No, she was just was born into a time where enough suffering, has resulted in science progressing to the point and where her hearing can be fixed. The act doesn't change control over natural or personal. She was fated to get the surgery and whatever comes in life. She is no different than her reflection and similar to everything in reality. It's a shame people are so against understanding how things really are at the fundamental level.

</comment></comment></comment><comment><USER10> I can't wait for headlines like these "CIA warns against using Huawei P-190(TM) ear implants".</comment>


Urban Airship sends half a billion push notifications - <AUTHOR> http://blog.urbanairship.com/2010/06/29/urban-airship-sends-half-a-billion-push-notifications/

<comment><USER2> How exactly does this work? I dug around the website a bit but couldn't get a clear picture of the basic architecture in my head.

<comment><AUTHOR> (cofounder here)

Since the post is just about Apple push notifications, I'm going to assume that's what you're asking about.

Apple maintains a persistent connection to every device with push notifications enabled. An application can show a user a dialog asking whether or not that user wishes to receive push notifications - if the user says yes, the application is given a unique identifier called a device token. That device token can then be used to deliver messages from the developer's server via a persistent socket connection to Apple using their binary protocol. According to Apple, this connection should be held open as long as possible - you can't just open it when you need to send messages. They also don't provide any grouping or broadcast functionality.

Where we come in (again, on the Apple push side) is allowing that application to register the device token with us along with any additional information they might want - tags, aliases, time zones, quiet time information. The application developer can then send messages through a simple RESTful API instead of maintaining the persistent connection to Apple. They also get the benefit of grouping, RSS to Push, scheduled notifications, broadcast messages and all of the other things we offer.

Our customers love it because not only do we take care of all of the difficult problems, as well as handling scaling to millions of devices, we provide a lot of features on top of the basic service. It's a lot of work that they don't have to implement and, any time that they have questions, they have a team of experts they can contact.

On top of that, we have AirMail, which allows application developers to use push notifications to drive users into a richer experience.</comment></comment>


Bicycle Boulevards Are Awesome [video] - <AUTHOR> http://www.treehugger.com/files/2009/12/bike-boulevards-video-streetfilms-cycling-bicycles-bikes.php

<comment><USER2> Dang, that's nice. Depicted in the video are several shots of Berkeley, CA where I live. I gave up owning a car a few years back and use a bike for most everything. I make pretty heavy use of our Bicycle Boulevards.

FWIW, here are some observations of things that commonly go wrong with these systems:

One of the most important Bicycle Boulevards (hereafter, B.B.s) in Berkeley is shared by spill-over traffic from a car boulevard because of the absence of traffic-calming diverters. The absence of diverters occurs because the self- same street is the main car route to the high school and to City gov't offices. One of the huge negative side effects is that, because of the heavy car traffic (no matter how polite the cars and bus traffic is) the pavement is perpetually in horrible, life-threatening shape for cyclists. Either that street needs diverters or the B.B. needs pushed aside one block.

Another weird problem with the B.B. concept is that on the one hand we teach drivers that cycles are subject to the same rules of the road as cars.... and on the other hand, B.B.s create situations where, for example, bikes can turn left but cars can not. In my experience, this upsets and confuses a small but significant subset of drivers. In one recent encounter a couple (otherwise quite nice, I'm sure) went out of their way to menace me with their car, roll down their windows, and shout at me about traffic law after I made an otherwise perfectly safe and legal turn.

In a similar incident, I was once balled out by a driver for not using the "bike lane" on a B.B., for one block, where there was distinctly no bike lane. I probably delayed her trip by about 15 seconds. She doubled that in the time she paused to chew me out. More commonly, there angry drivers who will tailgate and menace cyclists on B.B.s, looking for a chance to edge around the cyclist and cut them off at close quarters. If I could afford it, I would probably ride with a video camera mounted on my bike to have these folks cited.

That said, the B.B. situation in Berkeley mostly works and I want to give some of the other side of the story:

One phenomenon that really, really hurts the B.B. infrastructure yet is far too common are Idiot Cyclists who, themselves, abruptly cut off cars, blow off stop signs or red lights, and menace pedestrians. The I.C.s have what's coming to them but its the fall-out impact of them on responsible riders that really bugs me.

One trick I've learned that sounds ever so obvious in retrospect yet that not enough people do? If you are a cyclist, LEARN AND USE HAND SIGNALS and BE LIBERAL WITH FRIENDLY NODS / WAVES OF THANKS TO CONSIDERATE DRIVERS. Many, many (maybe most) drivers seem to greatly appreciate the cyclist who is both unsurprising and appreciative of common courtesy. If you think cycling in urban environments is important, go out of your way to socially reinforce good car driving.

Another trick I've learned is that, when it matters for your safety (really matters) - don't be shy about "taking the lane". Sometimes, shoving yourself towards the side of the road is far too risky compared to putting up with an annoyed driver behind you for a block or two.

Another trick - amazingly under-practiced by cyclists in Berkeley - is RIDE WITH AMPLE LIGHTING AND REFLECTION from dusk to dawn. The number of uncomfortable near accidents I've had with cars is comparable to the number of uncomfortable near accidents I've had with Idiot Cyclists who speed, ignore stops, dress in dark clothes, and ride in poor lighting with no lights.

Also, wear a damn helmet!</comment>


IBM S/360 - <AUTHOR> http://en.wikipedia.org/wiki/IBM_System/360

<comment><AUTHOR> I know, I know... you're thinking "Why is this on HN"? Well, here's why... the S/360 is a fascinating bit of computing history that every hacker should be familiar with. For example:

 _System/360 was extremely successful in the market, allowing customers to purchase a smaller system with the knowledge they would always be able to migrate upward if their needs grew, without reprogramming of application software or replacing peripheral devices. The design is considered by many to be one of the most successful computers in history, influencing computer design for years to come._

and

 _The chief architect of System/360 was Gene Amdahl, and the project was managed by Fred Brooks, responsible to Chairman Thomas J. Watson Jr.[3]_

If you don't know who Gene Amdahl and Fred Brooks are, go to Wikipedia and read up.

<comment><USER2> Makes me wonder what happened to all the S360 software.

<comment><AUTHOR> I'd bet that if you wander inside a bank or insurance company that's been around since the 60's or 70's, you'll probably find plenty of it still running. :-)

Of course, it might be running on a nice, spiffy, new IBM zSeries now, instead of an S/360.

<comment><USER2> Do you think IBM employees ever sang "Let's talk about Rexx" to the tune of the famous Salt-n-Pepa's song?</comment></comment></comment></comment>


California Moves to Mandate Female Board Directors - <AUTHOR> https://www.wsj.com/amp/articles/california-moves-to-mandate-female-board-directors-1535571904 <comment><USER2> I want to see a mandate for a non-executive employee board member</comment>


A Bitcoin millionaire is giving away their fortune to research - <AUTHOR> https://qz.com/1160997/a-bitcoin-millionaire-is-giving-away-a-fortune-to-psychedelic-research-curing-aging-and-clean-water/ <comment><USER2> IMHO there's still more room for the BTC/USD to grow (another 30x or so) and that he's selling a lil' short. But better than buying a hockey team like that other bitcoin millionaire.</comment>