skysight-inc/HackerNews huggingface dataset:
There were days in college when I drank 3 glasses of fruit juice with each meal, plus a couple cans of soda during the same day. For some reason, I was convinced that fruit juice was an entirely “natural” and “healthy” beverage. I know better now.

But I also still know people who eat large quantities of fruit continuously throughout the day, probably 8–10 servings daily. They’ve convinced themselves that as long as they avoid soda, candy, donuts, and ice cream, they can just eat as many fruits as they want with no effect. It’s true that the fruits are better than just guzzling Coca Cola. But it’s not a healthy balanced diet.

They’d be much better off replacing some of the oranges with carrots, some of the bananas with spinach, some of the mangos with broccoli.

Fruit isn’t inherently evil, but like everything, it’s best in moderation.
You dislike the particular compromises made to implement a bad version of the ideal. That does not mean the ideal is to be avoided, just that it is more complicated to achieve than the OSX team was willing to implement.
If I had to guess, the diversity of Android hardware and operating system versions in the wild make delivering a quality experience more difficult compared to the narrower range of Apple devices and their generally higher specification of processors and cameras.

And if I were to wildly speculate, Apple phone owners are a more desirable demographic to pursue over the long run.
The Motorola iDEN [1] series of phones were pretty sweet back in their day and had a JVM you could actually write and deploy apps on.

I worked on Loopt, an early mobile location sharing app, and we talked to our server over HTTPS. Things were working great on a few LG and Sanyo phones, and worked fine in the iDEN emulator, but POSTs would fail consistently on the device itself. GETs worked fine.

After watching traffic on the server for a bit, I noticed the POST requests all advertised HTTP/1.1 and sent the Expect: 100-Continue header. On a whim I configured the server to treat all incoming connections as HTTP/1.0 so it would never send the 100 (Continue) response [2].

It worked!

Or did it? Turns out the iDEN phones were now happy, but the other phones were not and would refuse to send POST bodies if they didn't receive the 100 (Continue).

This well and truly sucked, and we thought for a bit we'd need to have two different endpoints with different configurations to support the differently incompatible phones. Lame.

But then I remembered the format of an HTTP request:

POST /path HTTP/1.1\r\n
Expect: 100-Continue\r\n
[Header: Value]\r\n
\r\n
[Body]

What if I supplied a malformed URL? Something like "/path HTTP/1.0\r\nX-iDEN-Ignore:"? Then, if there's no validation or encoding, the request will look like this:

POST /path HTTP/1.0\r\n
X-iDen-Ignore: HTTP/1.1\r\n
Expect: 100-Continue\r\n
[Header: Value]\r\n
\r\n
[Body]

Turns out that worked. The JVM was never updated or fixed, the hack shipped, and it worked consistently for the lifetime of those phones.

[1] https://en.wikipedia.org/wiki/IDEN

[2] "An origin server ... MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client" https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....
At a previous company, we had a legacy software written in PowerBuilder, which crashed on some of the client's computers. We couldn't reproduce the crash on our computers, no matter how much we tried.

