skysight-inc/HackerNews huggingface dataset:
You're using "progress" as a judgement of something that's "better" or "improved" ... like "technological progress".

A "language progress" is a movement in usage and meaning. We "progressed" from "thy" "thee" to "your" "you" etc. It doesn't mean the words starting with "y" are "better" or "clearer" (in fact, they are the opposite of the previous formal/informal distinctions.) Nevertheless, language/culture has moved on.
> Typically installing Linux from scratch has involved less fiddling with drivers than installing windows from scratch on an empty laptop for a while now.

Windows 8 has worked out of the box on every configuration I've tried, with the caveat that it installs non up to date drivers (e.g. High end graphics cards). My experience with Linux (Ubuntu 15.04) is that the little use peripherals I have don't work at all ( I've a Bluetooth usb adapter and a usb capture card that both are plug and play on windows vista onwards but I've yet to find working drivers on Linux for).
Is "technical debt" not just "things you haven't done yet"? Or code for "hey client, you'll have to pay us for x more months"?
> I take serious issue with the "lesson" that this article is trying to teach at the end, which is that you should not generalize your particular problem into something abstract...

The problem, simply stated by Emil Persson is "Premature optimizations can be troublesome to revert, but premature generalizations are often near impossible."

Or, less delicately phrased by Chris Eric -- "Premature optimization, that's like a fart. Premature abstraction is like taking a dump on another developer's desk."

The root problem is -- you think you know all the possible use cases, you don't. You think you can see the future, you can't. Solve for what is in front of you -- abstract it when you need to for reuse.

