skysight-inc/HackerNews huggingface dataset:
My point is, the clients are generally pretty bad despite the IETF spec. Lots of edge cases ignored, poor security practices. I understand the intention but the effect is that the clients are just as opaque as the spec but often more incorrect. Who would try to launch a startup API for wide use without a Stripe-style spec these days?

Thanks for the advice, but it's not that I don't understand how to read it, it's that I can tell other devs don't understand it despite the good intentions of the authors.

Plenty of good clients are written for plenty of other tools, based on a much more straightforward call-and-response API spec. For example, the Hashicorp tools have a simple spec and proper clients in many languages.
You aren't going to get away from systemd with a Debian or Ubuntu system. Both Debian 8 and Ubuntu 15.04 (and beyond) use systemd. There are very few mainstream Linux distributions that haven't adopted it, Slackware being the notable exception.
Run your test suite, look at the code coverage report, find out which bits of your code doesn't get exercised by the test suite, become aware that changes in those bits of your code probably won't trigger any failing tests if they introduce breakage.
All very good reasons why we should be throwing more police officers as well as the executives and owners of Harris in jail for using these things. It's impossible to manufacture or operate a stingray without breaking the law.
This deserves it's own HN thread.
> A hike in the cost of labour was the reason why the industrial revolution happened in Britain vs India

There was also the forced de-industrialization of one of those nations by the other one.
Bahaha yes.

"White echoed the concerns of some industry insiders that these tech start-ups are missing out on the market discipline public companies receive by being accountable to the whims of public shareholder."

Really? Being accountable to whims is a good thing?!!
Where is the arbitrage?
> I don't see that changing unfortunately.

So from seeing it firsthand, would you agree that in 100 years from now, we will all be under Shiaa law and wave black/white flags or ISIS or other group will eventually form/merge?

If our political system forbids us from going eye for eye (disclaimer: Im not for it), then is there really any way to win without it costing US taxpayers large chunk of their money?
You're very wrong. The bus has its own lane around the toll plaza. The actual time on the bridge is 10 mins. I make it from Berkeley to SF in 35 mins once the bus picks me up. I can walk to the Bart station but always take the bus. It's a much cleaner and nicer experience. Wait. I mean, the bus is awful. Definitely nobody start taking the g or fs. Thanks.
> Even better, to the extent that we are able to produce everything we need with less labor, we can afford to let people work less.

I'm doubtful. From what I've seen it just means that those who do have full time jobs are expected to work more. Why employ two people for 20 hours a week when you can have one person for 40hrs a week? For most industries the managerial and administrative overheads are less with fewer staff who work longer hours.

> but has not really succeeded in shedding much light on where innovation comes from or what policies support it.

Deirdre N. McCloskey might have something to say about that in her tomb 'Bourgeois Dignity: Why Economics Can't Explain the Modern World'[1][2]. tl;dr her argument is that the ability to bring innovation to market, profit, and be dignified in doing so is the factor that brought about the modern world.

And besides, we only have to look at other developed nations with liveable minimum wages to see that it hasn't caused an automation revolution. Where I live, Australia, has an adult minimum full-time wage of $17.29[3] and has an unemployment rate of 5.8%[4] (for some definitions of 'unemployed').

A liveable minimum wage isn't going to cause an automation revolution. The Automation Revolution is going to be what causes the automation revolution, and for that to happen we're going to need cheap general purpose robots trickling in to the second hand market.

When a business can buy a general purpose robot for less than 5x the annual salary of a full-time employee, and it can learn new skills as easily as a human, we'll be close. It's looking like that's a way off yet.

1. http://www.deirdremccloskey.com/
2. https://en.wikipedia.org/wiki/Deirdre_McCloskey
3. https://www.fairwork.gov.au/how-we-will-help/templates-and-g...
4. http://www.abs.gov.au/ausstats/abs%40.nsf/mf/6202.0
Great point regarding providing motivation for people to sell their wares on Amazon. I did not think about that.

This especially makes sense to me because the majority of Amazon's sales are filled by third-party merchants, including nearly 100% of their sales when they launch new product categories.
I'm on Debian and not familiar with Java. I did that:

