Ask HN: Why don't more apps use peer to peer networking? - <AUTHOR> I think my question boils down to: is there a fundamental reason apps don't use p2p networking, or is it just that there aren't any good app P2P SDKs or programming techniques out there?
(Note: by P2P in this context I mean over the Internet, not the emerging wireless "Internet of things" P2P networking stuff. That's a bit different, and has a different use case.)
Take an example: SnapChat. (Just using them as a hypothetical here.) Why didn't they architect their app to send snaps directly when possible? It would have saved them a lot on bandwidth for starters. If they wanted to also store snaps on their servers they still could have done so, but they could have saved considerably on downstream bandwidth costs by sending snaps "horizontally" between users if these users happen to be online.
Is it just that it would have been too much work development-wise, or is there a more fundamental reason companies like this pass on P2P?
Spotify used a P2P protocol but last I heard they were moving away from it. Netflix -- about as bandwidth heavy as you can get -- doesn't do it. Skype has moved away.
Why?
The only reasons I can think of are:
(1) It's hard to program and there are few good SDKs to make it easier.
(2) Some users -- enough to be meaningful -- have bandwidth caps even on wired Internet connections.
(3) Cellular data connections almost always have bandwidth caps, and so users on these networks dislike p2p apps eating their bandwidth.
Which of these is most significant? Or are there other reasons? <comment><USER3> I have worked on multiple applications that use P2P networking, and the fundamental problem is this:

Not all networks support the ability to P2P network, or, if they do, they require intervention by the user.

So you have two issues: some users will never get to use your application, and for those that could potentially, they will likely need customer support to help them configure their network correctly.

Corporate networks are the worst for this. They aren't going to change their rules for your application (yes, they might, but don't assume that starting out).

A much greater percentage of home networks _can_ support P2P networking, but your application probably needs to support STUN as well as UPNP.

Some number of home routers won't work ever, or _can_ if you configure them correctly. And that's where it gets messy. Is it enough to tell a customer to 'go figure it out', when it pertains to router configuration? You might get away it with PC gamers; but I'd argue any other segment of people will have no idea how to do it, and need some help. So now you have to try figure out the enduser's home router configuration as best you can remotely. Huge drain on customer support resources, which in a small startup, usually means the developers.

So why go P2P with all these headaches? Unless you have a really strong reason to do use P2P, like keeping latency down between peers, you don't bother.

</comment><comment><USER4> My guess is it's a combination of development complexity and (probably more importantly) firewall/router issues.

It's very hard — impossible, really — to deploy P2P technologies on a mass scale without thousands of users encountering problems with their routers & firewalls.

For mass market products, you can't get away with asking people to whitelist your app, make sure port 28777 is open for UDP, etc.

Many P2P systems have freeloader issues, which can usually be resolved/avoided/ignored on desktop systems, but when you add mobile into the equation — with its paltry bandwidth limits and sky-high overage charges — the potential for it to become a problem is much greater.

<comment><AUTHOR> Hmm... so...

(1) Developer ease of use... must be almost as easy as simply opening a 'dang socket.

(2) Must be able to fall back on non-p2p _easily_ and _transparently_ if p2p is not possible for a given customer.

(3) Must be able to set a bandwidth quota on mobile devices, or possibly fall back to non-p2p easily and transparently when on a capped cellular connection.

(4) (via another reply) Must not do constant keep alives all the time at least on smaller mobile devices like phones, which will eat battery life-- must support some kind of sleep mode with instant wake.

This being HN, I have ulterior market research motives with this ask post. I have thoughts about building something, and want to know if it's worth doing. :-)

But I think it's an interesting question in the abstract too.

<comment><USER4> I have a hunch that WebRTC is going to make P2P a much more mainstream technology. Once most people are running browsers with WebRTC support, and there are good high-level libraries available for developers, I think we'll start to see it used for all kinds of things — not just real-time video conferencing, but all kinds of information sharing and dissemination, both real-time and who-cares-about-real-time, just because WebRTC will be there, will (mostly) work, and will be (relatively) easy.

You mentioned something about saving bandwidth costs, and I admit I've had a few ideas for bootstrap startups where I've thought, "Well, I _could_ do this, but the second it became semi-popular I'd go broke and have to shut it down," and then, "If only there was a way to have the apps distribute the data P2P, so I didn't have to pay for every single user downloading from the server."

<comment><AUTHOR> Check the thread and see my other reply.

</comment></comment></comment></comment><comment><USER5> Developer time is one of the most important things to optimize. Bandwidth is really cheap by comparison.

P2P isn't completely reliable. There are many cases where you can talk to a server but you can't talk to a peer, ranging from evil firewalls to excessive layers of NAT to simple things like the target device being offline. Thus, you must code a fallback that talks to a server if you want reliability. This server fallback will work for _all_ situations, so it's necessarily easier to just use it for everything and not bother to code the P2P bit at all.

P2P is also really hard to do well. It's pretty easy to do poorly: have one device tell the other device what its IP address is and a port to connect to, then connect to it. In practice, this fails about 99% of the time because approximately all consumer internet users are behind NAT these days. So then you enter the wonderful world of NAT traversal meaning you have to deal with horrifying things like UPNP, NAT-PMP, and STUN. And this is when both sides keep the same IP address throughout the connection! Now consider when your smartphone user goes from Starbucks, where he has WiFi, to the bus, where he only has LTE, to home, where he has WiFi again.

Bandwidth is cheap. Let's say it would take Snapchat one developer-month to implement this, or about $10,000. (I'd wager this would be a strong underestimate, both in terms of time required and the cost of that time.) Amazon S3, to take a random example, charges 12 cents per GB of outgoing transfer to the internet at lower use levels. You can buy 83TB with that $10,000. If your typical Snapchat image is 1MB (they're low resolution, right?) then you'd have to P2P 83 million images before you broke even on the investment. Factor in a more realistic timeframe, a more realistic cost, and the opportunity costs of not having that developer work on something more useful, and the payoff goes up by an order of magnitude or more.

P2P does get used where it pays off well. That's either high-bandwidth stuff or low-latency stuff. WebRTC does P2P whenever it can. Apple's FaceTime does P2P when they're not disabling that functionality to placate patent trolls. Skype does (or at least did, I seem to recall some changes) P2P for audio and video. And of course nothing beats BitTorrent for sending massive amounts of data to large numbers of people. But it just doesn't pay off unless you're really sending a lot of stuff.

</comment><comment><USER6> 1) Users don't care 2) It's complex, so it costs quality developer time. Even then there's no guarantees. 3) The old school approach is cheap/easy/fast. Additionally enabled by fast/quality clouds that allow scaling relatively easily. 4) Increasing number of clients do not accept incoming connections because of IPv4/Nat or because of cellular/mobile/wan connections that don't accept incoming. 5) It's a competitive market for apps, web services, and related. Any increase in latency or increase in support calls is prohibitive. If even one and 10 people need support for port forwarding that's a deal killer. 6) in an increasingly mobile world incoming connections and anything that hogs battery (bandwidth or even just being awake) is a disadvantage. 7) there's no easy money in P2P. No monthly data plans, centralized towers, centralized servers, etc. Sure a mesh network of smartphones with millions of clients could do cool things. But where does AT&T/Verizon make money? Without AT&T/Verizon is Samsung going to make a p2p/mesh network phone if they need to sell millions to break even?

As an example skype years ago with mostly desktop/laptop clients was largely p2p (just login was centralized). With increasing numbers of tablets, WAN connections, and smartphones they switched to central servers.

So sure, you might be able to spend a man year and get an awesome, robust, and performant solution. But your competition will have spent that time actually making users happier and steal your market.

</comment><comment><USER7> It's because startups rarely have time and resources to create a solid infrastructure from the beginning. Easy and simple are preferred. The product needs to be launched and validated as fast as possible.

So by the time a product becomes successful, it's core is already using inefficient solutions. And very few companies upgrade them because the effort is not really worth it business-wise.

If we would have been driven by real solutions instead of money, then P2P would probably be king. Direct communication everywhere.

</comment><comment><USER8> Let me give you a comprehensive answer on this that goes back to first principles. I've worked on apps like SnapChat, so I am probably pretty close to an authority on why apps like that don't use p2p.