As for Alan Kay and his fight against complexity (which is fair and nobel fight, great video on it: https://vimeo.com/82301919) -- he is arguing for the RIGHT abstractions from the perspective of DSLs ... with all the good (and very, very bad) that entails. That said, it is 7 levels of bullshit when you get down to "deploy to metal". Sure, it is a few hundred lines of code for a DSL and OMeta to render geometry -- but skip to 1:40:00 for the real scoop. It was incredibly hard to get to run with any level of performance on ACTUAL hardware in the REAL world. Alan Kay even puts forth that you should always keep the option of "rolling your own hardware", which sadly speaks to a disconnect with ACTUAL software development (and hardware development for that matter). There is no doubt he is a legend of CS (and brilliant), but I simply think his perspective is too far away from reality.

"Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs." -- Mike Acton (https://youtu.be/rX0ItVEVjHc)
Cached version: http://webcache.googleusercontent.com/search?q=cache:http://...

I'd actually argue a different point from the author. If you're a beginner at Linux, and want to learn more I would highly recommend Arch to you. Arch was the first *nix system I ever installed by hand (OS X doesn't count), and even as a developer, I learned more spending 3 weeks installing the OS than I'd ever known about linux previously.

I'm a big supporter of the mentality that you should know the stack you're working on (regardless of OS), and I've found it's too easy nowadays to ignore all the important frameworks and libraries that the tools you're using are built on. Arch forces you to understand them, because you can't just "guess" your way through. The thing I loved about installing it most was that on my 3rd and 4th attempt I realized how fun it was to just break stuff to figure out how it works. I'd never had the chance to do that to an OS. You learn how to diagnose errors, how to discover them, what to Google, and why it happened in the first place.

Understandably, most people might not be in the job situation where they need to do something as time consuming as install Arch as a dev environment, but I think that if you want to learn about operating systems, in a structured and incredibly well documented environment, Arch is unparalleled.
Proven? http://www.washingtontimes.com/news/2014/sep/25/golden-hamme...

Chatanooga's system cost 5-8k per subscriber household for fiber and smart grid. It has resulted in little to none of the projected economic growth. And the revenue stream in no way makes up for the capital investment. The market values the NPV of a Comcast customer at only $2,500, and cable customers pay quite a bit more than $70 per month.
>A number of lesswrong articles, typically addressing the nature of categories and how to reason based on them, also move into this territory and browsing lesswrong is probably worthwhile if you are interested.

To summarize, for those who don't want to archive-dive LW:

Analytic philosophy has traditionally held that concepts/categories are logical: defined by a conjunction or disjunction of predicates in a formal language. Or at least, it holds that they ought to be once we stop being silly and think clearly.

Most everything we've ever learned in machine-learning and cognitive science instead tell us that concepts/categories are statistical, and that formal logic is therefore not only a brittle framework for real-world reasoning but thoroughly incapable of describing where its own constituent objects come from in the mind.
I don't think raw jQuery is often used to build full dynamic frontends and SPAs. It's typically used to bolt on effects, transitions and asynchronous data fetching into otherwise statically generated server-side web pages.

Although SPAs, frontend frameworks and the model of communicating microservices is gaining lots of traction and visibility for web applications (particularly paid services that replace former desktop apps), plain old server-side CRUD that renders template variables from a data model is still going to be the dominant paradigm on the web at large, not to mention more of a conceptual neat fit to begin with.

In some ways I predict there will be a sort of resurgence in server-side CRUD frameworks again as being the hot trend you read about on HN, once people found out that you can easily build real-time, reactive UIs without having to context switch and directly deal with the often subpar client-side interfaces. Furthermore, the act of generating HTML and JavaScript from native language constructs will be lauded as a great time-saver, not to mention giving the same benefits of the so-called "isomorphism" that platforms like Node are hailed for. For examples of these concepts, see the Nitrogen and N2O frameworks (both Erlang).
Interestingly, the fact that the intersection feels confusing forces people to pay close attention to figure out what's going on. That can lead to fewer accidents in some cases.

I can't currently find it, but I once read about a roundabout that had accident problems, but had very good signage. People felt entirely in control going into it and weren't paying as much attention as they could be. By removing the signage people wouldn't inadvertently take for granted the behavior of the other drivers, they'd slow down more, they'd pay closer attention, and as a result the accident rate dropped.
tablets are vastly easier and more intuitive for small children

They sure are, and I don't really think there is a minimum age at which newborns and beyond should be allowed access to them. Yet it is of utter importance they also get access to actual non-flat toys/tools/... in order to develop dexterity, the feeling to handle objects and even creativity. Also not to forget about getting enough movement/excercise and not getting used to a sedentary lifestyle: most tablet apps unfortunately don't require the user to move around, on the contrary.
This works if you live in an area conducive to it. If you don't, like me, and almost always have to travel out of town for interviews it becomes much more difficult.
If you feel entitled to your business, and someone starts taking it away, that will feel like robbing, yes.

But it is pathetic for a serious businessperson to feel entitled to their future business success. That's the kind of pride that comes before a fall.
I don't think an n=1 test would be useful. Depending on people's preconceived biases, they would just say "see this confirms what I thought!" or "lol n=1 is meaningless". To do something conclusive, you'd need to do a real trial with n>>1. That costs way more money than Business Insider (or most other venues) is going to spend on an article.
This is excellent advice specifically because it's not about "prepping for interviews"; honing these skills simply makes you more valuable to any company, and it's an aspect of your capabilities that you can show off in a decent interview process... so take advantage of that.
Really great great feedback. So i will start with the obvious and remove the so loved mushroom. And do some cleaning on my tags.
As for growth strategy more high profile people or just one high profile professional that has a dedicated audience will help.
Thank you for mentioning this. It's frustrating that every time someone complains about Go's error-handling style, the first assumption is that the complainer then necessarily has to prefer exceptions. In truth, errors-as-values are very elegant in languages like Haskell IMO. And errors-as-values are not at all something that Go has managed to put back on the roadmap in a modern language against the grain of everyone else (the "exception people") as many seem to imply, including Rob Pike in his "errors as values" article.
The pattern is generally that Clang and GCC will have partial support when the standard is release, and full support a couple of years later. Intel will lag behind a year or two after that. Microsoft will be behind another year or two.

So, let's say that C++17 does come out in 2017. It will probably be the case that some of the features will be ready to use in GCC and Clang right away, and around 2019 or so they should have full or nearly full support. 2021 for Intel. 2023 for Microsoft.

So that gives you a range of answers. Depending on which features and which compiler, you could start using some of them immediately (or even before 2017, many of the features are implemented experimentally in advance), but if you want full support across the range of commonly used compilers, you're probably going to be waiting until the early to mid 2020s.
http://abstrusegoose.com/249
> [0] This is the best-kept secret of both Docker and systemd. I recently conducted a workshop on "Docker Without Docker" - in other words, how to run Docker containers without even having the Docker runtime installed (using pure systemd).

Could you expand on this? I'm curious as to what you mean/how you did this.
Ask HN: I am about to be fired. What should I do?
I am currently a data scientist for a major firm, and I am facing a manager who wishes to fire me.

He assigned me to follow the instructions of an "expert" in completing a compliance document (a task in which I am not trained), and the "expert" turned out to be producing documents that are not in compliance with Federal law. The "expert" repeatedly stated in writing that I was doing an "excellent" job, and I am concerned I am facing retaliation for reporting that her work was simply not correct.

When I raised that issue, he immediately began the process of putting me on a 30 day review, a necessary step prior to termination. Such programs are ostensibly to give an employee an opportunity to improve performance.

When I asked whether this was a true opportunity to improve performance, or simply a formality, he hesitated for a great deal of time before making statements that strongly implied, without directly stating, that it was a mere formality.

I have no desire to lose my job, but I am most concerned that being fired would place future job prospects in jeopardy.

According to my colleagues, I'm very competent at my position, but this supervisor has been angry with me since I pointed out to him a few months ago that he may have violated firm policy in a severe way.

What should I do? I would like to remain with the firm and be transferred to another project, but the steps he will take will prevent that.

I do not wish to move, and if fired I will be effectively blackballed from most firms in this city. I have a life, friends, a girlfriend I love very much, and don't wish to leave that behind.

HNers, whether or not you know it, you've been a big part of my life since this site's founding. I value your input and advice tremendously.

What do I do? Do I simply begin looking for other positions? Do I report his increasingly erratic behavior, and waste of firm resources? Do I quit before the period expires?

What are your thoughts?
One of the fortunate things about driving an older car is mechanical accelerator and mechanical steering.

I fear for when I have to upgrade someday to all drive by wire.

As coders we all know how bad some code can be or even how the best code has flaws.
While that was entertaining and accurate at a high level, John Oliver repeats the same mistakes other media outlets make regarding the finer points of this issue:

1. He references the roundly debunked "Patent Trolls cost X trillion dollars" study and accepts it as fact.

2. He calls ED Texas "plaintiff friendly", which it hasn't been for a while (http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1597919) - these days it's popular because of other factors.

3. He shows a video clip of that M-CAM guy, who's famous for claiming there's a "patent on toast" (there's no such thing) in that NPR episode on patent trolls. Which, BTW, had journalism worse than this clip. M-CAM is a laughingstock of the IP licensing world as they appear to have no idea how patents really work.

4. The whole "trial lawyers killed patent reform" thing is a red herring if you just stop a second to think about it. As Oliver himself says a few minutes earlier, the whole patent troll business model is avoiding trials by settling for less than the cost of a lawsuit. In fact 97% of patent lawsuits, patent troll or otherwise, settle without trial. Statistically, trial lawyers have very little skin in the game. I don't know what really killed this patent reform bill (my guess is the pharma lobby), but I'm really curious why people decided to blame the trial lawyers.
Indian Ministry of External Affairs has opened a 24-hour control room to coordinate rescue operations in Nepal.

https://twitter.com/meacontrolroom

https://twitter.com/MEAIndia
Sure. These are the slides for my talk, which includes some of the code examples that we walked through: https://chimeracoder.github.io/docker-without-docker/#1

Consider Git. Git exists solely on the filesystem. If you want, you can read git repos by inflating the ZLIB-compressed objects yourself, and create git repos by compressing objects, hashing them, and storing them in right locations the exact same way that Git does.

It's a lot of work, and the Git toolchain exists so you don't have to type insanely long bash one-liners just to read your commit history. But it's kind of cool to know that >95% of Git is really just 'syntactic sugar' around functionality that's also provided by other command-line tools[0].

I'll wave my hands a bit, but in short: containerization uses features implemented at the kernel level, and in fact, until recently, Docker and systemd both built on top of LXC (Docker has switched created their own libcontainer).

If you take a running Docker container and dump it, you'll get a root filesystem. You could chroot(8) inside this root filesystem, but as we know, containerization is more powerful than chroot. Once you've dumped the container, systemd doesn't need to know that it was once a Docker container - it'll just look for whatever binary is located at /sbin/init and run that (or run whatever command you tell it to run instead. Just like your actual OS - which is not a coincidence!).

One advantage to using systemd instead of the Docker daemon/runtime is that systemd is capable of running itself inside a container, whereas running init systems inside Docker containers is tricky and not recommended[1]. Futhermore, systemd is smart enough to know when it's running inside a container and when it's not, so the container init system plays nicely with the host init system - things like integrated system logs and networking.

Newer versions of systemd actually allow you to pull Docker images from the Docker hub directly, so you can even use systemd to replace `docker pull` as well as `docker run`.

[0] There's a tiny, tiny portion of Git which is home-grown, but most of the features it builds on (SHA, zlib, diff) are easily replaced by other command-line tools.

[1] While it's supported, the primary use case of Docker is for running application processes: https://github.com/docker/docker/issues/2170
It helps having this article next to (nearby) the HN article discussing the 80K static coding violations in Toyota throttle position sensing code, or whatever it was exactly.

THIS article didn't get into it very much, but "obviously" you'll have four times the bugs in a highly abstracted 40 part piece of code, than in a much simpler, less capable 10 part piece of code.

Reality is bug count never scales at a rate as low as linear with code length of course.

At any rate the two HN articles are both better if read at the same time.
http://www.tomelders.com/projects/curby lol
I'd think best use of effort would be getting this to support (and trivialize) writing PHP for Android apps. "Best use" meaning what would entice people to use it.

"Faster applications" won't entice most PHP devs to switch entire stacks/tools and deployment process to shave off a bit of execution time. PHP7 will offer a roughly 100% improvement already in a few months time - the "JVM will be faster" argument just doesn't hold enough weight on its own in 2016.
freshdesk.com
Sorry for the downtime, it's fixed now.

Maybe some advanced users could start with Arch, but most of the people I know, will find it too difficult and give up on it. Yes, it's a great way to learn how stuff works, but it's just not for everyone. And in my opinion, beginners should start with something different. I'd never recommend my mom to try Arch for example.
From what I've seen, if you can get 20dB of isolation mechanically between the speaker and mic, you'll be good. The AEC can generally take care of the rest.
Another study undermined by the fallacy of controlling for an intermediate variable.

Fulltext: https://www.dropbox.com/s/zn87fm4mmzkicjs/2014-mcclintock.pd... / http://sci-hub.bz/3e46d909c73b1bf06a440eb0515c8c7b/mcclintoc... "Beauty and Status: The Illusion of Exchange in Partner Selection?", McClintock 2014

Table 3, pg 14: all the correlations are positive, but that also includes the female attractiveness / male SES bivariate correlations, exactly as common wisdom has it - beautiful women do tend to marry rich men.

(Arguments about matching vs exchange are causal arguments, and 'controlling' is implicitly making some very strong and implausible assumptions.)
Ask HN: Students, Scientists, and Engineers: Need to Speed Up Your Programs?
I am an M.S. Computational Science and Engineering student who has experience in CUDA programming for general purpose graphics processing units (GPGPUs). If you haven't heard of this, it is a utilization of your graphics card to tremendously speed up scientific and engineering simulation programs by orders of magnitude (factors of 10x to 1000x). I am looking for students/scientists/engineers who use time-consuming programs and want to speed them up (for free, I am not looking for customers or anything). Contact me if you are interested and we can talk about whether your application would benefit from being ported to the GPU. Thanks for your time!
Impressive
http://freshdesk.com/
Yeah, this is what I liked about it too. I like the idea of common English evolving on time scales at which it may legitimately become mutually incomprehensible over the course of my lifetime.

Language isn't static, and I love the idea of more versatile forms with fewer rules providing new generally accepted grammars for creative writing. I also like how this change in English seems to be fascinatingly in the direction of several Asian languages where sections are dropped if they are considered obvious enough. Although English has its own charms in having so much more flexibility in word ordering, it's not as succinct in allowing for dropped sections.

I'm afraid that people who get pissed off about the singular "they" or other such conventions are going to very rapidly be incapable of communicating with younger people at all. That's fascinating to think about.
Not to mention, at least as a musician you may create some beautiful things, even though people may not appreciate them. With a startup, you may not do anything of the sort. It only makes sense if it makes you a lot of money, and that's not likely for most founders.
I agree with the example of the macro usage of thy->thee->you/your as being an instance of progression, but I don't see the current trends in internet slang as a parallel example of something that will have such a long lasting effect on our language as a whole, but instead, well, just what I said, I see it as a trend that will eventually be a ghost. This is a prediction, of course.
8 Things to Do After Installing Ubuntu 15.04﻿ Vivd Vervet
There is no progress. English is not better than it used to be. It was not wrong in Shakespeare's day and it's not wrong now. We have new words for new things. Adaptation is not progress.
I am assuming that SOC won't change under the influence of massively more available quantitative data, or at least any gains would be both slight and only applicable to a very small number of people. I think it is probably a misconception that humans are simple enough that measuring something (on Theranos' current testing panel) which is produced in ten different ways in five different organs from millions of cells and then diluted in 7 litres of blood is going to tell you anything revolutionary.

Certainly happy to be proven wrong, but there is a risk of harming people (financially, psychologically and perhaps medically) if you convince them that relentless tracking of their serum sodium tells them something useful.
Agreed, a n=1 test wouldn't reveal the most insidious kind of failure: guessing to cover up crummy data (err, I mean "leveraging machine learning techniques to maximize accuracy"). I doubt they're that evil, but it would be nice to know for sure.

> I'm assuming they've done this study, but have refused to publish it for some reason.

Because they're a bog-standard vertical integration play and if that fact comes to light before they are done using the hype train to raise money and grab market share then their competitive advantage will evaporate overnight. If they only release test results to interested parties under NDA it prevents public sector science from rebutting their claims to disruptive rather than incremental innovation, allowing the hype train to steam ahead unimpeded.
Some of it is; others are obscure references that must be explained along with the historical context. Still others are likely lost forever.
Good points. The target market is specific to people who work on cars, whether it's their own or professionally. This assumes a certain level of knowledge about the subject and possibly a realization about how the product would help them. We could certainly do a better job of explaining the user benefits to a more general market.
My understanding about patent cases in Germany, though, is that they are almost wholly decided by technical judges. This removes the costs and uncertainty of having a lay jury making decisions about things they cannot hope to understand.