skysight-inc/HackerNews huggingface dataset:
There's a related idea called the "transactional interpretation" of quantum mechanics: http://en.wikipedia.org/wiki/Transactional_interpretation

The idea is that every event (eg. a particle collision) sends waves forwards and backwards in time, eg. if * is an event and </> are waves moving backwards/forwards in time:

<- past future ->
<<<<<<<<<*>>>>>>>>>

The waves from multiple events can overlap and interfere, eg.

<<<<<<<<<<<<*>>>>>
<<<*>>>>>>>>>>>>>>

The interference depends on the phase of the waves, but let's simplify and say that similar arrows are destructive (represented as a space) and opposite arrows are constructive (represented as a dash). In which case, the interference pattern of the example above would be:

*--------*

It looks like there is something which is created at the first event, travels through time to the second event, and is then destroyed. That "thing" is what we'd call a particle. This idea is called "transactional" because it treats the existence of a particle as not just depending on the event which creates it, but also on the event which eventually destroys it, and the interference of these "waves through time" is like a 'negotiation' between the two events.
While the asset URLs are updated to the CDN, here's the GitHub repo: https://github.com/dariocravero/react-live/
On the other hand, one I see a lot is "I don't agree with your decision, so I'm going to keep asking this question over and over again."
That was my immediate thought as well. I can see few scenarios which could justify having the VM's. I'm also very wary about those "super productive" two other guys. One should at least consider that they unwillingly make the quality bad (and thus maintenance harder).

Unfortunately, some really bad technical solutions blow up very late.
First, you don't have to live with Unity if you don't like it - you can choose to start from any of the variants: Kubuntu, Xubuntu, Lubuntu... but you could just use the stripped down ubuntu-server distro, maybe change the default kernel and add a DE/whatever on top of that.

Another option would be oem-config, which lets you customise repositories & packages, and end up with an installed system which can then be remastered (by means of rsyncing or by copying whole partitions) before the final user customisation.

Ubuntu builder was a nice project too, it's a pity it was abandoned. Someone should definitely resurrect it!

Edit: I re-read your comment and understand you're not talking about packages, but rather about actual package contents, paths, init system and the likes. Yes, Ubuntu (and to a lesser degree Debian) has its own ways; it makes no sense to try to undo their customisations - unless you have the power to write your own.
Heh, yeah I've done this since.

I installed base Jessie from netinstall image with no desktop, then manually installed slim and openbox, and started from there.

It's much cleaner this way
You aren't someone's bosd if you don't have authority to fire them.

I've dealt with people like that. You explain something to them 5 times and they still don't get it. Some people just don't have the talent. The previous lead probably didn't notice or care.

Did you speak with your bosses about replacing them?

Even if the team lead is just being narrowminded, those two devs would be better off working with someone else.
So what do you do about the perma-tasks that are on the board forever because no one wants them?
You would still own the battery and you can still do what you like with it.
you don't need to be a junior or an intern to come up with an insanely bad design

That's true, unfortunately - although lack of hands-on experience helps
Free Resources Friday from Devbox
You must also understand that the kind of math classes they make engineering students take is also not what a math major does. The common thing for engineering programs to do is have a special course called something like "linear analysis" that is a rushed computation-heavy mix of linear algebra and calculus/ODEs. It depends on your institution, I'm sure, but I'd be surprised if your experience was a faithful representation of what it would be like to be a math major.
I haven't found ELK to be terribly resource intensive. We're currently loading ~20,000 events / min into an ELK stack that runs on a single m1.xlarge box, we do use redis as a logstash broker to deal with unusually bursty load, but it doesn't seem to have much issue keeping up with normal load.
This assessment strikes me as precisely correct. This article gets dangerously close to click-bait academia, since while it (presumably) does good science, the abstract highlights this sensational-sounding result, that the authors must know will get picked up by the public.

That 1/2 of the DNA is of unknown origin does not mean it is somehow really weird or alien (as the public will imagine), rather, it just means we don't know all that much about extant DNA.
Several. The plane operates as the first stage, basically. Only it's a far safer and more flexible first stage. Planes are well understood and completely reusable. The main limiting factor would be their carrying capacity.

However, the limited carrying capacity of a supersonic aircraft is partially made up for by the reduction in launch weight the rocket would gain by being launched from several miles above sea level.

