skysight-inc/HackerNews huggingface dataset:
Of all the problems we have as an industry, I'm convinced that version control is near the bottom of the list.

Sure, 'DVCS' in the form of git or mercurial doesn't deal well with binary files, and has large repo sizes. If these are problems, you might be using the wrong tool.

But that's fine; pretty much everybody should be using something like git or mercurial. They're flexible, relatively easy-to-use, and cover almost all use cases. If you need to store large frequently-changing binary blobs, then you are probably in a minority; there's nothing really wrong with git-annex for managing that content.

But this whole thing we're seeing at the moment with people objecting to DVCS utterly mystifies me, as someone who went from CVS to SVN to git and has utterly no interest in going back.
There is, in fact, quite a science of producing foods that have pleasing tastes. They call the optimum combination of flavors the "bliss point":

http://www.nytimes.com/2013/02/24/magazine/the-extraordinary...
So it's a pre-configured VPS and a little physical VNC device?
Is 1:1 really a resonance though? Any object with a similar semimajor axis will enjoy this orbital period, so it could just be a spatially defined coincidence.
LDN2SFO
I'm looking for a summer internship!

Location: Silicon valley
Remote: preferablly not

Willing to relocate:
Technologies: Backend development/ some frontend.

Résumé/CV: http://nickysemenza.com/resume

Email: nicky [at] nickysemenza.com
I reversed it back when it was version 1.1.something, it was basically all compiled Python modules with custom encrypted code objects and non-standard opcode mappings for the bytecode.

Quite interesting to see how it worked, and useful to get the key for the encrypted logs, to see it what it actually did while running. Back then you could intercept the https connections as well as they hadn't pinned the certificates yet, to get an even fuller picture.

There was nothing obviously nefarious going on back then, but that was quite a few years ago of course.
The point of his comment was that if Amazon have a fire that they'll deal with the issue, you won't have to do anything.
I'm an old python hacker, and while I appreciate C/C++ the most I've done with them is set up bridges with ctypes so I can call compiled libraries from python.

Go, to me, feels like it has some of the expressiveness and discoverability of python, with the added bonus of type safety and raw performance of C (for my purposes, at least). For most of my small projects, it fits a nice niche. Any time I need a lightweight HTTP/JSON API to talk with a fancy javascript frontend, Go is slowly becoming my tool of choice -- especially if it may end up on other platforms (including Windows).

When I wanted to learn Go I set aside a Saturday to grok the docs and "getting started" guide, and was surprised to find I finished by 10am (including a coffee break). The language itself is very small, and I found myself successfully "guessing" at structs and function signatures very early.

It's at least worth exploring, especially given the tooling for web, opengl, and android.
Hahahaha love this. But I think all version control systems suck - not inherently, but because their usability is atrocious. I enjoy Git... well, perhaps enjoy is a strong word, perhaps what I really mean is I have Stockholm Syndrome.

I've tried to go back to TFS, SVN and other centralized systems, but I'm too emotionally bonded to having my source control system with me, everywhere I go... Starbucks, Tim Hortons, the Train, sitting on the beach. But I don't delude myself into thinking this is anything more than emotional. I like having it there, it gives me comfort - and there is some convenience.

I don't want to have to worry about "How do I undo all those changes from my last 10 commits and go back to where I started down this path?" Git gives me that nice fuzzy feeling of being able to play meaninglessly with my code until something takes form and if it comes to nothing, I can do git reset --hard 1f3c2047 and I'm right back to where I was before I went down this path of insanity...and if it takes a nice form, I can do git rebase -i and squash all my messy commits into a single commit with a single commit message. I didn't need to branch, I didn't need to clone, I didn't need to do anything crazy, I just fire up Bash and I'm done, no muss, no fuss, no having to be connected to the source control server, no dependence on anyone else... and if I did want to put that code aside, I can stash it or spin it onto another branch before coming back to my original branch and resetting back to a sane commit. It's nice having ultimate control.

But having that amount of control has its drawbacks...you can't expect the ability to drive stick, but not have to learn how to use a clutch and gearshift.
I'm always wary of posts that proclaim that one thing is definitively better, especially using overly simply comparisons. Cloud offerings and usage have very complicated billing and a huge number of line items. Many of these are very dependant on architecture and deployment choices and are very hard to predict up front. Add to that the complication that the people doing the deployments are often not optimising for price, it's a recipe for a big bill.

So on one level, I completely agree with you. In my experience, it's almost always cheaper to hand roll hardware yourself. That said, of all the reasons to move into the cloud, cost should be at the bottom.

Instead I feel companies should be asking themselves "Can I gain a competitive advantage by outsourcing my infrastructure?"

