skysight-inc/HackerNews huggingface dataset:
You don't need to entirely disable Nagle; just flash TCP_NODELAY on then off immediately after sending a packet for which you will block for a reply. This way you still get the benefit Nagle brings of coalescing small writes, without the downside.

(Alternatively, turn Nagle off entirely and buffer writes manually or using MSG_MORE or TCP_CORK.)
Why has Italian cinema lost its appeal abroad?
The problem with the 360p videos is that Chrome eats up RAM like I drink beer, and add the neccessities of the Windows world like anti-malware software, adblockers, crappy 3G stick software... you get it :/
Trove of Antique Roman Coins Found in Swiss Orchard
I found myself recently needing to embed an open source library which used a similar mechanism for its plugin system. The goals of the plugin design of this system were to make it possible to cleanly register plugins for a range of different types in a manner which preserved type safety and to be able to use the same registration mechanism to define any of these plugins within arbitrary compilation units so that plugins could be easily added by consumers of the system -- using the same mechanism as used for the built in plugins... Including for plugins loaded at runtime.

The plugin registration mechanism involves a pre processor macro that authors invoke on each plugin class after definition -- this macro declares that the specified plugin implements a special factoryinstance template class. The factoryinstance template class is paramterized by the plugin type and the specific plugin implementation and provides a default constructor that retrieves the class name of the plugin implementation class via the qt meta object system and adds it to a central registry for each plugin type. This template class also contains a static member variable of the self same factoryinstance template class. This member variable gets initialized by default by the compiler during static initialization which causes the default constructor for the specialized type to be called which causes the plugin to be added to a registry with correct name and correct type information intact ...

This was all well and good however had a very annoying consequence for me as i wanted to embed some of the functionality of this system into a reusable static archive (the original system authors were only concerned with shared library scenarios). At the end of the day no code linking against this archive will make any reference to any symbols of any of these template class implementations -- so the linker will strip all these symbols away and remove all the static initialization calls -- leaving an empty plugin registry in the runtime environment of
The final binary ...

For now I work around the issue by requiring that each consumer of the static library pass linker flags to force load the whole static -- this works however makes the binaries larger than needed as each binary must include all plugins and the linker is not able to include just the ones used ... At some point I'm going to need to figure out the smallest set of changes to this registration mechanism to adapt this library to the embedded use case such that a consumer of the library will include only the plugins they use ... I haven't figured out what that looks like yet ...

This issue was kind of a mind warping ... Sometimes the more I learn about C++, the more insane it seems ...
I think Sam Altman touched on this masterfully when he wrote about how critical it is to have people tell their friends about your app/startup/whatever. Their reaction to it is the ultimate test of whether you built something anyone would give a damn about. Even in a hyperconnected world, there is still no substitute for word of mouth. Even though his advice is geared more towards full out startups, I think it applies equally well in this case. You really need to wow people with your product.

Working backwards from Sam's thesis, it seems the most logical first step would be to get your app in front of as many "real" people as possible. Show it to your friends, family, coworkers, your mailman, your mechanic, the dude sitting beside you at Starbucks. My 2 cents anyways...
I really enjoy reading Julia's blog. Not only does she have a real, infectious enthusiasm for learning; not only is the blog well written; but I also often learn a lot. Kudos.
I can't imagine btdigg can scrape the whole DHT, but I think the idea is that the traffic they see by running many "fake" nodes is proportional to the whole, because the DHT spreads all traffic around fairly equally? I'm presuming they're using a method similar to the one presented here: https://www.usenix.org/legacy/event/woot10/tech/full_papers/...
"What is a $50 investor"....

Like GoFundMe or KickStarter --or the thousand other sites that have copied their business model.

Some people use fundraising in really small amounts as a way to get early adopters or crusaders for their mission.
..and GTA San Andreas?
That game is more than 10 years old!
Firstly the Eskimos probably didnt have quite such fancy kayaks eighteen thousand years ago.

Secondly though, if you're struggling to survive in a vast empty landscape already you don't have a lot of time or motivation for ten thousand mile voyages of exploration.

Travel a hundred miles and you're really tired and you're in a different part of Alaska where you don't know where the good food and water sources are.

Keep travelling yet further and eventually you reach a place where you don't even know what food sources look like.
Yes, I can implement the fix that @bsilvereagle recommends, but consumers don't all need to be tech savy to avoid being abused. For the same reasons we have fair lending laws, we should have fair tech laws.
I haven't learned GoLang, but what I want to say here is quite general.