But more importantly, a plane can take off from anywhere in the world and launch the rocket at any angle. There is an optimal orbital angle that can be taken from fixed ground-launch points, and moving off of that angle or achieving retrograde orbits requires significantly more fuel and thus reduces launch capacity significantly (see the challenges of reconciling the orbital angles achievable from both Cape Canaveral and Baikonour that had to be addressed in order to build the ISS). Plane-assisted launches do not require a fixed ground launch facility and can be launched in far more varied orbits.

Point being, if we can make our satellites small enough, or launch them in self-assembling pieces, then we can achieve far more flexibility in orbital angles by using plane-assisted lauches.
Sad, sad news. It's the only Debian based distro that I've found to be nearly perfect out of the box for my workflow. I had a feeling this was coming for a while (as most #! users probably did), and I've mulled over trying to emulate its interface and approach using another major distro (Slackware) as the base. But the two, Debian and Slackware, are just so different that it's beyond my ability to commit the amount of time needed to do it properly.

Given the impending systemd switch in Debian, I probably would have had to give up using #! going forward anyway. Still, it kills me to see it possibly disappearing one day soon. I hope Corenominal can pass the torch to the community in a way that allows it to live on in some form.
yup - now write that in formal mathy terms and collect your Nobel prize.
I find the idea nice, I currently have a form on my website for people to upload things to me to solve this same problem.

I get that there are less savvy people who would want something like this because they can't code their own thing or don't have anything to run a website which would do this. However, $10 (lets be fair, if people need files under 20mb only, they are just going to use email) seems quite expensive for a simple service like this.

What I mean to say is, this seems like the kind of thing people only would use occasionally, to ask for files from people, right? $10/month seems quite excessive for that. Feel free to prove me wrong though, if you've already thought about that. (I'm just curious because I know that I couldn't justify $10 per month personally).

For the free plan, you state on the website that it has a 20MB file limit, what is the total bandwidth/transfer limit though?

Also, how does it handle malicious files? It shouldn't people to upload potentially malicious files onto the user's cloud, which is basically directly onto their computers.
The same issue exists, on a larger scale, for cars. Manufacturers have a motivation to lock you into dealer maintenance and DRM on the electronics is a great tool for this. We need to be the ones to educate consumers that its good when thing are hackable.
Programming is an interesting thing to manage. It's not like you're managing a warehouse where you can tell the guy "You see that box over there? Pick it up, and take it over to the other side of the warehouse". Or a restaurant where you say "You see that pasta? Put it in the boiling water for X amount of time and when it's done take it out".

My feeling, especially when starting with a new group of people, is the amount of time you should allow them to struggle is inversely proportional to their years of experience.

In the end productivity is important, but not at the expense of creating a hostile work environment. Programmers need to be ok with creating imperfect things. Sometimes it's the only way they'll successfully iterate toward creating less imperfect things.

Another interesting thing about managing programmers is it's difficult to create objective metrics by which to assess performance, which you can then easily compare to other members of the team. In other words, I can't go find the box and say "why is that box still over here? I thought I told you to put it on the other side of the warehouse?". or "Why is that pasta not in the boiling water?" At best I've only ever had a clear "sense" of where each member of the team is. Nothing I can put on a chart that shows definitively that Team Member A is performing at a higher standard than Team Member B. In this case it's critical to give the slower guys the easier tasks, and the more ambitious guys the bigger tasks.

Create a tighter feedback loop for those who you see as having difficulties. And create opportunities for people to collaborate, and in the process compare themselves to others on the team. And every once in a while sit with them while they're working for maybe 15 minutes at a time. Don't expect them to do things your way, but by the end of the session offer a few suggestions. And make sure they set goals for themselves. "How long do you think it will take you to finish that?". Make a note of their goal. And then when the time is up ask them "So have you been able to finish that?" If not, what's wrong, and how can we help you? If so, then good job let's move on to the next thing. And I saw in other posts the suggestion that sometimes you should break down the tasks into smaller more digestible chunks instead of having them do that. Great suggestion.

Finally, it's not an infallible metric (and in fact probably not a good measure for anything performance-related), but lines of code committed is I feel a good "BS detector". I had a guy (arguably senior, and arguably unmotivated) on a team I managed a while back who managed to commit less than 100 lines of code in a month. That's as close to an "obvious sign" that something is wrong as you will probably ever see. Writing code is what programmers are paid to do, so if they're not doing it there's no way to assess their performance.
Read this paper ("Set up to fail: How managers create their own poor performers"):
http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...

The paper's basic tenet is that managers, by over-focusing on "poor performers", actually cause their poor performance by interfering with their work and putting them on performance improvement plans. Are there measurable differences between these people and your high performers in terms of output, or are you simply observing that to be so?

And listen to jonstewart. Being a manager is very different from being a programmer. Be humble and introspective, and work on becoming better at your craft.
Other than it being untrue? Words have definitely hurt me. Words have made me cry. Words have made me yell out in frustration and anger. Words have also made me smile, and laugh, and cheered me up.
you have a shitty development environment.

i bet the 2 fast developers and yourself never cared about unit tests. leaving the people that don't want to write temporary test cases completely lost. they probably sake their head every time they look at the code base, try to start to sanitize it, realize it will take forever now, give up in the middle, and end up just contributing to the mess.
I never really got the popularity of CrunchBang it was basically a Debian minimal with a "sudo apt-get install openbox tint2 conky" post-install script.
I think it's far fetched to believe this is because people supposedly work there more.

It's probably got more to do with automakers chasing software engineers as cars start to become more like computers.

Automakers are definitely looking at Tesla and trying to emulate some things.
If only we could retard the process.
I doubt this will be a surprise to anyone but the latest book by Scott Meyers is truly a pleasure to read and allows you get up to speed with c++11 and c++14.
http://shop.oreilly.com/product/0636920033707.do
But high level languages do not require VMs. Time for a rant.

We were lead down a collective rabbit hole by rabid VM and JIT enthusiasts. Notice the absence of those extolling the benefits of JIT compilation today. People used to claim that at some point Java would consistently outperform C due to the greater number of optimisations available to a JIT compiler. They've all become silent because it's quite obviously a load of baloney.

The irony is that we had the answer all the time, but nobody wanted to believe it.

Back in the day, languages like Haskell, early C++, early Objective-C and Scheme compiled to C. Compiling to C was great! No need to spend man-centuries building an optimising cross-compiler to compete with GCC (and fail), no need to screw around with GIMPLE.

In 2015, compiling to a mid-level language is back in style. Except we don't call it C, we call it LLVM-IR. If you squint it's the exact same thing we were doing 15+ years ago.

LLVM-based languages that look like Rust and Swift will eventually dominate, because they are universal. You can use Rust for the lowest level embedded programming. You can use Swift for the highest level architecture astronautics.

What is depressing is that we could have built them 15 years ago but we were too busy fannying around with a dead-end technology.
Code Reddit
While I do not know the specifications of your Elasticsearch cluster, I am really surprised by your experience.

We (at skroutz.gr) use a moderately small cluster (four nodes) and easily process > 4 million rows a day and view them on Kibana dashboards in real-time. We also have success running aggregations on data going back as far as 3 months.
I tried some of the unofficial mirrors - the ones I could find did not have the latest version.
Wasn't that one of the original aims of GoogleTV? There were loads of shows legally available for streaming on network sites and on subscription services (in addition to live broadcast or cable) so you could search for a show or a movie and it would list all the places you could watch it at that time. Alternately you could browse by other criteria.

If I remember correctly, network sites and services like Hulu blocked GoogleTV via user agent strings and other methods because they wanted their streaming content to only be used as a secondary method of watching while at your computer, not on your living room TV and placed on and even footing with cable or (heaven forbid) independent/user-generated content.

Seems that happened pretty early on in GTV's product history and essentially put a damper on the sort of adoption that would have warranted further improvement of the service.
Thanks for this, was not aware of the name :)
Actually,you are in an ideal situation. Encourage the better developers to spend time mentoring the other developers. Developers appreciate managers who help them getting better.
Work on actionable and measurable goals for the developers to improve. I am pretty sure they will catch up. ATB
SARANAPOKER.COM AGEN TEXAS POKER DAN DOMINO ONLINE INDONESIA TERPERCAYA – TLD ID
There's an interesting commentary on this over at the FT:

