No kidding, I can't imagine how insurance companies could see insuring groups as being a higher risk than insuring individuals. Their entire industry is based on the idea of groups being a better risk for them than individuals.
No, here in California, we are smart enough to recognize that the Arsenic in the lake is naturally occurring, and is therefor healthy. No doubt one of our enterprising vegans will be bottling it and selling it with a big 'organic' label strung across the front.
It is safe to say that more killer went to public school than abused animals. More killers ate fried eggs than abused animals, and more killers brushed their teeth thank abused animals. If they were going to make more animal related laws, we would be much better off if they classified dogs like they should be... The same as a gun. They could follow that up by classifying cats as they should be...the same as rats.
Actually, your response is MORE likely to turn people off of FOSS. You imply that an industry wide problem is only a FOSS problem. I generally don't report bugs to closed source projects because the response tends to be worse. The last one I submitted was several years ago to MS concerning a math bug in MS Money. It was easily reproducable. I took the effort to call their tech support line, and spent at least 2 hours getting through and walking they tech support person in creating the error cleanly on their side. The call ended with them agreeing that it was a bug, and was reliably recreated on their end. A month later, there is a message on my answering machine saying that they had some questions, but since I'm not home, they are going to close out the bug report.
I spent FAR more time and effort trying to report a bug to a closed source group that I had actually paid to write the software, and in the end I was worse off than the OP.
I would be more worried about viruses on The iPhone. It is trivial to hide a trojan in a program. Nothing Apple does will even slow that down. So, given that the marketplace host is doing nothing to stop or even slow down viruses, how do the two compare? Well, with the iPhone, every application is basically Admin. If you can run any code, you can run it all. Android on the other hand, only lets you have access to features that you publicly request. Certainly, this won't stop some people from installing a wallpaper downloading app that requests access to their contact list, but at least there is a mechanism for the interested users to know if there is code in the app that wants to access to all of their friends phone numbers.
I don't know. MacOSX feels like a dated MacOSX to me. I was shocked when I recently got a Mac, and found how inconsistent the UI was, and simple things like being able to drag a window larger can only be done by grabbing the lower right corner. I thought I was done with that kind of limitation when I gave up my beloved Amiga.
I am saying that having your phone, and any wireless data involved in the task at all is a bad idea. Heavy lifting on a large cheap, configurable machine, and display on light simple machines. The full PC would transmit from the PC to the phone for phone tasks. It would transmit from PC to TV for TV tasks. It would transmit from PC to radio for radio tasks. It would transmit from PC to picture frame for photos. Putting the single point of processing in your phone for your desktop, TV, picture frames, etc..etc..etc... is simply the wrong path. Transmitting data between a phone and other devices when there is zero reason to is very bad. Having to plug your phone into wires every time you want to watch TV is a terrible idea. Having to plug your phone into your picture frame every time you want to see a picture is a bad idea. The phone is basically a two way TV. It should be treated as such. If you want a dozen computers running in your house, then sure, make your phone one of them. If you want one computer, and the rest to hang off of it's processing power, relying a phone to be that computer only increases cost, increases wireless bandwidth usage and increases the chance that you will lose all your data because you misplaced it or damaged the phone.
So, yes. "The definition of a thin client is a device which does very little except display the product of a remote server." Your insistence that anyone would even suggest transmitting to a thin client for processing means that you are unwilling or unable to take a useful part in the discussion.
2. You are using your phone as a terminal - the HDTV H.264 stream is being decoded elsewhere on a server somewhere on the internet and transmitted to your phone, which then displays it on the TV.
That statement right there says that you are unwilling or unable to understand what is being described. You are either trolling, or the entire discussion would have to be repeated to bring you back up to speed.
There is why you are confused. You missed the beginning of this conversation where it was hypothesized by another commenter that the phone would replace the PC. They suggested that the way that common usage like typing on a keyboard or watching a movie ON YOUR 50 INCH HDTV would be by wirelessly connecting to them from the phone. So, now that you are part of the actual conversation...
Conversely, the (lower powered) CPU is only active when I'm using my phone.
Wrong. Every time you did anything computer related, you would be activating the transmitter in your phone, because your phone was your computer.
Why on earth would I want to watch an HD movie on a phone of all things?
You wouldn't. You would want to watch it on the 50" HDTV. That is why you would not want to have your phone as the computing device to play that movie.
No, I use my phone to send SMS messages, emails, browse the web, write notes, manage my calendars, etc. All of these are things that can be done largely offline, only powering up the radio periodically. On the other hand, if you're using the phone as a thin client you need to power up the radio the whole time you're using the device because each time you press a key it has to go over the network to the server and each time the display needs to be updated all those graphics have to be pulled over the network.
Which is still less bandwidth than trying to use your desktop as a thin client for the phone. Remember, this conversation is concerning the premise of having ONE computing device, and whether that would be better as the phone or as PC.
Now you're arguing backwards. If you were using a phone as a thin client then reading Slashdot would require the transmitter to be powered up a lot - each time you scroll the screen, etc, you have to shove those graphics over the network. Running the browser application locally on the phone would mean that it only powers up the transmitter when retrieving the article - while you're reading it the transmitter can power down.
Not if your reading it on a decent sized screen. Remember, this conversation is concerning the premise of having ONE computing device, and whether that would be better as the phone or as PC.
I guess you haven't done a lot of development work if this is what you think.
I have done plenty. There are exactly 0 scenarios where writing a UI and porting an application is more work than just writing a UI. Can you point to a single library that is more work to use on one platform than it is on two?
It will be receiving all the time, but turning the phone into a thin client means it will be transmitting a lot too. This will far outweigh the energy benefits of using a remote CPU.
In a PaaT situation, the radio will be receiving all the time as well, and only using the transmitter when you are actively using the phone. Remember, this is a debate between replacing your various PCs with the phone vs. just using the phone as a terminal to the PCs. This means that in your scenario, when you wanted to sit down and watch an HD movie, the transmitter on your phone will crank up and run full speed for the entire hour and a half that you sit there watching a movie. It also means that when you sit down to read Slashdot, your transmitter would be running the entire time. Think about that. How much time to you spend actively interacting with you phone in a non-connected way vs. interacting with everything else in a using the processor way?
That's why programmers use libraries. Adapting a single application to serve several very different platforms is often far harder than just writing several different apps (that may all use the same libs for the backend functionality).
I can 100% guarantee you that writing one app that has multiple interfaces is always going to be easier = the amount of work it takes to write it for multiple platforms. Always.
I have to agree. One can argue that price controls are a legitimate social need, but if we go there, then entertainment events are pretty far down the list of places to complain about that. Me I would start with Real Estate.
If the gang showed up in line first, waited their turn, and then peacefully bought their tickets, and when they had them left without molesting any other customers, I don't see a problem with them.
Which is why capping bandwidth at the amount needed to use a phone as a terminal is a better plan than to just keep expecting an infinite amount of mobile bandwidth. Between my Roku and multiple remote desktop connections, I already use dramatically more bandwidth than what a phone as a terminal would ever use. Today, I may be a heavy user, but in a year or two, my current usage will be the norm. The phone as a terminal today would use less bandwidth than the phone as a PC. The future only pushes the balance farther into favoring the phone as a terminal over the other way around.
I think you got this the wrong way around - powering the radio in your phone uses a _lot_ of battery power - far more than the CPU. If you're going to use the phone at a thin-client all the time then you're going to be keeping that radio powered up all the time and your battery won't last long at all.
The radio is always on anyway.
If you're going to have a totally different UI for each platform (and you will need that - a desktop UI is completely unsuited to a small-screen device)
There is no reason that a single PC cannot serve dimension appropriate UI from a single back end, so complaining about the PC's UI on a phone is a red herring derived from a lack of imagination. In fact, I have a PC here that happily serves up an Android UI, and a Mac that happily serves up an iPhone UI.
you may as well be using a different application on each platform anyway.
It isn't 1983 any more. Writing the same code for a half dozen different platforms is a waste of resources and money.
I think you underestimate the cost of mobile bandwidth.
If you read my post, you would have seen that getting the bandwidth was the catalyst that would make the PaaT the right choice. It certainly would be less bandwidth to send a phone sized screen and audio from house to a phone than to send an HDTV video and audio stream while at the same time sending a PC screen and audio from your phone to your TV and desktop. Not to mention all of the other traffic that a PC gets from the internet. It also isn't like you sit and look at your phone for 12 hours a day. There is just WAY more data that is being used, and even in a Phone as a PC world, would continue to be used outside the phone, than there is data being used in the phone.
I think you underestimate the cost of mobile bandwidth.
Yes, I know, and nobody needs more than 640k. The fact is that bandwidth keeps getting cheaper. There is no reason to believe that it will not continue to get cheaper. Just 4 or 5 years ago the idea of something like the Roku would have fallen in the exact same category as a PaaT. Bandwidth into your home was just about as expensive as cellular bandwidth is now. PCs have an insatiable appetite for speed, power, and bandwidth. There is no end is sight as to how much of these individual computing will consume. The thing about PaaT is that the bandwidth and power consumption has a limit, while speed doesn't. With the Phone as a PC, speed has a limit, and power and bandwidth don't.
The opposite is the correct answer. Wireless connectivity to a PC for all phone functions as the phone is just a terminal. It is far easier and more cost effective to have your processing in a large device and transmit to the small one than it is to have your processing in a small device and transmit to a large one.
The best solution would not be to run apps on the phone at all. It would be to get always on bandwidth from a PC at home to your phone that was fast enough to do remote desktop at a speed where you couldn't tell that you were working remotely. Once we have that kind of bandwidth, the phones are basically done. The phone as a terminal. With this configuration, you get:
* Massive upgradeability on the phone since to make your phone faster, you just upgrade the PC in your home.
* Far greater battery life, as once the phone is a good terminal, adding more processing power to the PC will add power, but since that part is plugged into the wall, it won't drain your battery at all.
* Losing your phone does not effect any of your data.
* Replacing your phone is simpler.
* You can access the same application from a desktop, TV, or the phone, and there is no reason the interface cannot change for each.
* Better utilization of processing power, since people will end up with a home server anyway, for running their home media servers, security systems, home automation, etc...
* Cheaper. It will always be more expensive to build these things smaller, so putting it in a PC makes it cheaper.
* Faster to market. It takes time to shrink electronics.
* Possible functionality that is impossible on the phone. We are getting to the point where we may be limited by physics on how small transistor can become. This means that the amount of processing power that would be supplied to the phone as a terminal may be impossible to have in a handheld device.
Another option would be to make them write the exact text that is presented in the error, as a sort of Captcha.
I have some code that I include in the administrator/developer screens to clear the configuration of the apps I write. Of course, clearing the configuration data from an application will prevent it from working properly in the context that it was installed. While the UI to clear the configuration is only accessible to administrators and developers, that doesn't mean that the administrators won't run it anyway. (We have those kinds of administrators) So, when the code is executed, it prompts the user to type 'Break this application.'. If they don't type it, including the proper capitalization and punctuation, it won't run.
I prefer referring to them as child molesters. As in, I was taught while I was a child that sharing was good, and sharing information was REALLY good. So good in fact that I spent 13 year mandated by law to attend an institution whose primary purpose was to share information with me for free.
So, these organizations are molesting my inner child. They are "Child Molesters" as much as a copyright infringer is "Stealing".
Slashdot Mirror
No kidding, I can't imagine how insurance companies could see insuring groups as being a higher risk than insuring individuals. Their entire industry is based on the idea of groups being a better risk for them than individuals.
It is even more analogous to "marriage is between two people of the same color".
Of course, the duel deck VCRs could watch a recording and record something different at the same time.
No, here in California, we are smart enough to recognize that the Arsenic in the lake is naturally occurring, and is therefor healthy. No doubt one of our enterprising vegans will be bottling it and selling it with a big 'organic' label strung across the front.
It is safe to say that more killer went to public school than abused animals. More killers ate fried eggs than abused animals, and more killers brushed their teeth thank abused animals. If they were going to make more animal related laws, we would be much better off if they classified dogs like they should be... The same as a gun. They could follow that up by classifying cats as they should be...the same as rats.
Not to mention. Easier to read.
Actually, your response is MORE likely to turn people off of FOSS. You imply that an industry wide problem is only a FOSS problem. I generally don't report bugs to closed source projects because the response tends to be worse. The last one I submitted was several years ago to MS concerning a math bug in MS Money. It was easily reproducable. I took the effort to call their tech support line, and spent at least 2 hours getting through and walking they tech support person in creating the error cleanly on their side. The call ended with them agreeing that it was a bug, and was reliably recreated on their end. A month later, there is a message on my answering machine saying that they had some questions, but since I'm not home, they are going to close out the bug report. I spent FAR more time and effort trying to report a bug to a closed source group that I had actually paid to write the software, and in the end I was worse off than the OP.
I would be more worried about viruses on The iPhone. It is trivial to hide a trojan in a program. Nothing Apple does will even slow that down. So, given that the marketplace host is doing nothing to stop or even slow down viruses, how do the two compare? Well, with the iPhone, every application is basically Admin. If you can run any code, you can run it all. Android on the other hand, only lets you have access to features that you publicly request. Certainly, this won't stop some people from installing a wallpaper downloading app that requests access to their contact list, but at least there is a mechanism for the interested users to know if there is code in the app that wants to access to all of their friends phone numbers.
I don't know. MacOSX feels like a dated MacOSX to me. I was shocked when I recently got a Mac, and found how inconsistent the UI was, and simple things like being able to drag a window larger can only be done by grabbing the lower right corner. I thought I was done with that kind of limitation when I gave up my beloved Amiga.
I give up. Your still having a different conversation.
I am saying that having your phone, and any wireless data involved in the task at all is a bad idea. Heavy lifting on a large cheap, configurable machine, and display on light simple machines. The full PC would transmit from the PC to the phone for phone tasks. It would transmit from PC to TV for TV tasks. It would transmit from PC to radio for radio tasks. It would transmit from PC to picture frame for photos. Putting the single point of processing in your phone for your desktop, TV, picture frames, etc..etc..etc... is simply the wrong path. Transmitting data between a phone and other devices when there is zero reason to is very bad. Having to plug your phone into wires every time you want to watch TV is a terrible idea. Having to plug your phone into your picture frame every time you want to see a picture is a bad idea. The phone is basically a two way TV. It should be treated as such. If you want a dozen computers running in your house, then sure, make your phone one of them. If you want one computer, and the rest to hang off of it's processing power, relying a phone to be that computer only increases cost, increases wireless bandwidth usage and increases the chance that you will lose all your data because you misplaced it or damaged the phone.
So, yes. "The definition of a thin client is a device which does very little except display the product of a remote server." Your insistence that anyone would even suggest transmitting to a thin client for processing means that you are unwilling or unable to take a useful part in the discussion.
2. You are using your phone as a terminal - the HDTV H.264 stream is being decoded elsewhere on a server somewhere on the internet and transmitted to your phone, which then displays it on the TV.
That statement right there says that you are unwilling or unable to understand what is being described. You are either trolling, or the entire discussion would have to be repeated to bring you back up to speed.
Conversely, the (lower powered) CPU is only active when I'm using my phone.
Wrong. Every time you did anything computer related, you would be activating the transmitter in your phone, because your phone was your computer.
Why on earth would I want to watch an HD movie on a phone of all things?
You wouldn't. You would want to watch it on the 50" HDTV. That is why you would not want to have your phone as the computing device to play that movie.
No, I use my phone to send SMS messages, emails, browse the web, write notes, manage my calendars, etc. All of these are things that can be done largely offline, only powering up the radio periodically. On the other hand, if you're using the phone as a thin client you need to power up the radio the whole time you're using the device because each time you press a key it has to go over the network to the server and each time the display needs to be updated all those graphics have to be pulled over the network.
Which is still less bandwidth than trying to use your desktop as a thin client for the phone. Remember, this conversation is concerning the premise of having ONE computing device, and whether that would be better as the phone or as PC.
Now you're arguing backwards. If you were using a phone as a thin client then reading Slashdot would require the transmitter to be powered up a lot - each time you scroll the screen, etc, you have to shove those graphics over the network. Running the browser application locally on the phone would mean that it only powers up the transmitter when retrieving the article - while you're reading it the transmitter can power down.
Not if your reading it on a decent sized screen. Remember, this conversation is concerning the premise of having ONE computing device, and whether that would be better as the phone or as PC.
I guess you haven't done a lot of development work if this is what you think.
I have done plenty. There are exactly 0 scenarios where writing a UI and porting an application is more work than just writing a UI. Can you point to a single library that is more work to use on one platform than it is on two?
Either that, or the performers are playing too few shows.
Sounds like they are using the same system as just about every other business out there.
It will be receiving all the time, but turning the phone into a thin client means it will be transmitting a lot too. This will far outweigh the energy benefits of using a remote CPU.
In a PaaT situation, the radio will be receiving all the time as well, and only using the transmitter when you are actively using the phone. Remember, this is a debate between replacing your various PCs with the phone vs. just using the phone as a terminal to the PCs. This means that in your scenario, when you wanted to sit down and watch an HD movie, the transmitter on your phone will crank up and run full speed for the entire hour and a half that you sit there watching a movie. It also means that when you sit down to read Slashdot, your transmitter would be running the entire time. Think about that. How much time to you spend actively interacting with you phone in a non-connected way vs. interacting with everything else in a using the processor way?
That's why programmers use libraries. Adapting a single application to serve several very different platforms is often far harder than just writing several different apps (that may all use the same libs for the backend functionality).
I can 100% guarantee you that writing one app that has multiple interfaces is always going to be easier = the amount of work it takes to write it for multiple platforms. Always.
I have to agree. One can argue that price controls are a legitimate social need, but if we go there, then entertainment events are pretty far down the list of places to complain about that. Me I would start with Real Estate.
If the gang showed up in line first, waited their turn, and then peacefully bought their tickets, and when they had them left without molesting any other customers, I don't see a problem with them.
Which is why capping bandwidth at the amount needed to use a phone as a terminal is a better plan than to just keep expecting an infinite amount of mobile bandwidth. Between my Roku and multiple remote desktop connections, I already use dramatically more bandwidth than what a phone as a terminal would ever use. Today, I may be a heavy user, but in a year or two, my current usage will be the norm. The phone as a terminal today would use less bandwidth than the phone as a PC. The future only pushes the balance farther into favoring the phone as a terminal over the other way around.
I think you got this the wrong way around - powering the radio in your phone uses a _lot_ of battery power - far more than the CPU. If you're going to use the phone at a thin-client all the time then you're going to be keeping that radio powered up all the time and your battery won't last long at all.
The radio is always on anyway.
If you're going to have a totally different UI for each platform (and you will need that - a desktop UI is completely unsuited to a small-screen device)
There is no reason that a single PC cannot serve dimension appropriate UI from a single back end, so complaining about the PC's UI on a phone is a red herring derived from a lack of imagination. In fact, I have a PC here that happily serves up an Android UI, and a Mac that happily serves up an iPhone UI.
you may as well be using a different application on each platform anyway.
It isn't 1983 any more. Writing the same code for a half dozen different platforms is a waste of resources and money.
I think you underestimate the cost of mobile bandwidth.
If you read my post, you would have seen that getting the bandwidth was the catalyst that would make the PaaT the right choice. It certainly would be less bandwidth to send a phone sized screen and audio from house to a phone than to send an HDTV video and audio stream while at the same time sending a PC screen and audio from your phone to your TV and desktop. Not to mention all of the other traffic that a PC gets from the internet. It also isn't like you sit and look at your phone for 12 hours a day. There is just WAY more data that is being used, and even in a Phone as a PC world, would continue to be used outside the phone, than there is data being used in the phone.
I think you underestimate the cost of mobile bandwidth.
Yes, I know, and nobody needs more than 640k. The fact is that bandwidth keeps getting cheaper. There is no reason to believe that it will not continue to get cheaper. Just 4 or 5 years ago the idea of something like the Roku would have fallen in the exact same category as a PaaT. Bandwidth into your home was just about as expensive as cellular bandwidth is now. PCs have an insatiable appetite for speed, power, and bandwidth. There is no end is sight as to how much of these individual computing will consume. The thing about PaaT is that the bandwidth and power consumption has a limit, while speed doesn't. With the Phone as a PC, speed has a limit, and power and bandwidth don't.
As long as we actually tax sugar. So, get ready to pay a premium for your fruits, breads, potato, and pastas.
The opposite is the correct answer. Wireless connectivity to a PC for all phone functions as the phone is just a terminal. It is far easier and more cost effective to have your processing in a large device and transmit to the small one than it is to have your processing in a small device and transmit to a large one.
Phone as a Terminal
The best solution would not be to run apps on the phone at all. It would be to get always on bandwidth from a PC at home to your phone that was fast enough to do remote desktop at a speed where you couldn't tell that you were working remotely. Once we have that kind of bandwidth, the phones are basically done. The phone as a terminal. With this configuration, you get:
* Massive upgradeability on the phone since to make your phone faster, you just upgrade the PC in your home.
* Far greater battery life, as once the phone is a good terminal, adding more processing power to the PC will add power, but since that part is plugged into the wall, it won't drain your battery at all.
* Losing your phone does not effect any of your data.
* Replacing your phone is simpler.
* You can access the same application from a desktop, TV, or the phone, and there is no reason the interface cannot change for each.
* Better utilization of processing power, since people will end up with a home server anyway, for running their home media servers, security systems, home automation, etc...
* Cheaper. It will always be more expensive to build these things smaller, so putting it in a PC makes it cheaper.
* Faster to market. It takes time to shrink electronics.
* Possible functionality that is impossible on the phone. We are getting to the point where we may be limited by physics on how small transistor can become. This means that the amount of processing power that would be supplied to the phone as a terminal may be impossible to have in a handheld device.
Another option would be to make them write the exact text that is presented in the error, as a sort of Captcha.
I have some code that I include in the administrator/developer screens to clear the configuration of the apps I write. Of course, clearing the configuration data from an application will prevent it from working properly in the context that it was installed. While the UI to clear the configuration is only accessible to administrators and developers, that doesn't mean that the administrators won't run it anyway. (We have those kinds of administrators) So, when the code is executed, it prompts the user to type 'Break this application.'. If they don't type it, including the proper capitalization and punctuation, it won't run.
I prefer referring to them as child molesters. As in, I was taught while I was a child that sharing was good, and sharing information was REALLY good. So good in fact that I spent 13 year mandated by law to attend an institution whose primary purpose was to share information with me for free.
So, these organizations are molesting my inner child. They are "Child Molesters" as much as a copyright infringer is "Stealing".