aptitude install openjdk-8-jdk
I see your point. Much of this vulnerability is psychological, though. If you look at how many people have died from terrorism in the past, it's not many, at least compared to things like cancer, heart disease or traffic accidents. Still, I remember how most Americans were more than happy to give up their freedoms and human rights after September 11, in order to fight terrorism. Never mind that those freedoms and human rights were probably much of the reason why the US became great (compare it to say Argentina or Russia). Ironically, I think in order to preserve freedom during periods of terrorism, we would have to do away with democracy, since most voters are such morons.
never heard about faraday cages?
I've never heard a good argument to justify having a minimum wage. A lot of the people who argue for minimum wages commit the fallacy of the false dichotomy: they think that the choice is between everyone having jobs and getting paid what they're paid now, and everyone having jobs and getting paid more -- they think they can somehow legislate the latter outcome.

In reality, what tends to happen when you increase minimum wage is that businesses lay off workers. They only have so many dollars to spend on wages at current profitability levels. Seattle's minimum wage for example has caused a massive loss of jobs compared to the rest of the state: https://www.aei.org/publication/minimum-wage-effect-from-jan...

Minimum wage directly causes unemployment by making it illegal to employ people at their fair market wage. [Edit: I'd be glad to read an argument for minimum wage if someone would like to link one. The articles that I see in the news tend to engage in moralizing and lack real explanation and justification.]
> these tech start-ups are missing out on the market discipline public companies receive by being accountable to the whims of public shareholder

Wow, you mean the type of accountability faced by GM, Ford, Exxon Mobile . . .

how can this man say that with a straight face ?
What do you listen to? Do you choose specific songs to match your target cadence?
> Apple's non-unix line endings (CR) changed to LF...

That was because with OS X, they switched from a Mac OS subsystem to a Unix subsystem
He said static stretching is bad, and it absolutely is. Athletes do dynamic stretching.
But in the situation that a new version of the software is released, and I think it would benefit me right now, I'd trade all those downsides for being able to use that software right now than waiting to be included in my distro (like it happened to me with Gimp some years ago).

I don't understand what static linking vs. dynamic linking has to do with waiting for gimp to be included in your distro?

I'm plenty of memory, storage and bandwidth but not so much of time to compile it by hand.

No one is suggesting you have to do that, but someone will have to do that, and it does require resources (time, people, hardware, etc.).

I have to admit that this is just a workaround while we find a better software release and dependency management system.

If by system, you're referring to technology, then I disagree.

In other words, the technological constraints of today's package management systems are not the primary issue, rather it is how the software itself is being developed and managed and the available resources to do so.

Ultimately though, most of this all comes about because the underlying systems that applications depend upon in a typical Linux distribution are not properly release engineered. They don't properly version the shared libraries, they don't carefully avoid incompatible changes in interfaces, and they don't have sufficient regression testing.

So to me, the right answer is to fix the root of the problem, not paper over it by pretending there isn't one by essentially embedding copies of every dependency into an application.

In short, start encouraging developers to reduce their dependency chains, properly release manage their software, ensure that core system components offer stable interfaces, and provide timely updates.
They also promote stress fractures.
I'm not saying anything about this example, but why would you expect a refurbished unit, sold at a lower price than a new device to meet the same specs as that new device?

Surely, something must be different about it?
For #2 - where to look to troubleshoot those issues?
I'm not sure what's wrong with this. In the article the only issue I could find was that when companies are subject to the whims of public investors they get "market discipline" whatever that means.

If they are profitable (most aren't) I don't see why that discipline is necessary.
My formula:

bestcase * 1.3 + (worstcase - bestcase) * 0.5
Sometimes there's a disconnect between what you think you're testing and what you're actually testing.

After writing a unit test, I like to look at the code coverage analysis for that unit test and see if it actually tests the code that I think it tests. After seeing the analysis, sometimes I realize I'm not testing for a weird corner case that I should be.

It also slightly gamifies unit testing because there's something slightly satisfying in seeing 100% code coverage (though it's important to remember that 100% code coverage doesn't necessarily mean your tests are perfect or test all the conditions you should be).
What, having beta versions?
This was my thought as well. I'm not even sure how to judge this article. It seems very misinformed with making assumptions without any supporting evidence on how we get there.

It's true that automation would bring in new jobs, but not the jobs that the people affected would be able to jump into.

As far as the whole child care and home health jobs go, I'm not sure there would be a mass influx of opportunities there.

I don't know if I've ever personally seen employees at a daycare making much more than minimum wage and there's already a thin margin with daycares. So, I'd think they'd be in same trouble as a restaurant employee.
Uber sues Ola claiming fake bookings
Global access to the entire problem is definitely what we want to avoid. Encapsulation is a useful tool for maintaning invariants, controlling access to data and so forth. We don't want to give it up, and we may not even be able to give it up to begin with.

One way to consider an environment is that it may be a physical machine with a set of bindings, variables and processes on it, where some of the bindings point to other environments - ie, other machines.

Then if you're a user of the tree, and you want to invoke loudly, there exists at least one other machine, dog, between yourself and bark. You obviously don't know what is on the bark machine because the dog mediates your access to it. You don't really have any access to it other than by sending a message to dog which asks it to send a message to bark.

So the number of "loudly" options in such a network (ie, the internet) is potentially unbounded. The dog machine might know, by virtue of asking the machines it is directly connected to, whether the binding loudly exists, and it can chose to expose either the binding, or another message named loudly which discriminates between multiple loudly options if the other machines connected to it (aka, dynamic dispatch).

In the example above, replace "$branch" with "$spawn" and "$walk" with "$send", and you effectively have the actor model, which is more like the OOP imagined by Kay and others. The fun part here would be to implement $spawn and $send though.
The "good argument" for having a minimum wage is that without it, wages will be pressured down, because every business on the planet wants wages as low as possible, and they generally have the means to achieve this. It has nothing to do with job creation: it's about having jobs that are not basically slavery. It's for job quality, not quantity.

Besides, you're just assuming people should be employed at "fair market wage." The political process is part of the market, and the fair market wage is determined by what is politically determined to be fair (AKA, minimum wage) just as much as it is by employers' demands. As a business, you are not entitled to a profit. Especially not at the expense of your employees welfare.
It's amazing how pushing technical boundaries is seen as worthy challenge, but helping the those who are struggling with basic needs is seen as impossible and an irritating overstep by the government.
My first UNIX, a couple of years before GNU/Linux was even a thing.
Made a small JavaScript library for smooth pretty drawing/handwriting on Canvas
> Some low-wage work would be reallocated ... Since poor people are now making more money, there will be opportunities to sell them things — things like restaurant meals! — that they couldn't previously afford, which in turn creates demand for new jobs.

Even if the poor people were making more money, the rest of the logic here is equally as flawed; somehow by firing people and replacing them with machines, those people will spend more money, and that will create the same jobs for which they were replaced by machines. Kind of a new twist on circular logic where each point in the circle is also a logical fallacy.
Show HN: Hex.vim – nifty functions for your hex deps
Code coverage is simple a measure of the amount of the code touched by your tests.

It doesn't tell you the quality of effectiveness of the tests. Only what code got executed during your tests.
It varies wildly. For a student who's motivated, encouraged by parents and peers, and lives in at least a reasonably middle-class or higher school district, you can come out of most high schools having achieved most or all of the things you listed. If you're poor, live in an impoverished district, are surrounded by family and peers who do not value education, and attend dilapidated schools with few resources, it's much harder. Those are are the schools thats are sensationalized, but they're mostly an artifact of inner city urban areas, and are more a reflection of the overall culture of poverty than a cause of it.
It's not surprising that a conservative think tank released a study against the minimum wage.

There are also arguments and studies concluding that the minimum wage ultimately creates jobs.
"Although I certainly believe that any member of our highly digital society should be familiar with how these platforms work, universal code literacy won’t solve our employment crisis any more than the universal ability to read and write would result in a full-employment economy of book publishing."

I read the article. I have seen similar arguments made by Nicholas Carr in "Peak Code" (http://www.roughtype.com/?p=5594) Perhaps learning to code and universal code literacy (for now, lets not argue exactly what literacy means) may, or may not save individual jobs. I sense as software development as a discipline matures, at the level of the firm, software developer wages as percent of a software project's budget, may shrink. At a macro level, software development as percent of GNP may rise but the software developer employment may look like the numbers involved in manufacturing, or farming. The point I feel Ruskoff misses is that coding literacy may not save an individual's job. Or having a sizable chunk of the U.S economy (or any sophisticated modern economy's) GDP coming from software development. However a critical mass of the population programming, like universal literacy, will most likely translate into vast productivity gains and ability to create new opportunities. An example. The idea behind "software carpentry"http://software-carpentry.org) is about teaching scientists just enough programming, so they can write tools be productive at their main activities, instead of doing things by hand, or hiring programmers. As a whole, research immensely benefits. It is easy to extend these ideas to the populate in general (and yes, I, like chef Gusteau, believe anyone can program). When I come to think about it, maybe this is what the BBC Microbit is about. I feel fields like home automation would explode once a critical mass of the population are code literate. To get back to Ruskoff's analogy, book publishing would be a much smaller industry if universal literacy did not create the supply of writers and demand in the form of readers.
The arbitrage is where you purchase clicks for less money than you gain in commissions. It can be fairly lucrative if executed well.

The problem in the long run is that you're constantly working to find the next thing before the current tactic gets saturated. For example, the ad in the article is no longer possible on Reddit and most sources of cheap clicks to Amazon will get you banned from the program (they have stricter guidelines than you think for traffic sources)

Unless you stay ahead of the pack, your avenues for cash flow will rapidly close most of the time.
Note: You can still put affiliate links in AdWords, and many people do. Google just has a higher bar than it used to.
Oh! And also, if this sort of thing interests you, get your ham radio technician's license. There is no morse code requirement and the test questions and answers come from a publically-available pool. It is straightforward to study for (but do read the theory, don't just memorize test answers).

Once you have that, you can start operating digital modes on local bands at low power. You'll be amazed how far you can stretch 5W of transmitter.
AppFS ( http://appfs.rkeene.org/ ) aims to solve the packaging problem in a way that is very similar to this line of thinking.

Software is just files on disk, rather than statically linking (and this duplicating) to libraries we can use references to the libraries (dynamic linking), the issue is the user has to install the software and its dependencies then.

AppFS solves this by not having an install step. All files in all AppFS packages in all the world show up in the filesystem if you look for them. They are then cached to disk if you try to use them.

So if you had a package X that depended on library Y you simply run the binary you want from X and any libraries from Y will get used.

Since AppFS is a global namespace using HTTP, it has very similar semantics to the WWW, just with symlinks or ELF NEEDED entries instead of hyperlinks.

So you, as a developer can publish software that depends on the software another developer publishes, and the user can fetch the software directly from you without there ever being an install step.
I first saw the mention of 'millicode' when HP introduced then-new PA-RISC 1.0 ISA (second half of eighties), and now Wikipedia says IBM invented the concept and the term in 1997.
The First Exoplanet Detected Using the Special Theory of Relativity
Pay $0.02 per click, send that click to Amazon, earn $0.04 per click. Earn $0.02 per click margin for funneling cheaply acquired traffic to an entity that is willing and able to pay more for that click.
> is there a code review gate that forbids the code coverage figure to go below 80%?

That's one usage pattern.

Here are two others, more focused on individual productivity rather than team standards.

1. Write some code, write a test, run the test. Rather than stepping through the test with a debugger, you enable code coverage and can see the code path instantly. Same idea as a debugger, just faster and less precise. Occasionally a test passes for the wrong reason. Looking at coverage data is a fast way to find out that you didn't quite understand what your test did.

2. Write some code, and write a quickcheck-style test (generate random data, assert that properties hold on the output). Look at the code coverage, and see if the random data is covering all of the code paths. If it is, hurrah, you just built a great test with almost no effort. If the random data isn't triggering some code paths, you can now target your efforts on that unexplored branch.
Further down the page is a mention of Flex, which was designed to address the concerns you mention:

"Windowgrams are a neat way of arranging workspaces. For simpler
layouts, a windowgram can be typed up quickly. But if you need
detail, you may find yourself doing a lot of ASCII art.

In tmuxomatic 2.x, flex was added to automate the construction and
modification of the windowgram itself.

Flex is an object-oriented windowgram editor. It is visually
expressive, naturally worded, logically ordered, minimal, and
powerful. Its short command set may be combined to make any
conceivable windowgram -- likely more quickly and more easily than
crafting by hand. Flex is intended for power users who desire
detailed windowgrams without the tedium of manual entry."

There are some examples further on of how quick and easy it is to use flex for edits.
For me, it was a physical therapist (I've added my story as a sibling comment to yours.) That was the first professional I saw that watched me run and evaluated all parts of my body. The shoe stores and podiatrist only looked to see if I was pronating and at my feet. The chiropractor only looked at my back. The orthopedist only wanted to look at an MRI or bone scan. A massage therapist who works with athletes and/or is/was a runner may also be able to help. But honestly, I'm sold on the value of a good PT.
In regards to that quote, what I've seen is a move in quite the opposite direction since the early days of the "I program in rails. What's ruby?" dev shops.

With so many non-tech people creating businesses, these prospective business owners have been forced to become more tech-literate to get a piece of the pie. Working in the med-tech space, I interact with doctors who actually can understand what I'm talking about when I discuss client vs. server. I even had a surgeon approach me to discuss difficulties associated with "on-prem deployments" (I shit you not, he used those words). What I hear in their networking events is "don't go offshore", and that advice seems to be sticking.

That being said, I honestly don't know if it's industry specific. I realize that the medical industry does have significantly higher regulation, so it might simply be that they want to work with people that have the ability to understand the local regulations (as well as assume some shred of responsibility).