I seem to remember a similar issue when I had an Evo 4G device from Sprint a couple of years ago. The device came preconfigured with a system-wide HTTP proxy that was not only incredibly slow, but also compressed images badly. It would also affect most methods of tethering, if memory serves. Perhaps you're seeing the same proxy?

As far as I know there isn't actually any requirement by the network to proxy anything, and I've been able to disable it from the system settings on all of my devices since I learned about the proxy. I'm not sure if you have any access to the configuration for your wireless modem, but you might be able to disable it from there.

I have a TF300 that I run standard Linux on (Arch and XFCE). It's actually fantastic to have a touchscreen for some interactions, and the ability to make custom gestures is surprisingly useful. It's gotten to the point that whenever I use a normal laptop I accidentally try to touch the screen for scrolling, etc.

For added fun, Tasker has SL4A integration, so you can have Tasker run arbitrary scripts when various events occur. SL4A also lets you (in addition to its own APIs) lets you install, e.g., additional python modules, and the Java-interpreted scripting languages (BeanShell, Rhino, and probably JRuby) let you directly invoke the Android APIs. The latest Tasker release also has JavaScript support and exposes more device functionality to it than SL4A's APIs do.

I'm not really sure what all of the hate for device scripting is about, Android is surprisingly scripting-friendly, and it actually has some viable end results.

I may be misinterpreting the announcement, but tab sync currently doesn't actually *open* the tabs on your other devices, it just has an "other devices" tab (mobile) or a drop down (desktop). Only the page titles are actually loaded until you actually click them. I'm not sure how the pre-loading will work but I'd bet that it's configurable, as chrome's syncing has pretty fine grained configuration already.

It's to prevent brute force attacks (from the old article):

From some quick testing the CAPTCHAs are reused so I'm not all too sure it does this successfully, but it's an interesting idea nevertheless.

They only took about 10 minutes for me to find, and both are (spoiler-ish) fairly blatant meme references like many of the other things in the game. I'd love to see this developed more as it seems to run pretty well and could have some real potential. I've half-assed some JS RPGs myself and its always nice to see it being done "right" and with a playable final product.

Strictly speaking, the language itself shouldn't have any effect on how fast it executes, it's the implementation that really matters. Some languages might be more difficult to parse but in the end it's what the interpreter does with it that really matters. The whole sentiment that "fast code equals C/C++" is a little fishy to begin with, modern interpreted languages compile down to machine code via JIT anyway and often don't have a significant performance decrease compared to the same code in C/C++. Not that I'm against the notion completely, as native code (and specifically native code modules embedded in other languages) has its benefits, but it shouldn't be used as an excuse for a slow interpreter.

Unless you're exclusively playing Solitaire, you're probably not going to be able to play most games in a virtual machine, at least on a Linux host. I have a Windows XP VM that I run in both VirtualBox and VMware, and I've had very limited success playing games in either. VirtualBox can barely handle 3D graphics at all (though its support has improved significantly in the last couple of years), and VMware's acceleration, while significantly more stable, is awfully slow.

Unless the situation is for some reason better on OS X, bootcamp is probably the only reasonable solution. Parallels likely wouldn't be any better than just using Wine, considering it uses Wine's Direct3D libraries.

Alternatively, of course, you can just use wine - which works so commonly now that there's really no reason to waste your system resources with the overhead cost of a virtual machine. Even when system resources aren't an issue, VMs are never as fast as native code, and for that reason alone are a poor choice.

When it works, it's far better. Even with decent hardware virtualization is too slow for a lot of apps. VMware is slower than anything but has reasonable 3D support, while VirtualBox is fast but can only reliably run 2D apps. Neither is really an optimal setup for things like gaming.

When Wine works, though, it runs pretty darn fast and generally doesn't cause too many issues. It's really rare for me to find a game that isn't compatible anymore. The last I couldn't run that comes to mind is League of Legends, but it seems that within the last week since I checked there's been a new workaround that fixes it.

Overall, Wine is considerably more capable than it used to be. I generally don't even have to question whether most apps will run anymore, because the answer is, more often than not, "yes".

That's exactly what I've been doing. I tried using GNOME 3 for a few months, but I eventually just got fed up. While I really like the shell interface, some of the other UI "enhancements" meant to "simplify" everything drove me away after a while.

I still use it on my laptop despite its control panel but I now use a combination of XFCE and Kwin on my desktop. I spent ages searching for a DE that would "just work" and XFCE does exactly that.

