I actually think a short handwritten note to thank someone for meeting with you or whatever is a nice gesture that stands out from the standard email and doesn't take much effort. Of course, that's real handwritten, not faux handwritten.
I do receive marketing materials from time to time that make a particular effort to stand out--sent FedEx or physical swag of some sort or gimmicky attempts at games/contests/etc. I admit they usually get me to at least look at the mailing though I'm probably no more likely to buy something.
I agree handwritten notes or physical communication of some sort can be effective if people think it's genuine. The problem with making a startup out of this is you are inherently fighting virality because once you do go mainstream you lose the personal value of it.
An interesting comparison is how Facebook started charging to get into a strangers inbox. The intentions behind this seem to be the same. A world fighting for each others attention...
Yeah. It only really works if it's not the norm, i.e. it stands out. If every donation thank you letter over $20 starts being sent out this way, then it becomes worthless in a hurry. The other downside is that it encourages outsourcing the personal touch. If you're a charity, you should individually reach out to your large donors, not outsource that to a faux handwritten form letter. (Though as others have noted, politicians use robo-signers a lot.)
Personally, I have two problems with Republic Wireless: no ability to bring your own device (I'm never buying a device from a carrier again), and an attempt to guilt-trip the customer into not using data (either you're unlimited or you're not, don't tell me I have unlimited data if you're going to gripe when I use it).
Google can and probably eventually will solve the bring-your-own-device problem by making WiFi-to-cellular call handover part of the default Android stack. Until they do, anyone else has to make the modifications themselves, which is about as time consuming as bringing a whole new phone to market. The discouraging of cellular data use is something that all MVNOs have to do because they don't have enough leverage against the major carriers to get reasonable pricing. Google's got part of a solution by being an ISP that can deploy WiFi (and perhaps some cellular service on suboptimal spectrum) to the kind of places that suffer from the most congestion on the cellular networks. The rest is just a consequence of the market being controlled by an oligopoly, and it's not the little guys you should be blaming.
Well, Republic doesn't have a hard limit on data usage except when roaming (which most MVNOs don't offer at all). Republic will throttle your speed after 5GB but won't cut you off or charge you extra. The only difference between this and what the major carriers that charge 2-3x do is that Republic's threshold is lower and more publicized.
Buying the NASDAQ doesn't seem as prudent as buying a more representative fund covering the whole market. Not everything has done as badly as the NASDAQ. And you could do a lot worse than a whole-market index fund.
When it comes to investments, boring is a feature.
100% agreed. I've sat down with a few family members and friends who want to understand "investments" and it takes many conversations just to drill into their head that for most average people, boring is good. There are certainly complex, fast moving financial instruments that are exciting, but these should be steered clear of. It takes quite awhile to wash away the preconceived notions about what "investing" is. Investing shouldn't be like playing poker - it might be fun to have "action" and "excitement", but save that for the trips to Vegas.
It seems like the problem that WebRTC wants to solve could be solved another way, by putting more of the discovery logic into the browser rather than the application. WebRTC wants to find peers on the local LAN, and communicate with them directly. Why not let the browser find peers, and then hand the WebRTC application a connection without exposing where that connection leads?
That said, long-term, I think networks need to stop treating non-routability alone as a firewall mechanism. Any information that this WebRTC mechanism reveals could also be exploited by any random client application, or in the case of http-based protocols, by anyone who can embed an iframe or submit a form. Consider how you'd design a network in which every device had a routable IP address, and go ahead and design it that way anyway as a defense-in-depth measure. Use encrypted and authenticated protocols even on your "private" network.
This forces all WebRTC connections to only use server-reflexive and relay ICE candidates, and only on the default IP route. While this may cause a QoS hit (two users behind NAT can no longer keep their traffic internal to the NAT), it does allow the issue mentioned here to be fully addressed without disabling WebRTC altogether.
Thanks very much for your reply. I've been trying to enable the preference in Google Chrome Canary on Mac OSX. However, I haven't been able to successfully block the IP leak - I suspect because I haven't configured it correctly. I had to manually create the file "/Library/Google/Google Chrome Master Preferences" and add the setting you suggested. I then reinstalled Chrome Canary and tested but no effect. I also tried editing the user preferences file in ~/Library/Application\ Support/Google/Chrome\ Canary/Default/Preference but that seems to be overwritten by the browser. How should I be configuring this preference? Thanks again.
That doesn't necessarily mean they need to be sent to the server. The two browsers on the same LAN could coordinate via local discovery, establish a socket between themselves, hand that socket to WebRTC, and never tell the two applications running in the browser sandbox what local LAN IPs they use.
I'd like to see that as well. Machine intelligence is certainly an existential threat, but on the other hand, it's also one of the single largest improvements we could possibly create (insofar as it'd be the last we'd ever need to).
This announcement isn't as significant as it seems. As mentioned in the mail, Debian has already transitioned to using systemd by default for the upcoming jessie release, for both new installs and upgrades, with a carefully orchestrated transition coordinated between the sysvinit, upstart, and systemd maintainers. (That transition includes the ability for sysvinit and systemd to co-exist on the same system, choosing which one to boot at boot time with init= or a GRUB menu option, rather than having the packages conflict at installation time.)
This announcement only occurred because, after that transition, someone formerly on the technical committee (now resigned, but a member at the time) attempted to use the technical committee to force a revert of that transition. This announcement is effectively the current technical committee saying "nope, the other teams in Debian have done a fine job arranging this transition, and we're not going to overrule anyone".
(I helped draft this proposal, and spent a fair bit of time trying to make sure it would not be taken as changing the current state of affairs in any way, only affirming the work others had already done.)
> e.g. Systemd will own port 80, and feed it back to Apache who listens over 8080.
No, Apache actually listens to port 80, just on a socket created by systemd. systemd opens the TCP listening socket, spawns Apache (potentially on demand when connected to), and passes along the file descriptor for the socket. Apache then treats that file descriptor as though it had opened it itself. Similar to inetd, except that it isn't limited to stdio.
That said, since netstat -p shows who opened the socket rather than who is using the socket, socket activation does make it less useful. Given that netstat -p already reads all the necessary information from /proc, it'd be nice to teach netstat to show multiple programs listening on a socket, not just the opener.
That's a useful condition, but it ought to be completely unrelated to law enforcement. You shouldn't be required to live around people who look and think and act the same as you do to receive equal treatment by the law.
While I agree with you that it ought to be a separate issue I strongly doubt the separation is ever achieved in practice. Actual policing and "policing" of human behavior, looks and other norms appear to me to be inextricably linked. I'm sorry to single out this instance in particular but reinforcement of the local mores happens even through seemingly innocent behavior like your ought-statement above, which I happen to agree with but some people might not have, especially in the past. Police officers, persecutors, judges, etc. are affected by their own set of ought-statements in work as well as in life. (And the effect is exacerbated when you implement trial by jury.)
On my part, I cannot come up with one historical example of people generally satisfied with how significantly different outsiders to their community policed them. I have come to think it's more or less an inevitability and the best we can do is to make it possible for people to freely move to where they find the mores agreeable.