I mean--don't forget, some people will be using this text-only service to watch text movies.

The 17 minute long Star Wars movie from towel.blinkenlights.nl consumes a whole 3.23MB, so even with a whopping 10MB, you will only be able to watch that movie 3 times per day.

While I do see your point that it's a lot, I'd say it's still cutting it close on some of the decades-old telnet services that people might want to access...

I'm also sure there are some millennials right now clamoring for some of their newfangled DHTML content and Macromedia Flash games that is all abuzz amongst those with supercomputers fast enough to run Netscape 4.8.

But seriously - give it a break! We all grew up on telnet and we turned out okay.

Bitcoin addresses only exist once money is sent to them, so it's free to generate infinite addresses and you can't even know they were generated until money was sent.

Also, if money is never sent out of them, you wouldn't know the difference between a terrorist receiving it and a grandma being sent Bitcoins to hold onto.

So the terrorists can just kind of hold onto the money, and if they are clever they can wait a long time transact by sharing the private keys themselves instead of doing transactions with money in the wallet. That way there's no record of money changing hands and the terrorists aren't even involved.

I have no idea how law enforcement would be able to track these types of transactions. We're truly entering a scary era of funding.

Does the other wingtip get the red light?

If only it were so simple... /etc/hosts implementations do not generally support any form of wildcard.

Using hosts properly for this purpose is quite difficult, since the software could send to arbitrary subdomains. At this point you're better off writing a simple proxy.pac javascript file supported in all major browsers or running a local dnsmasq server.

... or close to localhost at least. I always wondered what they did with all the data I send by mistake to 12.7.00.1

NetRange: 12.7.0.0 - 12.7.0.7
CIDR: 12.7.0.0/29
NetName: PANERA-B13-0-0
NetHandle: NET-12-7-0-0-1

Bird sounds visualized using machine learning... hmm, where have I seen this before?

You want an app? I bet Google's already on it.

Lightwave vs Notepad: http://web.archive.org/web/200...

This was back after XP came out and Notepad was starting to experience some feature creep in XP Notepad, like the view menu or the ability to edit unicode files. I don't think anyone expected one of the classic windows apps like mspaint to actually get 3d support.

It's been a while since i've used DD-WRT. Last I checked, it was still using the 2.4 kernel with the closed-source drvier on many broadcom devices. Linux 2.6 has been out for 9 years, and the open source broadcom drivers have stabilized much since then.

I highly recommend OpenWRT with its Luci configuration interface. You're going to find it a worthwhile replacement for DD-WRT, including native IPv6 support (provided you go with the broadcom-2.6 kernel). You don't need to know much about using the command line to get things to work (and even if you go this route, there are many people who can help).

I've been using OpenWRT Kamikaze without issue on my WRTSL54GS (very similar in hardware configuration to the WRT54GL), and all the computers in my house have native IPv6 (with "radvd" autoconfiguration) using a 6to4 tunnel on Comcast. If you need details on how I got it set up, just let me know or start a post on the forum. The openwrt community is very friendly with a lot of knowledgable folk. I've loved OpenWRT and not had any reason to look back.

I don't think the UI is that much of a problem. Still, I usually use imo.im, since it syncs unread messages with their mobile app.

Yes, if I had mod points, I'd mod you up.