In many cases, the answer is yes - but it depends on the business; For example I can imagine that a business like Backblaze would not be able to compete as successfully using commodity cloud storage.
The team actually built their own streaming tech from scratch so it works quite a bit better than VNC.
Mostly broken on Safari
Go three post up, read the last paragraph. I'll quote it for your convenience:

> I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.
SOme previous HN post about old intelligence test results, filed away for 60 years. Rescored, those people who took those tests long ago, had an average IQ of 70.
We did a lot of prototyping on AWS and still use them a lot, but really we are pretty agnostic as to where the VM lives. We need nvidia GRID cards (which is what we use to scrape the remote desktop really fast and which AWS has for prototyping) but the rest is pretty off the shelf. So currently its a pretty hybrid system
How are IP and SMS traffic different, other than "packet" size and encoding constraints? Both are easily interceptable and spoofable, necessitating strong crypto.

I don't see how chacha20/poly1305 is somehow "worse" over SMS.
Works for planning applications in the UK too.

Building company wants to build a 12 storey block of apartments somewhere, but the locals will object to pretty much anything.

Initial planning application goes in for 42 storey block.
Locals up in arms demanding it be reduced. Big protest campaign launched.
Delays and then a revised planning application for 28 storeys.
Outrage (but less vociferous).
More delays and eventually a revised planning application for 12 storeys.
Little complaint, planning application successful.
Reminds me a little of the Declaration of Independence where the famous line would have been "We hold these truths to be sacred and undeniable" if Thomas Jefferson hadn't been "touched" by Benjamin Franklin with his edit to "self-evident".
This is a fair consideration. However, having seen "tiny homes" in person, I'm convinced they are very different than a traditional RV or trailer.

> There is no second, remote property in Nevada, because all the homes adhere to a common standard for utility hookups and foundation pads.

Solution: Solar (electricity) and gas propane (for heat).

> hotels, time-share condominiums, furnished apartments rented weekly, couch-surfing, pieds-a-terre.

None of these are economical because their high price is driven by regularly unused capacity. Also, there are benefits to being "swappable" in that entrepreneurs are always close to other entrepreneurs. YCombinator alone could benefit from such a system where they have 100+ entrepreneurs temporarily relocated to the Mountain View area every 3 months.
Sync 2.0: Skip the Cloud, Share Direct
Bitcoin poker exec: “I was led out in handcuffs in my underwear”
Lobster.media – legal access to social content from real people
I think that he misses a subtle point. A lot of the failed spin offs were crap. So he must explore also the failure of new shows to the failure rate of spin offs to give better idea.
what operating systems will it support out of the box?
Obviously, if women-only events encourage women to get into the larger tech scene as a whole, then that increases diversity. There's nothing "paradoxical" about it. It's very straightforward.

The idea isn't that we create a bunch of events so that women can program/hack without ever interacting with men. That should be obvious.
Bringing Native Games to the Web Is About to Get a Whole Lot Easier
I don't think you need REST to access a static file.
Linux and Windows.

We’re starting off with Windows and Linux options for now but plan to offer more operating systems in the future.
Unity 5 Ships and Brings One Click WebGL Export to Legions of Game Developers
[Here's the link to the Stack Exchange post](http://programmers.stackexchange.com/questions/122009/develo...) (on the Programmers site) that's reverenced in the blog post.
I can tell from the downvotes :)
Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce.

There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.
> advocating abandoning it completely in favor of RPC-over-HTTP

It surprises me that the author didn't go one step further and ask us to return to SOAP :)
As far as I can tell, Paperspace is a hosted VNC+VPS esque service wrapped in a friendly user interface? Seems nifty.

Anyways, the intro video is easily one of the more amusing ones I've seen in a long time. Props.
Personally, I'm fond of Algol style, where spaces are permitted in identifiers.

Man, Algol 68 was really ahead of its time... too bad it never caught on.
inotify is by far the best of the filesystem notification APIs. It's wildly reasonable.
> I have wanted to have the full history while offline a grand total of maybe about six times.

I have probably run git init in a directory at least once a month to have full tracking capability without the expense of setting up a "server". It says something that the author assumes that a DVCS can only exists if it has a central server and that your local copy is nothing but the "offline" copy. I have also run projects where the github repo was just a copy and the version on my box was the official repo. I also run expensive (cpu/time) scripts that walk over the projects history, something the server admin would never let me do. And then we get into the realm of very expensive hooks that run on my desktop and not on the "server". And lastly even in an always connected world if your server is in Australia you can't change the speed of light, hitting it from Germany will always be a long "slow" trip.

