Sure, any reasonably sized city can do it. But contrary to popular belief most people in the United States don't live in a reasonably sized city. Some figures calculate that as little as 30% live in the cities themselves, while over 50% live in much sparser suburbs around the cities. The suburbs are are far more expensive to provide decent public transit than the actual cities. In the suburbs putting a bus stop more than say every mile or two is just too expensive. But having to walk half a mile just to get to the bus stop is less than ideal. In the inner city bus stops are sometimes placed as close together as 3 city blocks, which is a much more reasonable walk.
Also don't forget about the 10-20% of the population that live in in rural areas. They often have no public transit at all.
The desiccant process be done by removing some amount of the brine, boiling excess water away in a separate tank, which then lets it cool to the exterior ambient temperature, and finally pumps it back into the main system. Also remember that heating is generally considered far cheaper than cooling, so the heating is not really the concern.
Honestly, I would be more concerned that if blowing air though a wet screen cools it (or rather it cools the water, which cools the evaporating pad which cools the air, then doesn't the process of removing the moisture also heat the air? So You first remove the moisture to make the evaporative cooling process more efficient, but by doing so you heated the air? that does not sound right. I'm probably missing something here, but I really cannot remember my fluid physics well enough to figure out what it is.
Somebody who listens to your tor traffic at your end has absolutely no way of telling who you are communicating with. so who you are talking to is just as hidden as what you say. All packets in the tor network are encrypted in such a way that the contents are only ever known by the exit node. There is little point in using SSL if sending a file to wikieaks via tor, since only wikileaks and the exit node would see the plaintext even over plain old http, and neither would be able to determine who or where the sender was. If wikileaks is going to publish what you sent anyway, so the exit node could see it upon publication, there is little reason to hide anything, unless there is identifying information in your submission that wikileaks has agreed not to republish. In that case using SSL over tor to talk to wikileaks makes good sense.
You would use SSL over Tor only if there was some reason why the it would be undesirable for the exit node to hear what you are saying, and you also want to hide your identity or perhaps only your location from the server you are talking to.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas.
Wrong. The Canadian population is even more thinly spread (a larger country than the USA with 1/10th the population) yet every city and/or province has public transport.
No. Most of Canada is uninhabited. The United States has far, far more inhabited land than Canada has. You are thinking of population density. The population density of Canada would be exactly the same if everybody lived within one square mile of each other, or if everybody was spread out equally.
What I am refering to is something akin to residential density.
The concept I an using could be: For each person take the number of people who live within 1 mile of said person. Sum those numbers, and divide by the total number of people.
Equivalently that would be average number of people who live within a mile of any chosen person.
One could also consider that I am talking about a measure of how clustered the population is. A population that has the vast majority of people living in tight clusters.
Canada is reasonably close to the united states in measures like this, but Canada is also not actually that much better off than the united states in public transportation relative to some other parts of the world. Much of the differences between Canada and the US in terms of public transit are due to the united state's car obsessed culture, which I did mention as part of the cause of poor public transit in many U.S. cities. If you had read my complete post, you would have noticed that.
Really? The desiccant being used is brine based on salts like calcium chloride. Any water from the air that becomes liquid while touching the solution will become part of the solution. witha suffiently high humidity level water molecules in the air is more likely to spontaneously condense near the brine, and mix with it, than for molecules in the brine to spontaneously become gaseous and leave (a.k.a. evaporate), since the later requires more energy than the former provides.
So with sufficiently humid air, water tends to leave the air for the brine. Now, that means that the brine becomes less concentrated over time, and becomes a less efficent dessicant.
Like most desiccants there are two ways to reuse it. One is to heat it, the other is to expose it to sufficiently dry air. In this process, you heat it, as the summary mentions.
Your points are fair, with a small caveat on the last one. It might be possible that something that works well in annother country will not work well here.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas. In all areas for public transportation to be convenient enough for people to use, there must be many stops. However, each stop cost money, and in low population density areas it may not be possible to recoup the costs if you have many stops, so they have fewer if there is a public transportation system in place at all. That explains a fair bit of the lack of good public transit in the US. There are other reasons though, such as a culture where owning a car is viewed as pretty important, even by those who really have no need for one. That helps explain why even in many cities the public transit is often not particularly good (although it is definitely far better than the public transit outside the cities), and the lack of good intercity public transit.
By similar mechanisms it is just as possible that some of the solutions used elsewhere will not work. That is of course not to say that no solution will work for the United States, but not all the systems that work elsewhere will necessarily work here. I would certainly agree that anybody who wants to argue that a specific system that works elsewhere will not work here should be ready to provide argument as to why that would be the case.
No. You are not necessarily instantly dead. First of all, it really depends on your definition of dead. A dead body is still organically live for some period of time after clinical death, brain death, or most other definitions of death.[1]
Even if we use a definition of death as "the permanent and irreversible loss of higher order brain functionality", decapitation is immediately fatal, but does not cause immediate death. Immediately fatal simply means that medicine currently is unable to prevent the person from dieing (or even significantly delay the death) as a result of the injury. The person can remain conscious for up to 20 seconds according to some accounts of experiments. Even once consciousness is lost, it could take some time before a completely irreversible (i.e. even future medical technology would never be able to reverse it) loss of higher order brain functioning.
A few things could cause immediate death using this definition of death. They include Being vaporized in an explosion, having the head completely flattened in an instant, or anything else that can completely decimate the structure of the brain in sufficiently short a period of time as to be considered instant.
However, a successful decapitation where the actual direct injury takes place quickly enough to be considered instantly might actually have very little pain. People with limbs that have been completely severed often experience "no pain", which may in truth be some level of pain but is considered very small relative to other pain that the person has previously experienced. In a similar fashion the pain from decapitation might be minimal. (Think more like a pin prick than say even a paper cut).
Footnotes:
[1] The individual cells can be very much alive and functioning, even when the composite organism is dead. Now, most of the cells lack the ability to survive without the proper functioning of the composite organism. The bacteria that live in symbiosis with (and are in fact essential to the proper functioning of ) the composite host may be able to survive the death of the composite organism. Said bacteria might reasonable be considered an integral part of the composite organism. Similarly parasites may be able to survive the death of the host, although they would not normally be classified s part of the host.
Sure, but approval voting is poorly suited for use in multiple seat elections.
The single seat version still encourages a two party system. (Although much less strongly than FPTP since it does show if a third party candidate had any significant support, while FPTP makes the third party candidate appear to have less support than they really do.)
However it has some issues. For example, it is possible if all voters vote honestly for the candidate who is the absolute last choice of a majority of the voters to still win the election. James Green-Armytage shows how this is possible.
The system you describe is a version of approval voting. You mark the candidates you approve of and leave the ones you don't unmarked. The one with the highest number of marks gets the first seat, the next gets the second, and so on.
If there exists a third party candidate that supporters of both parties like, he (or she) is likely to have the most votes and win. That is desirable.
It avoids the problem of spoiler candidates, assuming the voter votes for both the would-be spoiler and the likely winner.
However it has downsides. If there were for example two republicans and one democrat on the ballot (in addition to other candidates), the republican voters would feel the need to vote for both of the candidates,to avoid the spoiler problem, that would allow the democrat to win even if most of the population would support a republican over a Democrat. However, when doing so they have no way of expressing a preference for one of the two republican candidates over the other. That is not ideal. (Obviously, the scenario works equally as well if you swap the party names.)
The results that approval voting has in cases of multi-seat elections is unlikely to be proportional, but the type of results to be expected depend on the number of seats, and the number of clones (a technical term in voting theory, here it candidates that virtually always get the same vote on any ballot (i.e. if one is marked, all are marked)).
Yes, but AIUI the detailed billing available now is not the same detailed billing that was originally available. That 300 page bill would probably be something more like 10 pages under the current system. That original system was probably accounting for each an every packet, (possibly grouping all packets from a TCP connection together), while the modern detailed billing most definitely does not do that.
Correction. I slightly misunderstood the role of the internal storage. I know see that the 8GB chip (or 6 GB according to some sources) is indeed an internal SD card, but it is not actually treated specially. All normal user data is in the standard internal memory, and applications treat the 8GB or 6GB chip exactly like an SD card. No special code was written with regards to it. The idea was that apps are generally small, and any large amounts of data they store on the SD card, so keep the apps in real internal memory like normal, but allow programs to store data internally on the phone via the built-in SD card.
I am uncertain what happens when you insert an SD card into the external slot. I suspect it probably hides the internal sd card, and shows only the external one.
The Droid Incredible has what is basically a hard soldered 8 GB SD card in addition to normal internal storage, and the external SD card. It is being written there (possibly only if there is no external SD card, I am unclear on that). As a result it is not being touched on a factory reset. HTC has customized the ROM on that phone in special ways to make the 8 GB internal memory look like regular internal memory. Factory reset would actually not work very well except for special code they wrote to delete things from the internal SD card on Factory reset, but that code is apparently imperfect.
True, except that a square shaped unit life cell's possibility of existing is not guarenteed by the turring completeness. Wall that was guaranteed was that some form of emulation was possible.
Further now that both those old patterns and this new patter have been found/designed, which is more important? I mean we already knew self-replication in CA was possible, thanks to Von Neumann Universal constructor. All we did not know is if Conway's CA could support a self-replicator. (A universal constructor not being possible, thanks to orphan patterns.)
No. What I was proposing was that the billing system track actual usage. You pay exactly what you used.
However the data line items in the bill have nothing to do with what you are charged. They are just a listing of what your phone reported. So your phone could report an Exabyte of usage but you used only 1 Gig, so you don't pay any overage.
Or you use 3 gigs, but the phone reported only a meg of usage. So the only data usage line would be for 1 MB, but the total data line would read 3GB, and you would be charged for exceeding the cap by 1 GB.
I.E. the individual lines are for the convenience of the end user in determining when data was used, but only the actual data used really matters.
Are you sure? I am positive the actual total data line item you are actually charged for is done on the carrier's end. To do anything else is idiotic.
However, it is entirely possible that the individual line items on the bill are as reported by the phone. That would explain why the time is variable, why some were reporting the numbers don't add up, and what at least one macrumors user reported: the line item does not show up if the phone is in airline mode or off, but does show up at the time the phone is turned backed on.
Fact 1: The bills don't seem to add up for everbody, but the total usage portions of the bill sound about right.
Fact 2: At least one users in airplane mode/off mode the charges will not show up until the phone is turned on.
Fact 3: The GSM-series 3G data technology is packet based, not connection based, so a fully itemized bill would list every packet. The other options for the phone company is to attempt to group collections of packets as pseudo-connections (which is not ideal), or itemize by day (or hour, etc), or have no data of itemization.
Presumption 1: People would prefer real itemization.
Conclusion 1: The 3G phone companies are keeping two books, at least for the iPhone. One tracks the actual data you used, packet by packet. The sum of this is accurate, and is what you are actually billed for.
Conclusion 2: The other book contains the connections as and data usage as reported by the phone. This allows for clear itemization, as the phone can determine which packets would be proper to group as a single connection. These are the line items that appear on the bill.
Conclusion 3: If the phone screws up the reporting in some way, weird data usage lines would appear on the bill, and the data usage may not add up.
Conclusion 4: The line items in question are probably a result of some glitch in the iPhone code that is misreporting things. It may be an attempt to account for push notifications, but the numbers are not always correct.
Conclusion 5: The billing departments are not aware of the double books, so they cannot assure customers that the line items shown are potentially erroneous, but that the amount actually billed will be correct.
Caveat 1: The above conclusions fit all the data I have seen, and I am not aware of any simpler explanation that accounts for everything, but one may exist.
Well, sure, that, a login token in the URL, or passed around by means of hidden fields in a form, are the only concievable ways of having a persistant login.
The other alternative is to wait till somebody performs any actions that require authentication and at the last possible second (already pushed the submit button on the form), and then ask them for the openID, go through the authentication process, and committing the action upon successful verification. But people generally want to be able to perform multiple actions without having to authenticate for each action.
But there are ways to make a login token harder to use even if sniffed, such as tying it to the IP address.
That would then require the sniffer to either (a) be behind the same NAT (if any) as you or (b) have full intercept and injection capability, as well as being on the routing path between you and the site. (That allows to to forge packets that claim to be from your IP, and prevent the replies from reaching you. Mere sniffing only requires that you get a copy of the packets, which is far simpler, since not everything does full switching. (Early cable modems (and perhaps even current ones) could be modified to run in promiscuous mode, delivering all packets on that cable line, which would normally include at least your whole neighborhood, and perhaps more.)
Thus (b) basically requires a rouge ISP, which is not particularly likely. However (a) is still a legitimate concern. Other techniques are also possible to make using the login token difficult, such as also tying it to your exact User-agent string, and your "accepts" header line, which most browsers don't make it easy to manually configure, and perhaps a few other things. That would make it enough of a pain to use your sniffed login tokens that only somebody particularly determined will be able to use them. For many uses that is probably good enough. For those where it is not, HTTPS is usually already the norm.
One of those is Deep Cell which is a version of the pattern that simulates two independant life universes with a period of only 7680.
Another is the OTCA megapixel, which is a unit life cell that is larger and slower, but makes it much easier to see the state of each cell. It can also be program to follow any life-like pattern of number of neighbors needed for birth and starvation, as well as programmed to igore any (or all) of the eight bordering cells in its determination. so you could have a pattern that ignored diagonals. Of course the OTCA megapixel itself only runs under the standard rules.
Alpha is indeed a good idea, but I still lament the implementation.
Many times I've wanted data that can be trivially calculated from data it has (I can pull up each peice individually, so I know they are there, but there are a few to many to exract one by one and then calculate on them), but I cannot find any working syntax.
If I could have a programmatic interface to individual data points. My original thought was something like:
for x in ["USA, UK, JAPAN"]:
for y in range(1979,2009):
AlphaData("WolframAlpha.Countries.%s.government_debt.historical.%s",x,y)
However, exposing each piece of data with a unique URL that can be programmatically constructed would be just as useful. I would feel no need to have the returned data link to their locations, but I could imagine that for an example like this having some links like for the next year, previous year, next country, previous country, and perhaps several other links could be useful, and would probably be easy enough for them to expose.
As for tagging:
I agree with your doubt. Unfortunately machines are nowhere near good enough yet to do all the necessary tagging. Songs and movies can probably be handled by calculating good fingerprints, and looking up metadata in a large curated database, but photos tagging is much less easy. People usually want them tagged by both location, and people in the photos. The people in the photos is actually the easier problem, unless the photo source has GPS and geotags the image on creation. But even an algorithm to automatically identifies the individuals in each picture tagging them (prompting the user for a name if it lacks one for the individual) is difficult technology, and out current attempts are not particularly promising.
The problem with most of the semantic web concepts is that it wants to add lots of metadata to everything, generally of a type that cannot be added automatically. I see how many people's music collections are extremely inconsistent with the metadata. Sometimes half the music is missing artist tags, and whatnot. Furter how many people actually have well tagged photo collections?
If people are not willing to tag their music and photos consistently, when it have active immediate benefits to them, what chance is there of getting them to tag information in their web pages, when that provides no immediate benefit, and quite possibly no benefit ever if the Semantic web does not catch on.
The idea of linked data on the other hand has a shot of working, but probably not in the way Tim Berners-Lee imagines it. RDF seems to have too much of a stigma attached to it.
hungarian notation is best used not to store actual datatype of the variable, but additional information beyond the raw datatype. So "strTitle" is worthless in a statically typed language, and at best questionable in a dynamically type language.
But "uTitle" to indicate an unsafe (unescped) title and "sTitle" to indicate an title that is safe (has been escaped) is a coding convention that makes plenty of sense. It is very possible to then automatically scan code to find violations of safety, such as any assignment of the form "sFirstName=uFirstName".
Extend the convention to functions, and one can automatically detect the problem with "sAddress=uGetAddress", or passing "sLastName" to a function with the prototype "int HashString(std::string uString)", which clearly wants an unescaped string.
One can also detect other unsafe or undesirable actions like escaping an already escaped string, or concatenating a safe and an unsafe string, etc.
Now when Charles Simonyi described the system initially he had not yet made the full distinction between type information the compiler already knows, and additional type information. Many, but not quite all of his examples in the original paper gave additional information. His lack of a full distinction is what led to many of the uses where Hungarian notation is not giving anybody any useful information.
Of course the best way to handle the whole thing is to have each semantic data-type be a distinct data-type to the compiler. So I would have both an "UnsafeString" and a "SafeString" data-type, and doing something unsafe like assigning one to the other directly would result in a compiler error. For dynamic languages, having a compile-time error is not feasible, but having two data-types and having unsafe operations result in a run-time error is still possible, and should be preferable to a successful injection attack.
I feel very similarly. IRC works just fine (although the practice of idling for hours is less than ideal). I do agree though that IM would still be preferable to those others if IRC was off the table.
I think part of this is that Facebook is nearly ubiquitous in the US, while in many other locations no one social networking site holds that level of market share. In the US SMS has caught on especially with those in high school (or those who have been in high school in the last year or two) because it can be discretely used while in class. They are then in the habit of using SMS.
Where the hell are you? In the United States, traditional Instant Messaging is virtually extinct. Twitter, Facebook chat, and SMS are used as replacements.
Slashdot Mirror
Sure, any reasonably sized city can do it. But contrary to popular belief most people in the United States don't live in a reasonably sized city. Some figures calculate that as little as 30% live in the cities themselves, while over 50% live in much sparser suburbs around the cities. The suburbs are are far more expensive to provide decent public transit than the actual cities. In the suburbs putting a bus stop more than say every mile or two is just too expensive. But having to walk half a mile just to get to the bus stop is less than ideal. In the inner city bus stops are sometimes placed as close together as 3 city blocks, which is a much more reasonable walk.
Also don't forget about the 10-20% of the population that live in in rural areas. They often have no public transit at all.
The desiccant process be done by removing some amount of the brine, boiling excess water away in a separate tank, which then lets it cool to the exterior ambient temperature, and finally pumps it back into the main system. Also remember that heating is generally considered far cheaper than cooling, so the heating is not really the concern.
Honestly, I would be more concerned that if blowing air though a wet screen cools it (or rather it cools the water, which cools the evaporating pad which cools the air, then doesn't the process of removing the moisture also heat the air? So You first remove the moisture to make the evaporative cooling process more efficient, but by doing so you heated the air? that does not sound right. I'm probably missing something here, but I really cannot remember my fluid physics well enough to figure out what it is.
Somebody who listens to your tor traffic at your end has absolutely no way of telling who you are communicating with. so who you are talking to is just as hidden as what you say. All packets in the tor network are encrypted in such a way that the contents are only ever known by the exit node. There is little point in using SSL if sending a file to wikieaks via tor, since only wikileaks and the exit node would see the plaintext even over plain old http, and neither would be able to determine who or where the sender was. If wikileaks is going to publish what you sent anyway, so the exit node could see it upon publication, there is little reason to hide anything, unless there is identifying information in your submission that wikileaks has agreed not to republish. In that case using SSL over tor to talk to wikileaks makes good sense.
You would use SSL over Tor only if there was some reason why the it would be undesirable for the exit node to hear what you are saying, and you also want to hide your identity or perhaps only your location from the server you are talking to.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas.
Wrong. The Canadian population is even more thinly spread (a larger country than the USA with 1/10th the population) yet every city and/or province has public transport.
No. Most of Canada is uninhabited. The United States has far, far more inhabited land than Canada has. You are thinking of population density. The population density of Canada would be exactly the same if everybody lived within one square mile of each other, or if everybody was spread out equally.
What I am refering to is something akin to residential density.
The concept I an using could be:
For each person take the number of people who live within 1 mile of said person.
Sum those numbers, and divide by the total number of people.
Equivalently that would be average number of people who live within a mile of any chosen person.
One could also consider that I am talking about a measure of how clustered the population is. A population that has the vast majority of people living in tight clusters.
Canada is reasonably close to the united states in measures like this, but Canada is also not actually that much better off than the united states in public transportation relative to some other parts of the world. Much of the differences between Canada and the US in terms of public transit are due to the united state's car obsessed culture, which I did mention as part of the cause of poor public transit in many U.S. cities. If you had read my complete post, you would have noticed that.
Really? The desiccant being used is brine based on salts like calcium chloride. Any water from the air that becomes liquid while touching the solution will become part of the solution. witha suffiently high humidity level water molecules in the air is more likely to spontaneously condense near the brine, and mix with it, than for molecules in the brine to spontaneously become gaseous and leave (a.k.a. evaporate), since the later requires more energy than the former provides.
So with sufficiently humid air, water tends to leave the air for the brine. Now, that means that the brine becomes less concentrated over time, and becomes a less efficent dessicant.
Like most desiccants there are two ways to reuse it. One is to heat it, the other is to expose it to sufficiently dry air. In this process, you heat it, as the summary mentions.
Your points are fair, with a small caveat on the last one. It might be possible that something that works well in annother country will not work well here.
For example public transportation systems that work well elsewhere don't work as well here. We simply have too many people living in low population density areas. In all areas for public transportation to be convenient enough for people to use, there must be many stops. However, each stop cost money, and in low population density areas it may not be possible to recoup the costs if you have many stops, so they have fewer if there is a public transportation system in place at all. That explains a fair bit of the lack of good public transit in the US. There are other reasons though, such as a culture where owning a car is viewed as pretty important, even by those who really have no need for one. That helps explain why even in many cities the public transit is often not particularly good (although it is definitely far better than the public transit outside the cities), and the lack of good intercity public transit.
By similar mechanisms it is just as possible that some of the solutions used elsewhere will not work. That is of course not to say that no solution will work for the United States, but not all the systems that work elsewhere will necessarily work here. I would certainly agree that anybody who wants to argue that a specific system that works elsewhere will not work here should be ready to provide argument as to why that would be the case.
No. You are not necessarily instantly dead. First of all, it really depends on your definition of dead. A dead body is still organically live for some period of time after clinical death, brain death, or most other definitions of death.[1]
Even if we use a definition of death as "the permanent and irreversible loss of higher order brain functionality", decapitation is immediately fatal, but does not cause immediate death. Immediately fatal simply means that medicine currently is unable to prevent the person from dieing (or even significantly delay the death) as a result of the injury. The person can remain conscious for up to 20 seconds according to some accounts of experiments. Even once consciousness is lost, it could take some time before a completely irreversible (i.e. even future medical technology would never be able to reverse it) loss of higher order brain functioning.
A few things could cause immediate death using this definition of death. They include Being vaporized in an explosion, having the head completely flattened in an instant, or anything else that can completely decimate the structure of the brain in sufficiently short a period of time as to be considered instant.
However, a successful decapitation where the actual direct injury takes place quickly enough to be considered instantly might actually have very little pain. People with limbs that have been completely severed often experience "no pain", which may in truth be some level of pain but is considered very small relative to other pain that the person has previously experienced. In a similar fashion the pain from decapitation might be minimal. (Think more like a pin prick than say even a paper cut).
Footnotes:
[1] The individual cells can be very much alive and functioning, even when the composite organism is dead. Now, most of the cells lack the ability to survive without the proper functioning of the composite organism. The bacteria that live in symbiosis with (and are in fact essential to the proper functioning of ) the composite host may be able to survive the death of the composite organism. Said bacteria might reasonable be considered an integral part of the composite organism. Similarly parasites may be able to survive the death of the host, although they would not normally be classified s part of the host.
Sure, but approval voting is poorly suited for use in multiple seat elections.
The single seat version still encourages a two party system. (Although much less strongly than FPTP since it does show if a third party candidate had any significant support, while FPTP makes the third party candidate appear to have less support than they really do.)
However it has some issues. For example, it is possible if all voters vote honestly for the candidate who is the absolute last choice of a majority of the voters to still win the election. James Green-Armytage shows how this is possible.
The system you describe is a version of approval voting.
You mark the candidates you approve of and leave the ones you don't unmarked. The one with the highest number of marks gets the first seat, the next gets the second, and so on.
If there exists a third party candidate that supporters of both parties like, he (or she) is likely to have the most votes and win. That is desirable.
It avoids the problem of spoiler candidates, assuming the voter votes for both the would-be spoiler and the likely winner.
However it has downsides. If there were for example two republicans and one democrat on the ballot (in addition to other candidates), the republican voters would feel the need to vote for both of the candidates,to avoid the spoiler problem, that would allow the democrat to win even if most of the population would support a republican over a Democrat. However, when doing so they have no way of expressing a preference for one of the two republican candidates over the other. That is not ideal. (Obviously, the scenario works equally as well if you swap the party names.)
The results that approval voting has in cases of multi-seat elections is unlikely to be proportional, but the type of results to be expected depend on the number of seats, and the number of clones (a technical term in voting theory, here it candidates that virtually always get the same vote on any ballot (i.e. if one is marked, all are marked)).
Yes, but AIUI the detailed billing available now is not the same detailed billing that was originally available. That 300 page bill would probably be something more like 10 pages under the current system. That original system was probably accounting for each an every packet, (possibly grouping all packets from a TCP connection together), while the modern detailed billing most definitely does not do that.
Correction. I slightly misunderstood the role of the internal storage. I know see that the 8GB chip (or 6 GB according to some sources) is indeed an internal SD card, but it is not actually treated specially. All normal user data is in the standard internal memory, and applications treat the 8GB or 6GB chip exactly like an SD card. No special code was written with regards to it. The idea was that apps are generally small, and any large amounts of data they store on the SD card, so keep the apps in real internal memory like normal, but allow programs to store data internally on the phone via the built-in SD card.
I am uncertain what happens when you insert an SD card into the external slot. I suspect it probably hides the internal sd card, and shows only the external one.
The Droid Incredible has what is basically a hard soldered 8 GB SD card in addition to normal internal storage, and the external SD card. It is being written there (possibly only if there is no external SD card, I am unclear on that). As a result it is not being touched on a factory reset. HTC has customized the ROM on that phone in special ways to make the 8 GB internal memory look like regular internal memory. Factory reset would actually not work very well except for special code they wrote to delete things from the internal SD card on Factory reset, but that code is apparently imperfect.
True, except that a square shaped unit life cell's possibility of existing is not guarenteed by the turring completeness. Wall that was guaranteed was that some form of emulation was possible.
Further now that both those old patterns and this new patter have been found/designed, which is more important? I mean we already knew self-replication in CA was possible, thanks to Von Neumann Universal constructor. All we did not know is if Conway's CA could support a self-replicator. (A universal constructor not being possible, thanks to orphan patterns.)
No. What I was proposing was that the billing system track actual usage. You pay exactly what you used.
However the data line items in the bill have nothing to do with what you are charged. They are just a listing of what your phone reported. So your phone could report an Exabyte of usage but you used only 1 Gig, so you don't pay any overage.
Or you use 3 gigs, but the phone reported only a meg of usage. So the only data usage line would be for 1 MB, but the total data line would read 3GB, and you would be charged for exceeding the cap by 1 GB.
I.E. the individual lines are for the convenience of the end user in determining when data was used, but only the actual data used really matters.
Are you sure? I am positive the actual total data line item you are actually charged for is done on the carrier's end. To do anything else is idiotic.
However, it is entirely possible that the individual line items on the bill are as reported by the phone. That would explain why the time is variable, why some were reporting the numbers don't add up, and what at least one macrumors user reported: the line item does not show up if the phone is in airline mode or off, but does show up at the time the phone is turned backed on.
Fact 1: The bills don't seem to add up for everbody, but the total usage portions of the bill sound about right.
Fact 2: At least one users in airplane mode/off mode the charges will not show up until the phone is turned on.
Fact 3: The GSM-series 3G data technology is packet based, not connection based, so a fully itemized bill would list every packet. The other options for the phone company is to attempt to group collections of packets as pseudo-connections (which is not ideal), or itemize by day (or hour, etc), or have no data of itemization.
Presumption 1: People would prefer real itemization.
Conclusion 1: The 3G phone companies are keeping two books, at least for the iPhone. One tracks the actual data you used, packet by packet. The sum of this is accurate, and is what you are actually billed for.
Conclusion 2: The other book contains the connections as and data usage as reported by the phone. This allows for clear itemization, as the phone can determine which packets would be proper to group as a single connection. These are the line items that appear on the bill.
Conclusion 3: If the phone screws up the reporting in some way, weird data usage lines would appear on the bill, and the data usage may not add up.
Conclusion 4: The line items in question are probably a result of some glitch in the iPhone code that is misreporting things. It may be an attempt to account for push notifications, but the numbers are not always correct.
Conclusion 5: The billing departments are not aware of the double books, so they cannot assure customers that the line items shown are potentially erroneous, but that the amount actually billed will be correct.
Caveat 1: The above conclusions fit all the data I have seen, and I am not aware of any simpler explanation that accounts for everything, but one may exist.
Well, sure, that, a login token in the URL, or passed around by means of hidden fields in a form, are the only concievable ways of having a persistant login.
The other alternative is to wait till somebody performs any actions that require authentication and at the last possible second (already pushed the submit button on the form), and then ask them for the openID, go through the authentication process, and committing the action upon successful verification. But people generally want to be able to perform multiple actions without having to authenticate for each action.
But there are ways to make a login token harder to use even if sniffed, such as tying it to the IP address.
That would then require the sniffer to either (a) be behind the same NAT (if any) as you or (b) have full intercept and injection capability, as well as being on the routing path between you and the site. (That allows to to forge packets that claim to be from your IP, and prevent the replies from reaching you. Mere sniffing only requires that you get a copy of the packets, which is far simpler, since not everything does full switching. (Early cable modems (and perhaps even current ones) could be modified to run in promiscuous mode, delivering all packets on that cable line, which would normally include at least your whole neighborhood, and perhaps more.)
Thus (b) basically requires a rouge ISP, which is not particularly likely. However (a) is still a legitimate concern. Other techniques are also possible to make using the login token difficult, such as also tying it to your exact User-agent string, and your "accepts" header line, which most browsers don't make it easy to manually configure, and perhaps a few other things. That would make it enough of a pain to use your sniffed login tokens that only somebody particularly determined will be able to use them. For many uses that is probably good enough. For those where it is not, HTTPS is usually already the norm.
In case you missed the other person (falzer) who posted the link, the search term is "unit life cell", but the only page with an worthwhile detail I have seen is http://www.radicaleye.com/lifepage/patterns/unitcell/ucdesc.html
However falzer's link of http://www.conwaylife.com/wiki/index.php?title=P5760_unit_Life_cell because it links to other interesting things.
One of those is Deep Cell which is a version of the pattern that simulates two independant life universes with a period of only 7680.
Another is the OTCA megapixel, which is a unit life cell that is larger and slower, but makes it much easier to see the state of each cell. It can also be program to follow any life-like pattern of number of neighbors needed for birth and starvation, as well as programmed to igore any (or all) of the eight bordering cells in its determination. so you could have a pattern that ignored diagonals. Of course the OTCA megapixel itself only runs under the standard rules.
From the article:
In fact, this is arguably the single most impressive and important pattern ever devised.
Really? Not the universal Turing machine pattern, or the pattern that emulates the game of life itself? Those both seem more impressive to me.
Alpha is indeed a good idea, but I still lament the implementation.
Many times I've wanted data that can be trivially calculated from data it has (I can pull up each peice individually, so I know they are there, but there are a few to many to exract one by one and then calculate on them), but I cannot find any working syntax.
If I could have a programmatic interface to individual data points. My original thought was something like:
for x in ["USA, UK, JAPAN"]:
for y in range(1979,2009):
AlphaData("WolframAlpha.Countries.%s.government_debt.historical.%s",x,y)
However, exposing each piece of data with a unique URL that can be programmatically constructed would be just as useful. I would feel no need to have the returned data link to their locations, but I could imagine that for an example like this having some links like for the next year, previous year, next country, previous country, and perhaps several other links could be useful, and would probably be easy enough for them to expose.
As for tagging:
I agree with your doubt. Unfortunately machines are nowhere near good enough yet to do all the necessary tagging. Songs and movies can probably be handled by calculating good fingerprints, and looking up metadata in a large curated database, but photos tagging is much less easy. People usually want them tagged by both location, and people in the photos. The people in the photos is actually the easier problem, unless the photo source has GPS and geotags the image on creation. But even an algorithm to automatically identifies the individuals in each picture tagging them (prompting the user for a name if it lacks one for the individual) is difficult technology, and out current attempts are not particularly promising.
The problem with most of the semantic web concepts is that it wants to add lots of metadata to everything, generally of a type that cannot be added automatically. I see how many people's music collections are extremely inconsistent with the metadata. Sometimes half the music is missing artist tags, and whatnot. Furter how many people actually have well tagged photo collections?
If people are not willing to tag their music and photos consistently, when it have active immediate benefits to them, what chance is there of getting them to tag information in their web pages, when that provides no immediate benefit, and quite possibly no benefit ever if the Semantic web does not catch on.
The idea of linked data on the other hand has a shot of working, but probably not in the way Tim Berners-Lee imagines it. RDF seems to have too much of a stigma attached to it.
hungarian notation is best used not to store actual datatype of the variable, but additional information beyond the raw datatype. So "strTitle" is worthless in a statically typed language, and at best questionable in a dynamically type language.
But "uTitle" to indicate an unsafe (unescped) title and "sTitle" to indicate an title that is safe (has been escaped) is a coding convention that makes plenty of sense. It is very possible to then automatically scan code to find violations of safety, such as any assignment of the form "sFirstName=uFirstName".
Extend the convention to functions, and one can automatically detect the problem with "sAddress=uGetAddress", or passing "sLastName" to a function with the prototype "int HashString(std::string uString)", which clearly wants an unescaped string.
One can also detect other unsafe or undesirable actions like escaping an already escaped string, or concatenating a safe and an unsafe string, etc.
Now when Charles Simonyi described the system initially he had not yet made the full distinction between type information the compiler already knows, and additional type information. Many, but not quite all of his examples in the original paper gave additional information. His lack of a full distinction is what led to many of the uses where Hungarian notation is not giving anybody any useful information.
Of course the best way to handle the whole thing is to have each semantic data-type be a distinct data-type to the compiler. So I would have both an "UnsafeString" and a "SafeString" data-type, and doing something unsafe like assigning one to the other directly would result in a compiler error. For dynamic languages, having a compile-time error is not feasible, but having two data-types and having unsafe operations result in a run-time error is still possible, and should be preferable to a successful injection attack.
I feel very similarly. IRC works just fine (although the practice of idling for hours is less than ideal). I do agree though that IM would still be preferable to those others if IRC was off the table.
I think part of this is that Facebook is nearly ubiquitous in the US, while in many other locations no one social networking site holds that level of market share. In the US SMS has caught on especially with those in high school (or those who have been in high school in the last year or two) because it can be discretely used while in class. They are then in the habit of using SMS.
Actually anonymous implies no attached name, or name-like construct. If there is an attached name, then it is pseudonymous.
Where the hell are you? In the United States, traditional Instant Messaging is virtually extinct. Twitter, Facebook chat, and SMS are used as replacements.