The first problem is that mobile devices are pretty much inherently asynchronous. There are apps that you would use at the same time as another person (like real-time games) but especially on cellular, lag is an issue. This pushes people into designing products that can tolerate lag measured in seconds (because that isn't shockingly bad performance on cellular networks for apps that use your standard off-the-shelf tools like REST/HTTPS/AWS for example). This produces a lot of asynchronous, or semi-asynchronous applications.

Now partly due to those product designs, and partly due to people having lives, they use these apps asynchronously. You pull out SnapChat, fire off a message, and go back to reading Reddit or whatever. Snapchat is off. There's no way to reach you.

Okay, so why don't we run SnapChat in the background? Well there are layers of reasons. The first layer is that it costs energy, and the mobile revolution is in large part possible because software and hardware developers got very aggressive about energy management. If we ran things in the background like you do on your laptop it would need to be as big as your laptop and plugged in regularly like your laptop. There are also practical problems, like announcing every time your network address changes, or even _figuring out_ when your network address changes, which is hard to do passively. I'm glossing over some networking details but there's a deep principle here that within the design of existing TCP/IP/cellular stack you can't have reliability, energy-efficiency, and decentralization. You must pick 2.

Apple, very presciently IMHO, has decided to legislate a lot of rules about background processes that I don't have time to go into here but basically they try to regulate the types of work that apps can do in the background to only the energy-efficient kind. The rules are actually pretty well-designed but they're still rules and they restrict what you can do. Android doesn't have this limitation but unless your product is Android-only you're going to comply with the iOS rules when you design a feature that communicates across platforms.

Okay, so we can't run Snapchat in the background. But what if two users happen to have it open? We can use p2p then right?

Well sure. But the user may be on a network that blocks p2p traffic. That is their network's fault, but they still e-mail you to complain, and leave bad reviews for your product, because as far as they can see "the Internet works" so it's your app's fault.

So what you do is you design a scheme that uses p2p by default and client- server as a fallback. There are actually apps that work like this. Problem here is, instead of getting support tickets about it not working, now you get support tickets about it being slow.

And there are ways to solve this, like permanently giving up on p2p after a certain numbers of failures for example. But the first experience is still pretty bad, which is what counts in mobile. And I remind you, this p2p feature is already a scheme that only works in the 0.3% of cases that users actually have the app open at the same time, and now you want to add code that disables p2p in even more cases than it's disabled already. This process continues until basically zero actual customers will ever use the feature.

And we haven't even gotten to cases like "Why didn't this message get delivered to all my devices?" because there is just zero chance that any customer, anywhere, will have all his devices turned on at the right time to receive incoming p2p connections.

Now non-messaging products like Spotify or Netflix are more plausible, but you still have to ask who wins here. Customer experience is worse, both because of connectivity problems and increasing bandwidth bills and the energy efficiency losses that comes with rebroadcasting content to other users. Developers are worse because they probably have to build _both_ client-server and p2p architecture, because p2p isn't reliable enough on its own. Support is worse because almost any issue is potentially a p2p-related issue, have you tried disabling p2p and seeing if the issue persists?

There's really no reason, certainly no compelling business case, to inflict that much pain on any mobile product I can think of. I mean, there's probably a place where p2p makes sense--we live in a big world--but in general it makes things much worse for everybody.

<comment><USER9> Short version: there's no incentive to build or support reliable _infrastructure_ for p2p, so apps won't _design_ around it.

<comment><USER3> There is an incentive for real-time audio/video/gaming applications, though: latency.

And many such applications do use P2P.

<comment><USER8> You certainly can. The thing is though that the hops surrounding the server are generally the fastest hops in the whole path. The server is sitting in a big datacenter somewhere with multiply-redundant, professionally-managed network connectivity.

Doing a direct shot from client to client would be some faster, but not much. Meanwhile there are usually optimizations that are better you could do in the same amount of time.

<comment><USER3> That's not a valid generalization.

Yes, if User A, User B, and the server are in a hub city, such as Dallas, then the difference could be small in either direction.

But if user A is in San Francisco, and user B is in San Diego... then routing through the server in Dallas is almost always going to be significantly slower.

So if latency is a concern, and you want to route through your server, you need to now cover the network with servers. That's _a big deal_.

</comment></comment></comment></comment></comment><comment><USER10> NAT.

The vast majority of end-users cannot accept incoming connections. The vast majority of end-users cannot initiate connections to each other.

The only way around that is centralization.

BitTorrent users who are behind firewalls are only participating in a subset of the network - people who _can_ receive incoming connections. That's okay because there's probably at least one who has the file you're looking for, but it wouldn't facilitate direct messaging.

Skype was centralized on Supernodes. Two users make outbound connections to a Supernode, the Supernode passes traffic between the two parties. It was (sorta) decentralized because Supernodes were sometimes just random users who could accept incoming connections. Microsoft found it more reliable and scalable to just host the servers in datacenters instead of co-opting random PCs as servers.

In our NATed, firewalled world, there is no such thing as true P2P between mainstream users.

<comment><USER11> There are a number of ways around NAT [1]. I don't know of a 100% guaranteed solution but NAT is not impenetrable.

[1]: [http://en.wikipedia.org/wiki/NAT_traversal](http://en.wikipedia.org/wiki/NAT_traversal)

</comment></comment><comment><USER12> P2P is definitely complex to develop. And on phones P2P sucks battery life due to keepalives between peers; this is one of the reasons Skype is removing P2P. P2P push notifications could help, but they'll probably never exist.

</comment><comment><USER13> 1 - <USER2>

P2P is just hard, and not that pertinent for most products. And of course there is the network issue with special ports, UDP that makes these solutions sometimes impossible to deploy in the enterprise world.

</comment><comment><USER14> It really comes down to the fact that it's hard. Creating a secure P2P network takes a lot of time, a lot of smart people, and a lot of money. Especially on mobile the design is not reasonable. However, a semi P2P network could be an option. For example, a snapchat is sent and the app attempts to send the message directly to the user. If the app is open there is no problem, but if it isn't the message gets sent tp a snapchat server and saved for later. This is a design I used for a P2P email project I worked on and it worked.

</comment><comment><USER15> There is a definitive lack of P2P SDKs, and those that exist, address a very narrow set of problems. The advent of digital currencies may provide incentives for users to prefer P2P apps. Getting paid to put your computer to work will appeal to many people.

Maidsafe is a good example, but developing for that SDK is a major undertaking. I am working on peercentrum ([https://github.com/pmarches/peercentrum- core](https://github.com/pmarches/peercentrum-core)) which may appeal to a more general developer crowd.

</comment><comment><USER16> Servers are dirt cheap, developers and customer service reps are very expensive. P2P solutions have the potential to impose high reputational costs if users start getting angry about data or battery usage, or experience connection problems. In a very few edge cases (very high bandwidth use, very low customer value) it might make sense to use P2P, but in those cases you probably don't have a real business proposition.

</comment><comment><USER17> I am surprised podcast apps don't use P2P to download media.

1) Podcasts are made available for all at the same time, and rarely downloaded after the next episode. Lots of people trying to download the same file at same time. 2) Would save publishers a lot of bandwidth. 3) Latency is not really an issue

Seems like a perfect fit.

</comment><comment><USER18> One factor I would guess is that companies want control of the data their app is sending, so they can data mine it. Easy if everything is going via a central server, and looks legitimate. P2P will specifically have to "phone home" to do this and makes the data mining element obvious.

</comment><comment><USER19> Check out maidsafe.net - those guys think that the internet should have been designed as peer-to-peer in the first place!

</comment><comment><USER20> I'd like a p2p chess app to play with my brother using our mobile phones and nothing else.

Is that even possible?

<comment><USER12> It could probably be done with AllJoyn.

<comment><AUTHOR> That's a different thing in that it's hyper local, basically people next to you. Cool but different.

</comment></comment></comment><comment><USER21> Why _would_ they?

</comment><comment><USER22> Because there's never a guarantee the app is open, especially on mobile.

If we take your Snapchat example , if one user is trying to send a message to another and their app is closed or their device is off, where does the message go ?

On the desktop you have the luxury of mostly running in the background to pick up the ping, but it's almost never the case on mobile.</comment>


How Anti-Vaccine Sentiment Took Hold in the United States - <AUTHOR> https://www.nytimes.com/2019/09/23/health/anti-vaccination-movement-us.html <comment><USER2> I think this is a predictable response to a healthcare system characterized by rent seeking and monopoly. People want to exercise greater choice and feel their autonomy is threatened when they have little diversity of options but are financially responsible nevertheless.

To be clear, I'm not antivaccine, and personally make them a priority for myself and family (although I am opposed to mandatory vaccines). I just think that the antivaccine movement, along with things like the supplement industry and recent cannabis legalization efforts are almost inevitable when people are put in a system with few real options and a lot of control. There's pushback, skepticism, and exaggerated response.

Come to think about it, it's funny that we're mystified at all by people exerting a critical eye on something, and expect them to just go along. There has to be a better way.

It's bizarre to me to expect people to unquestionably accept vaccines when their generic drugs are being tainted or poisoned, and they can't afford anything else.

</comment><comment> super-serial The US healthcare system is the only system in the world that bankrupts people for receiving medical care. We constantly hear how we're getting charged many times more than other countries for the same health services.

Is it really surprising that large segments of the population distrust the medical community? I'm actually one of those people.

Luckily I realize the difference between valid research that has over 100 years of proven effectiveness like the research behind vaccines, versus the type that's done so there can be a new ad to "ask your doctor" about on TV.

A lot of people generalize and can't tell the difference. If we want to fix that maybe we should fix the system first.</comment>


Why Ice Lake is Important – a bit-basher's perspective - <AUTHOR> https://branchfree.org/2019/05/29/why-ice-lake-is-important-a-bit-bashers-perspective/ <comment><USER2> Author here in case anyone wants detail, to throw rocks, mock my limited understanding of Galois Field arithmetic, etc.

<comment><USER3> What is the state of compiler support for these very advanced instruction sets ? Can the average developer benefit by basically adding a few compiler flags ?

Also, each new Intel platform seems to bring additional instructions but most software isn't made available in a wide range of microarchitecture-specific builds. Is there typically capability detection going on behind the scenes ?

Some of the operations described here seem so specific, that I have a hard time imagining compilers being able to spot the relevant patterns in source code that can make use of them (then again, I'm not a specialist). I guess these are explicitly coded for in Assembly ?

<comment><USER4> Using these instruction sets usually requires explicitly writing code using C language intrinsic functions, which is a reasonable compromise between transparent automatic usage in C++ and needing to write assembly. On the positive side, most compilers have full support for these intrinsics and the compiler can even do compile-time evaluation for a few of them e.g. some intrinsics are treated as 'constexpr' in C++ by the compiler, but the compiler won't automagically use them for much and is generally poor at identifying ordinary code that can be reduced to these intrinsics. So for designing algorithms that take advantage of the advanced instruction sets, you are mostly on your own. Writing C/C++ code with heavy use of intrinsics isn't hard to learn or particularly opaque, just arcane.

These instruction sets can offer very substantial speedups for code paths when applied judiciously. You do need to check the CPU capabilities at start up time for practical software, you can't assume the environment supports it even when these instructions have been around a long time. Some had very uneven implementation timelines across CPU product lines. Even for explicitly high- performance software, I invariably would get bug reports because someone tried to run it on a 10+ year old machine that did not support the instructions I was using. There are standard open source libraries for doing this feature detection using CPUID.

</comment></comment></comment><comment><USER5> > I will also admit that I'm not very interested in deep learning, floating > point or crypto

I feel like I met that one other guy in the world.

<comment><USER6> There are dozens of us ... dozens!

</comment></comment><comment><USER7> For anyone else confused by the title, this is about the upcoming Intel CPU generation.

</comment><comment><USER8> GF2P8AFFINEQB sounds a lot like MXOR from Donald Knuth's MMIX (19 years prior). Now x86 just need MOR as well. EDIT: This link may be helpful: [https://math.stackexchange.com/questions/1107839/how-is-d- kn...](https://math.stackexchange.com/questions/1107839/how-is-d-knuth-mmix- instruction-mxor-useful-for-finite-field-multiplication/1723972)

<comment><USER2> Thank you - this led to some interesting background. I could definitely have used MOR during bitwise regex (Glushkov NFA) implementation.

</comment></comment><comment><USER9> Do we know if Zen 2 is going to support AVX-512? Even if in 2x256-bit fashion... That could boost adoption as many enthusiasts will be changing platform soon.

<comment><USER10> It does not :(

</comment></comment><comment><USER10> I hope they release more information soon, like latency and throughput for all these avx512 instructions on ice lake.

No 2nd FMA really sucks, hope they add it when they do desktop-

I can't tell from the micro architecture slide if the yellow box labeled "ALU" that is found on port 0 and 5 refers to only integer ops, or if that includes float(add/mul).

</comment><comment><USER11> Food for the brain. I never thought about it before tbh</comment>


Transparent California - <AUTHOR> http://transparentcalifornia.com/ <comment><USER2> Title is ambiguous; an appropriate title would include "Salary and Pension Search Engine for CA Public employees"</comment>


The Coming Sharing Economy - <AUTHOR> https://www.helpwith.co/pages/coming-sharing-economy <comment><USER2> It seems clear that hybrid-business models will pave the way to the next economic foundation–sharing economy, collaborative economy, etc. We are in a period of technological innovation where the economic possibilities are only constrained by society's ability to effectively message and disseminate emerging value propositions.

In other words, anyone can make a potentially revolutionary marketplace (helpwith.co?), but how do you get people to care?

<comment><AUTHOR> Yeah, that's definitely the right question. Part of our argument is that people are overly cynical concerning the fact that finding the answer to such questions is an active, iterative process, rather than a stroke of individual genius.

Technically, HelpWith is in over 100 cities, but we're focussing primarily on the Pacific Northwest. This is largely because cities like Portland are already more amenable to the type of ethos that makes the success of such a sharing economy platform possible.

We're building a successful, community-based model, then we plan on scaling.

</comment></comment><comment><USER3> Interesting read.</comment>


Apple boosts chipmaking efforts with $600M Dialog Semiconductor deal - <AUTHOR> https://arstechnica.com/?p=1392551 <comment><USER2> Apple's M&A is one of the best - they scoop up companies for a lot lesser than other giants, and the acquisition impact is typically higher than at other companies.

For instance, capacitive touch & gestures like pinch to zoom that setup modern smartphones for success was an acquisition of just $50M of Fingerworks!

</comment><comment><USER3> Bad news if you use Dialog chips in your designs. Little chance they are going to keep working on those when Apple needs their own custom chips.

Its too bad they had a nice niche that nobody else really filled.</comment>


Compiling Python Code - <AUTHOR> http://effbot.org/zone/python-compile.htm <comment><USER2> This article is from 2003, and most of the external links are pointing to parked domains.

<comment><AUTHOR> I was wondering if I someone has latest link to similar resources.

<comment><USER3> I was looking for some related just yesterday and, apart from Py2EXE, found these two interesting projects:

ShedSkin: <http://shed-skin.blogspot.com/> \- A restricted Python-to-C++ compiler.

Cython: <http://cython.org/> \- A super-set of Python language for writing C extensions.

<comment><USER4> I've successfully used Cython to speed up Python code in the past(1) and a friend has used it for BCI projects.

1: runtime went from 2.5 hours to 20 minutes, but then I redesigned the algorithm, taking a few shortcuts I didnt know I could take when I wrote the first version and then runtime was down to maybe five minutes in pure python.

</comment></comment></comment></comment><comment><USER5> Getting git-cola <http://cola.tuxfamily.org/> to snow leopard users has been tricky business. OS X is kinda like gentoo, but with more portability issues ;-) (I kid, I kid!) I don't know if I should use brew, fink, macports, etc. and if I did know, would my choice affect my users too?

py2app worked on leopard but doesn't work on snow leopard anymore. That was a bummer. The only available option is to compile it all myself and provide a separate installer just for Qt and PyQt4. I haven't gotten around to doing that yet ;-) but will do so soon.

Overall that will be better than py2app because using py2app meant having 40MB .app bundles. Providing a separate installer means I can ship small ~1MB installers that contain just cola and nothing else.

That said, I've never been satisfied with packaging on OS X. OTOH, maybe everyone has settled on something (brew?) and I haven't gotten the memo.

<comment><USER6> Having a packaging system at the core of the OS distribution has some great benefits. When a new Mac OS X comes out, don't you just hate having to wait for DVDs from Apple or making a trip to the Apple store? A packaging system would allow you to do a live upgrade as soon as the new version is out. (Note: I am fully aware that a package system is not necessary for this but think it is the most elegant solution for this problem). The other matter is of course software installation and upgrades. There is no reason in today's day and age for you to remember that Photoshop comes from adobe.com or wait for their DVDs by mail. Most applications can quit adding new version checkers too: why bother when the package system does it for you? Lastly, the package manager could also handle payments. Why bother building your own solution when a central one exists (or would exist)?

<comment><USER7> Probably because if I'm adobe, I make money off people buying new versions of my software and I don't want to rely on some packaging system I don't have full control over to push people to upgrade. I want to be able to upsell the hell out of my users right from within my app.</comment></comment></comment>


Ask HN: Do you use Facebook as your primary e-mail service? - <AUTHOR>

Do you currently use facebook as your primary e-mail service provider, or would you use it in the future if they improve their messaging app? Why or why not ?<p>Thanks <comment><USER2> No and I never will. Facebook cannot do anything to change that because I simply don't trust Facebook enough to use their messaging system as my primary email system.

Having said that, I also feel that Facebook messaging is greatly inferior to real email, especially modern clients like gmail. Besides the lack of bcc and a terrible interface (certainly in comparison to eg, gmail), in the past year, Facebook has failed to deliver/lost messages from people I know on multiple occasions.

</comment><comment><USER3> I don't trust any online service provider completely, so I have always been prepared for everything I have ever typed into a computer to be made public. That said, I trust fb much less than most email providers as far as keeping things private goes.

So no, I don't use fb as my primary email provider, and there is really nothing fb could do to change that.

</comment><comment><USER4> If there would be a way that email providers would resend my emails to my FB account, that would be nice. Currently I'm staying with my old email since most of my contacts are there. For me its like this, FB mail for family and friends and email for business.</comment>


PHP Performance Tips - <AUTHOR> https://developers.google.com//speed/articles/optimizing-php

<comment><USER2> Neat trick with the insert, but shouldn't one really be using PDO and at least making a pretense of using bind variables?

</comment><comment><USER3> This is garbage.</comment>


Show HN: Yakutils: Yet another collection of Python 3 helper functions - <AUTHOR> https://github.com/nficano/yakutils <comment><USER2> Friendly advice: in your README.md you should use some hash function that hasn't been hacked. I am a fan of sha384() and sha3_384(). The sha384() variant is better than most of the SHA-2 variants because it is resistant to common-prefix attacks.

<comment><AUTHOR> Added both of them, thanks again!</comment></comment>


Using Deep Learning to Reconstruct High-Resolution Audio - <AUTHOR> https://blog.insightdatascience.com/using-deep-learning-to-reconstruct-high-resolution-audio-29deee8b7ccd <comment><USER2> I hesitate to even post this, but I listened to the audio examples and it seems like this project was not yet a success. I'm not trying to be a jerk or snarky, but the reconstructed audio sounded terrible.

<comment><USER3> I have to agree. There's certainly more high-frequency content, but it seems mostly like noise, with only a vague amplitude correlation to the existing audio.

I'd be curious to see if any better results could be obtained by applying a similar technique in the frequency domain.

<comment><USER4> hey, author here

Thanks for the feedback.

"applying a similar technique in the frequency domain", "Maybe training an image reconstructor on the short term spectrogram" \- This is what I originally thought to do. However, this approach suffers from information loss whenever you transform from the frequency domain back to the time domain. Since the goal was super-resolution in the time domain, working in the time domain is more sensible.

<comment><USER5> Mathematically, the DFT is invertable, ie lossless, but practically there will be a bit of loss due to the finite precision of float point numbers. Even though it isn't lossless, the amount of loss should be miniscule as compared to the 16KHz->2KHz loss you are trying to overcome.

<comment><USER6> The problem with the DFT is not whether it's lossless or not, it's that it may not be the best feature representation for a given task.

Both the DFT and the proposed model apply convolutions to the input, but in the former case, these are fixed, while in the latter, they are learned.

This is similar to how we don't use hard-coded features like SIFT or wavelets, or Gabor filters when we do image classification with a CNN.

</comment></comment></comment></comment></comment><comment><USER6> I'm one of the authors of the paper that proposes the deep learning model implemented in the blog post, and I would recommend training on a different dataset, such as VCTK (freely available, and what we used in our paper).

Super-resolution methods are very sensitive to the choice of training data. They will overfit seemingly insignificant properties of the training set, such as the type of low-pass filter you are using, or the acoustic conditions under which the recordings were made (e.g. distance to the microphone when recording a speaker).

To capture all the variations present in the TED talks dataset, you would need a very large model and probably train it for >10 epochs. The VCTK dataset is better in this regard.

For comparison, here are our samples: kuleshov.github.io/audio-super-res/

I'm going to try to release the code over the weekend.

<comment><USER4> Thanks for commenting and the suggestion!

Indeed, the TED dataset has a lot of variability in terms of audio quality, etc. which, as you mentioned, with just 10 epochs of training is difficult to capture. I did try a larger network (up to 11 downsampling layers), but this proved even more time consuming to train (as expected). Thus, I split the difference and went with a network similar to yours but was trainable over a four-day period (10 epochs).

</comment></comment><comment><USER7> I'm interested in seeing how computationally efficient this method turns out to be and how well it generalizes to other audio data and perhaps other signals as well. Going on a hunch by the model, I think there are some more efficient methods to do bandwidth extension on audio samples with better quality results, but it is great to see more deep learning people take an interest in this domain. I do believe that deep learning can have tremendous impact in DSP and compression.

(Disclaimer: I developed a somewhat similar method earlier this year applied in audio compression, yet to be published)

<comment><USER8> Thanks for mentioning. Any links to your (or relevant) work?

</comment></comment><comment><USER9> While something like this is bound to fail for most music of any complexity (e.g. a singing voice), I've often wondered if this would be highly successful on, say, old solo piano recordings, where the possibilities of the instrument are extremely well-defined and limited.

</comment><comment><USER8> Thanks for sharing. The possibilities for this kind of technology are endless. Maybe one day we'll start having crystal clear conversations over telephone :)

</comment><comment><USER10> I am a little curious as to how this factors into fundamental information theory.

In my mind, you are simply taking a 0-2khz signal and combining it with an entirely different 0-8khz signal that is generated (arbitrarily IMO) based on the band-limited original data. I can see the argument for having a library of samples as additional, common information (think many compressor algorithms), but it is still going to be an approximation (lossy).

"The loss function used was the mean-squared error between the output waveform and the original, high-resolution waveform." \- This confuses me as a performance metric when dealing with audio waveforms.

I think a good question might be - "What would be better criteria for evaluating the Q (quality) of this system?"

THD between original and output averaged over the duration of the waveforms? Subjective evaluations (w/ man in the middle training)? etc...

</comment><comment><USER11> The title is good. The performance is limited and number of examples is not enough to make any useful conclusion.</comment>


A slight twist on MVP - <AUTHOR>

I came up with a system that I like to use to test ideas. It's similar to MVP but a bit more practical IMO.
After I come up with a product idea, I work on the brochure that I'll actually send to potential customers. This gets me  to list the main selling points early. But being a sales document, it typically puffs up the product and lists everything that is cool and that I think will add value, so its a more a VP than a MVP.
To make this system work I have to decide what features need to be built BEFORE I feel comfortable sending out the brochure. This forces me to decide what needs to be done before I can approach the customer. Say for example I'm creating a service which helps companies attract interns by listing their profile on an online directory of companies who offer internships. My brochure might mention that they will get a detailed profile page with their logo and a contact form. I can easily send the brochure on the basis that the website is launching in two months time. So the website at this point is not a MVP. However, if I list as a selling point that I have a readership of 20'000 readers per month, and if I consider this selling point to be so important that I don't think it's worth sending the brochure until I have this, then I a have the first element of the MVP - to get a readership of 20'000.
This means that I probably do need the website as an MVP so that I can get the readers, but it gives me a bit of a purpose now when launching the website. I'm not launching it to impress companies yet, I simply want the readers. Then I can send out the brochure even if the important features are not built yet.
So the creation of the brochure forces me to decide what elements are crucial right now, and which elements are crucial for phase 2. It gets me in front of customers testing my concept in the shortest possible time. <comment><USER2> I generally like your insight. The example seems to contradict your idea though—getting a readership of 20k is often much more difficult than getting paying customers from an MVP.

For the brochure, I would leave out specific metrics and data based results and instead keep the benefits high-level with tangible results.

If the brochure is merely an internal tool to help one focus on the important next steps, ignore above advice.

</comment><comment><USER3> > I think will add value, so its a more a VP than a MVP. >To make this system > work I have to decide what features need to be built BEFORE I feel > comfortable sending out the brochure. >I can easily send the brochure on the > basis that the website is launching in two months time

This is backwards of what is taught _The Startup Owner 's Manual_. You should "get out of the building" and speak with a lot of customers and really learn about their hair-on-fire problems first. Preferably ten per day. Additionally you should be iterating as fast as possible while you search for that MVP--the two months without a release is too long. Remember you're not going for version ∞ you're going for alpha-alpha-0.000001 release that tests a hypothesis.

</comment><comment><USER4> Creating marketing materials first clarifies a bunch of important things around your business: who your audience is, what your model is, how are you going to reach them. It also gets you speaking your customer's language early. All good things.

I tend to go this way too. In place of a speculative pre-startup business plan (though it grows into that, naturally, I find), this has a lot of the same benefits.

The downside is that I've produced a lot of vapourware, and have been in the position that I've conditioned potential customers to be disappointed. It isn't always easy to see what is feasible, and this can easily lead to over- promising and under-delivering.

If you can walk that fine line, it is an okay approach, I think.

</comment><comment><USER5> That in nutshell is what the LEAN methodology is all about.

<comment><AUTHOR> I know, but I always I always felt that LEAN and MVP thinking left me with more question than answers. This approach is probably not different, but I feel it a slightly more intuitive way of looking at it for me, and it helps me gain a bit of certainty about how to approach it.

</comment></comment><comment><USER6> I found it interesting that PG said in one of his interviews that when he's considering a pitch, he tries to visualize how a journalist could write an article about the pitch in a compelling way. Same idea.</comment>


Ruby's rmagick Gem looking for a maintainer - <AUTHOR> https://github.com/rmagick/rmagick/blob/master/README

<comment><USER2> I've never really liked the term "maintainer" sort of implies to me that the role is going to be monotonous patching, fire fighting and bug fixing rather than that _and_ influencing the product's direction with the design and implementation of new features. I think "lead developer" would be a better phrase.

<comment><USER3> Lead developer implies a lot more work. I'm sure they'd be happy to get a lead developer, but at minimum they need someone to just let the patches flow, dig through bug reports, and put out releases at the right time.

</comment></comment><comment><USER4> Slightly off topic: for quick & common image manipulation stuff, there's also mini_magick: <http://github.com/probablycorey/mini_magick>

<comment><USER5> IMHO, there's a huge difference between calling a C library directly and shelling out to an external process.

mini_magick uses Subexec which in turn causes a fork and exec and might, depending on how ruby's backtick operator work, also start a shell which in turn does another exec for the specific ImageMagick binary.

The process startup time alone is a significant overhead and so is the additional memory usage.

In the old days, when I was maintaining a mail server for a free web mail service, I remember the lengths I went through to prevent my MTA from forking for mail delivery due to the huge cost of launching another process.

<comment><USER6> I use RMagick for a rails based image repository, and I have to shell out to run the RMagick code because of memory problems. When I used to keep it all in the rails process, those guys would get up to the 2-3G range over the course of a couple of days.

I'll have to check out minimagick, it might be cleaner than what I am doing now.

<comment><AUTHOR> Have you tried manually calling GC.start with rmagick

<comment><USER6> In this particular application, I have to inspect PDF and TIFF files that might have hundreds of pages or frames. These files can be over 100MB easily. Running those through RMagick makes the process blow up to enormous sizes. Even if the memory gets garbage collected, Solaris doesn't really release it.

Its just safer to keep it in a different process.

</comment></comment></comment></comment></comment><comment><USER7> Yep, could someone take this over? And, also fix all the memory leaks while you're at it, thanks! ([http://www.google.com/search?sourceid=chrome&ie=UTF-8...](http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=rmagick+leak))

<comment><USER5> What kind of an attitude is this? If you care so much about the memory leaks, fix them yourself. It's open source after all.

Requesting bugs fixed this way is bad in a normal situation, but doing so as an answer to a call for help to keep the project moving forward is disgraceful.</comment></comment>


Ask HN: How do you deal with interview burnout, as an interviewer? - <AUTHOR> When I have to conduct 6-7 tech interviews a week, with sometimes 3 interviews a day, I am feeling more burnout than with other work duties. I also feel that I am wasting time asking the same questions all the time. Sometime I try to see this as a social experiment, to see how 100 people answer the same question or coding problem, but not much more than that. How do you "grow" or "learn" better while interviewing? <comment><USER2> First, remember that you're doing an incredibly valuable service for your team. The time spent finding and vetting new people will have an impact larger than most other direct contributions. Your team thanks you (or should!)

Second, remember that asking the same questions is the _only_ useful way to get a read on people. Without properly-calibrated questions, you have no basis to know whether a particular question is good or bad.

Third, try to improve your "read":

* For "soft interview" questions, instead of asking questions and recording the responses, look for specific _truths_ that you want to discover. Example: "Is this person a jerk?" You might be able to uncover this with one question or it might take several to dig in deeper. Choose calibrated questions from a pool as you go through the conversation and focus on discovering the questions which give the best signal. Try out different wording of the same basic question and see if you get different responses. Become a student of human nature... if a fellow interviewer notices something you didn't, ask yourself why and try to improve.

* For "coding challenge" interviews, focus on growing your ability to coax the best possible performance out of your candidate. Are they nervous? Learn ways to set them at ease. Brain freeze? Try to find the best way to get them un-stuck without giving away the solution. Your goal is to answer the question "Is this person competent?" as quickly and accurately as possible, ideally with a read on seniority level, _while ensuring that the candidate feels successful._ Even a clear No Hire candidate should walk away thinking that they are ok (as a person, if not in their skill level), you are ok, your company is fantastic, and they wish they could work there.

Fourth, give yourself a break. Understand that 3 interviews / day is a LOT. The context is artificial, and you're multitasking the entire time... asking questions, listening to responses, evaluating, guiding, recording, vetting, selling. I personally find it difficult to do more than 1-2 per day. Hopefully this situation is temporary. Don't be afraid to set boundaries and call in help if you can.

<comment><USER3> I've been the interviewee for 3 interviews in a day. It is just as exhausting to hear the same questions all day. It's even higher stakes on this side since it's my livelihood on the line.

</comment></comment><comment><USER4> Some suggestions:

1\. Raise the bar for previous step in the process. How many candidates are you rejecting? Is there a common thread between rejected candidates that can be identified earlier without a developer (e.g. phone screen with HR, automated FooBar test)?

2\. Spread the load. Train other people to interview.

3\. Align on hiring goals. Do you need to be interviewing this much, how many open positions are left?

</comment><comment><USER5> I used to do it a lot at a FAANG and another time for an agency, and 1 per week was often. I had a track record of good hires apparently and they still only asked me to do it once a week at most. So I think you're doing it far too often.

As for advice on how to improve it-- my best advice is to see it as talking shop with a fellow coder. Let your guard down, discuss areas you both overlap. At least half the time I would need to be extremely patient while they attempted to contribute, but it's what you do as an interviewer to attempt to coax out the best in a candidate, similar to what _ah said in their response. Sometimes they come through sometimes not, which is the point of the interview of course! Good luck, and have fun meeting some new people. I've kept in touch with some, have learned a lot from others, and seen some around the office, I always enjoyed that aspect of it as well.</comment>


Command line tools for the novice - <AUTHOR> http://andymatthews.net/read/2012/07/24/Command-line-tools-for-the-novice <comment><USER2> I knew before I even clicked on this article, that something inside was going to cause me nerd rage; it's almost always the case when I read these _Baby's first UNIX_ type articles. I thought this one might be different when I saw Andy's formidable neck beard, and for the most part it was decent but then I saw it.

 _..plus Ack is 4 or 5 times faster than grep._

Ack is implemented in Perl, which has a full featured regex engine, but is not generally known for being super fast. It's going up against GNU grep, which is a highly tuned regex engine, which is very fast. The ack guys make the argument that ack is faster because it doesn't search stuff you, the developer, don't care about, which in my estimation is horseshit. Try it yourself, I threw a regex at my email spool from the 90s which is about 128M. I made sure it was in disk cache first and then did:

        chunky:~$ time egrep -c -i '(d|m|j)ingle' RMAIL
        23

        real    0m3.129s
        user    0m3.075s
        sys     0m0.051s

        chunky:~$ time ack -c -i '(d|m|j)ingle' RMAIL
        RMAIL:23

        real    0m26.208s
        user    0m26.060s
        sys     0m0.121s

<comment><USER3> Yeah, I don't like it when people spout speed comparisons without backing it up either.

A lot of people do want/need PCRE, which ack relieves the pain point for.

<comment><USER2> GNU grep also supports PCRE.

        chunky:~$ otool -L /usr/bin/grep | grep pcre; grep --help | grep perl
          /usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
          -P, --perl-regexp         PATTERN is a Perl regular expression

Many users choose ack over grep for the same reason they choose htop over top, tmux over screen, zsh over bash, and postgres over mysql -- the perception that one is significantly better than the other. This advocacy often comes from folks whose use and understanding of either tool is superficial at best.

<comment><USER4> I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files.

Once the standard commands are learnt then by all means use ack if you understand the trade-offs and can fall back to the normal way when on another system or when ack's insufficient.

<comment><USER5> How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns?

As described here ( <http://blog.sanctum.geek.nz/default-grep-options/> ), you could use GREP_OPTIONS, but then you run into the problems here ( <http://brainstorm.ubuntu.com/idea/24141/> ) -- scripts that use grep without clearing GREP_OPTIONS will fail.

Do you have an alias? Or another script that wraps grep?

<comment><USER2>
        find . -type f -name \*.[ch] | grep -v \\.git | xargs grep something

Normally my directories aren't going to have .bzr, .git, .hg, and .svn in the same directory tree, but if they did it wouldn't be that much harder.

        alias nocrap="egrep -v \\.\(git\|bzr\|hg\|svn\)"
        find . -type f -name \*.[ch]| nocrap | xargs grep whatever

This is how I do it because I'm lazy. I suppose I could tell find to exclude directories so it wouldn't have to recurse into them, but the list of directories and files in my source tree is almost always in buffer cache anyway, so I never really worry about it.

<comment><USER4> You might want to consider using single quotes to protect your globs and regexps more rather than backslashes. \✳.[ch] will match the ./✳.c that may have been accidentally created by an earlier error, then find will only look for a file called precisely ✳.c and nothing else. '✳.[ch]' or \✳.\\[ch] is what's meant.

(Edited to use ✳ to workaround unescapable mark-up.)

<comment><USER2> Good point, thanks!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> > In Grep grep -R 'some term' * , in Ack ack 'some term'. The -R tells grep to > search through all directories and subdirectories while the * tells it what > types of files.

No, that's not how it works with grep. The shell is expanding the glob * to all the things in the current directory that don't start with a dot and that's what grep sees. It then reads each of them in turn or if they're a directory it descends into them recursively; the * plays no further part in the descent.

<comment><USER6> I was under the impression that * expanded to all things not starting with a dot in _all_ directories-- or better: in each directory that -R dictates. I understand that "* tells it what types of files," isn't correct, but I don't understand what you mean by "plays no further part in the descent."

<comment><USER7> just run echo * in your directory. That's the same argument grep will get(instead of the * ) when you pass it * .

grep will run through all those files, if any, and recurse through all the directories, if any. grep recursing down a directory will process all the files/subdirs in that directory. (which includes . files).

If the shell can't expand the * , grep will receive a literal * and try to open a file/directory named * .

<comment><USER4> Personally, I `shopt -s failglob' in my .bashrc so any glob that fails to expand is treated as an error by the shell and the command never gets started. I then quote all special globbing characters that I intend to pass to the command as it avoids the sometimes hard to spot errors where a glob expanded unintentionally and the command didn't see the wildcards. Relying on non- matching globbing to reach the command will bite one day.

</comment></comment></comment></comment><comment><USER8> I've wanted to try zsh for a long time now, but I worry about the mental context switching I'll have to do when developing locally and then ssh'ing into another server to perform other tasks (servers, I should add, where I can't install zsh).

Is anyone in a similar situation? If you switched, was it worth it?

<comment><USER9> I switched cold turkey from bash to zsh a few months ago, and going back to bash on servers hasn't been a problem. In my experience, if you've used bash for a long time you don't forget it.

Minor tip - you can use the same .aliases file for both shells, I just source it in .bashrc and .zshrc on my dev machine. So if I ever need to switch to bash for some reason, my most used aliases are still available.

If you switch, don't forget oh-my-zsh [1].

1\. <https://github.com/robbyrussell/oh-my-zsh>

<comment><USER10> I'm actually not very taken with oh-my-zsh. It seems to add a layer of complexity while not really adding anything you couldn't just paste into your .zshrc. If it eliminated tinkering overhead that would be one thing, but in my experience it just gave me a new layer of software that needed tinkering.

<comment><USER3> It's along similar lines to copying someone else's rc file willy hilly, without understanding what you're getting. Extra layer of quirks and features that you need to figure out, on top of the already existing layer.

</comment></comment></comment></comment><comment><USER11> Grey text on grey background: <http://contrastrebellion.com/>

<comment><USER12> Contrast rebellion refers to _W3C's Web Content Accessibility Guidelines_ , which specify a contrast ratio of at least 4.5. Just for fun, I plugged in the numbers, the site has a contrast ratio of about 4.9.

W3C: [http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio- contr...](http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast- contrast.html)

<comment><USER11> It's not nearly enough for my liking.

I'll take a look when I've got a few more moments to see where various of the W3C's recommendation levels fall on my own assessment of readability.

Speaking as a 40-something with decent vision, the site isn't impossible to read, but it's most definitely annoying. For someone with compromised or old eyes, it would be much worse.

<comment><USER4> I agree, annoying, and I didn't realise many others thought the same. Thanks for the link, I've tried to spread the word. [https://plus.google.com/115649437518703495227/posts/iWtSJhR8...](https://plus.google.com/115649437518703495227/posts/iWtSJhR8QpA)

</comment></comment></comment></comment><comment><AUTHOR> I'd love to hear other tools that you guys are using for your daily workflow.

<comment><USER13> This was a good list for the intermediate command line user looking to customize. For the absolute newbie I'd reduce it down to git/hg, ssh, grep/ack and curl.

For crazy power users, I'm a huge fan of vim+tmux+zsh combo as described in <http://www.drbunsen.org/text-triumvirate.html>

<comment><AUTHOR> That's a good list. I considered including Git but that could be an entire article by itself. I've looked at TMux but I just don't I'd use it.

<comment><USER14> What's the difference between Tmux and iTerm2?

<comment><USER15> tmux is a CLI terminal multiplexer. As an interactive CLI program, you need a shell to use it. To run such a shell, you need a terminal emulator. iTerm2 is a Mac OS X only GUI terminal emulator.

You can run tmux in iTerm2.

</comment></comment></comment></comment></comment><comment><USER16> Tools similar to z:

1\. [Autojump](<https://github.com/joelthelion/autojump>), first implementation and what z was based on, written in python. Functionality similar to z.

2\. [Fasd](<https://github.com/clvv/fasd>), feature-rich fork of z, support for files, support for more shells and platforms (BSDs, Android).

</comment><comment><USER17> tmux - Without a doubt, the biggest upgrade to my workflow in years. If you aren't using tmux (or at least screen), you are doing yourself a big disservice.

Also, I keep seeing iTerm2 get mention. You mentioned split panes and what not, which are not critical when I have that with tmux (as well as the tabs). And while before Lion, Terminal's color support was weak, that's changed. So, I really wonder what the big reason for using iTerm2 is over Terminal?

<comment><USER18> What's the benefit from tmux? Why is it better than just using multiple windows?

<comment><USER17> Because I can shut down my computer, move to another one, and pick up right where I left off. This means even if I leave a process running, it doesn't stop.

tmux is like screen, only it has more features.

Which is really why I asked. What does iTerm2 offer that I can't get from tmux and current terminal? People always refer to iTerms ability to do multiple windows/tabs. For me, this is useless if it's just available client side.

There is an amazing amount of freedom being able to just shut down, move to another computer, and be able to pick up exactly where I left off.

<comment><USER18> So you have to install tmux on the server?

</comment></comment></comment></comment><comment><USER19> So, first (and most obvious) point of interest. Your function "server" will not work. It contains "python -m SImpleHTTPServer .." .. Notice the typo? It should be SimpleHTTPServer. In addition, that other fluff around it is unneeded in general. Just "python -m SimpleHTTPServer $port" is almost always "good enough", though the SimpleHTTPServer module contains severe bugs. Secondly, your link right above that snipped to Paul Irish contains an href="" which, obviously, links it to your own page. It makes it seem like you're trying to take credit for his work. This is all sloppy and bad form.

Honestly, anyone who puts code into a blog post without even bothering to RUN IT THEMSELVES first should get out of the business of writing even slightly technical posts. Feel free to review food without tasting it first instead; at least then it's subjective so you can't be wrong. Here, the "/usr/bin/python: No module named SImpleHTTPServer" you'd get if you had arsed yourself to actually check your code to be valid easily clues the reader into your carelessness.

In addition to all that, there's the audacity of posting a post for the "novice" to hacker news when the post is clearly neither relevant for any hacker who has performed any real work or has any real intelligence (they would already know all the mentioned tools) and neither is news for all the tools mentioned are fairly old and well known. You might as well just call us all stupid and dilute the front page further with crap.

<comment><AUTHOR> Citnoven...

I appreciate you taking the time not only to read the post, but to offer your opinion and corrections to my article. I've updated those two mistakes you pointed out.

As I understand it, SimpleHTTPServer offers basic functionality to the user, which is all I use it for...a quick way to view pages using AJAX requests. I attempted to use http.server instead, but as I'm not running Python 3.0 I'm not able to use that option. Since Lion ships with Python 2.7, and many people are using that OS, I felt safe leaving the reference in place.

I do run the server function myself, many times a day in fact, but I made the mistake of typing it in manually rather than copying and pasting from my .zshrc file.

This post isn't intended for hackers, thus the title "...for the novice". The comments I've received about the article thus far, most likely from people not as advanced as yourself, have been positive and appreciative for the information. I'd love to hear some of the tools that improve your workflow daily...would you care to share them?</comment></comment>


Patent Troll: Anyone Using WiFi Infringes; Won't Sue Individuals 'At This Stage' - <AUTHOR> http://www.techdirt.com/blog/wireless/articles/20111001/00365416161/patent-troll-says-anyone-using-wifi-infringes-wont-sue-individuals-this-stage.shtml <comment><USER2> Hams have been doing packet radio since the 70's in earnest and it's been around far longer.

<http://en.wikipedia.org/wiki/Packet_radio>

There is clearly prior art. When you make this big a nuisance of yourself, clearly exploiting the system at society's expense, you should be permanently disbarred. You are a clear and present danger to the continued operation of the justice system.

Edit: Might a flood of complaints to the bar association do some good here?

<comment><USER3> Say what you will about the trolls; these guys have it figured out. They're targeting people with enough cash to make it go away, but not enough to mount a proper defence. Prior art doesn't enter the picture, as the trolls' targets are unlikely to retain counsel. When it costs as much to retain a lawyer as it does to make the issue go away, it's perfectly rational for the small business owner to pay up and move on. Tragedy of the commons at its finest. It's cynical, reprehensible, and evil, but it's a pretty solid business model.

<comment><USER4> An acquaintance of mine goes by bars, small stores and coffee shops in his town. He tells them that he knows the neighbourhood pretty well, and that for the low, low fee of $400 a month, he can make sure that their store doesn't burn down or get trashed. It's cynical, reprehensible, and evil, but it's a pretty solid business model.

<comment><USER3> Nobody's saying it isn't a protection racket, just that it makes more sense for individual business owners to pay the extortion than to tangle with the mob, even if the net result is everyone having to pay extortion to a powerful mafia.

</comment></comment></comment></comment><comment><USER5> The book "Against Intellectual Monopoly" is highly recommended reading for the question of patents (and other intellectual property). The authors make a mostly empirical survey of the effects of intellectual property laws and of their absence in a wide range of industries, and conclude that their effect is a _stifling_ rather than an encouragement of innovation. I think it's especially appropriate because, while my own opinion on the issue comes from moral reasoning (and it's generally frustrating to try to argue that side), this book presents a wealth of stories and statistics that are just plain interesting to anyone who cares about the issue.

<http://www.dklevine.com/papers/imbookfinalall.pdf>

<comment><USER6> Intellectual property and patents are not the problem, the problem is the broken system around them that allows these types of abuses.

<comment><USER7> Nope. The problem is granting monopolies and expecting to encourage growth. It's nonsensical.

Even if our courts were up to it, and we see time and hand again that they are not, you simply cannot consistently enforce incoherent laws.

All IP laws other than trademark are harmful to society and the economy and need to be abolished.

<comment><USER8> You think that if I were to write a song and post a recording of it on YouTube, then it would be perfectly acceptable for anyone, from the grandmother down the street to the ultra-mega business in the big city, to take my lyrics and melody and make mounds of money from it without compensating me in the least?

<comment><USER7> Absolutely. You got your compensation already when you learned about music from everyone else. And even if not, it's just morally wrong and nigh impossible to contain ideas.

How do you think the ultra-mega-corp is going to get unreasonably huge without monopoly control of creation or distribution though? And with tiny profit margins because their competitors can just copy them.

I also don't think you should get government help in keeping secret the method you use to do anything. It's possible to look at you and see what you're doing - if you do it where people can see you they'll just naturally be able to copy you. We'd have to lobotomize them or set up some ridiculous bureau of ideas to check everything for originality. Both nonsensical. A society can't afford to handicap its creators.

</comment></comment></comment></comment></comment><comment><USER9> Leeches. Someone should destroy these folks. Legally and peacefully, of course. But they must be destroyed.

<comment><USER10> I'd honestly prefer someone did it with a MOAB at this point.

<comment><USER11> I'm currently finding myself question my own disapproval of capital punishment. Every single one of the board members of this company could be put to an incredibly painful death by lethal injection and I just might bake a cake.

<comment><USER12> You know that death by lethal injection is actually not painful? Not that I support your hyperbole (if it is hyperbole), just clarifying the facts.

<comment><USER13> It is meant to be a bit painful in all circumstances. It isn't a pleasant way to die, but it doesn't look all that bad to watch, which is why it is used. Pain and trauma free measures like nitrogen asphyxiation aren't used for that reason; pro-death penalty advocates want to keep it painful.

</comment></comment></comment></comment></comment><comment><USER14> I really hope they do start suing individuals. Congressmen, and judges specifically.

<comment><USER15> Patent trolls may be evil, but they're not stupid. The best we can hope for is for them to sue a close friend of a congressman or judge.

<comment><USER16> Maybe not stupid, but I think their hubris is steadily growing.

At some point a patent troll is going to fly too high and set fire to the entire business model.

<comment><USER17> I wonder if a possible defense would be to intentionally trigger some political response via some patent trolling of your own.

<comment><USER18> Dang, this is a REALLY good idea. Get a whole slew of companies to combine patents and start suing "influential" people. Call it lobbying with teeth. The EFF could be the "troll" and could take the extras as contributions.

</comment></comment></comment></comment></comment><comment><USER19> This is very nice!

Politicians will only solve a problem after it becomes a calamity. If the problem gets bad enough, they might start paying attention.

<comment><USER20> Politicians created the problem by creating IP laws. If they "solve" it, they will undoubtedly just introduce some new problem.

<comment><USER21> That's a really cynical view, isn't it? Implying that the people, through their democratically elected governments, can't ever improve upon things that have come before.

<comment><USER22> Cynicism is rarely proven wrong in cases like this.

<comment><USER23> The cynic can only take pleasure in saying "I told you so," but can never take credit for any improvement, which does occasionally happen against all odds.

</comment></comment></comment></comment></comment><comment><USER24> This is actually a very good development. This will help that even general public start understanding "patent troll" problem which, in turn, will get some ears in in Washington.

I hope that more and more opportunistic lawyers join the "patent troll" bandwagon. Eventually, some of them will not say "wont sue individuals" because they will understand that changes in IP laws are going to happen soon: make money now or never (very similar to what was happening just before the housing crash of 2008). Then the politicians will act. Hopefully, giving bailouts and not doing reforms will not work for this issue.

Is there anything we can do to speed up this process?

<comment><USER25> Of course - only sue politicians, the media and anyone else with political influence. Give them 2 options:

1\. Pay - where all proceeds will be used to acquire more frivolous patents and lawyers to sue them again

2\. Change the law to ban all software patents

</comment></comment><comment><USER14> Original article: [http://patentexaminer.org/2011/09/innovatios-infringement- su...](http://patentexaminer.org/2011/09/innovatios-infringement-suit-rampage- expands-to-corporate-hotels/)

</comment><comment><USER26> It sounds like they're going after small business owners individually, so not necessarily "any old joe." Still, this gives me hope given how hot small businesses are in the current political climate. Perhaps targeting one or two of the wrong (read: noisy and politically-connected) owners will result in an outcome at least slightly positive for patent reform?

</comment><comment><USER27> Do the descendants of Joseph Guillotin still hold the patent on his invention? I fancy a scenario unfolding in today's environment that might vastly enrich his heirs.

</comment><comment><USER28> > While its initial lawsuits against coffee shops and restaurants did focus on > the central corporations, with the hotels, Innovatio appears to be focusing > on individual franchisees. Yes, the small businesses who own individual > hotels and probably have no idea how to deal with a patent infringement > lawsuit -- all because they dared to offer WiFi somewhere in their hotels. > To make it "easy" of course, Innovatio's lawyers will let them settle for > between $2,300 and $5,000. In almost every case, that's going to be cheaper > than hiring a lawyer to just get started dealing with this -- which I'm sure > is exactly what Innovatio intends.

Isn't this precisely the sort of thing that can be forwarded to corporate? Someone who owns a Motel 6 would surely expect the corporation to help them with this, no?

<comment><USER29> Ya but your local B&B can't deal with this. They need to mobilize _now_ and pool together to buy good legal defense.

<comment><USER28> I sort of imagine that the large chains would smack these trolls down pretty hard. Hilton and Marriott and Starbucks aren't exactly mom-and-pop.

<comment> steve-howard Which is why, I imagine, they'll either stay far, far away from the biggest players (Caribou is several orders of magnitude smaller than Starbucks) and just harass companies too small to take a stand. The system works again!

</comment></comment></comment></comment><comment><USER30> It's nice to see that Innovatio IP is focused democratizing the opportunity to license their patents. Patent trolling isn't just for the Fortune 500 anymore.

<comment><USER31> Look who's talking: a patent troll himself. <http://news.ycombinator.com/item?id=3058876>

<comment><USER30> Have you considered law school?

Your insights into the actionability of patent _applications_ would be highly informative to the majority of legal scholars and practicing lawyers.

</comment></comment></comment><comment><USER32> I'm not a lawyer, so my question is simple - say that you receive a citation from Innovation and you simply ignore this. What then ? They will actually take you to court ?

<comment><USER33> This is exactly what I have been wondering. The case has no merit: they can't sue me for buying a Linksys router, can they?

<comment><USER34> The way the US legal system works, if you are sued then the plaintiff and you go to the court and make your arguments. If you don't show up, then they automatically win all arguments they make. Even if the argument is wrong. So you automatically lose, and then it moves to the collections stage.

tl;dr; Yes, they can sue you for buying a router. And win, if your high-priced lawyer doesn't show up in court on the appointed day.

<comment><USER35> A couple of things:

1\. If you get sued and don't show up, the judge might _or might not_ enter a default judgment. Think of a lawsuit as a road rally. The plaintiff has to hit a number of checkpoints. In federal court, one of the first checkpoints is that the complaint---that is, the plaintiff's formal statement of its claim--- must allege enough facts to set out a _plausible_ case entitling the plaintiff to relief. (This is the _Twombly/Iqbal_ standard established by the Supreme Court a couple of years ago.) Even if the defendant doesn't show up, usually the judge and his or her law clerk will still read the complaint, to see if it passes the smell test, before granting a default judgment.

2\. They can sue you for buying a router, but under section 2-312(2) and (3) of the Uniform Commercial Code [1], absent a proper warranty disclaimer you would normally be able to pass the buck to the seller, by filing a cross-claim for breach of the implied warranty of noninfringement. Of course, that too would require paying a lawyer, unless the seller stepped up and voluntarily assumed the defense of the infringement suit (which is not uncommon; vendors want to stay on customers' good side).

[1] <http://www.law.cornell.edu/ucc/2/article2.htm#s2-312>

</comment></comment></comment></comment><comment><USER36> Does anyone know what these patents claim to cover? "wifi" seems a bit broad

<comment><USER37> Here's one of their suits: [https://docs.google.com/viewer?url=http%3A%2F%2Fia700405.us....](https://docs.google.com/viewer?url=http%3A%2F%2Fia700405.us.archive.org%2F3%2Fitems%2Fgov.uscourts.ilnd.253349%2Fgov.uscourts.ilnd.253349.1.0.pdf)

I don't know enough about the details of wifi to say whether the patents in question actually apply, but it seems plausible. Here are all the patents listed in the suit:

<http://www.google.com/patents?id=zi8SAAAAEBAJ> <http://www.google.com/patents?id=0W-qAAAAEBAJ> <http://www.google.com/patents?id=89fGAAAAEBAJ> <http://www.google.com/patents?id=rlHHAAAAEBAJ> <http://www.google.com/patents?id=HQwgAAAAEBAJ> <http://www.google.com/patents?id=i9UYAAAAEBAJ> <http://www.google.com/patents?id=Uz8JAAAAEBAJ> <http://www.google.com/patents?id=f6mwAAAAEBAJ> <http://www.google.com/patents?id=YxQcAAAAEBAJ> <http://www.google.com/patents?id=unMYAAAAEBAJ> <http://www.google.com/patents?id=yPcOAAAAEBAJ> <http://www.google.com/patents?id=zDQSAAAAEBAJ> <http://www.google.com/patents?id=Bkh4AAAAEBAJ> <http://www.google.com/patents?id=vfnOAAAAEBAJ>

</comment></comment><comment><USER38> What is this patent actually for? I was looking up wifi, and the precursor to 802.11 came out in '91. That's well over 17 years ago.

<comment><USER39> US Patent 6714559 is one they sued several hotels over. It was filed in 2001 but was a string of 6 continuations of a patent filed November, 1991.

</comment></comment><comment><USER40> After getting sued a good course of action would be to sue the manufacturer for loses incurred. At least that would get their attention. Somebody could start a class action lawsuit agains the manufacturer.

<comment><USER41> They should be suing the manufacturers in the first place. Even if we were to assume for a moment that this patent has any validity whatsoever, it would not be the users of the wireless router than owe them a royalty payment, but the router manufacturers. And I seriously doubt that a fair royalty on a single router (such as what you might find in one of these small coffeeshops that they are suing) is in the thousands of dollars.

<comment><USER42> Why? It's not just the implementation of a patented idea that's protected; it's also the use.

<comment><USER43> Don't consumers have some protection here? I mean, they probably bought the wifi at a common store. You don't normally walk out of _Walmart_ with a box containing a product you expect to not legally be able to use.

<comment><USER42> Legally I believe that's an issue between the consumer and the merchant and/or manufacturer.

<comment><USER41> Legally, it depends. A bit of web searching did turn up (so far) one LinkSys router that explicitly disclaims implied warranty of non-infrigement. If that is disclaimed, then yes, it falls to the consumer to deal with it.

</comment></comment></comment></comment></comment></comment><comment><USER44> Someone needs to set up a Patent Troll company and patent a bunch of processes for political methods / action / campaigning / etc.

Then start trolling politicians.

</comment><comment><USER45> It's about time the CSIRO ([http://en.wikipedia.org/wiki/Commonwealth_Scientific_and_Ind...](http://en.wikipedia.org/wiki/Commonwealth_Scientific_and_Industrial_Research_Organisation)) got some money for their invention.

<comment><USER46> I have seen a few US writers attempt to call CSIRO a patent troll. Somewhat amusing. This article isn't talking about the CSIRO patent though.

</comment></comment><comment><USER47> The patent is from 2004. [http://www.google.com/patents?id=zi8SAAAAEBAJ&printsec=a...](http://www.google.com/patents?id=zi8SAAAAEBAJ&printsec=abstract&source=gbs_overview_r&cad=0#v=onepage&q&f=false)

I hope their greed gets the best of them. Here's a poll I created to get general feedback on this subject. It's so infuriating to me, but a lot of people seem to be indifferent on the subject of patents: <http://www.wepolls.com/p/3363896/>

<comment><USER48> If they applied for the patent in 2001, how can they possibly sue users of wifi? 802.11 has been around longer than that.

<comment><USER42> It's possible that the patent(s) are only alleged to apply to 802.11g and/or 802.11n implementations. At least one of the patents appears to relate to MIMO, which would apply only to 802.11n.

</comment></comment></comment><comment><USER49> Good luck with that one Trolls.

</comment><comment><USER50> Surely this?

</comment><comment><USER51> I wouldn't think they could ever win anything. One of the rules with patents is you can't just kick back and wait for your competitor's product to grow and sue 10 years later.

Considering WiFi is almost 20 years old, and has practically surpassed 'ubiquity', I'd say that ship sailed.

<comment><USER34> That's the beauty of the scheme. They don't HAVE to win anything. They threaten to sue for $2,000 to $5,000 which is less than the cost of hiring a lawyer to defend. 98% of the people threatened pay up. Some miniscule percentage are incredibly cussed individuals who are willing to spend thousands of dollars just to be right... maybe they'll lose those cases. It doesn't matter: they're still making huge amounts of money.

The only threat to the scheme is having your lawyers be sanctioned for unprofessional conduct. If there was NOTHING behind the threat, this would be a real possibility (like, say, if you tried this scheme when you didn't even HAVE a patent). But as long as it's a plausible case, the threat works and it's highly profitable.

<comment><USER52> It makes me wonder how this is not extortion? Pay up or we'll make your life miserable and/or more expensive.</comment></comment></comment>


Ask HN: Tools for sharing info on distributed teams? - <AUTHOR> I'm wondering if anyone can point me to a set of tools that you use to find/share info (procedures, docs, etc) between colleagues on your team? <comment><USER2> We host our company playbook as a collection of Markdown files in a GitHub repo.

<comment><AUTHOR> We do the same right now, it kinda works but we might have info for tools we've built spread across repos.</comment></comment>


Touch Gestures for Application Design - <AUTHOR> http://www.lukew.com/ff/entry.asp?1641

<comment><AUTHOR> Pretty detailed walk-through of touch gestures and how we can use them in our applications.</comment>


How fucked up are the US cellphone carriers? - <AUTHOR> http://abhijitdhakne.blogspot.com/2011/12/how-fucked-up-are-us-cellphone-carriers.html

<comment><AUTHOR> A whole lot!</comment>