After Universal Basic Income, the Flood - <AUTHOR> https://medium.com/p/after-universal-basic-income-the-flood-217db9889c07 <comment><USER3> I don't think rent prices would be such a problem if UBI was introduced. Right now a lot of people are essentially forced to live in big cities because they can't find a job elsewhere and they need the money desperately. This drives up rent prices in the cities.

If you give everyone just enough money to survive, it will encourage people to move back to the suburbs where rent is cheaper. They might have a hard time finding a job there initially but they may have the opportunity to start their own small businesses instead - This would be a boost to suburban economies.

Regarding the argument about some people wasting their UBI. I think that's fine. We're not looking for equality so much as we're looking for fairness. If someone gambles away their UBI every month, at least that money will be put into circulation and provide work to other people who are not wasteful.

UBI is about giving people breathing space to make decisions in their lives instead of being forced to follow the line of breadcrumbs that corporations have left behind.

<comment><USER4> Rent is cheaper in the suburbs, yes, but suburbs have their own costs. For example, you may need to use a car to go places, and car ownership is not cheap.

Various sites ([http://www.moneysense.ca/spend/real-estate/city-or- suburbs-w...](http://www.moneysense.ca/spend/real-estate/city-or-suburbs- where-can-you-afford-to-live/) , [https://www.thepennyhoarder.com/life/cost- of-living-in-city-...](https://www.thepennyhoarder.com/life/cost-of-living-in- city-vs-suburbs/) , [https://boomerandecho.com/living-in-the-city-vs-the- suburbs-...](https://boomerandecho.com/living-in-the-city-vs-the-suburbs-pros- and-cons/) ) discuss how sometimes it's cheaper and sometimes it's more expensive to live in the suburbs.

The first two point out other alternatives; the first, "many Canadians are opting for walkable communities that offer nearby shopping, work, transit and amenities. Known in city-planner speak as "complete neighbourhoods," these walkable neighbourhoods can be found in both urban and suburban settings."; the secondm "you may find a lower cost of living in a small town.".

Personally, I think UBI is more likely to support living in small towns than living in the suburbs. There are many small towns losing population because of people moving to the big cities to find work.

<comment><USER3> I live in a big city now (London UK) and take the train to work. Transport costs me much more than owning a car back when I lived in a town; even if you factor in depreciation, petrol, insurance, traffic fines etc... It's incomparable.

Every big city I've lived in (across many different countries) is similar in terms of transport costs so it's not just a UK thing.

The cost of living in suburbs is nothing. Peanuts. When I was working remotely living in a mid size town in Australia I was able to save up a lot of money very quickly. I just can't do this in a big city.

<comment><USER5> How much do you pay for the train every month?

<comment><USER3> Minimum £180 per month - $250 USD; that's just for my daily work commute. I usually pay extra for weekend travel.

</comment></comment></comment></comment></comment><comment><USER6> Until I read this I was more or less pro-UBI but this article makes some excellent points.

UBI essentially assumes that everyone is a rational actor and that they will not succumb to spending the basic income on non-productive things (drugs, alcohol, gambling, excessively expensive consumables, etc). This is demonstrably false, especially if individuals don't have a day job. On an individual level it's easy to say that people should be responsible for their own wellbeing. But as a matter of public policy, it's just plain bad policy.

It's also hard to see how that money would /not/ be extracted in the form of higher prices across the board.

And the main point of the article is a very good one: what happens to all the now-unskilled labour?

<comment><USER7> > UBI essentially assumes that everyone is a rational actor and that they will > not succumb to spending the basic income on non-productive things (drugs, > alcohol, gambling, excessively expensive consumables, etc). This is > demonstrably false, especially if individuals don't have a day job.

Most people that collect social welfare payments in Australia and New Zealand don't do this - they are frugal with what they get and are careful to pay for their essentials first.

Those that aren't able to budget like this are often offered help in the form of budgeting advice and planning. Sometimes they will find themselves in a situation where they receive the payment they are entitled to, minus the cost of their rent - which is paid directly to their accommodation provider (often the government).

Beyond this, the number of people that don't benefit from their welfare payments because they fritter them away is vanishingly small.

BTW, here in NZ we do actually have a UBI, it's available to everyone regardless of income. The only condition is you have to be of retirement age. Unsurprisingly, it is very, very popular and nobody _ever_ brings up the kind of objections to it that you have here with regard to UBI.

<comment><USER8> That condition is important though. Have you ever wondered why the retirement age keeps going up despite there being a constant shortage of work? That's because society will only grant you a certain number of years off in return for the years you spent on the job.

So retirement is just deferred wages. That's a different concept to getting paid for nothing all the time.

<comment><USER7> How to afford a UBI is a different issue. (As an aside, I believe it is possible, but only after fundamental tax reform that shifts the burden away from earned income and towards unearned income.)

My point with the pension example above was to illustrate that a universal 'living allowance' doesn't necessarily get squandered.

</comment></comment></comment></comment><comment><USER9> Reading the article, the author takes a lot of stabs at "hipsters" and makes "men just want to do drugs and watch TV" comment. So what?

If we truly are moving to a society where labor as we have it today becomes unnecessary, leisure has to replace a portion of that. Note that 18-19 century landowning classes produced a lot of what we today would call negative behaviors (drugs, drinking, gambling, parties, etc), but the same classes also produced a lot of scientific and philosophical advances we take for granted today. A lot of these advances are possible because people could sit for hours musing on various topics without the need to produce something marketable immediately.

If we can finance one more Newton or Einstein at the cost of hundreds of thousands spending their time watching TV, I'd say that's a worthy trade.

Another issue here is that UBI can bring about a lot more investment of human capital into causes that do not produce marketable outputs, such as care for environment or fellow human being on a voluntary basis. This needs a culture/norm shift, but it is possible.

<comment><USER9> One of the unintended consequence that just occurred to me is trying to game the system with the number of children to secure the greatest total income. This could lead to unsustainable (not that we know if our current population size is sustainable) population growth/explosion.

To combat such gaming, the UBI may need to phase out payments beyond replacement rate until they reach 18 or something like that.

<comment><USER4> Your observation which just occurred to you has been a long-time bugbear of the conservative tabloid "Daily Mail" and at least some Tories. Here's an article combining the two: [http://www.dailymail.co.uk/news/article-2364718/No- benefit-c...](http://www.dailymail.co.uk/news/article-2364718/No-benefit- child-youre-dole-Tories-unveil-controversial-welfare-plan.html) .

My view is that people don't want to simply maximize income, otherwise everyone would have two or three jobs and no free time. And taking care of children sometimes feels like having an extra job. I think the Daily Mail, etc. view comes from the idea that the poor are poor simply because they are a bad type of person, and not because of, say, structural inequalities or class oppression.

Bear also in mind that those countries with a level high amount of social services (long paternity leave, free day care, subsidies for children, etc.) tend also to have low rates of childbirth. Quoting [https://en.wikipedia.org/wiki/Birth_rate#Coercive_population...](https://en.wikipedia.org/wiki/Birth_rate#Coercive_population_control) :

> In many countries, the steady decline in birth rates over the past decades > can be greatly attributed to the significant gains in women's freedoms, such > as tackling the phenomenon of forced marriage and child marriage, education > for women and increased socioeconomic opportunities. Women of all economic, > social, religious and educational persuasions are choosing to have less > children as they are gaining more control over their own reproductive > rights. Apart from more children living into their adult years, women are > often more ambitious to take up work, education and living their own lives > rather than just a life of reproduction.[45] Birth rates in third world > countries have fallen due to the introduction of family planning clinics.

<comment><USER9> The low rates are from incumbent majority populations, as things you describe tend to also come with a much better treatment of women and significantly increased use of contraception.

My comment was not meant to vilify a family that would choose to have more kids as the result of UBI, but more to indicate that it could be a rational choice for some.

With full time work, it's often hard to raise one child, but if all you are obligated to do is care for the children and everything else is flexible, it is rational to consider that many families will choose 2 instead of 1, 3 instead of 2 and so on.

This choice is irrespective of the income braket, btw. End result could still be a disaster for our ecology.

<comment><USER4> I'm sorry to sound disrespectful, but I find it hard to believe that within an hour you did the research to go from "I just thought of X" to being able to make large-scale statements like "The low rates are from incumbent majority populations".

Do you have references that support your statement?

Especially as the reference I gave concerned people on the dole in England, most of whom are members of the "incumbent majority population".

"This choice is irrespective of the income braket"

Yet if you look at rich people, with more than enough income to hire nannies, au pairs, and the like, and who don't need to work _at all_ , you still don't see them as a group having more children.

<comment><USER9> Relationship between furtility rates and condition of women is very well documented and something I studied in advanced Econ classes in university. Google would be a good source for that.

Here's one example of a paper on the subject: [http://onlinelibrary.wiley.com/doi/10.1111/padr.12037/full#p...](http://onlinelibrary.wiley.com/doi/10.1111/padr.12037/full#padr12037-tbl3-note-0001) "Immigrants from Pakistan and Bangladesh in the UK and immigrants from Turkey in France, Belgium, and Germany have significantly higher first birth rates than most other population subgroups, which is expected given that they arrived in Europe from high-fertility societies."

Note that there is a decaying towards the national average with each successive generation.

Please show statistics that demonstrate that the ultra wealthy do not have more children than the national average.

<comment><USER10> This is dodging the issue. There must be another reason than "not immigrant".

The direct inverse correlation is with income per capita (PPP and adjusted for social services) and nothing else. Not education levels, GINI, freedom of women. Even in countries where contraceptives are rarely used and women have limited rights, such as Saudi Arabia.

Try stats from, say, gapminder.

The biological theories suggest birth rate selection based on living conditions.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The problem I have with UBI is - I lived in a country that had something very similar - communist Poland.

I've seen it personally - when you get money no matter if you do anything - <USER2> LOT of people just won't. They will happily consume what little they have and focus on other things. You could go to jail for not working in these times, so people pretended to work, but they weren't really working.

Efficiency was awful. One example - my country is one of the top food exporters in EU. 27 years ago we had food shortages and rationing system for many goods. Exports grew over 20 times. GDP grew around 10 times.

That's the difference in output I'm talking about. And countries where they had full collectivization were even worse. We had "communism lite".

Admittedly there are differences between communism and UBI - the system was forced by USSR and they also did some very unpopular things (like persecuting people for religion, murdering WW2-era heroes, beating students and falsifying elections). Also - the chances to make any proper career were very small without at least some participation in the regime - for example signing "I will spy on my colleagues", giving bribes (not money, money were worthless, but favours), etc.

So compared to capitalism the positive reinforcement to working was much weaker, and negative reinforcement wasn't there.

With UBI negative reinforcement also disappears but positive reinforcement stays there. Maybe it will suffice. I don't think so.

<comment><USER12> Except "how do I motivate my workers to actually do work" isn't a problem we have as a society anymore, it's "oh shit what do we do with all these people no employer has any use for?"

<comment><USER13> To horrendously butcher a quote: "He who claims the unemployed should not be lazy but find jobs usually has none to offer nor knows where one can be found."

</comment></comment></comment><comment><USER14> I think many of the UBI supporters know "UBI will replace all the existing welfare programs" is just a sales pitch, and not actually what will happen. For the reasons mentions in this article, UBI will end up being _in addition_ to existing welfare programs, not _instead of_ them. This deceit allows supporters to claim it won't be astronomically expensive, and then once it has become policy and it turns out people aren't using the money on necessities, they will say "oh, I guess we need to keep all the other programs too!" Thus achieving their actual goal of massively growing the welfare state.

UBI is fundamentally about ratcheting up redistribution, not ensuring that people's necessities are met. Programs for the latter will continue to be necessary.

<comment><USER13> > I think many of the UBI supporters know

A supposition. Fine. Opinion is ok although supporting evidence would be nice.

> UBI is fundamentally about ratcheting up redistribution, not ensuring that > people's necessities are met

Declaration of fact without supporting evidence. An argument based on an unsupported opinion.

<comment><USER15> common sense requires no supporting evidence.

</comment></comment></comment><comment><USER16> Nice article. The most interesting point is the question posed for proponents of UBI: what do you do if it doesn't work out as planned? Extending that, if it turns out UBI is a bad idea, how do you get out of it? One thing that governments find hard to do is take back something that they have started giving away to people. It seems to me that, despite the obvious challenges, it is going to be far easier to launch UBI than it would be to close it down and move onto something else. If anyone knows of a UBI supporter that has explained how to 'exit' UBI if it isn't working, I'd be interested in the link.

<comment><USER17> You could introduce it gradually. First it's only available to those of age 65+, then one year later, if all goes well, it becomes available at age 64, etc. When it turns out a bad idea, you similarly roll it back, one year at a time.

<comment><USER18> Then most of the advanced countries already have this sort of system in terms of pensions or social security in the US. And based on discussions around strengthening social security, the solutions which are politically feasible seem to revolve around: increasing retirement age, reducing the benefits (by limiting COLAs), increasing taxes (by removing caps on salaries subject to SS taxes).

Any final proposal to improve SS budgets would be a combination of all three, but I don't see _reducing_ retirement age on the table. So how would your proposal work in this political climate?

</comment></comment></comment><comment><USER19> UBI makes sense only if you're able to ignore pretty much every economic theory except communism.

One particular issue I have is the fiat nature of money: it's meant to be printed to promote economic growth but it will usually reduce purchasing power. This is similar to the effect of dilution on stock.

The article talked about price inflation bit the real issue with UBI is we finally remove any economic value that may be equated to money - it just becomes a piece of paper and it will likely lose value until it has none left.

<comment><USER20> Try Georgism if you need an alternative theory: [https://en.m.wikipedia.org/wiki/Georgism](https://en.m.wikipedia.org/wiki/Georgism)

</comment></comment><comment><USER21> UBI without a basic safety net for health care is a non-starter. It's not a substitute for a welfare state. Without it you are on an ever escalating probability curve towards destabilization.

As for people not "being productive" with their UBI...I hate to break to everyone but the vast majority of people involved in corporate America are not productive at all. There is more make work and duplication and accountability avoidance built-in to corporate life to protect people's income than people involved in valley startups could possibly understand.

Because the stakes are so high around unemployment, accountability becomes a very dangerous proposition. Projects are designed to put potentially career ending actions on consultants or outside parties that assume that responsibility as part of implementation contracts. It's crazy.

If there was a UBI and social safety net that allowed people to pursue interests and not force them to take jobs that they dislike and cling to for dear life...everyone will be better, and I promise the people motivated to perform will still be performing, they just won't have people in the way that don't want to be there.

It will also stop hiding the cost of getting high performance employees. People won't have to take employment to survive.

</comment><comment><USER22> I am in favor of UBI, a few remarks:

\- mostly because people on the bottom can be powerless and get stuck in low paying jobs, no means to move, to re-educate, etc.

\- today most countries already redistribute money, in form of minimum wage, tax cuts, food stamps, disability benefits, heath insurance, etc.

\- UBI is a dial, you can turn it up, or turn it down, redistribute 15% of all value created is not unreasonable, some European countries are already at 10-15%

\- make sure every dollar earned, helps you move forward, benefits, UBI, taxation, should never have jumps in scales, but always be linear (this is horribly off in my country today)

\- drug misuse, poor that cannot handle money, is a problem today, and UBI won't solve it, it's not on the agenda to dump all social workers ...

\- lazy hipsters, that is intuitive but likely wrong, ... UBI is not exactly luxurious living, you'd want a job or no car, no nice clothes, no travelling, etc ...

</comment><comment><USER23> I'm curious why UBI has become popular over Milton Friedman's negative income tax. It seems to avoid a lot of the lack of incentive and cost issues.

<comment><USER24> UBI will work even in an environment where many people have no marketable skills, while negative income tax would just be the state sponsoring activities with no real value.

We're not there yet, but the odds of ending up there sooner or later is very high.

(Negative income tax could still be good if the activities themselves have a positive social value.)

</comment></comment><comment><USER25> Small nit from article - "You don't build a nuclear power plant (or even a dam) without a plan for what to do if it goes critical."

Reactors going critical is a good thing.

From wikipedia: When a reactor's neutron population remains steady from one generation to the next (creating as many new neutrons as are lost), the fission chain reaction is self-sustaining and the reactor's condition is referred to as "critical".

</comment><comment><USER26> Wrong on many levels. Just plain wrong assumptions.

</comment><comment><USER27> My pessimistic conspiracy theory is UBI is just a carrot on a stick to keep people pacified. Humanity does not take the high road on a global scale. A war is likelier and the excess humanity will be killed off.

<comment><USER28> That's a conspiracy theory, indeed. If you want to prepare a war, you don't want "pacified" population. I can imagine somebody combining UBI with some sort of fascism, just like leninism did it with marxism, but by itself.. I don't see how alone it could be misused.

<comment><USER27> I think the political climate is getting more heated up with every passing year. The right/left rift is large and getting larger. In the US and EU. If it keeps getting worse like it has been, a (civil) war is a distinct possibility 5-10 years down the line.

</comment></comment></comment><comment><USER29> UBI has to be extremely aggressive to be effective. We're going to have to stop wasting resources on wars and militaries. With the obscene amount spent on the US military to maintain an empire could we instead give every US citizen a 100k income? Not once the dust has settled, we're in debt for generations and looking at 70-80% income tax on the small amount of people left working not to provide income for those pushed out of the economy but to provide income fr the rentier class who pay hardly or no taxes and live off the labor of others.</comment>


Ex Machina: Where Turing Meets Bechdel Test - <AUTHOR> http://robohub.org/ex-machina-when-turing-meets-bechdel-test/

<comment><USER2> Loved the film but we aren't going to see robots look or move like that any time soon. Think? Maybe.</comment>


Neovim: input encoding and you - <AUTHOR> http://www.aktau.be/2014/11/04/neovim-input-encoding-and-you/ <comment><USER2> If this is the general quality of new code in the Neovim code base, I would be fairly worried.

In the first piece of code, which is apparently new to Neovim, there's a bug waiting to happen: casting size_t pointers to int pointers will fail on big- endian platforms where sizeof(size_t) != sizeof(int), and in general, the number of casts sprinkled everywhere is indicative of sloppy coding.

The whole area of code also seems to be poorly reimplementing iconv, which is actually supported in the code, but never enabled in Neovim for some reason, according to the footnote - why have two code paths to do the same thing?

<comment><USER3> In general they appear to have a problem with mixing lengths between being ints and being size_ts (Decently common problem). In that particular instance they could run into a problem if they compile for 64-bit (64-bit size_t, 32-bit int) and string_convert_ext gives a negative length, since int is signed.

<comment><USER4> We compile for 64-bit and 32-bit on every commit with travis CI and for many files activate extra warnings such as `-Wconversion`. We are acutely aware of the problem. However, we can't refactor the entirety of the (quite large) Vim codebase in one go. Whenever we add new code or replace old code that calls into more old code (often), we have to decide whether we will also refactor said old code to be more modern.

In fact, we have sections of the projects wiki devoted to this type issue: [https://github.com/neovim/neovim/wiki](https://github.com/neovim/neovim/wiki) (the specific section: [https://github.com/neovim/neovim/wiki/Integer-types- refactor...](https://github.com/neovim/neovim/wiki/Integer-types-refactoring- guidelines)).

It's not perfect, but you'll see we've put at least some thought into it and we welcome new contributions.

It's a problem of manpower and/or time, not necessarily of misunderstanding C and making rookie mistakes about types as the grandparent seems to imply.

There, had to get that off my chest. (I'm not seeing Neovim's code, old or new, is perfect, but it's probably better than what the tone of the comment implied).

<comment><USER5> aktau, your HN account appears to be dead. I'm guessing it's because this comment of yours was posted multiple times.

<comment><USER4> Thanks for the heads up. I went back and pressed submit several times because in my incognito window my comment didn't show up. (I was trying to post while noprocrast was on, didn't expect something I wrote to hit HN). I wonder now what I should do to not become dead anymore? I deleted the superfluous comments, hopefully that's enough. I'll look up what it means to be dead on HN.

<comment><USER5> Deleting those posts seems to have worked. I can now see your previously elided comments with my "showdead" set to on.

</comment></comment></comment></comment></comment></comment><comment><USER6> As a user, what benefit do I have switching from vim to neovim?

<comment><USER7> My understanding is that Neovim will make it much easier for plugins to execute tasks in parallel and in the background.

I'd use that for running ctags on save without blocking the editor, for example.

<comment><USER8> The reason I'm following neovim is that I'm hoping for a future where linting doesn't freeze my editor on save. Sadly,

I do like my gui, so I'll have to wait a bit more</comment></comment></comment>


Ask HN: SaaS solution to provide easy and nice PDF embedding in a web page? - <AUTHOR>

I'm somewhat disappointed by the ways I've found to embed a PDF in a web page for user interaction... My main gripe at the moment is with Chrome, as it appears the Chrome PDF reader does not correctly implement the PDF Open parameters (https://code.google.com/p/chromium/issues/detail?id=64309).<p>So, my question: is there any friendly, use-and-forget service out there where I can just upload the PDF, easily embed it into my website and have the same interface cross-browser for interacting with the PDF, as well as the possibility to open it with "fit width"? <comment><USER2> The Firefox PDF viewer (pdf.js) can be used in any browser from any website. [https://github.com/mozilla/pdf.js](https://github.com/mozilla/pdf.js)

See a demo: [http://mozilla.github.io/pdf.js/web/viewer.html](http://mozilla.github.io/pdf.js/web/viewer.html)

<comment><AUTHOR> Wouldn't I need a node.js server to run that? It's listed as a prerequisite in the GitHub page...

<comment><USER2> I've not worked with it except as an end user. But my understanding is that you only need node.js if you're trying to test this locally, because browsers treat file:/// URLs differently than [http://localhost](http://localhost)

<comment><AUTHOR> You are right, actually, as long as it's coming from a webserver (IIS here) I'm able to run the demo. Thanks!

</comment></comment></comment></comment><comment><USER3> pdf.js is where all the work goes these days - [http://mozilla.github.io/pdf.js/](http://mozilla.github.io/pdf.js/)

I haven't used it for a couple of years but is was pretty good back then and playing with the demo now it seems very slick. I'd start there if I were you (maybe there's a hosted service using it).

</comment><comment><USER4> Shameless plug, GroupDocs Cloud Viewer API should support what you require, there's a 14 day trial to allow you to try it out, I work for GroupDocs.</comment>


Worrying about the NPM Ecosystem - <AUTHOR> https://sambleckley.com/writing/npm.html <comment><USER3> The npm ecosystem needs something like the distinction between Ubuntu's "main" and "universe" repositories, so that you have a smaller subset of known-good packages with harmonized transitive dependencies, stronger centralized curation, a lot more direct scrutiny, tighter control over versioning, and some party that is responsible for addressing vulnerabilities and ensuring appropriate maintainership.

As a venture-backed startup, the company behind npm needed the number of packages and the number of downloads to constantly trend upward in order to justify their valuation. This led to extremely poor policy and prevented them from taking strong steps to remedy the deterioration of the ecosystem. Now that it's owned by Microsoft, there's an opportunity to fix this.

Linux distributions have decades of experience solving these problems, there's no excuse for the JavaScript community to continue ignoring the longstanding precedents and best practices that have emerged from that experience.

<comment><USER4> This is a really good idea, and a fitting analogy. NPM already supports private registries, so it would be a simple configuration change to point to "main". On top of that, there is a lot of good work in the node community around static analysis, CVE detection in transitive dependencies, and more finely grained security perimeters, which could be used to detect possible backdoors or malicious code.

<comment><USER5> It would be completely straightforward to do the work you describe. Presumably numerous private actors have already done it for themselves. Until someone does this work and shares it with the public, we'll all have to wonder how valuable it would really be... anyway, it's unreasonable to expect the npm people to do this work on top of everything else they do.

</comment></comment></comment><comment><USER6> This post describes several potential "problems" with NPM packages, but not _why_ they are problems in the first place. The author doesn't say why they consider circular dependencies bad, or why dependency depth should be low, or even why their categorization of packages is the way it is (and leaves out large categories like tools and CLIs).

I don't think that a high number of dependencies is necessarily bad, or a low number is necessarily good. A dependency can often have factored out common functionality into a shared and higher-quality project than the same bespoke implementation re-implemented in several packages.

I think we'd need some more complicated metrics, possibly looking a bit like a web of trust analysis, to determine quality and health of packages. Depending on a well-maintained, popular, and highly-trusted package like lodash or express shouldn't be an indicator of low-quality or low-trust. We also have deprecation and security notices provided by NPM.

So I'd be much more interested in questions like "how many unique, low-trust packages are included in this package graph?" or "how out of date are the dependencies?" to try to estimate package health. From there I'd be curious to know how healthy the ecosystem is in aggregate, weighted for usage.

<comment><AUTHOR> You're absolutely right that I am doing a certain amount of "searching under the spotlight", here. The metrics I measured were the ones I had the information and computational power to measure. You want to see how many "low trust" packages there are -- me too! But what does that mean? How do I find them? That is, in essence, the _problem_ I'm describing. If I could solve it, believe me, the post would have been about that, instead :)

I do propose, towards the end, a network-of-trust score -- but I don't think that's something a single person can implement today; it requires social work.

(I am sorry you feel I didn't explain why deep dependency trees are a problem -- my premise is based on the desire to assess packages for if they are appropriate to include in a project, and I _do_ mention why deep and broad trees make that harder. Circular dependencies I specifically say _aren 't_ a problem; they're just disconcerting to me.)

<comment><USER7> +1 for "searching under the spotlight", such a great (and IMHO underused) turn of phrase

</comment></comment></comment><comment><USER8> One of the author's points it the thing that makes me crazy about the JS ecosystem "... find a package ... it might depend on hundreds of other packages, with dependency trees stretching ten or more levels deep..."

I cannot count the number of times when I've installed a package and got >500 or >1000 packages as dependencies.

Just today I installed 'alptail' a simple set of components using AlpineJS and TailwindCSS (I love both!) but it npm installed 1314 packages! For a simple set of maybe a dozen components.

This is madness.

How do we make this better?

Maybe we need more support from tooling to understand just what is being used down the tree of trees of trees?

Maybe as lib writers we should seek to implement our own supporting functions (within limits, of course) rather than having a first reaction "let's go grab XYZ for that" and inherit XYZ's entire dep tree.

Not sure what the answer is but what we have today is a beautiful mess (love/hate it).

Thanks for letting me vent a bit. I feel better. But this really bothers me.

<comment><USER9> I just wonder who cares? At all? What is "better"? Reinventing wheels instead of relying on open source, battle tested code?

Also alptail isn't an npm package? [https://github.com/danieljpalmer/alptail](https://github.com/danieljpalmer/alptail)

<comment><USER10> This "reinventing the wheel" concept has to die.

Writing your own code is not "reinventing the wheel". It's what we do. A lot of times writing a new implementation is faster in the long run (more focused, less obscure, easier to maintain).

Open source code is often not "battle tested" in your environment for your use case. And if there is a problem, getting it fixed can be a nightmare.

It's like I'm making a go-cart, and making some nice appropriately-sized matching wheels for it, and someone comes along insisting I don't "re-invent the wheel" and use these four mismatched truck wheels instead. Yes, I'll save time making the wheels. But the rest of the project is screwed.

<comment><USER8> > Writing your own code is not "reinventing the wheel". It's what we do. A lot > of times writing a new implementation is faster in the long run (more > focused, less obscure, easier to maintain).

So much agreement. We often will rewrite smaller sets functions or other code for the express purposes of trimming dependencies, understanding what the code does, and having the opportunity to adopt it into our codebase with a fresh re-look at implementation, adding comments, etc.

> Open source code is often not "battle tested" in your environment for your > use case. And if there is a problem, getting it fixed can be a nightmare.

Again. Agree with you strongly. Just because something as been available in npm does not automatically mean battle tested. There's a ton of broken/poor code out there.

</comment></comment></comment></comment><comment><USER11> The chance to fix npm is dwindling quickly. With each year, a culture sets in that will get harder and harder to fix with time.

Personally I suspect that the lefpad debacle might have been the point of no return for npm; the fact that such a simple package managed to break everything g should have been a wake up call, but it does not appear that the community fixed much.

<comment><USER12> What could potentially happen with a malicious dependency added knowingly by the original author or unknowingly because his account is compromised will one day make leftpad look like a harmless warning / near escape we ignored.

Sure, leftpad broke productivity for one day. But the continued willful ignorance we show towards "yet another dependency" will kill us one day.

There is work happening in creating notary etc. Github/Microsoft is in a very good position to solve this. I hope they take the opportunity.

<comment><USER13> The sad thing is that it already happened 2 years ago [1]. And nothing changed apart from some general apathy on the interwebs.

The JavaScript ecosystem is past the point of no return right now. Any improvements will only be band-aids.

[1] - [https://www.trendmicro.com/vinfo/dk/security/news/cybercrime...](https://www.trendmicro.com/vinfo/dk/security/news/cybercrime- and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin- wallets)

</comment></comment></comment><comment><USER14> My non-technical thoughts on the npm ecosystem:

1\. Split package-lock into a human readable file and a machine readable one. Right now it's just pain.

2\. TRUSTED PACKAGES. Somebody has to assign trust. Companies or highly involved developers should become curators.

3\. LIMITED Packages with reduced security risk: File Access, Network Access, package access, OS access, etc...

4\. Transit npm package best-practices into a single module format. Reduce clutter and number of files in node_modules.

5\. Better tagging. Allow votes on tags.

6\. Add monetization links for package authors to npm (blunt) and to the CLI (subtle, e.g. 'npm pay leftpad' opens the monetarization page on npm.).

Additional ideas:

A: Buyable certificates/insurance for packages.

B: Better clone, modify & re-publish workflow

C: Integrate FAQ/Forum directly in NPM directory website. Simple downvotes/upvotes for visibility. Allow and ask for readme pull requests from npm package page.

<comment><USER15> If packages are "trusted", how would NPM ensure that they are continually trusted as new versions come out? I've read those stories with packages whose developers hand them over for maintenance, and then a new update comes out with malicious code

<comment><USER16> M of N signatures on new version tags, or on ranges of commits?

</comment></comment></comment><comment><USER17> Hate to break it to the author, but npm has been a raging dumpster-fire for over 4 years now. My personal advice on how to live with it:

\- Assume you will have to rewrite your app in a year or less from now and organize it as such. This won't be easy when dealing with release deadlines which result in all-nighters full of sphagetti code. Whether you're doing react, vue or angular, just keep your components and logic small and if you need a package, (say for handling CSVs) then look for one that promotes itself as having no dependencies. Keep in mind that while re-writes can be a taboo subject to many managers, they can actually be the fastest way to solve deep dependency issues.

\- Unless your framework requires it, try not to lock your package versions, this is a very common bad practice in my opinion. ```npm audit``` is your new best friend, make updating to latest part of every sprint. If you're just 3-4 months out of date these days you're likely to have over 40 security vulnerabilities. If you're 6 months out of date on a public facing application and need to pass a security audit, you're not gonna pass it. Compliance requirements, like SOC2 or healthcare ones are getting a lot more thorough as well. It's a lot less work to update continuously.

-Secure your devops. Any npm package that runs has full acess to your entire disk and network I/O. The cheapest way to harden security is to move your devops to aws or gcp. They can afford to audit their networks and OSes a lot more often than you can. If you're doing it alone or on a very small team, i'd recommend trying out aws-amplify or firebase hosting on gcp.

-If you're doing node on the backend, go full typescript. I think it's easier to adopt a "strongly typed" mentality when your logic is clearly defined. If you don't feel confident in your use of typescript, then don't use it in the front end. You're gonna have a bad time, especially with state management in React. However it is getting more mature and package managers are learning to avoid type issues too when updating their methods.

\- And last, when picking a new framework or boilerplate or package, run npm audit on it first then make sure to read up on their github issues as much as you possibly can. It's very important to get not just a technical feel but a social one too on how their devs react to their issues.

<comment><USER18> Aside from the "raging dumpster-fire" \- I personally have benefitted greatly from NPM, and many of its problems are likely common in other package ecosystems/managers - I do find myself nodding in agreement with all your points.

"Assume churn as inevitable and be organized for it" is a good mindset to stay sane on the leading edge, especially in the world wild web. The Jenga tower of dependencies will move around, break things every so often - <USER2> interface for sometimes seemingly no reason other than preference. Major shifts in foundation, architecture, patterns, standard libraries, or organizational concepts are a regular occurence.

</comment></comment><comment><USER19> A lot of the results of this analysis are a consequence of actually good UX in dependency management.

In NPM publishing a library is really easy. To compare with java, I recently had to follow a [three part medium article]([https://proandroiddev.com/publishing-a-maven- artifact-3-3-st...](https://proandroiddev.com/publishing-a-maven- artifact-3-3-step-by-step-instructions-to-mavencentral-publishing- bd661081645d)) to publish. NPM: one login, one cli command and you're done. That lowers the bar to create a library, there are a lot of low quality libraries, but there's also much more diversity and really cool libraries. In java I've seen a lot of copy pasting. In Node you just create a library. You can worry a lot about 1k dependencies, but a lot of those will be one liners.

In node, it's basically impossible to have conflicts with dependencies. Again if we compare to Java. In Java namespaces are global, if there are two libraries sharing the same package name they will collide. That makes deep dependency trees actually a liability. I've seen recommendations of not using guava if you are writing a library, because they change the api so much that it will most certainly give problems if your user wants to use it as well, so much for a library. In Node, in contrast, if there are two different libraries that require different versions, they will each have their own dependency version. That has the cost of space, but there it saves hundreds of hours on conflict resolution. You can even have two different versions of the same library with different name, in case you need to partially migrate a project.

Making it easy to create and consume libraries has of course a clear consequence, more deep and big dependency trees.

</comment><comment><USER20> The solution mentioned at the start of the article is what distribution package maintainers have been doing for decades. I would take this account as a giant flashing warning sign of what could happen to the flatpak/snap ecosystem, and also a flashing warning sign for languages that are developing their own package manager, especially if it is difficult for packages from the language package manager to be integrated into actual system level package managers. The curation effort required to get NPM into manageable shape is almost certainly beyond the scope of any traditional community effort.

<comment><USER21> Not having a package manager for your language means you're back to CMake and the "FindBoost", "FindCuda", "FindMKL", scripts that always fail for one reason or the other.

It encourages reinventing the wheel instead of standing on the shoulder of giants. For smaller languages having everyone implement a JSON parsing library because there is no dependency management would be a significant hurdle that might kill off the language before it's even started.

System package manager are a pain to deal with as a developer, when adding CI to my projects I'd rather deal with the language package manager, that works on Windows, MacOS, Linux rather than brew + msys2/pacman + apt-get and some C/C++ dependencies are just unavailable (looking at you recent BLAS/Lapack on Windows)

It also significantly streamline the documentation. Any step you add to your git clone or foo install is an extra hurdle for package adoption.

Lastly the language community needs is often at odds with the system administrator needs. You can't expect the distro package manager to deal with every single packages in the R community for example which allow you to analyze in a slightly different but niche way. This was examplified by the recent Haskell package management in Archlinux rant (link dead but was here: [https://dixonary.co.uk/blog/haskell/cabal-2020](https://dixonary.co.uk/blog/haskell/cabal-2020))

Now I'm not saying that system package managers are bad, I go out of my way to integrate all the Data Science libraries I use in my system: [https://github.com/mratsim/arch-Data- Science](https://github.com/mratsim/arch-Data-Science), but that's because here I take my sysadmin/end-user/package consumer hat.

<comment> dane-pgp > Not having a package manager for your language ... encourages reinventing > the wheel instead of standing on the shoulder of giants.

Isn't writing a new package manager from scratch a pretty clear example of reinventing the wheel, especially when these package managers often miss vital features that system package managers have had for 15 years?

[https://wiki.debian.org/SecureApt](https://wiki.debian.org/SecureApt)

<comment><USER22> You link a package management solution that works for a single OS and wonder why programming language libraries don't just use that?

So, I have a useful library that I want to share with the world. I do what, exactly, so that other people across platforms can use it?

<comment><USER23> Your comment is a beautiful demonstration of the problem -- a lack of understanding of the existing tool drives a desire for a new, different tool.

There is absolutely nothing about apt or dpkg that are os specific other than they require a posix-like environment. The same goes for rpm and yum. And pacman.

At the end of the day, these package managers all do the following: 1) describe the dependency relationships of packaged software 2) describe where to extract files 3) describe any actions that need to be taken prior to or after extracting files

There's nothing stopping you from installing .debs with dpkg on an RedHat system nor .rpms with rpm on a Debian system aside from conflicts when both package managers try to put files in the same place.

This same conflict occurs when language package managers come into the picture, because newsflash: someone else has been working on the same fucking problem for decades, and somewhere between just ignoring their work, and actively hampering it.

<comment><USER22> Can you give an example of a project, maybe a programming language ecosystem, that unifies some sort of publish-once, access-anywhere package system that uses those tools and works across Linux, Windows, and macOS?

I don't understand what that would look like in practice. Tools like Homebrew and MacPorts don't even do what you are asserting is the obvious, trivial way to do it. And I have a feeling it isn't just because my microbrain doesn't get it.

For example, I don't see how your post pitches something different than what I used to have to do with C/C++ deps and CMake back in the day, and those were not the hey days of dep management.

Also, enough with the animosity. When you find yourself registering a new account because you want to sneak in some venom when talking about software dep management on an internet message board, what are you doing?

<comment><USER20> Gentoo prefix can run on a wide variety of operating systems and distributions. It needs a few updates to work around the recent changes in macos permissioning, but if it can find a familiar shell it will more or less work as expected.

I think part of the above comment is expressing frustration about the fact that part of the reason for the lack of wide portability of these programs is precisely because people say "oh they can't do x" or "this is operating system specific" and taking it as axiomatic rather than realizing that with a bit of engineering time and effort they can be extended to work on other systems. This especially since there is pretty much no language that is used entirely by itself without dependencies on another at some point in time. If your language has a ffi, then you need a real package manager to accompany it.

[0] [https://wiki.gentoo.org/wiki/Project:Prefix](https://wiki.gentoo.org/wiki/Project:Prefix)

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Nice to see some actual numbers and research on the topic. Most complaints about NPM seem to fall into the category of fretful, emotional hand-wringing (although there's some of that here too).

If we measure success by the amount (not the percentage) of high-quality packages available, NPM is easily the best package management ecosystem yet. But there's definitely room for improvement.

One major improvement I'd like to see is some solution for unwanted indirect dependencies. If I depend on package A, and A provides features X and Y, and I only need it to do X, and the code for doing Y depends on package B, then it shouldn't download B. The recommended solution is to split up A into a family of packages (like lodash's per-method packages), but that just creates a mess of versioning that's annoying for both the authors and the consumers. And those massively-multipackage libraries (like Babel) just seem to create dependency hell situations that semantic versioning is not good enough at solving. So maybe instead of package splitting, the next-gen package manager could have first-class understanding of ES6 modules, with tree-shaking logic to prevent unused indirect dependencies.

</comment><comment><USER25> I think that a lot of ideas here are really good, but they shouldn't be implemented in npm. Npm is not meant to be curated. NPM is meant to be a canonical way to reference a dependency, and that's about it.

I don't think it's NPMs role to assign "quality" to a package (even though ironically they have a quality metric) -- that's something a third-party should do on top of npm.

That's the unix philosophy in me speaking.

</comment><comment><USER26> For most other languages the package ecosystem is a competitive advantage; Perl had CPAN; Python famously comes with batteries included, but is used where its batteries don't matter (numpy and friends, django); rubyists will go on about their gems for as long as you care to listen. JS is the only ecosystem I know of where the libraries are something that scares people away from the language. My own opinion is that npm is not state-of-the-art, and there is a culture problem (starting with wrapping single statements in a library — leftpad is most famous, but wrapping a single regex in its own, incompatible wrapper seems to be an accepted way to do things, too). The culture problem may be unsolvable.

<comment><USER27> Some other salient differences with Perl and Python:

\- Perl and CPAN are tightly integrated, whereas NPM and JavaScript are not. Perl without CPAN is unthinkable; JavaScript without NPM is rather pleasant. A huge amount of JavaScript culture, best practices, and idioms existed before NPM and therefore there's much less cultural cohesiveness on "standard" third party libraries, etc. It's a different story with Node specifically but the horse already left the barn by then.

\- many of the "batteries included" in Python are from a rich standard library that JavaScript/Node lacks. So there isn't a need for a third party library to implement extremely basic functions like you see in Lodash or leftpad, and for pip packages there's a much deeper base of code/API standards to draw standards and idioms from.

<comment><USER28> I'm of the opinion that most of lodash should just be incorporated into vanilla javascript, as part of its standard library. It could be done similarly to Python (or any language, really), and just group each collection of functions by usage (like itertools in Python groups tools for iteration).

Once people stop feeling the need to reach for third-party packages to accomplish day-to-day tasks maybe there'll be more freedom to move away from the way npm is the way it is today.

<comment><USER29> > lodash should just be incorporated into vanilla javascript, as part of its > standard library

That's already happening. More and more of lodash/underscore/etc's functions are being introduced to Array/Object/String APIs.

[https://github.com/you-dont-need/You-Dont-Need-Lodash- Unders...](https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore)

</comment></comment></comment></comment><comment> open-source-ux I think the problems articulated in this article will make Deno attractive to many JavaScript developers. The standard Deno library has everything needed for building server-side dynamic websites.

But I think what will speed adoption of Deno is something that has been little-commented on: the runtime is a single-executable. This massively simplifies deployment.

Contrast that with Node, Python, Ruby and the way they spew out dozen, often 100s, of tiny script files all over the place. Simple, uncomplicated deployment solutions (particularly for self-hosting) simply don't exist with many interpreted languages. Whatever you think of Deno, their decision to create a single executable runtime will make it attractive to many developers.

<comment><USER30> Deno makes not sense to me outside of hobby projects, lambda functions and other small components. Large projects with thousands of lines of code will be difficult to support with this paradigm. The security model is also not great. I applaud the effort, I think it is great, but command line flags for security work only for small project files. For any large project you need something that is granular and per module/function. If you start going down that rabbit hole you will end up with some kind of configuration file no different than package.json.

</comment></comment><comment><USER31> I have decided to use javascript strictly for frontend only, no more node.js or express or whatever else for backend. I will just use non-js backends these days, which are plenty.

It's sad I still have to use npm even for frontend development nowadays, along with babel, webpack and a matrix to get started.

I now stick with jquery(yes I know, but its concise syntax matters to me) and bootstrap, and they seem working for 99% use cases for me. super easy to get start and maintain, good enough for my use cases.

</comment><comment><USER32> The only problem I see is the lack of a comprehensive standard library for Node.js.

<comment><USER33> Ruby: x.is_a? Integer

PHP: is_int($x) (alias of is_integer)

Python: isinstance(x, int)

Node.js[1]:

        typeof val === "number" &&
        (!(typeof value !== 'number' || value !== value || value === Infinity || value === -Infinity)) &&
        Math.floor(val) === val

I think all supported Node.js versions now have Number.isInteger (via es262), but the is-integer package still gets a 200_000 downloads a week[2].

[1]: [https://github.com/parshap/js-is- integer/blob/master/index.j...](https://github.com/parshap/js-is- integer/blob/master/index.js#L4-L8)

[2]: [https://www.npmjs.com/package/is- integer](https://www.npmjs.com/package/is-integer)

<comment><USER34> This actually taps into something I really like about npm. For things that "should be easy/obvious", there are usually edge cases, _especially_ around how `Object` is handled.

The real answer is for Node to have built-ins that handle this (which they now do for `isInteger`, but absent that, I love that there are these specific packages that have unit tests and a simple API. People scoff at things at `isPromise`[1], but it's reliably filling a super important niche that the language doesn't handle.

[1]: [https://github.com/then/is- promise/blob/1d547300e780a4eca391...](https://github.com/then/is- promise/blob/1d547300e780a4eca391236f15e5ccbf76a5789d/index.js)

<comment><USER33> Maybe we should adopt these packages into es262 and make the shims available by default directly with the language?

</comment></comment></comment></comment><comment><USER35> A package depending on itself is just an accident (and probably something npm ought to detect on publish and reject, but alas...)

However, I believe a 1-package circular dependency is often the result of a developer mistakenly adding a package as a dependency when they mean to add it to `peerDepedencies`:

e.g. in TFA: "babel-core depends on babel-register, which depends on babel- core... yeoman-generator depends on yeoman-environment which depends on yeoman-generator."

Peer dependencies, of course, no longer exist because it got deprecated because raisins.

Which leaves us with zero options to define sideways dependencies.

<comment><AUTHOR> Where did you read peerDependencies was deprecated? It's still valid and recommended, AFAIK:

[https://docs.npmjs.com/files/package.json#peerdependencies](https://docs.npmjs.com/files/package.json#peerdependencies)

<comment><USER36> I think they meant the behavior of not installing peerDependencies was "deprecated".

<comment><USER35> Right, I misspoke. However what's the point of calling it a "dependency" when you don't install it alongside?

</comment></comment></comment></comment><comment><USER37> "is this package 'healthy'?" is a good line of thought, but the proposed metrics are all less useful than just opening the source on Github or unpkg.com and giving the source code a quick skim read.

If it looks too scary for you to maintain, you shouldn't take it on as a dependency.

> It's not really a technical problem, but mostly a social one.

This is absolutely correct.

<comment><AUTHOR> You're right! That works great for the package itself, and it's what I do. But will you also chase down and open on github all that package's dependencies, and their dependencies, etc? It is that, more recursive problem that I'm trying to point at. If you are content to trust that the package maintainer chose their dependencies wisely, then this probably won't seem like a big deal -- and that's ok! Different projects have different requirements for how they assess third-party code.

<comment><USER37> I do check out dependencies, yeah – Octolinker makes it easy to do due diligence on reasonable libraries.

If it has a ton of dependencies, then I don't want to take it on/maintain it anyway.

</comment></comment></comment><comment><USER38> The problem with the javascript ecosystem is that javascript ecosystem rejects the problems with the ecosystem.

</comment><comment><USER39> Why why why is the default behavior of npm install to choose a range of versions rather than a single version.

I don't want "a version compatible with lib 0.1.0" I want lib 0.1.0 ... package-lock is a strange bandaid over this.

If I want the code my app depends on to change, I'll change it.

<comment><USER10> why bother with the package system at all then? Why not just copy/paste the code into your project?

<comment><USER39> Npm provides much more value than copy-pasting code! I think we all know that.

That said if I happen upon a possible dependency that's just one JS file and has a permissive license, I often do choose the copy-paste route.

</comment></comment></comment><comment><USER30> Btw, nobody is forcing anyone to use any packages from npm. You can easily use whatever repository you want. You can store your dependencies in your source repositories together with you application or another entirely separate repo.

JavaScript is a huge, perhaps the biggest, software ecosystem in the world. There is a vast amount of code out there and you are going to get some bad stuff if you are not careful. This does not mean it is bad at the core. It means that it comes at the cost of doing security work upfront if you care about this. while benefiting from the crowd-sourced experience of the masses.

</comment><comment><USER30> While I agree that NPM can be improved, most people who are complaining about the number of dependencies have no idea what they are doing.

If you install a package without the --production, which is default, you get everything including perhaps some build packages like babel, linters, and what not. These dev dependencies tend to be huge. That is how it works. Similarly, if you install the dev version of a library in some other language you get not just the source but perhaps hundreds of megs more of other source. What is the problem?

<comment><AUTHOR> This analysis does not include devDependencies. The counts and statistics in it relate to strict dependencies only.

</comment></comment><comment><USER40> What if npm packages are re-coded by popularity? In the sense that any package that has achieved high connectivity and popularity must eliminate as much dependencies with pure JS code. But again that would cause code bloating. Dan Abramov had a talk about abandoning Clean Code. It is kind of strange that simple React app now days has NPM folder with 1GB of files, but I guess we got used to.

</comment><comment><USER41> If I install React it's because I trust React. If React installs 10000 packages, I see no problem because I assume that React knows what they're doing, otherwise I wouldn't trust them and I wouldn't have installed React in the first place.

If I don't like deep dependency trees, then I install packages that I trust not to use deep dependency trees (or rather graphs since they can have cycles).

</comment><comment><USER10> I refuse to use npm at all. Too risky.

I only use libraries if they can be added as a first-order dependency (i.e. in a script tag on the page). This is still risky, but I can mitigate it somewhat. And at least I'm not giving a bunch of random maintainers commit-to- prod access in my core code.

</comment><comment><USER42> Been looking for mdns browser package and still not sure how to filter out node packages on NPM.

</comment><comment><USER43> Cyclical dependencies are a feature, not a bug. Many languages don't allow such a feature to exist at all with their compilation/interpreter models.

<comment> yjftsjthsd-h What is a good usecase for circular dependencies?

<comment> crooked-v Compilers/transpilers seem like a prime example. For example, imagine Typescript vX using utility-library-a, which itself is written in Typescript and has Typescript vY as a dev dependency.

<comment><AUTHOR> You're right, that is a perfectly valid occurrence! However, I did not count dev- or peer- dependencies in cycles; only true-blue dependencies. So all the cycles I counter were either not of that type, or failing to use devDependencies -- which would also be unfortunate.</comment></comment></comment></comment>


Study Estimates 50% of Web Sites Using WebAssembly Do So for Malicious Purposes - <AUTHOR> https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-usage/ <comment><USER2> Is this possibly a basis error? Would _most_ sites these days be malicious, regardless of whether or not they use WebAssembly (or any other feature/capability)?

The number of sites most users visit regularly is small. Malicious sites are probably not among those, so there's a long tail of malicious websites. Some fraction of those rely on WebAssemby, or other features.

It might be better to track based on use _weighted for site-visits by users_. That is, behaviour trumps census counts.</comment>


The last audio cassette factory [video] - <AUTHOR> https://www.youtube.com/watch?v=UJ4BcZ8ZTjc?

<comment><USER2> My first guess was 'ho-hum, somewhere in the bowels of China and who cares'.

Then I noticed the Vietnamese media name and thought, 'oh, it's in Vietnam. A little more interesting.'

But it's in Springfield Missouri. What?

They have Revox(!) components.

The label printer is affixed with duct tape.

They have equipment from 1938. It's fully depreciated :-)

</comment><comment><USER3> Web version/framing of this: [http://www.bloomberg.com/news/articles/2015-09-01/this- compa...](http://www.bloomberg.com/news/articles/2015-09-01/this-company-is- still-making-audio-cassettes-and-sales-are-better-than-ever)

Rather cool, we do all sorts of interesting things in flyover country, Springfield, MO is 70 miles east of where I was born, raised, and have retired to.

</comment><comment><USER4> I bought a bunch of cassette tapes earlier this year from Tapeline (tapeline.info). Based in Stockport, Cheshire, UK. Bought both custom-length blank cassettes (for replacing broken ZX Spectrum game cassette tapes), and cassette boxes (single and jewel case).

<comment><USER5> The police still use them a lot: [http://www.bbc.co.uk/news/magazine-20556330](http://www.bbc.co.uk/news/magazine-20556330)

</comment></comment><comment><USER6> Did they intentionally add tape hiss to the video???

</comment><comment><USER7> video removed</comment>


A brief history of lost civilizations - <AUTHOR> http://floobynooby.blogspot.com/2011/03/10-civilizations-that-mysteriously.html

<comment><USER2> If you enjoyed this article, you might want to look into the work of Joseph Tainter (<http://en.wikipedia.org/wiki/Joseph_Tainter>) and read his book, The Collapse of Complex Societies, [http://www.amazon.com/Collapse-Complex- Societies-Studies-Arc...](http://www.amazon.com/Collapse-Complex-Societies- Studies-Archaeology/dp/052138673X).</comment>


How does a fly turn upside down to land on a ceiling? (with video) - <AUTHOR> http://www.bbc.co.uk/bang/ask_yan/fly_upside_down_ceiling_land

<comment><USER2> Video is "Not available in your area". :-(

<comment><AUTHOR> Bother. And I searched for _ages_ to find that video. Now I have to go looking again - not sure there is any readily accessible video of this. It's on the BBC, isn't it.

Short sighted of them. Sorry I didn't think of that, and thanks for pointing it out.

Apologies to all.</comment></comment>


UK Mobile Network O2 Is Down - <AUTHOR> https://status.o2.co.uk/ <comment><AUTHOR> Interesting because:

We're aware that our customers are unable to use data this morning. One of our third party suppliers has identified a global software issue in their system which has impacted us. We believe other mobile operators around the world are also affected. Our technical teams are working with their teams to ensure this is fixed as quickly as possible. We'd encourage our customers to use Wifi wherever they can and we apologise for the inconvenience caused.</comment>


Cambridge Analytica Files 'I created Steve Bannon's psychological warfare tool' - <AUTHOR> https://www.theguardian.com/news/2018/mar/17/data-war-whistleblower-christopher-wylie-faceook-nix-bannon-trump?CMP=fb_gu <comment><USER2> Active discussion on different Guardian article about same topic:

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

</comment><comment><USER3> What's fascinating to me about The Cambridge Analytica Files is the reaction from within Facebook. They seem to be panicking. I've never noticed Facebook reacting so defensively before, regardless of what they were accused of.

The writer even claims that Facebook threatened to sue the Guardian before publication: [https://twitter.com/carolecadwalla/status/974995682124804099](https://twitter.com/carolecadwalla/status/974995682124804099)

Really makes me wonder if there were any other big stories that got redacted pre-publication because Facebook threatened to sue the publisher.

<comment><USER4> Maybe Mr. Mueller should open the investigation on Facebook role in the 2016 elections instead of looking into Russian trolls actions.

<comment><USER5> It seems worthwhile to keep the investigation into Russian activity open, since it has turned up a lot of interesting things already. There are many other capable prosecutors besides mr Mueller who could look into the role of Facebook during the elections. The justice system is concurrent; it can investigate more than one thing at a time :)

</comment></comment></comment><comment><USER6> Why do we keep getting these breathless articles about how secret geniuses used social media to "hack" elections? Do we really need a mass conspiracy to explain why large chunks of the population find populist/nationalistic leaders appealing? Motivating voters with this kind of rhetoric predates the internet, in fact it predates the United States.

As mentioned in the comments on the other hacker news post about facebook profiles being scraped by Cambridge Analytica:

1\. Obama's 2008 election absolutely bragged about their use of social media to win. I vividly remember multiple long articles in the NYTimes talking about how they exploited new tech to reach voters.

2\. During the 2016 election Clinton raised and spent nearly double trump. On top of that most of the money Trump got was towards the end of the election whereas Clinton had huge coffers from day one.

3\. I read the guardian article linked and this is one of the few parts that seem to mention what exactly this "hacker" strategy was at Cambridge Analytica

>"And then I came across a paper about how personality traits could be a precursor to political behaviour, and it suddenly made sense. Liberalism is correlated with high openness and low conscientiousness, and when you think of Lib Dems they're absent-minded professors and hippies. They're the early adopters… they're highly open to new ideas. And it just clicked all of a sudden."

This is the insight that that apparently is being called a "psychological warfare tool?" You're telling me that Clinton's campaign didn't have sociologists and psychologists who were absolutely obsessed with exactly the same advertising criteria? This kind of psychological profiling is the kind of stuff you learn about in 101 classes at university. For the past 80 years (that I as a lay person know of, probably longer) people have spent their entire careers analyzing and applying propaganda and marketing to political campaigns. Why should anyone believe based on what's being presented in this article that not only was none of this stuff done before but that it somehow handed Trump one of the greatest election upsets in American history? The mental gymnastics people are going through to deny the fact that yes, many voters have conservative values, is getting out of hand.

<comment><USER7> Sure, the Obama and Clinton campaigns used social media and astroturfing. And they developed and targeted their stuff based on psychological profiling. However, as I understand it, their stuff was targeted only in traditional ways. Based on lists from various sources. Some of those lists were based on website signups, and even posting history and so on. But they generally weren't very granular.

Basically, Cambridge Analytica took the behaviorally targeted ad approach that's taken over the Internet, and applied it to political campaigns. So they're doing psychological profiling at the individual level. They targeted likely Clinton and Sanders voters with messages that discouraged voting. They targeted likely Trump voters with messages that bolstered support and encouraged voting. Messages in ads. In Facebook and Twitter posts by agents and bots. Telephone calls. Physical visits by canvassers, who carried phones with apps that provided real time access to individual user profiles.

That _was_ new tech!

But of course, now everyone will be using it. If they can afford it, anyway. And what does that portend for democracy? Nothing good, I'd argue.

<comment><USER8> LOL, we do know from Podesta emails, that Clinton campaign colluded with Google, Facebook, Twitter _directly_. Clinton got help from _inside_ of these companies. Don't tell us your nonsense.

<comment><USER9> Your use of the word "collusion" and list of sites appears intended to imply that the Clinton campaign was as criminal, or more criminal, than the Trump campaign which itself is accused of "collusion" with Russia. You even use italics to emphasize how much _worse_ the implied dirty connections must be between the Clintons and these companies.

What laws, specifically, do you believe the Clinton campaign broke with their "collusion" and in what way was the Clinton campaign's social media strategy intended to deceive?

And for bonus points, why does this only, specifically, implicate Clinton, the Democrats and the left in wrongdoing, but not Trump, the Republicans or the right?

</comment></comment></comment></comment><comment><USER10> I was wondering how Breitbart and Trump did so well. It makes sense now that it was not luck, but they had access to new "tech" in away. Fake news for them is kinda like how Obama was the first to used Twitter and other SM platforms to get connect with voters and get elected.

Reminds me of the quote ~ "it's artificial intelligence until you understand how it works. Then it's just algorithms"

<comment><USER11> You think the DNC didn't have something similar given how close Facebook and Google's leadership were with the Clinton campaign?

</comment></comment><comment><USER12> I may be wrong but I'm not sure I get why they put so much emphasis on the getting of the data from Facebook, as I feel that that's really easy.

Can't you just 1. crawl public profiles 2. create convincing fake profiles by mixing around the info in real profiles, and then add people, and progressively crawl private profiles that way? 3. pay app owners to require more permissions and sell you the info, or create your own apps

I guess it's such a big deal because they managed to do it in a way that was legal, on first glance

<comment><USER13> "may be wrong but I'm not sure I get why they put so much emphasis on the getting of the data from Facebook, as I feel that that's really easy."

That's exactly the point.

</comment></comment><comment><USER14> This kind of work combining propaganda and disinformation with AI models and feedback into them to get a progressive change of belief is fascinating. I think of this as the first of many wars democracy will fight against AI and we are currently loosing.

<comment><USER15> Populists have been doing similar things for ages and most of the population goes with it

<comment><USER16> We just have to figure out a democracy without letting the peasants decide things on their own.

<comment><USER15> That's the great irony of it

Or you can let them vote to ban Dihydrogen monoxide and see them shoot themselves in the foot

</comment></comment></comment></comment><comment><USER7> Christopher Wylie is being utterly courageous. But even so, I'm reminded of Robert Oppenheimer. We still have nukes. And we'll still have targeted PSYOP. So it goes.

<comment><USER17> He is just being Canadian. It would be very impolite not to apologise, having just screwed up your neighbour's entire political landscape.

</comment></comment><comment><USER18> What I don't understand about this company is how it supposedly uses facebook data that facebook itself doesn't use for its ad platform. They seem to want to point out that they are smarter than facebook, and therefore are a better choice to do targeted ad publishing through. Why are they so relatively unknown and underused then? Any company could use this data to do better business, and it would be trivial for facebook to compile it. That it would have caused the election to swing seems a little far fetched. If anything, it would have provided the campaign with more than ever information about what the American people really want, and how much they want it. That there is lots of talk and no action is the fault of the campaigning party, not of the system used to figure out what their fellow citizens really care about. Republican president follows a Democratic double term, news at 11?

<comment><USER19> I think Facebook would be missing the correlations of likes to the Big Five personality traits. But they could rebuild it if they wanted to, by promoting a free personality test on their site. (I assume that correlations between personality traits and political learnings has been researched before and there's various bits of data available?) Then you can go from targeting ads at likes to targeting ads at political views.

</comment></comment><comment><USER20> If this really works and you can't do this legally it will be done by governments covertly.

I find it difficult to believe it had a real impact though. I think they are just enjoying notoriety.

<comment><USER17> I think RAND have been doing this for quite a while.</comment></comment>