Having the full repository at your disposal without being tied to some other authoritative repository provides a lot of flexibility and enables capabilities that are just not possible otherwise. Some features could easily be included in non-dvcs systems (such as local hooks), but I do not know if we would have seen their success without dvcs systems providing the means for exploration.
Stupid gaudy trainers and wide-screen TVs only. Tsch, kids today eh?
Well that's the ironic thing - by overstating how much he was paying, the police officer showed that he earned less because his costs were so high.
Roadmap for npm
It's worth mentioning that I fully expect it to "just work" on windows as well (judging by past testing experience). The only caveat in this particular case is I'm not sure how or if my third party serial port library has been tested on Windows. I'd expect it to run just fine but need tweaking to find the correct handle for the serial port since it won't be as easy as opening "/dev/tty.x"
More amusing than the article itself are several stories recounted here.
hs1.8xl's don't come with SSD storage. See http://aws.amazon.com/ec2/instance-types/ where it's not flagged as having SSD's.

As I noted above - cloud pricing is hard.
> That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage".

And in that cause you can scp your repo somewhere and change your origin and move on.

Also, do people really rely on 3rd party services for their deployed code? I've used github as a repo and colab tool at companies, but we still deployed from repos owned by the company.

> I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved.

I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.
Yes! We are working hard on perfect + consistent measurements. Here is a quick overview:http://imgur.com/ndgq2Ci
And this feature will be released in API really soon. Stay tuned!
The increasing energy cost in computing these days should change our thinking on Moore's law. We shouldn't be worried as much about doubling the power of a cpu, especially in a cloud setting, because you can always do that by using 2 cpus. We should instead create an equation based on the computing power, energy consumption, and energy prices.
You only see most primitive and dirty last stage. Showing anything before (fixing and reusing whole products) wouldnt be sexy enough.

Its like those tent city documentary movies, think Michael Moore.
Yea, so VNC is really versatile but not very performant. We set out to build a remote desktop protocol that could stream HD video streams and which would make doing things like high-end graphics and other media-rich applications possible.

On a more technical level, VNC sends block of pixels whereas we are using a video stream.
> Why not simplify by removing parameters from the URL altogether?

Caching. Put a caching proxy in front of your api endpoint and enjoy.

This is the same reason you'll want to do:

/api/customer/1234/order/abcd

instead of:

/api?customer=1234&order=abcd

Because even if your cache includes query strings (which it may, and you can configure it to), you lose order. Now you also have to configure your cache to ignore ordering on the query string, and that's a lot less obvious (and probably not even HTTP compliant?).
Show HN: SQL tests in python, deterministic and fast
I didn't see anything in the article about how political concerns over technology such as RNAV (http://www.faa.gov/air_traffic/publications/atpubs/aim/aim01...) have held back the transition to a nextgen system. I work at an airport where community concern over any potential changes to where aircraft fly has held back implementation of new technology that would make the whole process more efficient. My understanding is that many other major airports in the US face similar community and political issues about RNAV. I suspect this has also had a major role in the delay of the nextgen roll out.
I concur. For one, I find Indian food pretty bad, too much spices, too much ingredients, and everything tastes like curry ;)
Will there be any support for gaming?
OTOH, "removing information from the URL for aesthetic reasons" may not be the best reason to move a safe operation from GET, which is defined as safe, to POST, which is neither safe nor idempotent, particularly if you are using middleware that is aware of HTTP semantics -- you've just thrown away valuable information.

So a part of the point of and value of GET is to communicate idempotency? We can know certain parts of the API are idempotent because they are GET?
Walk Hard. Walk Easy. Repeat
This product is awesome, one of the biggest issues I have with docker is the low visibility inside containers.
> Bitcoin poker exec: “I was led out in handcuffs in my underwear”

Sounds uncomfortable -- and don't the police frisk suspects any more? How could they overlook handcuffs in someone's underwear?
I absolutely love unity. I've been playing with it on and off for the past few years and it has been surprisingly easy for me to pick up. The free version has a pretty spectacular feature set.

I've had a lot of fun with 2d mode- as a learning project I recreated the Monkey Island I Melee Island scenes with mixed sprites from Monkey Island II. Such a blast re-creating a game from my childhood. I really need to find more time for this stuff.
A close family member of mine is one of the project leads on this nextgen program and their is little to no concept of security built into this program. There are so many points of failure and data integrity is based upon non-crypto hash functions such as fletcher 32 bit.
Thats a truth few wearable companies understand. Many just shove the same functionality of the phone onto your wrist, which is the worst of both worlds. They miss out on the unique opportunities wearables have and focus on smartphone features that are sub-optimal (at best) for a wearable.

Pebble is the leader in this way of thinking. They are showing more innovation than Apple with the announcement of the smartbands. Opening up a world of possibilities for software and hardware engineers/ideas
What happens to your C# gameplay code?
My experience has been that any place big enough to be dealing with recruiters, a couple layers of HR, and so on, is also going to have an online application system where you'll be lucky to have something more than "paste your resume into this text box". Certainly no way to send a photo even if you wanted to.

