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.
Re:Tab syncing: first thing I'll disable
on
Google I/O Day Two
·
· Score: 2
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):
The second component is transformed into a CAPTCHA image and then protected using evolution of a two-dimensional dynamical system close to a phase transition, in such a way that standard brute-force attacks become ineffective. We expect our approach to have wide applications for authentication and encryption technologies.
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.
We plan to release the source for the recently-announced Ice Cream Sandwich soon, once it’s available on devices.
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.
I'm in a pretty similar situation - I know quite a few teachers who, having just been given some new tech, take it and thrive. Optimistically I'd say that the tech does at least as well as the "old methods" in 90% of cases, and most of the time is an improvement. Every now and then, though, it's just done plain wrong. One teacher I recently worked with had just been given the so-called "full setup", consisting of about $3000 of classroom tech. This teacher was laid off at the end of the year, and while working with their replacement, we discovered that absolutely none of it had been so much as touched during the year.
On the other end of the spectrum, some teachers take the time to fully integrate things into their curriculum, and it really does improve the classroom - students are far more engaged and responsive, and their test scores (among other things, obviously) reflected it. But in the middle of the spectrum, the majority of teachers barely use it to displace the 25-year-old overhead projectors.
The issue is that, while some teachers actively want to embrace the tech, the rest lack any sort of direction in doing so, either doing the absolute minimum, or ignoring it completely. I'd say that in many cases, the funding is there, as is the tech and the software. But without solid planning, training, and support, it just doesn't get used to anywhere near its full potential.
Their speeds aren't the best, but they don't restrict usage at all. I can tether my (rooted) 4G android phone for free with no data caps or throttling (as far as I can tell), and on occasion I've used nearly ten gigs over a WiMAX connection while on vacation without any issue. I've rarely needed customer service as downtime and issues in general are virtually nonexistent, but it's there when needed and is pretty good.
As for price, though, the smaller/contractless providers like Virgin Mobile may be your best bet. I've heard they're far cheaper than any of the "big three" and make good on their "unlimited" promises. Even so, I can't vouch for their quality, having never used one myself.
For the record, TFA is only referring to the Email app (often called Email.apk) which is just a normal app. Unlike Apple's apps it has no special access to system APIs, keychains, or the like. On top of that, it isn't even included on many Android devices. HTC uses their own which could very well handle things differently, and I'm pretty sure other manufacturers do the same. On my CM7 device I don't even use it in favor of the dedicated Gmail app, which seems to take security quite a bit more seriously. Call me crazy for actually reading TFA but an Android dev made a very helpful comment on the situation:
Now, with respect to this particular concern. The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection. These protocols require us to retain the password for as long as you wish to use the account on the device. Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example. Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password.
And as demonstrated by many others here, the keychain is not actually the be-all, end-all solution to the problem, as it either leaves the decryption key elsewhere on the disk, making it useless, or requires the user to constantly enter a password, making it annoying. Android leaves it up to the app to handle passwords (as does iOS in most cases, I believe), and in this case the Email app doesn't really have a choice. Asking the user to enter their keychain password every time the Email app wants to grab new emails would get annoying quickly, and the protocols that it needs to support can't use the more secure token-based systems. Unfortunately there's no other feasible way to do it, and this debate is ignoring the real issue: mail servers that don't support secure authentication.
tl;dr: Article is not about "Android", only one app, and said app doesn't have much of a choice.
It's a cute idea. It assumes a single point of contact with the ground, and thus requires a flat, hard floor. This is limiting.
I've worked pretty extensively with mechanum wheels - essentially omniwheels with the smaller wheels at a 45 degree angle to the main wheel. Arranging four of them provides the same degrees of freedom as the example shown with two of these HOG wheels. Mechanum wheels work well and move quite fast, and I've yet to see a surface where they don't work - but they're costly, heavy, and wear quickly, not to mention the pretty enormous power requirements. Because of these limitations, for hobbyist robotics, they're simply not practical.
For many of the smaller projects I've done, traditional drive systems were slow and not nearly as useful as an omnidirectional (3 DOF) system - and without the ability to easily use something like omniwheels or mechanum wheels due to various constraints, HOG wheels would be a godsend. They provide most of the benefits of the traditional omnidirectional drive systems with very few hitches - and you'd be surprised how often the hard and flat surface requirement isn't an issue (or, in many cases, applies to traditional drive systems as well).
As an Android developer, this information is extremely useful to me - I now have a testimonial from another small developer which could certainly influence future decisions. Knowing this, I'll think twice before trying to publish my apps with Amazon. And the same could likely be said for other Slashdot readers - I've read plenty of posts by developers here who are also likely to benefit from this information.
On the other hand, there's also plenty of normal users reading Slashdot. They likely decide that this information isn't pertinent and move on to another article. Problem solved, no?
Running Chrome 13.0.772.0, both Bookmarks and History are accessible directly via the tools menu, no settings panel needed. I guess I could perhaps see putting a history or bookmarks button on the toolbar but personally I prefer it slightly (i.e. one extra button click) out of the way as I don't use either all that often.
As for searching, Ctrl+T, type query, [enter] opens up a search in a new page quite quickly. Even using the mouse goes pretty fast for the same purpose. Ctrl+L -> Type query -> [enter] is also pretty quick to search on the same page. For mouse users, a triple click in the address (in Linux, I believe it's just a single click in Windows) selects all text, and you can just type from there. I believe Firefox works mostly the same way, I've never known its search box to open a new tab by default.
For bookmarks, though it's not the best solution, you can drag the tab opened off the tab bar pretty easily, effectively achieving the same thing. And looking at the Print option now (for the OP), I have to say I love the new integrated Print and Preview, it's much more intuitive (IMO) than the Firefox alternative. And it also seems to be laying out pages far better (e.g. no overlapping elements on this page) but the complaint about a higher page count seems to be valid (24 vs 19 for Firefox).
Overall I think Chrome could certainly be more customizable, as the default behavior isn't a perfect fit for most users. But usually the interface will let you do what you want regardless of some of its behavior.
Just being picky, but... depending on the plan, Sprint's data can actually be really unlimited. Any device with the extra $10/m 4G addon gives you real unlimited 3G/4G data.
Midori is really lightweight and fast. It tends to outperform Chrome on older computers in my experience. Plus it runs in XFCE, so you're set for a lightweight environment.
Sprint is looking like the only real option left and I really detest the $10 smartphone tax just on fucking principle.
The promise of unlimited wireless internet is looking bleaker and bleaker by the day.
The "tax" is just for Sprint's 4G phones, but even then, it gives you truly unlimited data (as in, no 5GB/month limit or anything of the sort) that their standard plans don't get. I went on a trip a couple of weeks ago and was tethered to my 4G phone almost the entire time, probably downloading more than 10 GB of data without a single complaint from Sprint. I don't pay for their tethering plan, either. I'm happy to pay the extra $10/month for that benefit.
I still have to hold in a laugh when some friends of mine who are stuck with AT&T complain about their tiny download caps and crappy limitations on their phones, and now with T-Mobile going the same way... From how I see it, Sprint is one of the only sane providers left. Here's to hoping they stay that way.
Seconded. Swing is (despite what many people around here would like to believe) a very capable GUI library. It's by far the best object oriented GUI library I've come across, with a much more logical API than SWT, Qt, or GTK. Plus, Java2D for raw drawing is incredibly easy to use and it automatically gets hardware acceleration (OpenGL on *NIX systems) so the performance is good. Swing does have a bit of a learning curve, but there's excellent GUI builders for it (e.g. NetBeans) and the API really makes a lot of sense when you learn it.
If Java isn't your thing, Qt would probably be the way to go. I find the API a bit clumsier than Swing, but the major features (hardware accel, powerful 2D, and cross platform) are there. On the other hand, raw OpenGL has a comparatively huge learning curve and wouldn't have any sort of system look and feel. It would likely be the best performance-wise, though.
Slashdot Mirror
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.
The second component is transformed into a CAPTCHA image and then protected using evolution of a two-dimensional dynamical system close to a phase transition, in such a way that standard brute-force attacks become ineffective. We expect our approach to have wide applications for authentication and encryption technologies.
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 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".
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.
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.
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.
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 :
We plan to release the source for the recently-announced Ice Cream Sandwich soon, once it’s available on devices.
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.
I'm in a pretty similar situation - I know quite a few teachers who, having just been given some new tech, take it and thrive. Optimistically I'd say that the tech does at least as well as the "old methods" in 90% of cases, and most of the time is an improvement. Every now and then, though, it's just done plain wrong. One teacher I recently worked with had just been given the so-called "full setup", consisting of about $3000 of classroom tech. This teacher was laid off at the end of the year, and while working with their replacement, we discovered that absolutely none of it had been so much as touched during the year.
On the other end of the spectrum, some teachers take the time to fully integrate things into their curriculum, and it really does improve the classroom - students are far more engaged and responsive, and their test scores (among other things, obviously) reflected it. But in the middle of the spectrum, the majority of teachers barely use it to displace the 25-year-old overhead projectors.
The issue is that, while some teachers actively want to embrace the tech, the rest lack any sort of direction in doing so, either doing the absolute minimum, or ignoring it completely. I'd say that in many cases, the funding is there, as is the tech and the software. But without solid planning, training, and support, it just doesn't get used to anywhere near its full potential.
Their speeds aren't the best, but they don't restrict usage at all. I can tether my (rooted) 4G android phone for free with no data caps or throttling (as far as I can tell), and on occasion I've used nearly ten gigs over a WiMAX connection while on vacation without any issue. I've rarely needed customer service as downtime and issues in general are virtually nonexistent, but it's there when needed and is pretty good.
As for price, though, the smaller/contractless providers like Virgin Mobile may be your best bet. I've heard they're far cheaper than any of the "big three" and make good on their "unlimited" promises. Even so, I can't vouch for their quality, having never used one myself.
Now, with respect to this particular concern. The first thing to clarify is that the Email app supports four protocols - POP3, IMAP, SMTP, and Exchange ActiveSync - and with very few, very limited exceptions, all of these are older protocols which require that the client present the password to the server on every connection. These protocols require us to retain the password for as long as you wish to use the account on the device. Newer protocols don't do this - this is why some of the articles have been contrasting with Gmail, for example. Newer protocols allow the client to use the password one time to generate a token, save the token, and discard the password.
And as demonstrated by many others here, the keychain is not actually the be-all, end-all solution to the problem, as it either leaves the decryption key elsewhere on the disk, making it useless, or requires the user to constantly enter a password, making it annoying. Android leaves it up to the app to handle passwords (as does iOS in most cases, I believe), and in this case the Email app doesn't really have a choice. Asking the user to enter their keychain password every time the Email app wants to grab new emails would get annoying quickly, and the protocols that it needs to support can't use the more secure token-based systems. Unfortunately there's no other feasible way to do it, and this debate is ignoring the real issue: mail servers that don't support secure authentication.
tl;dr: Article is not about "Android", only one app, and said app doesn't have much of a choice.
It's a cute idea. It assumes a single point of contact with the ground, and thus requires a flat, hard floor. This is limiting.
I've worked pretty extensively with mechanum wheels - essentially omniwheels with the smaller wheels at a 45 degree angle to the main wheel. Arranging four of them provides the same degrees of freedom as the example shown with two of these HOG wheels. Mechanum wheels work well and move quite fast, and I've yet to see a surface where they don't work - but they're costly, heavy, and wear quickly, not to mention the pretty enormous power requirements. Because of these limitations, for hobbyist robotics, they're simply not practical.
For many of the smaller projects I've done, traditional drive systems were slow and not nearly as useful as an omnidirectional (3 DOF) system - and without the ability to easily use something like omniwheels or mechanum wheels due to various constraints, HOG wheels would be a godsend. They provide most of the benefits of the traditional omnidirectional drive systems with very few hitches - and you'd be surprised how often the hard and flat surface requirement isn't an issue (or, in many cases, applies to traditional drive systems as well).
On the other hand, there's also plenty of normal users reading Slashdot. They likely decide that this information isn't pertinent and move on to another article. Problem solved, no?
Running Chrome 13.0.772.0, both Bookmarks and History are accessible directly via the tools menu, no settings panel needed. I guess I could perhaps see putting a history or bookmarks button on the toolbar but personally I prefer it slightly (i.e. one extra button click) out of the way as I don't use either all that often.
As for searching, Ctrl+T, type query, [enter] opens up a search in a new page quite quickly. Even using the mouse goes pretty fast for the same purpose. Ctrl+L -> Type query -> [enter] is also pretty quick to search on the same page. For mouse users, a triple click in the address (in Linux, I believe it's just a single click in Windows) selects all text, and you can just type from there. I believe Firefox works mostly the same way, I've never known its search box to open a new tab by default.
For bookmarks, though it's not the best solution, you can drag the tab opened off the tab bar pretty easily, effectively achieving the same thing. And looking at the Print option now (for the OP), I have to say I love the new integrated Print and Preview, it's much more intuitive (IMO) than the Firefox alternative. And it also seems to be laying out pages far better (e.g. no overlapping elements on this page) but the complaint about a higher page count seems to be valid (24 vs 19 for Firefox).
Overall I think Chrome could certainly be more customizable, as the default behavior isn't a perfect fit for most users. But usually the interface will let you do what you want regardless of some of its behavior.
Just being picky, but... depending on the plan, Sprint's data can actually be really unlimited. Any device with the extra $10/m 4G addon gives you real unlimited 3G/4G data.
Midori is really lightweight and fast. It tends to outperform Chrome on older computers in my experience. Plus it runs in XFCE, so you're set for a lightweight environment.
Sprint is looking like the only real option left and I really detest the $10 smartphone tax just on fucking principle.
The promise of unlimited wireless internet is looking bleaker and bleaker by the day.
The "tax" is just for Sprint's 4G phones, but even then, it gives you truly unlimited data (as in, no 5GB/month limit or anything of the sort) that their standard plans don't get. I went on a trip a couple of weeks ago and was tethered to my 4G phone almost the entire time, probably downloading more than 10 GB of data without a single complaint from Sprint. I don't pay for their tethering plan, either. I'm happy to pay the extra $10/month for that benefit.
I still have to hold in a laugh when some friends of mine who are stuck with AT&T complain about their tiny download caps and crappy limitations on their phones, and now with T-Mobile going the same way... From how I see it, Sprint is one of the only sane providers left. Here's to hoping they stay that way.
Seconded. Swing is (despite what many people around here would like to believe) a very capable GUI library. It's by far the best object oriented GUI library I've come across, with a much more logical API than SWT, Qt, or GTK. Plus, Java2D for raw drawing is incredibly easy to use and it automatically gets hardware acceleration (OpenGL on *NIX systems) so the performance is good. Swing does have a bit of a learning curve, but there's excellent GUI builders for it (e.g. NetBeans) and the API really makes a lot of sense when you learn it.
If Java isn't your thing, Qt would probably be the way to go. I find the API a bit clumsier than Swing, but the major features (hardware accel, powerful 2D, and cross platform) are there. On the other hand, raw OpenGL has a comparatively huge learning curve and wouldn't have any sort of system look and feel. It would likely be the best performance-wise, though.