Bit_Torrent was invented because all the Warez Websites were getting shutdown.
Uh... no.
Bittorrent was invented because its inventor correctly noted that given the essentially almost entirely serial nature of existing data communications, coupled with the fact that many upstream network paths are often saturated with other data that they are simply relaying, which limits serial throughput, simultaneously downloading different parts of the same content in parallel from different locations, and thereby using multiple network paths instead of only one, would complete faster than downloading it all from a single location.
Pirates quickly glommed onto this concept, and applied the protocol to distributing unauthorized copies of works because it was, in fact, so much faster than simply downloading it from a single source via ftp or conventional http.
Bittorrent was not invented for the purpose of piracy. Not remotely.
Ah... but the point being raised here is that you currently *CAN* patent algorithms... as long as the algorithms are considered sufficiently complex to be allegedly "non-obvious". That's the crux of the problem.
Except physics isn't math. We can model physics with mathematics, but that doesn't mean they are literally the same thing.
Conversely, algorithms *ARE* math. This is entirely provable (a good text on the theoretical foundations of computer science might even describe such a proof), but probably not readily comprehensible to people who do not have a very thorough understanding of mathematics and mathematical proofs (which is, I'm afraid to say, most people... including even a lot of computer professionals).
What the minimum amount of energy to perform a calculation was. I forget where I saw it, but I seem to remember it having to do with an equivalence of energy to information, which is to say that a certain (non-whole) number of bits could be represented per unit of energy. A minimum amount of energy it would require to reliably change a single bit can be reasonably be derived from this. Using a turing machine to model a calculation and counting the cycles that it takes to complete, you could then calculate the minimum amount of energy needed to perform that calculation.
Although for trivial operations, the energy requirements are absurdly tiny fractions of a joule, I might suggest that for modern complex computing that we perform today, those minimum energy requirements aren't going to be anywhere as near to zero as they expect.
The only way it will really "approach" zero, is if we start demanding less from computing devices. This may be happening in some areas already, but I wouldn't say it's a ubiquitous phenomenon.
My point is that if there are going to be different screen sizes and the programmer is going to have to write particular code to handle them, then I don't understand the point of ever bothering with the supposedly "resolution independent" screen positions, when previous to the retina dispay, those supplied positions were just raw pixel coordinates?
Starting with the retina display, the programming API's for the iPhone took a one-way trip away from utilizing absolute pixel measurements, and referring to screen positions by resolution-independant "points", instead. In this way, coupled with the usage of floating point values for screen positions instead of integers, code would be made entirely resolution independent, without having to inquire about the phone's physical pixel resolution. All of the iPhone screens up until that time, whether retina display or not, were considered to be the same dimensions in these "point" sizes, so the same code could look and work exactly the same both on pre-retina and post-retina displays (perhaps only being of higher fidelity on the latter).
Now Apple decides it's time to make a phone with an entirely different aspect ratio. Really, what was the point of bothering with the resolution-independent screen positioning in their API's in the first place if they were just going to go and produce a completely different screen size that the programmer is going to have to write extra code to account for anyways?
Don't hold your breath.
There are three phenomena associated with superconductivity: zero resistance, the Meissner effect, and a superconducting phase transition. Only the last one has been observed so far in the graphite-based superconductor. But it's my understanding that it's only the first two that are practically useful. Either of the first two effects observed on a macroscopic level at room temperatures or above, and that is tractable to scale, would be utterly revolutionary, and the long-term impact on industrialized society would likely be beyond anything we've yet conceived.
The notion that people have no way to think about or discuss concepts that they have no words for is flawed, since, to use your own example, the concept of democracy clearly came about well before anybody had an actual word for it.
The only significant technical problem that I can see with trying to make something like a turbolift actually work is if multiple cars are wanting to go to the same destination, and are arriving there at about the same time. If one particular spot is a popular dropoff zone at a particular time of day (say, the cafeteria near dinnertime), then a queue could end up getting created that could easily be just as bad (if not worse) than a normal single-car elevator system.
The maps app on iPhone has had streetview for at least as long as I've had an iPhone. Place a pin. Tap on it. Then tap the circular orange icon that resembles a portrait view of a person's head and shoulders.
This assumes that Apple will allow them to do this.
Indeed. Although I would expect that this would obligate Apple to also nix all of the assorted GPS apps that are also on the iPhone.
Why should Google come along and save them?
It's less about saving Apple than it is being considerate to end users who bought a phone only to have previously existing functionality ripped from it after the purchase.
Apple's pulling a bait-and-switch here, and I know that there's going to be a lot of people upset with them for it.
Turbolifts are only very superficially like elevators.
They are more similar, I believe, to escalators in that they are always ready to board. When a person gets on a turbo lift and the door closes behind them, another person can board the turbo lift immediately afterward, and they can move in the same direction, or another one. They do not need to wait for the lift that the previous person took to arrive.
Please cite your source for this. It's my expectation that if Google were to try and do this, Apple would reject the application on iOS6 and later on the grounds that it duplicates too much of the internal functionality.
The loss of maps feature will not only stop some people from updating, it will cause no shortage of people from jumping ship and switching to Android, which has a full-blown Google maps application with turn-by-turn navigation already.
Apple won't care, of course. They never do. And the drones that go on to update or to buy new apple shiny stuff will continue.
I still feel entitled to be pissed off about it, however.
I certainly hope so, but I'm not optimistic. Not because I think Google wouldn't want to do it, but because I think Apple would disallow the app on iOS6 on the grounds that it allegedly duplicates built-in functionality on the operating system.
Of course, to be fair, they are going to have to simultaneously deprecate every GPS app out there for iOS6. This might piss off customers and developers of such applications, but Apple has a historical practice, about not giving two shits about people who don't fit into their own ideal of what they believe an end user will want.
1. They changed the aspect ratio. This is going to cause a headache for some applications designers who must now design new screen layouts and possibly reposition things to take advantage of the new display. Application complexity will be increased as the app will probably support both old and new aspect ratios.
2. The maps app that Apple developed to replace Google Maps is not that good.
There is no Streeview facility - something that I used with Google maps all the time.
The "flyover" feature is only usable in certain select major cities. Although the number of cities will probably grow over time, it's my understanding that it will only ever be applicable to major cities.
If you live in a smaller town, forget it. Google streetview, by comparison, works just about everywhere. The Google browser-based application will still work normally, of course, but the native map application has many features that the web application does not.
The turn-by-turn navigation feature that their map application has is only usable within the USA.
3. The deprecation of some functionality is going to give cause for some users to not update their iOS version, which introduces delays and increases costs for development studios developing applications, who must verify that newly developed applications still work on other widespread iOS versions... especially since there may be some that will actively choose to not update.
Ultimately, this product seems to be one that is geared towards fragmenting their own user-base. It's unhealthy for them as a company, and it's not remotely helpful to the consumer.
More specifically, the equipment you would have had would been a radio receiver. Improperly shielded, the mere act of tuning older radios could often cause interference with other nearby electronics. I've actually witnessed this phenomenon first hand in 1980, when an Apple ][+ computer and a nearby AM radio interfered with eachothers operation while the radio tuning knob was being adjusted. Of course, this hasn't been an issue with any popular consumer electronics now for quite a long time.
...in the field of computer programming they expect to be completely un-employable at 40 years of age (not due to lack of talent, but to rampant unchecked agism).
The ageism you speak of is largely prevented against by laws which prohibit it. It doesn't prevent all of it, of course, and it's sad that it ever happens at all, but it certainly *does* keep it from becoming "rampant", or "unchecked".
Slashdot Mirror
Would that not mean that cell phone providers would be obligated to discontinue carrier service to customers who had purchased one through them?
Uh... no.
Bittorrent was invented because its inventor correctly noted that given the essentially almost entirely serial nature of existing data communications, coupled with the fact that many upstream network paths are often saturated with other data that they are simply relaying, which limits serial throughput, simultaneously downloading different parts of the same content in parallel from different locations, and thereby using multiple network paths instead of only one, would complete faster than downloading it all from a single location.
Pirates quickly glommed onto this concept, and applied the protocol to distributing unauthorized copies of works because it was, in fact, so much faster than simply downloading it from a single source via ftp or conventional http.
Bittorrent was not invented for the purpose of piracy. Not remotely.
[twitch] [twitch]
Sadist.
Ah... but the point being raised here is that you currently *CAN* patent algorithms... as long as the algorithms are considered sufficiently complex to be allegedly "non-obvious". That's the crux of the problem.
Except physics isn't math. We can model physics with mathematics, but that doesn't mean they are literally the same thing.
Conversely, algorithms *ARE* math. This is entirely provable (a good text on the theoretical foundations of computer science might even describe such a proof), but probably not readily comprehensible to people who do not have a very thorough understanding of mathematics and mathematical proofs (which is, I'm afraid to say, most people... including even a lot of computer professionals).
Although for trivial operations, the energy requirements are absurdly tiny fractions of a joule, I might suggest that for modern complex computing that we perform today, those minimum energy requirements aren't going to be anywhere as near to zero as they expect.
The only way it will really "approach" zero, is if we start demanding less from computing devices. This may be happening in some areas already, but I wouldn't say it's a ubiquitous phenomenon.
Get it right.
It's Apple //e.
The ][ was for the Apple ][ and ][+.
My point is that if there are going to be different screen sizes and the programmer is going to have to write particular code to handle them, then I don't understand the point of ever bothering with the supposedly "resolution independent" screen positions, when previous to the retina dispay, those supplied positions were just raw pixel coordinates?
Starting with the retina display, the programming API's for the iPhone took a one-way trip away from utilizing absolute pixel measurements, and referring to screen positions by resolution-independant "points", instead. In this way, coupled with the usage of floating point values for screen positions instead of integers, code would be made entirely resolution independent, without having to inquire about the phone's physical pixel resolution. All of the iPhone screens up until that time, whether retina display or not, were considered to be the same dimensions in these "point" sizes, so the same code could look and work exactly the same both on pre-retina and post-retina displays (perhaps only being of higher fidelity on the latter).
Now Apple decides it's time to make a phone with an entirely different aspect ratio. Really, what was the point of bothering with the resolution-independent screen positioning in their API's in the first place if they were just going to go and produce a completely different screen size that the programmer is going to have to write extra code to account for anyways?
But yeah... I wouldn't hold my breath on this.
Because there's plenty of horrendous accounts in that text.
The notion that people have no way to think about or discuss concepts that they have no words for is flawed, since, to use your own example, the concept of democracy clearly came about well before anybody had an actual word for it.
This appears to be something new, however
The only significant technical problem that I can see with trying to make something like a turbolift actually work is if multiple cars are wanting to go to the same destination, and are arriving there at about the same time. If one particular spot is a popular dropoff zone at a particular time of day (say, the cafeteria near dinnertime), then a queue could end up getting created that could easily be just as bad (if not worse) than a normal single-car elevator system.
Will it keep you from getting a social disease?
<rimshot badjoke="true"/>
The maps app on iPhone has had streetview for at least as long as I've had an iPhone. Place a pin. Tap on it. Then tap the circular orange icon that resembles a portrait view of a person's head and shoulders.
Indeed. Although I would expect that this would obligate Apple to also nix all of the assorted GPS apps that are also on the iPhone.
It's less about saving Apple than it is being considerate to end users who bought a phone only to have previously existing functionality ripped from it after the purchase.
Apple's pulling a bait-and-switch here, and I know that there's going to be a lot of people upset with them for it.
Turbolifts are only very superficially like elevators.
They are more similar, I believe, to escalators in that they are always ready to board. When a person gets on a turbo lift and the door closes behind them, another person can board the turbo lift immediately afterward, and they can move in the same direction, or another one. They do not need to wait for the lift that the previous person took to arrive.
Turbo lifts are like an elevato
Please cite your source for this. It's my expectation that if Google were to try and do this, Apple would reject the application on iOS6 and later on the grounds that it duplicates too much of the internal functionality.
Tell me what does the native Youtube application do that you can't do with the web interface?
The loss of maps feature will not only stop some people from updating, it will cause no shortage of people from jumping ship and switching to Android, which has a full-blown Google maps application with turn-by-turn navigation already.
Apple won't care, of course. They never do. And the drones that go on to update or to buy new apple shiny stuff will continue.
I still feel entitled to be pissed off about it, however.
Of course, to be fair, they are going to have to simultaneously deprecate every GPS app out there for iOS6. This might piss off customers and developers of such applications, but Apple has a historical practice, about not giving two shits about people who don't fit into their own ideal of what they believe an end user will want.
Ultimately, this product seems to be one that is geared towards fragmenting their own user-base. It's unhealthy for them as a company, and it's not remotely helpful to the consumer.
More specifically, the equipment you would have had would been a radio receiver. Improperly shielded, the mere act of tuning older radios could often cause interference with other nearby electronics. I've actually witnessed this phenomenon first hand in 1980, when an Apple ][+ computer and a nearby AM radio interfered with eachothers operation while the radio tuning knob was being adjusted. Of course, this hasn't been an issue with any popular consumer electronics now for quite a long time.
The ageism you speak of is largely prevented against by laws which prohibit it. It doesn't prevent all of it, of course, and it's sad that it ever happens at all, but it certainly *does* keep it from becoming "rampant", or "unchecked".