I'm an app developer, and I've had to deal with countless network problems (usually NAT's dropping connections without RST) that ended up being resolved by stupid strategies like "f it, lower the keepalive interval to 5 minutes", and killing a connection if it was not ack'ed in X seconds (you can be more agressive with killing TCP connections by adding protocol-level acks on client&server).

But despite this, I've managed to reduce bandwidth greatly by making my protocol independent of TCP connection -- in other words, I connect, tell the server who I am, and keep going with my connection, slowly making forward progress even if my layer 3 connection is killed every few seconds. At this point, TCP port 443 becomes basically a heavyweight datagram protocol (with a SSL handshake) because you can't rely on anything.

I'd rather use push notifications, but they have two glaring holes: 1) You can't rely on messages arriving on time. This means it's useless for a VOIP app where you expect it to ring within a few seconds. 2) Google C2DM requires that you have android market installed. This means your app won't work on half the phones around the world.

It's funny that you say that, because based on (admittedly half year old) data that an app developer collected about reconnect rates, Japan was by an order of magnitude the worst country with regards to number of reconnects that this app had to perform (DoCoMo was the second-to-worst carrier around the world).

Reconnects happen because the cell carrier closes a connection or times out--a good cell carrier won't change your IP address or RST your connections when you switch towers, but a bad one might decide to assign a new IP address each time. On some apps, reconnection may consume up to 1MB of bandwidth each time as they attempts to resync data (Yes, good apps shouldn't do this, but I have seen it happen.)

The problem is not Android -- the problem is the shitty QoS that most mobile carriers put on their networks, combined with the fact that they often kill connections at the NAT layer without notification, time out connections over unwanted ports and block protocols that they don't like.

The end result is that everything on a cell network has to happen over port 80 or port 443, with the SSL negotiation overhead that involves, combined with sending keepalives every 4 minutes. Yes, Android is unoptimized. DoCoMo might be doing everything right, but they bear the price of all of the terrible cell carriers that go out of their way to block data (AT&T, T-Mobile, I'm looking at you). Android 4.0 has a Data usage monitor that helps a ton in debugging misbehaving apps, but data is a fact of life.

That said, Apple may have made a good decision by forcing app developers to use push notifications when the app is in the background. Android messed up push notifications by tying them to Google Talk and Android Market -- this means apps that require push will not run on a large fraction of android devices around the world (including the Kindle Fire). The result is that apps don't use push and implement their own (often buggy/wasteful) push system.

Finally, if DoCoMo doesn't want users to send/receive data, then limit their bandwidth for crying out loud. Don't whine when you provide fast service and people use it. What is complaining to the OS manufacturer going to do? They provide a platform, not the apps or the service they run on.

Why did this article make slashdot? Who cares that a distro with all the default packages enabled won't fit on a CD? Does Windows Vista fit on a CD if you include all the default packages and a word processor? Does OS X?

If you have an old system, you can use the https://help.ubuntu.com/community/Installation/MinimalCD and download packages off the net.

As long as they continue to support PXE boot, USB boot and other minimal bootstrap images that require network support, I'm fine. Heck, you can put your harddrive in another system and debootstrap ubuntu onto it if you are in a bind with a bad net connection and no DVD drive.

Yes, and the original standard allowed any site to frame any other site and access any data from it... This isn't 1999, and you shouldn't be quoting a 12-year-old spec to talk about security issues that weren't even known at the time. Read the HTML5 spec and maybe you will start to see just how many nuances there are in keeping things working while having security on top. Not even the HTML5 spec explains all the complicated shit that browsers have to do... Mozilla's documentation is the best resource for this stuff because they describe what a real browser does. Here you go, first google result:
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header

X-Frame-Options is a standard header (despite the "X-" part, it is a standard security feature built into *all* modern web browsers, including IE), and it is up to a site owner to choose to use it. This is the only guaranteed way to solve clickjacking attacks. Other methods require javascript enabled and some nasty hacks. See this page if you don't believe me:
http://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

That said, it's like using a hammer to put in a staple, way overkill. Problem is, there is no way to guarantee that your page is not being clickjacked -- there are so many ways to do a clickjacking attack that browsers simply can't guard against all of them, for example, plugins, opacity, ...

Yes, users shouldn't be stupid enough to input confidential information when the address bar has an untrusted URL... but the clickjacking attack works by showing users confidential information that only a trusted site could possibly know and giving them a familiar login form... It's very difficult for all but the most trained user to distinguish this type of site from the real thing.

Not all sites use this, but Google decided it was worth adding the header to protect themselves. That's their decision to make. For my web page, I'm considering the javascript-based solution because it allows a more clear message and lets users override the check if necessary, but this may compromise security in one or two cases, so it's a tradeoff.