I regard that (class names ending in "er") as an antipattern, and have seen them again and again in Java programs. I call them "thingers". Except in simulation programs, objects should just sit there passively and have things done to them by methods. For example, rather than a parser class you should have a parse method, which belongs to a grammar class, and takes a list of tokens as its argument, and returns a parse tree.

Here, it's simpler just to have a method/function/procedure called read() which can be an method belonging to whatever classes of object you want to read from. And if you want to make something, just call new rather than have a factory class.

I'm not the only one who doesn't like thingers: see http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...

Now, before you argue that I don't grok object orientation, I'll tell you that I've added object orientation to Prolog, and to a Lisp dialect (twice). (I've also got several years of OO application programming, in Java and Lisp, behind me.) Perhaps you could call me an OO skeptic though - I can accept that.
PCG is a family of PRNGs. Any sensible member of the family will trivially pass TestU01 BigCrush. If you use a 32-bit PCG it's going to necessarily fail BigCrush.

PRNG design is an empirical science. We can implement a generator and throw it into a statistical battery. If one passes, we've got a constructive proof of goodness. Any of us can run BigCrush and verify the results. Unlike CSPRNGs, we don't need to sit around and wait for the results of cryptanalysis.
https://news.ycombinator.com/item?id=10601238
Using /dev/urandom to generate every new ID is not optimal for a few reasons:

1) It's not better than the method I suggested, but requires to use I/O for every generated ID. So without gaining anything you lose performances. In fact you could imagine /dev/urandom as a more complex form of an hash function in "counter mode". Given that for this application, cryptographic properties are not needed, but only good distribution, the two methods are identical but one is very fast and one is slower.

2) /dev/urandom in certain systems, notably OSX, at some point may block for some time, it is not guaranteed to be always able to generate a stream of random numbers. Certain operating systems may generate only a given amount of stream to /dev/urandom, starting with a given amount of entropy they have in the pool. If the seed cannot be renewed with new entropy the OS may block readers on /dev/urandom. I think this implementation does not make much sense and /dev/urandom should always provide output as long as the original seed had enough entropy, but implementations may vary, and you cannot ignore OSX.
We're a bit offtopic here :) but let me respectfully disagree.

The whole point of doing testing with rockets is to find what you don't know, validate your assumptions... What you usually don't know is when a thing will fail - and you don't want to learn that in a real mission, so you push the test article to extreme. Another reason to do tests is something which should work - and shouldn't fail - but you can't test that without actually doing a flight test.

So, in my opinion, cherry picking test flights - where things fail routinely, otherwise why testing? - doesn't show you the designed - and updated, with test data - reliability of the system.

Regarding whole stack - I meant the whole thing which lifted off and the part of which reached low Earth orbit. That stack had the pulling safety tractor rocket. But frankly, if I'd consider Apollo-13 flight, I'd assume we have the case of mission abort in a later stage of flight, after which the existing measures were taken to bring back the craft safely. So mission was aborted - just as it would be if, say, Saturn-V grossly misbehaved on 30th second of flight - and the systems worked on safe return.
I doubt there was a secret version. Any such patch has not been spotted. I've heard the story told that the patch was worn upside-down, an act which is itself an inside joke amongst US pilots. Note that TheSpaceReview created an image of this patch, and has dared affix their name. Is that a pathetic attempt to copyright something that the article itself claims was a creation of nasa?

['flight patches' mean for flight suits are held on with velcro so that they can be removed prior to flight. Affixing a patch upside down has various meanings depending on the force, much like tucking a tie into one's shirt has meaning in navies.]
Imagine living all your life surrounded by idiots (parents, teachers and superiors included), having to explain the stupidest thing in painstaking detail (and regularly being scorned as the one who doesn't get it), and of course having no palatable romantic partners.

I think this is the most accurate description I've ever seen of my pre-university life.
After a certain point, it isn't a question of valuing one thing over another, but instead a question of addiction. People who are addicted to cigarettes smoke them because their body feels the need to. Once hooked, it's _very_ difficult to force yourself to stop.
Reading the advice from this thread hurts. Has anyone here actually "gone to market" with what they're saying?

Having built and launched a successful go to market strategy here are my tips for you. Ultimately because it seems like you're bootstrapping and have limited funds since it's a side project, you want to aim for a
scalable strategy that will give you a CPI that makes sense for your monetization path (ROI).

Note: I'm not even sure you're ready to go to market so ill assume you are.

1) Influencer Marketing: Do manual reach out and negotiations or hire someone with the network/connections who can help you with this. Since you're in the fashion niche there are tons of instgram/youtube influencers that would promote your app for a fee.

2) Content distribution: Get bloggers or guest posts up about your app on sites/blogs that have massive traffic and engagement.

