Actually, it's worse. Android maintains an arbitrary distinction between "coarse" location invariably meaning "network/tower-based", and "fine" location invariably meaning "GPS-based". The problem is, lots of Android phones have GPS that's basically dysfunctional indoors (*cough* entire Samsung Galaxy S family with official firmware), and network-based location doesn't work in places where you might have no 3G signal, but have wi-fi (like a foreign country with roaming disabled).
First to address that last point: I've never had a problem with wifi-only positioning, except for it being imprecise. However it may not work at all if there are no access points in range for which Google has location data.
As for your general point:
Honestly, there is a bit of an issue.
For example while GPS works in my dwelling, it provides a position fix no more accurate (albeit more precise) than the coarse location, when I have both Wifi and Phone enabled.
It turns out that due to the number of WiFi points in range of my dwelling, a WiFi only fix gives data with an uncertainty of a yard or two. However, Google has erred on the side of caution and artificially increases the circle of uncertainty by a substantial amount. The end uncertainty with both Cell and Wifi is 5-10 times that of GPS, despite the center of the circle actually being just as accurate.
With the phone off (coarse location using only WiFi), the circle of uncertainty increases by a factor of 2, despite zero change in the identified position.
With no WiFi, I get a a very coarse position, which cannot even positively identify which two suburbs I live right on the edge of.
I actually find how "fine" the cell+WiFi coarse position is to be a bit unsettling, as it would positively identify my apartment complex!
In reality, Android's location services should make use of all sources of location information available to it, but blur and dither it to reduce its accuracy when the user requests "coarse" location.
The difference is that Cell+WiFi positioning information uses almost zero additional power on a device, because the phone already has the cell tower, and list of nearby access points as a consequence of having those features enabled. From there, all it takes is a quick query to Google, and you get positioning information. On the other hand, the GPS chip in most Android phones draws more power than any other single component expect possibly the screen. Therefore, you really don't want to be running it to get only a "coarse" location.
My understanding is that First to File actually strengthens prior art. For First to Invent, the prior art must have been published a year before the application was filed, otherwise, what you have is not a question of prior art, but a question of who invented first.
My understanding is that for First to File, if there was prior art from the day before the application, then too bad for the filing company, they get nothing.
As I understand it, First to File basically does not distinguish between prior art, and earlier patenet applications. Either prior art or earlier applications would be handled exactly the same way in rejecting or limiting a patent.
That assumes you have installed Koush's or ChainsDD's Superuser app, which admittedly pretty much all rooted "ROM"s and pretty much all instructions for rooting a phone contain, so in practice it is always installed. However, please note that any app that exploits a kernel flaw to gain root could bypass the superuser application.
Google will be porting the UI to phones, at least wherever it makes sense. Some of the changes to the built-in apps that really depend on the extra screen space will not make it back to the phones, which will usesomething different, likely whatever is currently being done for those apps on phones.
But the on-screen buttons for example is a feature that will (has already been confimed) be coming to phones[1] (although it will likely only show up on phones designed without the corresponding physical buttons.) I also fully expect the overflow menu feature to come to phones since it is far too easy to forget about the menus currently displayed by the menu key.
[1] and has in fact long been permitted in in the Android Compatibility Definition Document, in anticipation of somebody doing the work. Nobody else stepped up so Google did it as part of Honeycomb.
A Samsung Galaxy Tab is currently just an over-sized Android smartphone, down to literally still being a phone! Honecomb will add a bit more differentiation between the Android phones and tablets, but the Framework and Kernel have relatively few differences from gingerbread, and those changes will almost certainly find their way to smartphones where relevant.
The real differences are in the built-in apps.For example, even when the UI changes of Honeycomb comes to phones, the version of the start screen seen on the tablets will probably not be present, simply because something like the current phone start-screen makes better sense for a phone.
I don't know. But apparently the Microsoft icon is still Borg-Gates, but a redesigned version of it! That simply makes no sense. Borg-Ballmer might make good sense now, or the image of a chair being thrown, but Borg-Gates is simply obsolete.
Total possible bandwidth scales with the number of towers in a nice clean way only when the towers are optimally positioned. If I have 5 towers positioned well, and I want to add another, unless I move all but one of the existing towers I will likely get of gain of only a percent or two from that tower, rather than the closer to 20%[1] I would get if they were positioned optimally.
Moving towers is prohibitively expensive, so it is just not done. Similarly fr various reasons (e.g. NIMBY, or skyscraper/mountain in the way) optimal placement is often not possible to begin with, much less to maintain as cells are added.
Lastly even if we did install more optimally placed towers in a perfect world where moving towers has no cost, and nothing obstructs optimal placement, there is little that can prevent the problems hat will happen when thousands or tens of thousands of smartphones gather in one place, (for example, at the Super Bowl.) Wiring up enough zeptocells[2] to support that would cost far, far more than all the revenue generated for the Super Bowl. At that point yuo might as well just provide an Ethernet port per seat. (Imagine the huge number of switches and routers needed to support that!)
Footnotes:
[1] Due to it being difficult to create towers whose signals create something like a square or hexagon rather than a circle, I would have overlap and thus not get th full 20% even with optimal placement, but I'd get a lot closer than just adding a tower in some random spot.
[2] Zeptocells of course being even smaller than femptocells, since the area of signal provided by femptocells would still likely be too large.
NAT64 (as commonly presented as an ISP level-solution[1]) is idiotic because of the DNS abuse it uses (DNS64).
DsLite seems far preferable to me based only on that consideration. DsLite is also what pretty much everybody has been expecting the whole time. Assign users routable IPv6 prefixes, and throw their IPv4 addresses behind "carrier-grade" NAT. Most users will not even notice the "carrier-grade" NAT. Those that do can pay more for the routable IPv4 addresses free up by gradually transitioning most users to the "carrier-grade" NAT.
The system also creates pressure on services that want to connect directly to clients to implement IPV6, which should help get IPv6 up off the ground. The eventual goal needs to be getting to the day that man devices have turned the IPv4 stack off completely, because every machine they want to talk to is available via IPv6, so the IPv4 Stack would be merely wasting resources.
[1] Rather than the literal meaning of the term, which would be any NAT system with v6 "private" and v4 public, which might have reasnable use cases that don't requiring abusing DNS. A DNS server should simply be serving up a text file via pattern matcihing (non-recursive), or query other servers and passing along the unedited results[2] (recursive). Any dynamic behavior (including dynamic DNS, DNS-based load balancing, DNS-based geolocation routing, dynamic reverse DNS, and DNS64) is an abuse of the system that should be avoided whenever possible.
[2] Possibly passing back all the results for the recusrive query in the case of DNSSec with a validating stub resolver.
You are welcome. I got hit by that same issue (but only since D3 was deployed), and just by good luck stumbled onto that page. The five comments at a time option is just idiotic.
Android devices have two main storage locations. One is internal storage. That term specifically refers to the device mounted on/data , in which user downloaded apps, and internal app data is stored. (This is in reality pretty much always a partition on the same storage device as provides the partition mounted on/system (a.k.a. the "ROM")).
The other is known as shared storage, and it is invariably SD. On phones without an external SD card slot, this is either an internal SD card slot, or more frequently an SD chip soldered directly to the mainboard. Shared storage is mounted on/sdcard (or/sdcard is a symlink to the real mount location, either is permitted).
When somebody says SD Card in an Android Context they are referring to whatever is mounted on/sdcard.
Now to further complicate matters, a few phones have provided both internal shared storage and an external SD card slot for shared storage. That is a very bad idea, since it leads to all sorts of odd bugs, but they did it anyway.
To make matters even more confusing I am aware of at least one phone (the Droid 2) which uses a hard soldered SD chip for/system and/data, but provides no shared storage on it. It uses an external SD card slot for the shared storage.
Change the line that reads "Retrieve Few Comments" to read "Retrieve Many comments" by using the dropdown box. You might also want to set "Get Oldest Comments first" if it currently reads "Get Highest Rated Comments First".
Nice thanks. I actually did better than highlighting friends, and restored the original icons, while ensuring the icons still function as a link.
In case anybody finds it interesting: https://gist.github.com/801524 (Sorry about Gist's syntax highlighting making it hard to read, but you can click the raw link for the formatted text.)
No but XP only really supported one DPI setting. For non-(DPI aware) applications you need to scale all resources equally relative to the DPI. If you just display the font at the specified point size, and leave everything else unscaled, you end up with all sorts of display issues. Vista added support for that scaling.
Thanks. So now my Slashdot user stylesheet has been updated to fix that bug. It currently removes the gray border, makes the header and sidebar stay where they belong, makes they gray outlines around a comment thicker (more like they used to be with D2), and fixes the italics bug. Now all I need to do is add code to restore the friend/fan/foe/freak/... icons, and Slashdot will be relatively usable again.
Exactly. I'm about to publish a leak proving that alien lizards have infiltrated the highest levels of our governments. Just don't ask me for my sources, they're "confidential". Stay tuned to www.UFOleaks.com for more info!
I think you mean tune into ABC. They are currently airing a serial documentary abut these very aliens.
I think he meant that the subscribers should be checking their math again, so they notice the $25/month option is not worthwhile when the $0/month AOL provides everything they use (the email service, and even the AOL client).
Autodesk appears to have an AutoCAD for Mac product, but I have no idea if it is limited in some way, or if the HVAC specific components are Windows only. But it may well be that no decent vendor selection tool is available for non-Windows operating systems.
Of course, for your line of work, paying extra for a Mac may not make much sense, since it may not provide much (if any) additional benefit over Windows, considering the cost difference. For better or worse, GNU/Linux and other FOSS operating systems, don't have a culture that is particularly friendly to non-free software.
That is sort of the way of things. You have Windows which although flawed is good enough for many things, OS X which is only available (at least offically) for Apple Computers, and the free POSIX-style operating systems which are not particulary friendly to non-free software vendors. As far as desktops go, those are pretty much all of them worth considering. Other desktop systems do exist, like the Plan 9-based Inferno, or ReactOS, but those projects are obscure enough that support options are too limited for most people, including many slashdotters.
I find twitter is sometimes the best way to contact somebody if what you need to say is something you would be willing to post on a web forum related to the topic at hand. For example it is often the best way to ask questions of those who mod ROMs for phones, and other people who have significant online presence, but don't have a log with comments enabled, and have no posted e-mail address.
I can also see public figures using it as to post information that they would have otherwise posted on a blog or equivalent, without having to come up with enough to say to make the blog post a reasonable size. For example, Lawrence Lessig uses Twitter for that.
But I do take issue with using it like many people do, posting things that would normally be considered private, and often things that even their followers would not be interested in.
Actually the law is quite clear that gun cases are not permitted to be tagged, since that would make it far to easy for a gun to be stolen (pick any tagged cargo), and used in some crime.
To the best of my knowledge, full blown PCs generally don't have DSPs for that sort of thing, but simply use GPGPU techniques for this, which could be done even without GPU manufacturer support, but I believe for some common codecs they due provide special support.
However for mobile products, the DSP is often completely separate from the 3D graphics chip, and is often built into the CPU. (Well, not built into the the ARM core, but still on the same piece of silicon.)
Sample code for accelerating common codecs is often supplied, which could be modified to support WebM too by somebody familiar with Codecs and DSPs.
IE would not need a browser plugin. All they would need is the proper DirectShow/Media Foundation filters and codecs, and it would simply support WebM (it would also cause Windows Media Player, and many other windows apps to support WebM). Just like Safari would need merely need the proper Quicktime codecs, for WebM to just work.
Serious question: How is a five port Torx any different from a pentalobular? (Standard Torx's are also known as hexalobular, so it would make sense that a 5 point torx would be a pentalobular.)
Slashdot Mirror
Actually, it's worse. Android maintains an arbitrary distinction between "coarse" location invariably meaning "network/tower-based", and "fine" location invariably meaning "GPS-based". The problem is, lots of Android phones have GPS that's basically dysfunctional indoors (*cough* entire Samsung Galaxy S family with official firmware), and network-based location doesn't work in places where you might have no 3G signal, but have wi-fi (like a foreign country with roaming disabled).
First to address that last point: I've never had a problem with wifi-only positioning, except for it being imprecise. However it may not work at all if there are no access points in range for which Google has location data.
As for your general point:
Honestly, there is a bit of an issue.
For example while GPS works in my dwelling, it provides a position fix no more accurate (albeit more precise) than the coarse location, when I have both Wifi and Phone enabled.
It turns out that due to the number of WiFi points in range of my dwelling, a WiFi only fix gives data with an uncertainty of a yard or two. However, Google has erred on the side of caution and artificially increases the circle of uncertainty by a substantial amount. The end uncertainty with both Cell and Wifi is 5-10 times that of GPS, despite the center of the circle actually being just as accurate.
With the phone off (coarse location using only WiFi), the circle of uncertainty increases by a factor of 2, despite zero change in the identified position.
With no WiFi, I get a a very coarse position, which cannot even positively identify which two suburbs I live right on the edge of.
I actually find how "fine" the cell+WiFi coarse position is to be a bit unsettling, as it would positively identify my apartment complex!
In reality, Android's location services should make use of all sources of location information available to it, but blur and dither it to reduce its accuracy when the user requests "coarse" location.
The difference is that Cell+WiFi positioning information uses almost zero additional power on a device, because the phone already has the cell tower, and list of nearby access points as a consequence of having those features enabled. From there, all it takes is a quick query to Google, and you get positioning information. On the other hand, the GPS chip in most Android phones draws more power than any other single component expect possibly the screen. Therefore, you really don't want to be running it to get only a "coarse" location.
My understanding is that First to File actually strengthens prior art. For First to Invent, the prior art must have been published a year before the application was filed, otherwise, what you have is not a question of prior art, but a question of who invented first.
My understanding is that for First to File, if there was prior art from the day before the application, then too bad for the filing company, they get nothing.
As I understand it, First to File basically does not distinguish between prior art, and earlier patenet applications. Either prior art or earlier applications would be handled exactly the same way in rejecting or limiting a patent.
That assumes you have installed Koush's or ChainsDD's Superuser app, which admittedly pretty much all rooted "ROM"s and pretty much all instructions for rooting a phone contain, so in practice it is always installed. However, please note that any app that exploits a kernel flaw to gain root could bypass the superuser application.
Google will be porting the UI to phones, at least wherever it makes sense. Some of the changes to the built-in apps that really depend on the extra screen space will not make it back to the phones, which will usesomething different, likely whatever is currently being done for those apps on phones.
But the on-screen buttons for example is a feature that will (has already been confimed) be coming to phones[1] (although it will likely only show up on phones designed without the corresponding physical buttons.)
I also fully expect the overflow menu feature to come to phones since it is far too easy to forget about the menus currently displayed by the menu key.
[1] and has in fact long been permitted in in the Android Compatibility Definition Document, in anticipation of somebody doing the work. Nobody else stepped up so Google did it as part of Honeycomb.
A Samsung Galaxy Tab is currently just an over-sized Android smartphone, down to literally still being a phone! Honecomb will add a bit more differentiation between the Android phones and tablets, but the Framework and Kernel have relatively few differences from gingerbread, and those changes will almost certainly find their way to smartphones where relevant.
The real differences are in the built-in apps.For example, even when the UI changes of Honeycomb comes to phones, the version of the start screen seen on the tablets will probably not be present, simply because something like the current phone start-screen makes better sense for a phone.
I don't know. But apparently the Microsoft icon is still Borg-Gates, but a redesigned version of it! That simply makes no sense. Borg-Ballmer might make good sense now, or the image of a chair being thrown, but Borg-Gates is simply obsolete.
Total possible bandwidth scales with the number of towers in a nice clean way only when the towers are optimally positioned. If I have 5 towers positioned well, and I want to add another, unless I move all but one of the existing towers I will likely get of gain of only a percent or two from that tower, rather than the closer to 20%[1] I would get if they were positioned optimally.
Moving towers is prohibitively expensive, so it is just not done. Similarly fr various reasons (e.g. NIMBY, or skyscraper/mountain in the way) optimal placement is often not possible to begin with, much less to maintain as cells are added.
Lastly even if we did install more optimally placed towers in a perfect world where moving towers has no cost, and nothing obstructs optimal placement, there is little that can prevent the problems hat will happen when thousands or tens of thousands of smartphones gather in one place, (for example, at the Super Bowl.)
Wiring up enough zeptocells[2] to support that would cost far, far more than all the revenue generated for the Super Bowl. At that point yuo might as well just provide an Ethernet port per seat. (Imagine the huge number of switches and routers needed to support that!)
Footnotes:
[1] Due to it being difficult to create towers whose signals create something like a square or hexagon rather than a circle, I would have overlap and thus not get th full 20% even with optimal placement, but I'd get a lot closer than just adding a tower in some random spot.
[2] Zeptocells of course being even smaller than femptocells, since the area of signal provided by femptocells would still likely be too large.
NAT64 (as commonly presented as an ISP level-solution[1]) is idiotic because of the DNS abuse it uses (DNS64).
DsLite seems far preferable to me based only on that consideration. DsLite is also what pretty much everybody has been expecting the whole time. Assign users routable IPv6 prefixes, and throw their IPv4 addresses behind "carrier-grade" NAT. Most users will not even notice the "carrier-grade" NAT. Those that do can pay more for the routable IPv4 addresses free up by gradually transitioning most users to the "carrier-grade" NAT.
The system also creates pressure on services that want to connect directly to clients to implement IPV6, which should help get IPv6 up off the ground. The eventual goal needs to be getting to the day that man devices have turned the IPv4 stack off completely, because every machine they want to talk to is available via IPv6, so the IPv4 Stack would be merely wasting resources.
[1] Rather than the literal meaning of the term, which would be any NAT system with v6 "private" and v4 public, which might have reasnable use cases that don't requiring abusing DNS. A DNS server should simply be serving up a text file via pattern matcihing (non-recursive), or query other servers and passing along the unedited results[2] (recursive). Any dynamic behavior (including dynamic DNS, DNS-based load balancing, DNS-based geolocation routing, dynamic reverse DNS, and DNS64) is an abuse of the system that should be avoided whenever possible.
[2] Possibly passing back all the results for the recusrive query in the case of DNSSec with a validating stub resolver.
You are welcome. I got hit by that same issue (but only since D3 was deployed), and just by good luck stumbled onto that page. The five comments at a time option is just idiotic.
Android devices have two main storage locations. One is internal storage. That term specifically refers to the device mounted on /data , in which user downloaded apps, and internal app data is stored. (This is in reality pretty much always a partition on the same storage device as provides the partition mounted on /system (a.k.a. the "ROM")).
The other is known as shared storage, and it is invariably SD. On phones without an external SD card slot, this is either an internal SD card slot, or more frequently an SD chip soldered directly to the mainboard. Shared storage is mounted on /sdcard (or /sdcard is a symlink to the real mount location, either is permitted).
When somebody says SD Card in an Android Context they are referring to whatever is mounted on /sdcard.
Now to further complicate matters, a few phones have provided both internal shared storage and an external SD card slot for shared storage. That is a very bad idea, since it leads to all sorts of odd bugs, but they did it anyway.
To make matters even more confusing I am aware of at least one phone (the Droid 2) which uses a hard soldered SD chip for /system and /data, but provides no shared storage on it. It uses an external SD card slot for the shared storage.
You can fix this yourself.
Go to http://slashdot.org/prefs/d2
Change the line that reads "Retrieve Few Comments" to read "Retrieve Many comments" by using the dropdown box.
You might also want to set "Get Oldest Comments first" if it currently reads "Get Highest Rated Comments First".
Nice thanks. I actually did better than highlighting friends, and restored the original icons, while ensuring the icons still function as a link.
In case anybody finds it interesting: https://gist.github.com/801524
(Sorry about Gist's syntax highlighting making it hard to read, but you can click the raw link for the formatted text.)
No but XP only really supported one DPI setting. For non-(DPI aware) applications you need to scale all resources equally relative to the DPI. If you just display the font at the specified point size, and leave everything else unscaled, you end up with all sorts of display issues. Vista added support for that scaling.
Thanks. So now my Slashdot user stylesheet has been updated to fix that bug. It currently removes the gray border, makes the header and sidebar stay where they belong, makes they gray outlines around a comment thicker (more like they used to be with D2), and fixes the italics bug. Now all I need to do is add code to restore the friend/fan/foe/freak/... icons, and Slashdot will be relatively usable again.
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("slashdot.org") {
body {
padding: 0 !important;
}
i { font-style: italic; !important}
div.col_1
{
position: absolute !important;
padding-top: 40px !important;
}
header.h
{
position: absolute !important;
margin-top: 0px !important;
padding-top: 0 !important;
}
header.h hgroup
{
border-radius: 0 0 0 0 !important;
margin:0 !important;
}
div.col_2
{
padding-top: 40px !important;
}
li.comment
{
border: 2px solid #C8C8C8 !important;
}
}
Exactly. I'm about to publish a leak proving that alien lizards have infiltrated the highest levels of our governments. Just don't ask me for my sources, they're "confidential". Stay tuned to www.UFOleaks.com for more info!
I think you mean tune into ABC. They are currently airing a serial documentary abut these very aliens.
I think he meant that the subscribers should be checking their math again, so they notice the $25/month option is not worthwhile when the $0/month AOL provides everything they use (the email service, and even the AOL client).
Autodesk appears to have an AutoCAD for Mac product, but I have no idea if it is limited in some way, or if the HVAC specific components are Windows only. But it may well be that no decent vendor selection tool is available for non-Windows operating systems.
Of course, for your line of work, paying extra for a Mac may not make much sense, since it may not provide much (if any) additional benefit over Windows, considering the cost difference. For better or worse, GNU/Linux and other FOSS operating systems, don't have a culture that is particularly friendly to non-free software.
That is sort of the way of things. You have Windows which although flawed is good enough for many things, OS X which is only available (at least offically) for Apple Computers, and the free POSIX-style operating systems which are not particulary friendly to non-free software vendors. As far as desktops go, those are pretty much all of them worth considering. Other desktop systems do exist, like the Plan 9-based Inferno, or ReactOS, but those projects are obscure enough that support options are too limited for most people, including many slashdotters.
I find twitter is sometimes the best way to contact somebody if what you need to say is something you would be willing to post on a web forum related to the topic at hand. For example it is often the best way to ask questions of those who mod ROMs for phones, and other people who have significant online presence, but don't have a log with comments enabled, and have no posted e-mail address.
I can also see public figures using it as to post information that they would have otherwise posted on a blog or equivalent, without having to come up with enough to say to make the blog post a reasonable size. For example, Lawrence Lessig uses Twitter for that.
But I do take issue with using it like many people do, posting things that would normally be considered private, and often things that even their followers would not be interested in.
Actually the law is quite clear that gun cases are not permitted to be tagged, since that would make it far to easy for a gun to be stolen (pick any tagged cargo), and used in some crime.
To the best of my knowledge, full blown PCs generally don't have DSPs for that sort of thing, but simply use GPGPU techniques for this, which could be done even without GPU manufacturer support, but I believe for some common codecs they due provide special support.
However for mobile products, the DSP is often completely separate from the 3D graphics chip, and is often built into the CPU. (Well, not built into the the ARM core, but still on the same piece of silicon.)
Sample code for accelerating common codecs is often supplied, which could be modified to support WebM too by somebody familiar with Codecs and DSPs.
IE would not need a browser plugin. All they would need is the proper DirectShow/Media Foundation filters and codecs, and it would simply support WebM (it would also cause Windows Media Player, and many other windows apps to support WebM). Just like Safari would need merely need the proper Quicktime codecs, for WebM to just work.
e-Fuses would be PROMS, not EPROMs (although many later generation PROMS were EPROMs without the window for erasing.)
But e-fuses are just PROM bits found on a chip that also contains digital logic (so would not be using a PROM specific fabrication process.)
Indeed, all P problem (or NP problems for that matter) are PSPACE.
In the video M.J. describes what is in the kit as a five pointed philips, not a 5 sided torx, but that may have just been a slip-up on her part.
Serious question: How is a five port Torx any different from a pentalobular? (Standard Torx's are also known as hexalobular, so it would make sense that a 5 point torx would be a pentalobular.)