I'm not really sure what's wrong with the filesystem APIs, at least for simple (and even a lot of advanced) IO. Off the top of my head the only exception I can think of is that filesystem attributes and the like were a load of garbage in Java 6, but supposedly the situation is much better in 7.

As for graphics, I did (and still do) work a lot with Java2D, and for the most part it's worked flawlessly on both Windows and Linux. I've run into a couple of platform specific bugs in the past but they would generally be fixed within a couple of patches, and even then were easy to work around. I can't vouch for 3D stuff as I haven't written too much myself, but there's a large number of libraries that have seen some serious cross-platform success.

I'll admit, it isn't "write once, run anywhere", but if you're on any of the major platforms (Windows, Linux, OSX, BSD to some degree) the number of real issues is pretty minimal, and even OpenJDK works pretty damn well. I'll hate on Oracle as much as the next guy, but the influence I see from them on day-to-day independent coding is next to nothing. Apart from the uglier Oracle-themed icons and doc pages, at any rate.

I've been using them as well. Went with them for their low-cost Xen hosting and don't have any regrets. A general VPS tip I've had to learn the hard way: avoid anything OpenVZ. The shared kernel causes lots of problems, especially if the host machine isn't too well maintained.

One host I used about a year ago couldn't keep their server's clock in-sync at all, eventually the time drifted so much that it broke our Google Apps authentication and brought down email access for the entire building for a couple hours, which we eventually had to fix with a poor software hack. They were impossible to contact, and because it was an OpenVZ VPS, the VM clock was shared with the host, so we couldn't fix the time on our own. Not an issue, as far as I know, with Xen / KVM hosts.

From what I've read, the cheaper hosts tend to use OpenVZ because they can oversell the server memory a lot easier. Not an issue for Xen / KVM hosts, which is why I'm now using ThrustVPS for all of my personal stuff now - they're the cheapest/best-reviewed Xen host I could find.

Oh, and to expand a bit, for little to no electronics and entry-level programming, Mindstorms is again the best option. Graphical programming for new users, and hobbyists can use both a C derivative (NXC) and Java (LeJOS), two programming environments that I personally envy, even with higher-level robotics.

VEX again comes fairly close. You can program it with EasyC, which works very well for teaching to kids and I think would work great for letting the kids become more independent after a short time.

I've never seen an independent kit that offers reasonable ease of use. I've worked with quite a few, and for the most part none of them will satisfy the requirements. They generally are difficult to set up, and require lots of soldering, etc. While great for those interested, they wouldn't work very well for kids working independently. Essentially, the focus is on the electronics side rather than the software side, while the more mainstream kits (Mindstorms, VEX) tend to be more about software and construction (with pre-made parts) rather than electronics.

+1 to this. I know from personal experience that this is the way to go, especially for younger kids. Not only does it have a solid track for growth, from elementary until high school (FLL -> FTC -> FRC) , but it makes sure that you have other people to work with. Plus, there's generally no or very little cost to the student.

If that's not an option, I'd still recommend Mindstorms. It's more expensive, sure, but it really is leaps and bounds better than the alternatives. Younger kids (late elementary through middle school, 10 - 14 or so), tend to struggle with some of the less-developed kits, particularly if they lack a large community. Mindstorms is a great development kit, as you can see from all the /. articles about it. Adults and kids can make great use if them - I do all the time.

If that's still out of budget, VEX may be somewhat less expensive. I believe kits run about $200 and there's still a large community and yearly competitors and challenges to participate in. It's not quite the same community as FIRST, though.

Basically, there's no cheap way to get a (good) robotics kit. Even homebrew stuff (Arduino and the like), is going to be $100 at the absolute minimum. The cheapest way is to find a local team, or perhaps try starting one - many schools districts offer funding, support, or even full kits for new teams, in addition to lots of FIRST scholarships.

Disclaimer: I mentor FLL (Mindstorms) and FRC teams, after having been on several myself through middle and high school.

Gingerbread is version 2.3. Ice Cream Sandwich is version 4.0. Most devices won't ever see the 3.0 updates and instead will just jump to 4.0.

This whole article is a non-issue - Google has said several times that the source would be released along with the new Galaxy Nexus. From http://groups.google.com/group/android-building/msg/c73c14f9b0dcd15a :

They had some decent reasons for not releasing the Honeycomb source. Perhaps their reasons weren't good enough to make up for not releasing it at all, but their promises to release the 4.0 source have kept devs happy for a few months now. I see 4.0 as the update to 3.x that cleans up the source properly, and has the added benefit of no longer dividing between phones and tablets. Devs can finally get back to writing one app that works on everything.