3) PR: If you're running this as a business then there beeds to be a need in the market for your product that you must reach out to journalists and tell...ie your story. You can use HARO as well.

4) Viral coefficient: Make sure this is engineered into your funnel otherwise you're missing out on reaching critical mass and will steuggle to acquire users sustainably.

If you have questions let me know!

Hope this helps.
That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and doing a product for Autodesk on non-networked PCs.

Delayed ACKs are a win only in certain circumstances - mostly character echo for Telnet. (When Berkeley installed delayed ACKs, they were doing a lot of Telnet from terminal concentrators in student terminal rooms to host VAX machines doing the work. For that particular situation, it made sense.) The delayed ACK timer is scaled to expected human response time. A delayed ACK is a bet that the other end will reply to what you just sent almost immediately. Except for some RPC protocols, this is unlikely. So the ACK delay mechanism loses the bet, over and over, delaying the ACK, waiting for a packet on which the ACK can be piggybacked, not getting it, and then sending the ACK, delayed. There's nothing in TCP to automatically turn this off. However, Linux (and I think Windows) now have a TCP_QUICKACK socket option. Turn that on unless you have a very unusual application.

Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload. Tinygram prevention won't let you send a second packet if you have one in flight, unless you have enough data to fill the maximum sized packet. It accumulates bytes for one round trip time, then sends everything in the queue. That's almost always what you want. If you have TCP_NODELAY set, you need to be much more aware of buffering and flushing issues.

None of this matters for bulk one-way transfers, which is most HTTP today. (I've never looked at the impact of this on the SSL handshake, where it might matter.)

Short version: set TCP_QUICKACK. If you find a case where that makes things worse, let me know.

John Nagle
Lower Back Issues
I'm a 26yr old full stack web developer and recently I've been having really terrible lower back pain from sitting too long.

I work at home and I'm considering purchasing an Aeron (right now I'm just using cheap office-max chair)

I know an Aeron chair is expensive ($1000+), but I need a comfortable chair because I work long hours.

When I'm pushing hard to finish my projects, it's not uncommon for me to get sucked deep into problem solving, lose track of time, and not take any breaks for hours on end.

Any suggestions on the best chair to buy for lower back pain?

Thanks.
Wow What an Orgasism
There is indeed a kind of overlap between the approach in the article and phage therapy, which is to clone the lytic enzymes present in the phages and use the purified products directly on bacteria (I worked on characterizing these things during my PhD). Actually there are some bacteriocins that are homologous to their phage equivalents, and so at a molecular level these two efforts are basically the same.

Further reading for the interested:
http://www.ncbi.nlm.nih.gov/pubmed/16125935
With Version 1 UUIDs you expose the MAC/IP and it may also not be desirable if you don't want your ids to be predictable (which IIRC, may have been a requirement of the original article).
Notes on Writing Makefiles
This is a general problem of leaky abstractions. If you're a top-down thinker, you're going to have a bad time some day and have a hard time figuring it out.

OTOH bottom up thinkers take much longer to become productive in an environment with novel abstractions.

Swings and roundabouts. Top down is probably better in a startup context - it's more conducive to broad and shallow generalists. Bottom up is great when you have a breakdown of abstraction through the stack, or when you need a new solution that's never been done quite the same way before.
React killed their JSX transpiler after Babel added support for JSX. Angular merely merged AtScript into TypeScript.

React had CommonJS module support from the get go. Angular1 was incredibly awkward to use with a real module system, Angular2 is only marginally better.

Ugh.
Convergence Coming for Supercomputing, Machine Learning
Yeah, I was going to post something to the same effect. Her posts (and videos) really drive into not just the how, but the WHY people should care, and her writing is lively and clear. I really love the ambition she has to learn all these things and share it with the world, and to make it inclusive for folks of all experience levels.
Some isolated groups aside, there was widespread travel and trade in the era prior to the arrival of Europeans. But it could be risky. When you depend on a migratory existence, screwing up can mean watching your family starve. Not to mention, some groups were hostile.

The Athabascans living on the Koyukuk river were supposably the last group of Alaskan natives to make contact with white people. When they met up with Russian fur traders, they already had tobacco and metal artifacts.

Of course, prior to that, people did explore south, in the course of the settlement of the Americas.
No, just botanically.

You can't make jam from tomatoes. Or at least it wouldn't be called jam. You can make jam from rhubarb, so in some sense that is a fruit.

