The TMobile "Even More Plus" plans in the U.S. do, in fact, offer lower rates because the do not subsidize a phone. They are BYOP (bring your own phone) plans (or buy one from TMobile at regular price, with financing, etc.).
That, or you can create your own network by putting up one cell in a remote location like Montana (can't remember the exact place) and do everything else through roaming agreements. You don't think that Virgin Mobile owns their own network in the U.S., do you?
believe it or not there is an icon for Hotmail there as well as Yahoo, Hulu, Facebook, Twitter and the rest is Google apps
Why does this surprise you? Android, another Google-authored operating system (but for smartphones as you likely already know), comes with bookmarks in the browser for all sorts of non-Google properties.
What's with this cynical belief that Google is so self-serving?
Your statements are similar to those who believe Google tries to lock users into its services without ever having visited The Data Liberation Front.
Are you jealous of Google's success or something petty like that?
As has been mentioned in previous posts, native C++ development is available via the Android NDK. Even native access to OpenGL is supported.
with their own version of the app store and installation verification
I guess you never clicked on a URL (in the built-in browser on the phone) that points straight to an Android Package (.apk) file and simply allowed the phone to install it. No "app store" required.
If you are searching for code, use Google Code Search. It supports regular expression matching, but it only searches source files (not the entire Web).
What we've found is that code reviews take forever...
Ugh. Are you reviewing each individual commit (where code reviews are quick and very effective), or are you rounding up a bunch of developers in a conference room and reviewing an entire module using an overhead projector?
Peer-to-peer reviews of individual diffs using good workflow tools have been very effective at several places I have worked and in open-source projects to which I have committed.
Some of the fastest team development velocity I have experienced has been with peer code reviews within the team.
I would suggest keeping the battery pack warm using the same power source that is being used to charge the battery. Also, insulate the battery pack, since the batteries typically warm themselves as a result of being discharged, due to their own internal resistance.
This mainly becomes an issue if you park the car somewhere for a long time in a place that is cold, but there is no way to plug the car in. I suspect that parking garages would start offering electrical outlets for charging the parked vehicles. Smart grids would probably help with this, causing the car owner to be billed for the electricity used to charge and pre-warm the car (or credited, if the car contributed excess electricity to the grid during daytime peak hours in periods of relatively mild weather).
Similarly, the car interior could be pre-warmed (or pre-cooled in the summer) when plugged in.
Also, at the recent Google Summer of Code mentor summit in October, an Android engineer mentioned in a presentation to attendees that native (ARM) code.so files would be bundle-able in.apk files soon. These libraries would be accessible via JNI. They would initially only have access to libc and libm in the first incarnation, though.
So, yes, I do believe Android is a mobile gaming platform.
(This was discussed in a public forum at an open source conference hosted at Google, so I don't believe it is secret information...)
Ummm, no. The underlying Linux system is not exposed to the Android app developer. Only the Android APIs in Java are. So, Android is a platform by itself, unless people start porting the Dalvik VM and the Android Java code to LiMo and other embedded Linux variants.
Apps written for one do not run on the other, so that makes it a different platform. I suspect that "Linux" shouldn't be lumped together the way it is in that statistic, either. How many of those are QTopia-based, or some other UI stack on top of embedded Linux?
If I need to exchange documents with someone that needs to edit it, I just send them a link to the document uploaded into Google Docs. No need for a big, chunky email attachment.
Sounds like you are working at the wrong company. Perhaps you should work at some place like Google, where the engineers drive innovation from the bottom up.
Hmmm, sounds like a job for some sort of challenge-response system using PKI. This is quite do-able, if every mine has a Certificate Authority public key and modulus embedded in it, and the commands are signed with the CA private key. There are plenty of digital signature and public key exchange methods that are suitably secure. The mine just needs to use one of these to verify that the received commands are legitimate.
In fact, I wouldn't be surprised if the mines themselves didn't have a private key embedded in them that they used to decrypt signed information sent to them from the other mines. You would certainly want the mines to hide what they are exchanging from outside listeners and also be able to confirm that anything they received was from a valid mine (not some rogue mis-informer).
Actually, it would be more computationally efficient for the mines to use PKI to exchange a "shared secret" and then switch to some symmetric cipher (AES, anyone?) using that shared secret to exchange status and "strategy" information after that.
This sounds more like a bug in the controllers inside the Flash cards than the actual choice of filesystem. Most Flash card formats (CompactFlash, MemoryStick, MMC/SD) contain a microcontroller that does wear-leveling and ECC. So, logical block zero of the device does not remain physical device zero if that block gets worn out. There are lots of references on the web discussing the microcontrollers in various Flash cards, for example this article (linked via Google cache because the original is a PDF).
These microcontrollers are precisely the reason why it is not a good idea to use these formats in devices that can be powered off suddenly. Look here (search down for "asynchronous power fail" for a mention of these problems. Elsewhere on the site (and in the JFFS author's other online comments), more discussion of this problem is available, including the JFFS author's own experiments.
JFFS works with MTD devices, which are flat Flash arrays with no microcontroller (and the JFFS author doesn't plan on supporting ATA-type Flash cards, although it appears others may be working on this). This gives JFFS complete control over journalling, wear-leveling, and error correction. It is able to do these things in a fashion that is robust in the face of asynchronous power failures. The microcontrollers in various Flash cards do not appear to be this sophisticated.
So, 1) it may not be the choice of filesystem that is the problem, 2) there are documented reasons for not using Flash cards in certain types of systems, and 3) JFFS (and JFFS2), even if they support non-MTD devices now, probably cannot safeguard against the problems in microcontroller-based Flash cards.
About two years ago, I worked for Cyra, the company whose Cyrax 2500 they are using to scan these monuments. The device is pretty cool, but expensive at US $125,000 for one unit, not including any license seats of the Cyclone software you need to manipulate the HUGE data sets that the device generates. All you get from the device is a cloud of individual points. It really takes the software that runs on the PC (Cyclone) to turn the point clouds into surfaces and then into files compatible with CAD systems like AutoCAD and Microstation.
By the way, it is a good thing that none of these monuments that they are scanning with the Cyrax 2500 are red. The green laser used by the unit doesn't even see some shades of red. There was a bright red toolbox in the lab that would crash the scanner every time until we got the "no-return timeout" code right.
It's too bad the company is in such a bad financial situation. The device is really cool, but the slowing US economy has really put the brakes on large capital expenditures like the Cyrax 2500, even though many studies have shown that the labor costs savings and the improved accuracy of the results more than make up for the cost of the device and the training.
For those of you who live in the San Francisco Bay Area, a Cyrax 2400 (the previous model) was used to scan the existing I-880 / US-101 interchange in order to obtain a starting point for designing the new interchange they are currently building. The next time you are travelling south-bound on I-880 near the Montague Expressway exit, look at the paved shoulder and see if the spray-painted "scan 101" etc. marks are still there, indicating where the parked the "scan van" to take each of the scans they stitched together to get the entire interchange model.
If you're gaming, I suppose the drive would be spinning much more often, but then you've usually got the game music/sfx playing fairly loudly anyway
You can eliminate most CD-ROM noise by using CloneCD to image the data CDs you use often, and then using something like Daemon-Tools to mount these images. This works (in Windows systems, anyway) even with most copy-protected game CDs, as Daemon-Tools emulates most CD copy protections. This assumes you have large hard disks...
Sorry to reply to myself, but I noticed a lot of talk about sharing of 2.4 MHz of spectrum by all of the users in a cell sector. Just to compare this with i-BURST: 4 bits/sec/Hz, which provides 40 Mbits/s of useable bandwidth in a 10 MHz band, or 28.8 Mbits/s in the 7.2 MHz of spectrum mentioned, and that is un-sectorized (omni antennas). The capacity just goes up as you add sectors, because each sector acts as a separate basestation, so to speak. This capacity is possible because spatial channels allow the SAME channel to be simultaneously used by multiple users, as long as they are not co-located.
Slashdot Mirror
This one?
The TMobile "Even More Plus" plans in the U.S. do, in fact, offer lower rates because the do not subsidize a phone. They are BYOP (bring your own phone) plans (or buy one from TMobile at regular price, with financing, etc.).
That, or you can create your own network by putting up one cell in a remote location like Montana (can't remember the exact place) and do everything else through roaming agreements. You don't think that Virgin Mobile owns their own network in the U.S., do you?
believe it or not there is an icon for Hotmail there as well as Yahoo, Hulu, Facebook, Twitter and the rest is Google apps
Why does this surprise you? Android, another Google-authored operating system (but for smartphones as you likely already know), comes with bookmarks in the browser for all sorts of non-Google properties.
What's with this cynical belief that Google is so self-serving?
Your statements are similar to those who believe Google tries to lock users into its services without ever having visited The Data Liberation Front.
Are you jealous of Google's success or something petty like that?
...with another OS from a giant company that's trying to tie all its services together to lock you in.
Never heard of The Data Liberation Front, I presume?
with their own version of the app store and installation verification
Or, even better, pointed the built-in camera at a URL barcode displayed on a laptop screen and downloaded the .apk file...
Java/Dalvik development only
As has been mentioned in previous posts, native C++ development is available via the Android NDK. Even native access to OpenGL is supported.
with their own version of the app store and installation verification
I guess you never clicked on a URL (in the built-in browser on the phone) that points straight to an Android Package (.apk) file and simply allowed the phone to install it. No "app store" required.
There are times when the Kindle edition can save you a substantial amount:
$1519.05 off the price of the hardcover version in this case.
If you are searching for code, use Google Code Search. It supports regular expression matching, but it only searches source files (not the entire Web).
What we've found is that code reviews take forever...
Ugh. Are you reviewing each individual commit (where code reviews are quick and very effective), or are you rounding up a bunch of developers in a conference room and reviewing an entire module using an overhead projector?
Peer-to-peer reviews of individual diffs using good workflow tools have been very effective at several places I have worked and in open-source projects to which I have committed.
Some of the fastest team development velocity I have experienced has been with peer code reviews within the team.
A good style guide also helps...
Wow. Only 5 comments and the site is already returning 500 errors.
I would suggest keeping the battery pack warm using the same power source that is being used to charge the battery. Also, insulate the battery pack, since the batteries typically warm themselves as a result of being discharged, due to their own internal resistance.
This mainly becomes an issue if you park the car somewhere for a long time in a place that is cold, but there is no way to plug the car in. I suspect that parking garages would start offering electrical outlets for charging the parked vehicles. Smart grids would probably help with this, causing the car owner to be billed for the electricity used to charge and pre-warm the car (or credited, if the car contributed excess electricity to the grid during daytime peak hours in periods of relatively mild weather).
Similarly, the car interior could be pre-warmed (or pre-cooled in the summer) when plugged in.
Google, at least, supports user data portability, and not just with. social networking.
GMail lets you import and export your contacts in a variety of formats and access your email (for back-up or whatever) via IMAP and POP.
Picasa syncs the web albums to your local machine (and runs under Linux, thanks to Google's open source contributions to Wine).
Blogger lets you push blog content elsewhere.
There are probably more (like stuff you can access via GData APIs), but these are just the ones I could think of off the top of my head.
Android includes an OpenGL API. I have personally seen Quake 1 running on the TMobile G1, which has an on-board GPU as part of the Qualcomm chipset in the phone.
.so files would be bundle-able in .apk files soon. These libraries would be accessible via JNI. They would initially only have access to libc and libm in the first incarnation, though.
Also, at the recent Google Summer of Code mentor summit in October, an Android engineer mentioned in a presentation to attendees that native (ARM) code
So, yes, I do believe Android is a mobile gaming platform.
(This was discussed in a public forum at an open source conference hosted at Google, so I don't believe it is secret information...)
Ummm, no. The underlying Linux system is not exposed to the Android app developer. Only the Android APIs in Java are. So, Android is a platform by itself, unless people start porting the Dalvik VM and the Android Java code to LiMo and other embedded Linux variants.
Apps written for one do not run on the other, so that makes it a different platform. I suspect that "Linux" shouldn't be lumped together the way it is in that statistic, either. How many of those are QTopia-based, or some other UI stack on top of embedded Linux?
Really? According to:
http://code.google.com/chromium/terms.html
it looks like BSD for the Google-authored parts.
If I need to exchange documents with someone that needs to edit it, I just send them a link to the document uploaded into Google Docs. No need for a big, chunky email attachment.
Sounds like you are working at the wrong company. Perhaps you should work at some place like Google, where the engineers drive innovation from the bottom up.
Hmmm, sounds like a job for some sort of challenge-response system using PKI. This is quite do-able, if every mine has a Certificate Authority public key and modulus embedded in it, and the commands are signed with the CA private key. There are plenty of digital signature and public key exchange methods that are suitably secure. The mine just needs to use one of these to verify that the received commands are legitimate.
In fact, I wouldn't be surprised if the mines themselves didn't have a private key embedded in them that they used to decrypt signed information sent to them from the other mines. You would certainly want the mines to hide what they are exchanging from outside listeners and also be able to confirm that anything they received was from a valid mine (not some rogue mis-informer).
Actually, it would be more computationally efficient for the mines to use PKI to exchange a "shared secret" and then switch to some symmetric cipher (AES, anyone?) using that shared secret to exchange status and "strategy" information after that.
This sounds more like a bug in the controllers inside the Flash cards than the actual choice of filesystem. Most Flash card formats (CompactFlash, MemoryStick, MMC/SD) contain a microcontroller that does wear-leveling and ECC. So, logical block zero of the device does not remain physical device zero if that block gets worn out. There are lots of references on the web discussing the microcontrollers in various Flash cards, for example this article (linked via Google cache because the original is a PDF).
These microcontrollers are precisely the reason why it is not a good idea to use these formats in devices that can be powered off suddenly. Look here (search down for "asynchronous power fail" for a mention of these problems. Elsewhere on the site (and in the JFFS author's other online comments), more discussion of this problem is available, including the JFFS author's own experiments.
JFFS works with MTD devices, which are flat Flash arrays with no microcontroller (and the JFFS author doesn't plan on supporting ATA-type Flash cards, although it appears others may be working on this). This gives JFFS complete control over journalling, wear-leveling, and error correction. It is able to do these things in a fashion that is robust in the face of asynchronous power failures. The microcontrollers in various Flash cards do not appear to be this sophisticated.
So, 1) it may not be the choice of filesystem that is the problem, 2) there are documented reasons for not using Flash cards in certain types of systems, and 3) JFFS (and JFFS2), even if they support non-MTD devices now, probably cannot safeguard against the problems in microcontroller-based Flash cards.
About two years ago, I worked for Cyra, the company whose Cyrax 2500 they are using to scan these monuments. The device is pretty cool, but expensive at US $125,000 for one unit, not including any license seats of the Cyclone software you need to manipulate the HUGE data sets that the device generates. All you get from the device is a cloud of individual points. It really takes the software that runs on the PC (Cyclone) to turn the point clouds into surfaces and then into files compatible with CAD systems like AutoCAD and Microstation.
By the way, it is a good thing that none of these monuments that they are scanning with the Cyrax 2500 are red. The green laser used by the unit doesn't even see some shades of red. There was a bright red toolbox in the lab that would crash the scanner every time until we got the "no-return timeout" code right.
It's too bad the company is in such a bad financial situation. The device is really cool, but the slowing US economy has really put the brakes on large capital expenditures like the Cyrax 2500, even though many studies have shown that the labor costs savings and the improved accuracy of the results more than make up for the cost of the device and the training.
For those of you who live in the San Francisco Bay Area, a Cyrax 2400 (the previous model) was used to scan the existing I-880 / US-101 interchange in order to obtain a starting point for designing the new interchange they are currently building. The next time you are travelling south-bound on I-880 near the Montague Expressway exit, look at the paved shoulder and see if the spray-painted "scan 101" etc. marks are still there, indicating where the parked the "scan van" to take each of the scans they stitched together to get the entire interchange model.
I guess I've rambled on long enough...
If you would actually read the Moller and Freedom Motors web sites, you would see that it is not a gearbox, but a rotary engine. Learn to read.
You can eliminate most CD-ROM noise by using CloneCD to image the data CDs you use often, and then using something like Daemon-Tools to mount these images. This works (in Windows systems, anyway) even with most copy-protected game CDs, as Daemon-Tools emulates most CD copy protections. This assumes you have large hard disks...
Sorry, what I meant to say is that CDMA became commercially popular in Korea first.
Sorry to reply to myself, but I noticed a lot of talk about sharing of 2.4 MHz of spectrum by all of the users in a cell sector. Just to compare this with i-BURST: 4 bits/sec/Hz, which provides 40 Mbits/s of useable bandwidth in a 10 MHz band, or 28.8 Mbits/s in the 7.2 MHz of spectrum mentioned, and that is un-sectorized (omni antennas). The capacity just goes up as you add sectors, because each sector acts as a separate basestation, so to speak. This capacity is possible because spatial channels allow the SAME channel to be simultaneously used by multiple users, as long as they are not co-located.