I know when I worked at big companies, by the time I saw a resume it had always been through at least one system, and often two or three; and any formatting that the applicant had done was long stripped out, leaving bizarre line breaks and other problems all over the place.
Camel case results in several sources of frustration for me:

1. Is it userID or userId? HTTPClient or HttpClient? Leaving this additional stylistic choice up to people results in conflicting styles even within the scope of "camel case" everywhere! (JavaScript mostly leaves them uppercase, e.g. DOMException...then there's XMLHttpRequest...)

2. Code isn't the only place we need to make this choice: what about configuration files? I find that using camel case for configuration keys – even if the configuration will be the input to a camel-case-language program! – just feels incredibly wrong.
I don't engage devil's advocacy.. only pedantry.
The copy on your website ranges for me from confusing to offputting. I'm not even sure exactly what you're selling after having looked at your site for two minutes. Maybe you sell virtual machines in a data center, accessible with vnc or rdp implemented in JS? And maybe an additional mini computer preconfigured to access that?

Note: The answers to that do not matter. What matters is that your website doesn't answer them and is in fact so vague that it triggers all of my mental fraud bells.

Edit:

Also small footnote. This is probably honest and well-meant, but it reads like snake-oil: "Your desktop is managed in a secure data center and we send you a fully-encrypted feed." Which data center? What does secure mean? What guarantee do i have about that security? What encryption are you using? What about the data i put on my VM, are you backing it up? Is it encrypted by default or can any paperspace employee read my diary on my cloud computer?

You need to answer them in that sentence but without links and/or footnotes to further explanations it's just meaningless and amounts to "Just trust us, ok?"
Wat je met overvloed kunt eten als je een slank en gezond lichaam wilt
What is annoying is when build artifacts are checked into source control systems along side of the source. There is very little way to exclude them or only check out the binaries, you can only have both. This happens all too often and I don't care if you want to keep using subversion you really should stop doing this.

/src/foo.c
/src/foo.o
You don't need debugging symbols to trace system calls.
You're right - regulation without any support from the AI/ML community would be less effective.
LeadGenius is hiring engineers and designers for our home office in Berkeley, CA
As much I understand, the service (not the device) is not generally available?

When will it be ready? When will it be possible to use it from other countries (other than US)?

The service as such is very interesting, for example, when I want to have quick access to a Linux/Windows desktop with a particular OS without the need to install on real iron.

Depends of course on the pricing. The idea sounds really neat!
The project specifications demanded by the FAA are absolutely ludicrous. This is not the F35 program.
I think that we're only a few years away from someone reinventing SOAP but with JSON playing the role of XML.
How about buttons by crosswalks that don't do anything?
Perhaps recessional photo studio lights? I imagine photographers are picky, so those lights hav to be good.
You'd think that someone choosing a name for a new technology product would do a single google search first, yet time and time again we end up with these collisions. There should be a central repository mapping names to services that we can use to look up potential names.
Being reflexively cynical can be just as harmful.

The problem for Yahoo is that, at the moment, the critical articles are very dense in facts. Take a look at things like this for an example:

http://www.forbes.com/sites/ericjackson/2015/03/01/yahoos-in...

As much as you can disagree with the content of this article, it's hard to argue that it's as light and fluffy as the PR piece served up by Levy.

Regarding Carlson's stuff on Yahoo, you might disagree with some of his opinions. You might even think his book is a hit piece. But, at the very least, it's a well-researched hit piece.

Levy only seemed to speak with Yahoo PR and republish their opinions directly. I don't think any reasonable reader could assume that Carlson only spoke to a hedge fund manager short on Yahoo.
Exactly, I don't understand why but it seems to me that a lot of people like to use the word REST as much as possible without knowing what it actually means, or without even having read the damn paper :(
Except that RPC-structured APIs are complete garbage to consume for external developers because, surprise, they don't know or care what your internal function names are. And if you aren't thinking about the experience of real or theoretical third-party developers when building your API, why even have one at all?

If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your system. It's less about adherence to some strict standard and more about helpful signaling. A GET fetches data, POST creates new records, PUT is idempotent, DELETE deletes. 4xx status codes indicate a request error, 5xx indicate a server error. That's all useful information for someone trying to integrate with your API, but you think that instead everyone should memorize your in-house conventions. Good luck getting buy-in on that.

The only partial agreement I'd give to this is that I no longer think it's wise to nest multiple levels of resource IDs (e.g. /customer/123/order/456). This is, again, out of respect for external developers. Instead, I would have /customers/123 and /orders/456 (assuming that IDs can't be duplicated between customers). A flatter URL structure (which is, note, still REST-friendly) can be an easier-to-consume experience for other devs.