We finally got access to one of the crashing laptops, and (with the client's permission) installed a debugger on it. After a few false starts, we found that some code deep within PowerBuilder's framework crashed when it received a particular accessibility window message, and that this window message was being sent by some Microsoft touch screen component. All of us techies had avoided buying touch screen laptops (this was when touch screen laptops were Microsoft's latest fad), which is why it had never happened on any of our machines.

The solution was to do a binary edit of the import table of the relevant PowerBuilder DLL to route all Windows calls to a helper DLL, which forwarded them to the real Windows DLL after replacing the window message callback with a small thunk. Said thunk then filtered out the offending window messages, before forwarding the rest back to the real window message callback within the PowerBuilder DLL. Hacky, but worked perfectly.
Open Street Maps

http://www.openstreetmap.org/

open source mapping. You'd have to host or find a host. It will take time and effort, but the data is free.

there are other maps as services too.

https://www.mapbox.com/pricing/
It's popular in mapping because it can be georeferenced. https://trac.osgeo.org/geotiff/
He's being hyperbolic, but once you cut out sugar long enough sweet things really do taste worse. Try it for yourself and see.
I'm no Stallman, but I'm deeply uncomfortable with how readily everyone is accepting (and encouraging) GitHub as the complete overlord of open-source software. As already pointed out, Sourceforge is a cautionary tale of how these services can go very wrong due to business issues. There's also a much larger philosophical issue with basing the open-source economy on a proprietary platform with no particular intent of open-sourcing its core software.

Yes, GH does a lot of things right, including generally making it easy to export data form their apps in a reasonably vendor-neutral form. But what happens when GH runs into financial trouble like SF did? Do we want just about every project out there to have to struggle to do something with their GitHub issues?

There are issues with having open-source projects maintain their own infrastructure, but I think it's the right thing to do wherever possible. It makes them truly independent in a way that a GitHub repo can never be.
Ask HN: Wanting to become a programmerkeep running into problems
Hi all...Little bit of background. I am 43 years old and have been working as a sysadmin type person for the last few years. I have some scripting skills (bash, perl, python) that I acquired as part of my job. I do not have formal comp sci education.

I have been wanting to learn how to become a "decent" programmer with the following goals in mind to move towards on a _professional_ basis (aka make some money doing) - AI, machine learning, potentially game development.

Anyway, towards that end, I have been doing a bunch of research and tried a couple of things but keep running into issues. I have started MOOCs and never finished due to getting frustrated on the problem sets. Looked into Python (CS61A, MIT 6.001.x), Scheme (SPD1x)..tried going through SICP (got destroyed at the first chapter), HTDP2e (stopped again)...

Partially it is due to the lack of time to actually devote to psets, partially due to getting frustrated and giving up too early....probably I am not doing things too efficiently and all over the place... I find the problem sets too difficult at times and just get frustrated and start looking at other options which is I am guessing the crux of the issue.

Does anyone have any advice?
Thanks for sharing Marc, I'm looking forward to reading through this!
TIFF is still used in the Apple ecosystems. It got a mini-rebirth recently when Apple started doing retina displays. TIFF has the ability to store multiple images, which Apple has latched onto to allow different images to be used for different resolution screens.
Signed certificates work even when your AAA system is entirely offline. An individual server can make a valid authentication/authorization decision just by validating the signature.

There are some significant advantages to working that way.
IIRC, the lead for an angel syndicate can make deal-level carry (as opposed to the fund-level carry that is described here). This leads to some incredible risk-taking: there is no consideration for how they might be harming their "fund-level return" (i.e. the return on all the investments they as an individual have participated in) -- and they don't really care because that isn't their biggest opportunity. The biggest opportunity is the carry they can make on this _one deal_ if it's a home run. So the average angel who is just participating (and not leading) has a really risky portfolio.

http://avc.com/2016/02/fund-level-vs-deal-by-deal-carry/
I don't know much about the Google Maps API, and this may sound obvious, but could you use caching to help you drastically reduce requests? I imagine many different visitors are making the exact same requests.

Also, are most of your requests coming from unique users, or do you see lots of users making repeated requests over and over? Maybe you could limit the number of requests for a single user. It sucks for them, but it allows you to implement a cap and affect the least number of people possible.

Are there any features of your product you can offload to other services? For example you mentioned directions -- why not link to Google Maps itself and let them handle that? (This might not be an applicable solution because I haven't studied your product to see how it works, but you get the gist.)

Is your code written modularly? Ideally you won't have to port all your code at once in some gigantic all-or-nothing rewrite. You can simply move one component of your code at a time to a free or open-source alternative to Google Maps. This could reduce your burden chunk-by-chunk over time until it's manageable.

Another avenue is to increase your revenue. Easier said than done, I know, but perhaps you could request payment/donations from users, or at least for repeat users. Or maybe you could reach out to the conferences on your site and see if they'll sponsor you.

Finally, I don't know anyone at Google, but it can't hurt for you to try to look up the right people and send some emails. I'd start with their developer advocates. This is a shameless plug, but I started a forum on my site (https://IndieHackers.com) recently as a place for founders to help each other out with problems just such as these. Can't hurt to post there and see if anyone has advice or connections at Google.

Good luck, sounds like a tough position to be in! (By the way, your site is awesome and it'd be very cool to interview you for Indie Hackers.)
I am East Asian and came to America in my 20's. I love pastries and deserts, always looking for local pastries to try whenever I travel, to the point to book hotels that are close to famous pastry shops.

Sorry for any misunderstanding my early comment causes.
Mattermark Daily – Monday, September 12th, 2016
> What am I saying, that place[0] exists

One day, this will have only existed. Until then, they should host the repository on Google Code.
With RevokedKeys. It looks like Facebook also uses short-lifespan certificates.
I don't think we're seeing a Github decline. Yes they've had some internal strife not all that connected to business, but Google just moved a lot of its OSS there, Microsoft just moved a bunch of stuff there. Git repos take a single command line statement to move, but Github is only slowing if by the force of not having much left to hoover up.

Gitlab et al are growing, and now AWS has its own integrated solution, but I don't see Github going anywhere for a very, very long time. (Barring catastrophic happenings, of course.)
Hootsuite was absolutely a little snowball. Invoke Labs was an agency in Vancouver that build Ow.ly (a link shortener that's still around). They then continued to build an early ver of Hootsuite to manage their clients' social media campaigns. Then they realized that other people might want it and offered a free version. I had dinner with the founder the night before they turned on their paid plans, and he was unsure what the reception would be since they gave so much to so many people for free.

The reception was somewhat positive but they continued to grow and sell the crap out of Hootsuite and now it's on track to go public. But they started SUPER small.
Microsoft's on a very strong redemption arc. You don't want to stall that by burying the brand when they do good work.
Not OP, but have been ketogenic over 3 years. No bread, no fruit, no potatoes, squash, tomatoes, grapes etc.
Which is why a DVCS is important, the history goes with every copy.
There is a new project, Software Heritage [0], that specifically addresses the problem of long-term code availability.

https://www.softwareheritage.org/
In my (limited) experience, canker sores are an allergic reaction. Raw pineapples make the inside of my mouth tingly, and then voila: canker sores. I stopped eating raw pineapple, and I've not had a canker sore since.
Not really a bug, but I just ran into this. A linter for Ruby that only wants double quotes if there is string interpolation and prevents builds from triggering. Never mind if you want to avoid escaping single quotes for readability. Here is a work around ;)

fuck_linters = ''
linted_string = "${fuck_linters}don't stop apostrophes"
Yup well aware of the alternatives. It's just that converting my gMaps javascript code into this new API is gonna be a big pain and ensure downtime until I'm back live (I'm currently paying gMaps as a temp fix until I find a solution). Looking to find an easier solution
Since Pix is an alternative to the built in Apple app, it makes sense that it provides an alternative functionality from a user standpoint...and perhaps from a not-getting-booted-out-of-the-app-store standpoint.

As a person pushing get off my lawn age, taking selfies feels unseemly even though I know it is entirely mainstream among younger people. One of the things I find interesting about photography is how rapidly the 'uncanny valley' becomes normal. I look at Instagram filters and wonder
'why I would want to make something look like a Polaroid?' It just means the filter is not for me.
You would need a GPU with an onboard SSD (exists). Or GPUs and drivers with the ability to talk directly to infiniband hardware (exists).

Or the ability to not be ridiculously wasteful of existing resources (also exists).

Your naysaying doesn't make you smart. Your naysaying makes you cut off from learning a different, better way of doing things.
I'd say a starting guess for determining low wage for full-stack devs is anything < (backend dev salary + frontend dev salary), using market averages by location. If you're going to have a single person doing the work of two, pay them accordingly. Otherwise, hire two people and lighten the load.
The fact that it all ends up as "sugar" is less important than how long it takes to fully metabolize, how much energy and other resources it takes to do so, and what other byproducts the food provides.
In the quantities used in many processed foods, the "sugar" that you see on the food label and that is used as an sweetener is generally undesirable for those characteristics.
For the curious, it's completely possible to buy used Rolls Royce turbine blades on eBay. eg:

• http://www.ebay.com/itm/331908581051

Off topic side note - seems like someone's buying them, mounting them + spray painting them at large markup:

• http://www.ebay.com/itm/122000006766

;)
Several companies have implemented databases on GPUs but there is a good technical reason that the approach has never really caught on, and some of these companies even migrated to selling the same platform on CPUs only.

The weakness of GPU databases is that while they have fantastic internal bandwidth, their network to the rest of the hardware in a server system is over PCIe, which generally isn't going to be as good as what a CPU has and databases tend to be bandwidth bound. This is a real bottleneck and trying to work around it makes the entire software stack clunky.

I once asked the designer of a good GPU database what the "no bullshit" performance numbers were relative to CPU. He told me GPU was about 4x the throughput of CPU, which is very good, but after you added in the extra hardware costs, power costs, engineering complexity etc, the overall economics were about the same to a first approximation. And so he advised me to not waste my time considering GPU architectures for databases outside of some exotic, narrow use cases where the economics still made sense. Which was completely sensible.

For data intensive processing, like databases, you don't want your engine to live on a coprocessor. No matter how attractive the coprocessor, the connectivity to the rest of the system extracts a big enough price that it is rarely worth it.
Hopefully no one will be driving by then.
> The amazing part is the lens. First Dudley worked out exactly what optical qualities he’d need, simulating the parts and distances involved in a ray tracer. Then he actually printed it out using a high-quality transparent resin and sanded it down with a custom machine. Then a dip in liquid resin fills in the tiny valleys and flaws

So crafting things is 3D printing now?
It's just a hard problem, especially when you have to try and get a number of different artists to maintain a single style for a project. Disney was struggling with this problem for decades and financially they were hardly breaking even with their studio part of the business because of the cost of generating all the art they needed. Computers lowered the costs and the manpower quite a bit, but then increased the quality expectations.
That's an interesting subscription model. I'm curious how it'll turn out.

In the meantime, I wasn't sure what "sync" meant in the context of your app. I had to read a lot of your page before I understood (even after reading this post first).

I actually thought you meant syncing bank accounts or something similar.
Value-Seekers Warm to a $450 Annual Credit Card Fee
RE:"But to capture global market we want to make a pitch very simple and easy."

Part of your sales format could be like a FAQ setup where the most compelling features are part of the question (How-do-I, Could I?, etc).

This way potential customers do not have to wade through info on features that don't interest them.

If you could incorporate video into the answers it would be even more powerful.

Hope this insight helps.

Best of success.
E.g. recently, scripture and mass was mostly in Latin, so even most of those who were literate had to rely on priests to interpret it for them.
The problem with articles and discussions like this is that the "markers of success" pointed out may all be true, but incidental.

Take Slack as an example. Yes, it was a simple idea with low product surface area and easily protypeable etc etc. But other people had built Slack-like products before that met the all those same criteria and were not successful. The critical factors for Slack were the connections the founders had (or made), the VC money, and perhaps a whole bunch of other things.

As much as we'd like for there to be a nice, neat guides for successful businesses e.g. "build a little snowball", the truth is that the reasons for success are often totally unique, contradictory and unrepeatable.
That's awesome and the solution is not as uncommon as you'd imagine.

At "a large telecom" I used to work at, we had a specific process that handled billing that relied on a DOS application which was written targeting a specific modem's hardware. They'd tried to migrate it to something else for quite some time but the guy who wrote it lived in a different state and was let go from the company when we closed that site down and moved all of its equipment to Detroit. It ran on an old Compaq (not HP Compaq, Compaq) desktop PC and in 2014 or our VP received a frantic call that the drive had failed and the computer wouldn't boot (from a younger tech who was used to working on server class hardware). The code for this application had been lost forever and nobody had any idea how it actually worked but my understanding was that with it not functional, we were losing enough money to make it a "drop everything priority".

They brought the machine over to my building and the VP of my department called me to assist[0]. Sure enough, the system wouldn't even see the drive. It was at this point that I noticed three numbers with the letters "C", "H", "S" next to each. This had happened before, apparently, and someone discovered the BIOS battery had died. Thankfully, they were kind enough to put the drive parameters on a label for me. I popped into the BIOS, put 'em in and it booted. The computer remained powered on in the cubicle I repaired it in (just outside said VP's office) for a year until the dev team got around to modernizing the code.

[0] I was not a support person at this time but was in the past and it wasn't unusual for them to call me in on strange problems. I was also known for having recovered a hard drive with important data on it using the break-room fridge (though I'm not sure this VP was aware of that).
Toward what kind of testing, mind sharing?
I think that in this cases you can submit the link, and then send an email to ask dang to un-dead it.
Cards? No, you need to feel the bits, inputting them with manual switches.
Cinemagraphs are all the rage now. Maybe it was intentional. Probably compresses much better.
Too funny, though, I'd be willing to bet "the same time every afternoon" was more that it happened at the same time in the afternoon when it failed which probably made it even more painful to isolate since it was reliant on the sun appearing in an area not known for sunlight.
Interesting. I switched to Barclays for my personal accounts, and they seem unusually tech savvy.
I had read the article but didn't see the video. Happy I came across this, really amazing stuff.

Obviously, real life is way more complicated. But why don't we see antibiotic resistance happening faster in the wild, as the video would suggest...?
Seems like a smarter response to me. Go ahead and use a GPU database if you want?? I have yet to see a good use case of one though.
Seems like a great application of AMD's Fiji GPU w/onboard flash: http://www.anandtech.com/show/10518/amd-announces-radeon-pro...
If you're not using vimclutch already you're doing it wrong

https://github.com/alevchuk/vim-clutch
Many years back, I was working on a web application that, among other things, could generate PDF user reports. These reports were generated from HTML web pages using a third-party library. Normally this worked well (as well as such a tool could be expected to work anyways), however once a month or so the fonts on the reports would come out super tiny. This would then happen in random reports until we rebooted all of the app servers. The bug occurred in production only, never in our dev, staging or QA environments.

Many hours of investigations were committed, many emails to the vendor were written, much hair was torn out. No luck whatsoever. Months passed, and the bug reoccurred at random intervals and did not consistently affect all reports. One day I logged in remotely to one of the Windows app boxes as an admin/console user and was annoyed to once again discover that it forced my screen resolution to change. That's when I had an epiphany and 10 minutes later was able to reproduce the bug in my local environment.

Turns out the third-party library had some funky rasterization logic that took into account both the resolution of the machine when the library/service was started as well as the current resolution, pretty much expecting both to be the same. Logging in remotely as a console user has the behavior of taking on the resolution of my local machine, which was always higher than what the remote box ran at. Another thing to note is that the console user logged into the same running instance of Windows that was generating the PDFs. BAM! The cached value used by the library no longer matched the runtime resolution and the reports now generated screwy tiny fonts. This happened rarely because logging in as admin/console was not the recommended approach, and it was inconsistent because we had multiple app boxes and the other ones continued to work OK.

Solution - disallow admin/console remote logins. This was one of the most obscure bugs I have had the pleasure of solving.