http://ftalphaville.ft.com/2015/02/05/2113091/reminiscences-... (login needed)

The problem with the abstracted version of the market is that, well, none of the potential repercussions for breaking the rules involve any sort of face-to-face experience. Just the same way that defrauding people via email is much easier than doing it face-to-face, the lack of a physical interchange creates a similar bad behaviour incentive in the market.

With no social-pressure to be collaborative, everyone in it for themselves and regulators inevitably asleep at the wheel, because, well, there’s no way for them to keep up with how bad behaviours are innovating, all we end up with is a Wild West market in which nobody can ever trust anyone. Whether that leads to social stability and growth in the long run, we guess only time will tell?
I suspect people without kids or other similar obligations tend to work more in any industry or location; it's not specific to the Bay Area.

The difference is that in the Bay Area it may be that the ratio of those with to those without obligations is lower. It's certainly socially acceptable to implicitly discriminate against "older" (mid-30s and up) workers in certain sectors of the tech industry out here.

That said, I briefly considered applying to Tesla. Then I did my homework and asked around: their pay is below what even a green "webdev" at some random startup might expect (well below in some cases), and the work/life balance seems to resemble something closer to the video game industry (lots of "crunchtime") than to anything respectable. (NOTE: Of course that is based on anecdotes from contacts and, e.g. sites like glassdoor.com; it's not a scientific survey of employment at Tesla.)
No one pointing to the fact that GPG has major issues like no perfect forward secrecy? Are we celebrating that big-brother money is funding a (out)dated technology??
The link lifebeyondlife submitted is actually quite a good read:

Set up to fail: How bosses create their own poor performers
http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...

"I like how it describes the negatively reinforcing cycle of closer scrunity which results in worse performance etc. " -lifebeyondlife
...with the associated legal risk. If you start making too much money, you need to carefully structure your company to be raid-proof and judgment-proof. Make daily off-site, offshore backups. Don't ever do sales and manufacturing in the same country. Put your supply chain in a different business structure than your customer management, which is likewise separate from your reverse engineering operation. Use strawman purchasers to acquire your OEM hardware for analysis.

All that represents overhead costs. If you don't pay them, your company could potentially be eaten by lawyers.

Only white-hats can sleep soundly at night. (They would be naive to do so, but they do have that option.) They are also the only ones able to accept an over-the-table buyout offer.

That said, the grey-hat route is probably the most fun, and likely to attract people from the "because its there" crowd. Judging from the jailbreakers in the console and mobile markets, they might just do it just to kick a multinational in the nuts and run away, laughing.
So when are we all starting to measure sounds around us (including cafes, vehicles, cities) and create a map of quietest things and places?
I'd say the same. Its not as shallow as the title insinuates.
Not being able to fix things yourself is bad for the environment. Things that you use and throw is by design bad.
DRM also means not being able to improve on the product created by the corporate entity.

As hackers we need to be able to tinker and repair the things we have bought. Components that we by need to be recycled. Your old cell phone and laptop needs to be converted to a new one not thrown on the junk yard as trash or end up at tash dumps in Africa or China.
Fair enough, but it's still a valid comparison for most of us looking. Is the $600 machine 'good enough' for my usage, and it looks like it will be.
Playing devil's advocate:

PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.

FastBoot, I suspect, will dictate how I code my application/server side logic.

On the surface, it looks like the cost of FastBoot is higher.

The benefits are, I suspect, are higher though: single code base, reusable views, etc.
Do You know of any good examples of how to do it?

I was once considering creating a VM for each of my side projects, but unfortunately, I found they are tightly configured to the hosting environment! It's most probably my mistake, so maybe you could answer how to avoid following:

* I thought I could share VMs across computers, but having created a VM with hardware virtualization made tied it to a Intel Host with the virtualization extension. At home I have some laptops which are AMD's and don't support it.

* Is there a way to setup a whole VM from a script, including network card tunnels and shared folders?

* Is it possible to access a project environment, within a linux VM, which requires a Windows domain authentication? I guess it didn't work for me, since the requests originating from the VM lacked the necessary NTLM headers.
As much as I'd like to believe they are being genuine (as a developer who benefits from being in high demand) I've heard that this statement can really be re-written as "We can't get enough talent at the price we want to pay" thus the push to try to make it easier to bring engineers into the USA (One's they conveniently leave out will accept less for the same job). I'm not saying this is all fact but just that I'm not sure how much I believe that they really are scrambling for talent.
> That's how a magnetic compass works. I'm not Jack Sparrow.

Thank you. That's the first time in a while I've laughed out loud. It's been a dreary week.

On the other hand, I've got to give props to what is clearly a project someone worked hard on. It's got a very attractive design, despite it's technical difficulties (that may be surmountable!).
Processing Binary Protocols with Client-Side JavaScript