Similarly, you can make soup out of tomatoes, but not out of rhubarb.

So, from the point of view of a cook, tomatoes can be considered vegetables and rhubarb fruit.
Innovations in antibiotics discovery using mass-production methods like the iChip have already made potentially big discoveries:
http://www.nature.com/news/promising-antibiotic-discovered-i...
Promising antibiotic discovered in microbial ‘dark matter’ (soil bacteria)
Yes, but how is the title sensationalist? I think it's quite accurate. They're borrowing money just to pay off the interest on previously borrowed money. 8 trillion Yuan just in 2015 alone. If anything, the title of the article may be understating the problem. Common sense should dictate that it's not a sustainable practice at any level.
Tomatoes are not generally considered culinary fruits, so there is, in fact, a sense of "fruit" on which tomatoes are not fruits. They are biological fruits, which is what someone who invokes a "technical" sense likely means.
This.

The backbone of all effective marketing is product. Period. Your first goal is to identify who, exactly, wants your product, and who wants it the most. You do this by getting the product in the hands of as many objective, unaffiliated users as you can -- ideally without spending too much money doing so.

Not everyone will dig it, and that's fine. If you find yourself in a situation where everyone tells you they love it, something is either ridiculously right (highly unlikely) or nobody is really, really telling you the truth.

You'll want to have a hypothesis in mind as to whom you're targeting -- start by identifying and sampling among these people. But don't be afraid to consult total randoms. The key is to seek objective feedback and observe actual usage.

Also, think of your hypothesis testing the way a scientist would. In some respects you are seeking disconfirming evidence, not confirming evidence. If you seek feedback with a conscious bias towards confirming your preconceived beliefs, you risk "leading the witness" and nudging people down the path you want them to. You also risk overcounting the positive feedback and emotionally discounting the negative feedback.

Once you believe you've found evidence of a core user group, stick to that group and overservice it. Be the absolute best solution for that group. Kill it with that group. Just be...absurdly, undeniably awesome for it. Then play around with referral hooks, mechanics, and incentives. This is how you sew the seeds of word of mouth.

A word on gauging positive user feedback: when someone really loves your product, you'll know. They will be begging you to let them know when and how they can get it. Genuinely positive feedback is usually very enthusiastic. Beware of "meh" feedback disguised as positive feedback. Remember: you are seeking awesome.
Downloading isn't a concern, as websites can already force you to download a file. <img src=...> The new risk is P2P connections that bypass HTTP settings, and perhaps uploading. (You could already upload by making a POST, so it's only in combination with P2P stuff that this is novel.)

If WebRTC prompted or forced use of the HTTP connection settings in the browser, I'd have no issue with it.
Surely it'd be cheaper and healthier for you to just set yourself a "get up, stretch, walk around for 10mins" calendar reminder every hour?
This method leaks internal info (ip/mac), and is not as collision resistant as the one I propose. imagine you have an embedded system that after a restart has the internal clock reset because of clock battery failure. Pid and thread_id are the same after every restart (or may be the same) because of the OS initialization steps which are simple and deterministic. You have your system in "reboot loop" for some reason. It reboots every few minutes. Soon or later you'll generate a repeated ID. Given the method is also more complex, why to use it?
True but it's familiarity with oneself, one's own human dimensions.
It's a new meaning for me too. I knew General Relativity before I could program.
More:
http://www.npr.org/sections/health-shots/2015/01/07/37561616...

http://www.technologyreview.com/news/533966/from-a-pile-of-d...

and I could have sworn that PBS had a segment on this research on Nova or Nova ScienceNow, but their search doesn't seem to find it.
Websites can already link to illegal content without user consent. Is this really a new threat?
While you're right that it's not a huge deal, architectural issues are not solved by putting "an entire 8088 on die for legacy compatability" unless you'd want to run the old software at very low speed. Intel solved it with lots of R&D. Their solution involves a layer that translates x86 instructions to native ops[1], plus many little hacks and improvements.

[1] http://www.realworldtech.com/nehalem/5/
What you really need to do is prioritize distribution highly as your are thinking about product ideas. Building the product and then thinking about distribution is the wrong approach.

Next, you need a good product idea. My immediate impression is this probably doesn't qualify.

But since it's built, I'd do things like see if you can get exposure through Pinterest, Facebook, Instagram etc. Try to find some trendsetters willing to use and talk about the product. Seed it to a college or high school.
Primarily it's good to understand how to these things work in the first place which is why this blog post is interesting. `/dev/urandom` on most machines works in a very similar manner to what is described here.