I am all for having real OFF switches available as an option. But if one is eliminating standby altogether to save energy, one needs to look at the changes in human behavior that might result and see if it would still save energy.
For instance, if Mr. Couch Potato needs to get up to turn off the TV, he might instead mute it. Granted, we could build a TV that you can fully turn off remotely but where you need a physical switch to turn it back on. But even so, Mr. Couch Potato may not want to turn off the TV if he can't get it back on with his remote.
This is even clearer with devices with a startup time like computers and cellphones. If the alternative to standby is power off and a restart wait, people may just leave them on.
A crucial thing to remember in policy work is that one cannot assume that present behavior will remain the same given the policy. A jurisdiction would not make more money from taxes than it does if it set the tax rate at 100%!
And in the US the legal way to do it is just to stock multiple DVD ROM drives, each set for a different region. At $20 a drive (plus a single USB2-ATAPI adapter) it's not so bad. It's more or less what the copyright office recommended in response to the request to make region-coded DVDs an exception to the DMCA.
IANAL. But here's what I found by a quick googling:
"Copyright protects only the particular manner of an author's expression in literary, artistic, or musical form. Copyright protection does not extend to any idea, system, method, device, or trademark material involved in the development, merchandising, or playing of a game. Once a game has been made public, nothing in the copyright law prevents others from developing another game based on similar principles.
"Some material prepared in connection with a game may be subject to copyright if it contains a sufficient amount of literary or pictorial expression. For example, the text matter describing the rules of the game, or the pictorial matter appearing on the gameboard or container, may be registrable." - The U.S. Copyright Office (http://www.copyright.gov/fls/fl108.html)
Basically, from the copyright point of view, the guy would have been OK unless he copied the rules verbatim (or maybe close to verbatim) or he copied other parts of the game graphics.
By the way, I wonder if it is possible to sue people for providing false or misleading legal information when they ought to have known better? I am not saying Hasbro is guilty here--that depends on whether the rules were copied verbatim. Another example of the provision of false information are the warnings on DVDs saying that ALL copying is prohibited by law, which is simply false, since there is NO reasonable interpretation (though IANAL) of copyright law under which there is no such thing as fair use. For instance, it seems clearly legal to take a family photograph, for non-commercial purposes, with a TV playing the movie in the background (incidental copying, I think it's called). I wonder if one could get a class action lawsuit by people who were defrauded through the signage.
The CPU is much faster on the TX than on the TH (nice for video playback, for instance, unless one is using video software heavily optimized for the TH's video accelerator), NVFS is nice (no danger of losing data when memory runs out), and the large amount of Program Memory is nice, too. The TH needs third-party software for landscape support.
I am curious: How much of the general public cares very much? A lot of people are quite willing to copy or decrypt things illegally if that's what it takes--presumably it doesn't matter too much to them whether something is legal or not. It matters to me because if it's illegal, then I can't in conscience do it (unless it's a law that it is immoral to obey, or maybe a case of public civil disobedience against an immoral law, etc.) But many people don't mind engaging in illegal copying, illegal circumvention of access controls, etc.
Does this law have exceptions? Otherwise it would seem like it could make it rather hard for TV journalists to do their job...
Does "copyrighted work... being shown" include non-moving-picture works? If so, then it's illegal to use video cameras in just about any business, since just about any business shows copyrighted works, such as advertising posters, book covers, paintings on walls, sculptures in hotel lobbies, etc.
mpeg4 (the standard behind xvid) and mp3 are also patented. As far as I know, Thomson doesn't ask for payments from people who distribute mp3 decoders (only) for free, but they do ask for them for people who distribute decoders for money. MPEG LA requires licenses for all mpeg4 decoders, free or not, but doesn't charge any royalties to a licensee if one distributes less than 50,000 or maybe 100,000 copies (I've actually become a MPEG LA licensee so that I could have legal copies of xvid and tcpmp for personal use; there are potential GPL Section 7 issues with this, but since I'm only copying for myself, it should be OK, since Section 7 applies to distribution).
These folks have two choices, as far as I know (IANAL). (1) They can license the patents and use commercial or homebrew non-GPL codecs. (2) They can license the patents and use GPL codecs BUT pay the copyright owners of the GPL software for a non-GPL license (otherwise GPL Section 7 MIGHT be a problem).
Movies for portable devices... One could store 60 divx movies at a decent quality level (assuming one lives in a place where this is legal) and view them on a portable device, with much better battery life than a hard drive.
I thought one of the basic ideas behind the GPL was that unlike many commercial EULAs, it has no use restrictions whatsoever--it only governs copying and distribution. Abandoning this principle would be a major change. It would also require moving from the current model on which the legal force of the GPL lies in copyright law which prohibits unauthorized copying and distribution (beyond fair use, etc.) to a model that, like EULAs, is based on contract law (and has all of the dubious validity that some EULAs have). IANAL, though.
Wouldn't upholding a right that you signed away be an infringement on your freedom to enter into contracts (not one of the standard listed freedoms, but a very important one--the ability to make promises is what made humans an interesting animal, Nietsche wrote)?
Of course, some contracts are non-enforceable, e.g., those for slavery. So there are limits even there.
Actually, the Tapwave people worked hard to make available a much improved software architecture. While PalmOS 5 devices run on ARM processors, most software is written in 68K code which gets run on an emulator, with CPU intensive stuff, hopefully, optimized in ARM. It is possible to write ARM-only code, but hard. There are globals and segmentation issues (hotsync only allows 64K per segment, so things need to get split up). It's a mess. But the Tapwave folks made possible the generation of ARM-only apps, with no silly limitations.
I don't have one myself as I need a built-in keyboard (I have a Clie NX 70), but users were very happy with the Zodiac as a PDA. Fast, tons of memory.
The two big nuisances were that if you wanted to write software that used the hardware acceleration, you had to get it signed, and that you couldn't very easily use a free dev tool chain like prc-tools, but were stuck with Codewarrior.
For a while, I had Dvorak set up on my home machine, and I used QWERTY everywhere else. No problems about confusion. All was well. I did notice one thing: I couldn't type in QWERTY on my home machine if the Dvorak driver was off. My brain would see my home machine and automatically switch me into Dvorak mode, and I would type very slowly in QWERTY on my home machine, even though I would type at my normal speed in QWERTY everywhere else (five or six fingered, but still pretty fast; Dvorak I touch typed with all ten fingers).
PalmOS itself can't do it. Definitely not impressive. My Pocket PC executes.exe files right off the memory card. Every PalmOS 5 device will let you execute applications stored in the/PALM/Launcher directory of every inserted card--they automatically show up in a separate Launcher category. This won't work for hack-like applications that need to stay persistently in RAM, of course, but for standard applications it will work. Of course, the app has to be copied to RAM before executing, and this takes time, but the same is true on the PPC, too, no?
Supports resolutions up to VGA and there are already at least 5 devices shipped with it. PalmOS 5 supports resolutions up to VGA and beyond, but there are no devices shipped (though there IS the Dana Alphasmart, which while a 72DPI device has a screen that is about 800 pixels wide, though only 160 tall). Moreover, until devices are shipped, developers aren't bothering to include support in apps (e.g., including triple density bitmaps in bitmap families).
PalmOS 6 will support smooth fonts if an OS 6 device is ever produced. OS 5 does not have any native smooth font support. Of course some applications do smooth fonts stuff on their own, independently of the OS (e.g., PalmFiction, Weasel Reader (I think), Plucker and PalmBible+ on the open source side and Docs To Go, Mobireader, Wordsmith on the closed source side), and there is my shareware FontSmoother that extends smoothed font support to almost all apps, but there is definitely no support in to the OS. Fonts are a definite weakness on the PalmOS side. There is no Unicode support built in, either (and I am not sure if there is any third-party Unicode support).
You do lose data if batteries run out, but hopefully you have sync'ed recently and have a backup there. (There are still some problems with OS updates.) Or better yet, you have automated card backup running at 3 am every night.:-)
There were one or two trojans for PalmOS. It's something nobody really worries about, though. A couple of months ago somebody posted on a dev forum some questions that indicated that he was making a virus scanner, and he got a lot of abuse for it--provoking paranoia, etc., since there is no need for such a product.
Technically, I am sure it would be pretty easy to do something. Of course, I won't talk about the details.
I didn't mean to say that the font system, even with third-party stuff, is superior to what you get on PPC. I suspect that grayscale antialiasing at 320x320 resolution produces roughly the same quality as ClearType at 240x240 (at the cost of some kerning-caused artefacts with FontSmoother), but not having tried a PPC, I don't know.
The use of databases is both a plus and a minus. If one uses the system for what it is designed for, namely storing and editing multiple records, a database system is nice because you can resize data in one record, add a record or delete a record, without having to shift down or up the rest of the data in the database. It makes for neat, compact code for many purposes and on the more traditional PalmOS devices (not the new NVFS ones: T5, Treo 650, TE2), stuff done with databases in RAM is super fast. There is no loading of data when reading--one just locks a memory chunk. Writing is essentially just writing to memory, though one normally calls an OS function that does bound checking and sets a semaphore. For the stuff that PDAs were originally designed for, this is great, unless one happens to be working with databases too big for RAM, in which case one can't avoid the complications coming from working with data on a card where it is stored in a file system.
Most higher end systems in effect combine the two ways of storing data, by having RAM-based databases (or at least ones that the OS makes seem like RAM) for quick retrieval/writing and flash memory (perhaps built-in, as on the T5 or UX50) with a proper file system for multimedia. This is nice technically, but somewhat complicated from the developer point of view, and if the developer is lazy, then also not great from the end-user point of view.
As for crashes, my NX70 hardly ever crashes, except when I am testing buggy versions of my own or other people's software, or perhaps trying legacy software that is no longer compatible with the latest stuff. (Software programmed up to PalmSource spec should continue to work on OS5 (with the exception of the new NVFS systems which are a big screwup from the compatibility point of view, since correctly written old code can fail: one of these days I am going to have to go through all of Plucker and PalmBible+ code and fix most uses of DmQueryRecord(), for instance.). But corners get cut, optimizations made--we know the drill--and so compatibility is sometimes lost.)
Crashes are often a safety mechanism built into PalmOS. The OS could continue blithely ignoring an underlocked chunk. But it crashes lest the software bug that caused the underlocked chunk should cause further damage. Since presumably all data from other apps will have been written out to a database (remember that pre-OS 6 we have essentially a single-threaded system, except for the sound thread), the damage should be minimal. (Except on those Clie NX60/70 units that have a nasty ROM bug.)
The 160x160 (72 DPI) thing is not accurate. Most PalmOS 5 devices are 320x320 (144DPI) or 320x480. Almost all apps that are still being developed use the full 320x320 resolution, and many use 320x480/480x320. Moreover, even legacy apps tend to at least display text in 320x320 (unless they install a custom font that requires 160x160) because PalmOS 5 does that automatically, and standard UI elements like buttons, checkboxes and menus also automatically get upgraded to high resolution. Of course if an app shows bitmaps that haven't been upgraded to 144 DPI, there is nothing the OS can do about that.
2. On fonts:
Agreed--the built-in ones aren't great. But again third-party stuff comes to the rescue. Lubak's Fonts4OS5 provides a bunch of beautiful bitmapped fonts (but not antialiased), while (to give a plug for my own commercial stuff) my own FontSmoother provides antialiased (admittedly, grayscale only) smooth fonts (converted from TTF/Type1 via two different GPL converters, though FontSmoother itself is shareware and closed source).
3. On installing apps in flash:
Actually, non-hackish applications can be installed directly on a flash card without any utilities, though any databases that they use will have to be in RAM unless the app is designed to use databases in flash or unless you use a third-party utility.
4. On the C API:
It may be archaic but it makes for very nice, compact applications and one can develop on basically any platform to which one can port gcc.
5. On OS crashes:
I don't know the PPC world at all, but under PalmOS most crashes aren't a big deal--the system just resets and ten to twenty seconds later you're back up and running. Of course a really bad bug can cause nastier things (reset loops, hard resets, etc.), but that I assume can happen on any platform.
6. On battery life:
Actually, a number of slightly older PalmOS 5 devices have rather poor battery life--three hours or so. But the latest palmOne devices with NVFS have very good battery life.
Slashdot Mirror
I am all for having real OFF switches available as an option. But if one is eliminating standby altogether to save energy, one needs to look at the changes in human behavior that might result and see if it would still save energy.
For instance, if Mr. Couch Potato needs to get up to turn off the TV, he might instead mute it. Granted, we could build a TV that you can fully turn off remotely but where you need a physical switch to turn it back on. But even so, Mr. Couch Potato may not want to turn off the TV if he can't get it back on with his remote.
This is even clearer with devices with a startup time like computers and cellphones. If the alternative to standby is power off and a restart wait, people may just leave them on.
A crucial thing to remember in policy work is that one cannot assume that present behavior will remain the same given the policy. A jurisdiction would not make more money from taxes than it does if it set the tax rate at 100%!
OK, so what Microsoft is doing is not censorship, but complicity in censorship. That does not get them off the hook.
Can't one get news and weather from the radio, also for free (except you have to buy a receiver, but those are cheaper than TVs)?
And in the US the legal way to do it is just to stock multiple DVD ROM drives, each set for a different region. At $20 a drive (plus a single USB2-ATAPI adapter) it's not so bad. It's more or less what the copyright office recommended in response to the request to make region-coded DVDs an exception to the DMCA.
IANAL. But here's what I found by a quick googling:
"Copyright protects only the particular manner of an author's expression in literary, artistic, or musical form. Copyright protection does not extend to any idea, system, method, device, or trademark material involved in the development, merchandising, or playing of a game. Once a game has been made public, nothing in the copyright law prevents others from developing another game based on similar principles.
"Some material prepared in connection with a game may be subject to copyright if it contains a sufficient amount of literary or pictorial expression. For example, the text matter describing the rules of the game, or the pictorial matter appearing on the gameboard or container, may be registrable." - The U.S. Copyright Office (http://www.copyright.gov/fls/fl108.html)
Basically, from the copyright point of view, the guy would have been OK unless he copied the rules verbatim (or maybe close to verbatim) or he copied other parts of the game graphics.
By the way, I wonder if it is possible to sue people for providing false or misleading legal information when they ought to have known better? I am not saying Hasbro is guilty here--that depends on whether the rules were copied verbatim. Another example of the provision of false information are the warnings on DVDs saying that ALL copying is prohibited by law, which is simply false, since there is NO reasonable interpretation (though IANAL) of copyright law under which there is no such thing as fair use. For instance, it seems clearly legal to take a family photograph, for non-commercial purposes, with a TV playing the movie in the background (incidental copying, I think it's called). I wonder if one could get a class action lawsuit by people who were defrauded through the signage.
The CPU is much faster on the TX than on the TH (nice for video playback, for instance, unless one is using video software heavily optimized for the TH's video accelerator), NVFS is nice (no danger of losing data when memory runs out), and the large amount of Program Memory is nice, too. The TH needs third-party software for landscape support.
I am curious: How much of the general public cares very much? A lot of people are quite willing to copy or decrypt things illegally if that's what it takes--presumably it doesn't matter too much to them whether something is legal or not. It matters to me because if it's illegal, then I can't in conscience do it (unless it's a law that it is immoral to obey, or maybe a case of public civil disobedience against an immoral law, etc.) But many people don't mind engaging in illegal copying, illegal circumvention of access controls, etc.
Does this law have exceptions? Otherwise it would seem like it could make it rather hard for TV journalists to do their job...
... being shown" include non-moving-picture works? If so, then it's illegal to use video cameras in just about any business, since just about any business shows copyrighted works, such as advertising posters, book covers, paintings on walls, sculptures in hotel lobbies, etc.
Does "copyrighted work
mpeg4 (the standard behind xvid) and mp3 are also patented. As far as I know, Thomson doesn't ask for payments from people who distribute mp3 decoders (only) for free, but they do ask for them for people who distribute decoders for money. MPEG LA requires licenses for all mpeg4 decoders, free or not, but doesn't charge any royalties to a licensee if one distributes less than 50,000 or maybe 100,000 copies (I've actually become a MPEG LA licensee so that I could have legal copies of xvid and tcpmp for personal use; there are potential GPL Section 7 issues with this, but since I'm only copying for myself, it should be OK, since Section 7 applies to distribution).
These folks have two choices, as far as I know (IANAL). (1) They can license the patents and use commercial or homebrew non-GPL codecs. (2) They can license the patents and use GPL codecs BUT pay the copyright owners of the GPL software for a non-GPL license (otherwise GPL Section 7 MIGHT be a problem).
Movies for portable devices... One could store 60 divx movies at a decent quality level (assuming one lives in a place where this is legal) and view them on a portable device, with much better battery life than a hard drive.
I thought one of the basic ideas behind the GPL was that unlike many commercial EULAs, it has no use restrictions whatsoever--it only governs copying and distribution. Abandoning this principle would be a major change. It would also require moving from the current model on which the legal force of the GPL lies in copyright law which prohibits unauthorized copying and distribution (beyond fair use, etc.) to a model that, like EULAs, is based on contract law (and has all of the dubious validity that some EULAs have). IANAL, though.
Couldn't one have an EULA for a hardcopy book, now? A wrapper that says that if you unwrap this, you are bound. Is there a law prohibiting it?
I assume one could even have a completely unambiguous EULA by making buyers sign something at the bookstore prior to purchase.
Wouldn't upholding a right that you signed away be an infringement on your freedom to enter into contracts (not one of the standard listed freedoms, but a very important one--the ability to make promises is what made humans an interesting animal, Nietsche wrote)?
Of course, some contracts are non-enforceable, e.g., those for slavery. So there are limits even there.
32mb was NOT low in memory for Palm devices at the time. Only the T3 had more.
Actually, the Tapwave people worked hard to make available a much improved software architecture. While PalmOS 5 devices run on ARM processors, most software is written in 68K code which gets run on an emulator, with CPU intensive stuff, hopefully, optimized in ARM. It is possible to write ARM-only code, but hard. There are globals and segmentation issues (hotsync only allows 64K per segment, so things need to get split up). It's a mess. But the Tapwave folks made possible the generation of ARM-only apps, with no silly limitations.
I don't have one myself as I need a built-in keyboard (I have a Clie NX 70), but users were very happy with the Zodiac as a PDA. Fast, tons of memory.
The two big nuisances were that if you wanted to write software that used the hardware acceleration, you had to get it signed, and that you couldn't very easily use a free dev tool chain like prc-tools, but were stuck with Codewarrior.
But copyright law bans copying of expressions, not of ideas. So as far as copyright law goes, one could give away all the ideas, no?
What little I've done with BT surfing on my T5 suggests this was a Sony problem--connections remain after switching apps.
For a while, I had Dvorak set up on my home machine, and I used QWERTY everywhere else. No problems about confusion. All was well. I did notice one thing: I couldn't type in QWERTY on my home machine if the Dvorak driver was off. My brain would see my home machine and automatically switch me into Dvorak mode, and I would type very slowly in QWERTY on my home machine, even though I would type at my normal speed in QWERTY everywhere else (five or six fingered, but still pretty fast; Dvorak I touch typed with all ten fingers).
PalmOS itself can't do it. Definitely not impressive. My Pocket PC executes .exe files right off the memory card. Every PalmOS 5 device will let you execute applications stored in the /PALM/Launcher directory of every inserted card--they automatically show up in a separate Launcher category. This won't work for hack-like applications that need to stay persistently in RAM, of course, but for standard applications it will work. Of course, the app has to be copied to RAM before executing, and this takes time, but the same is true on the PPC, too, no?
Supports resolutions up to VGA and there are already at least 5 devices shipped with it. PalmOS 5 supports resolutions up to VGA and beyond, but there are no devices shipped (though there IS the Dana Alphasmart, which while a 72DPI device has a screen that is about 800 pixels wide, though only 160 tall). Moreover, until devices are shipped, developers aren't bothering to include support in apps (e.g., including triple density bitmaps in bitmap families).
PalmOS 6 will support smooth fonts if an OS 6 device is ever produced. OS 5 does not have any native smooth font support. Of course some applications do smooth fonts stuff on their own, independently of the OS (e.g., PalmFiction, Weasel Reader (I think), Plucker and PalmBible+ on the open source side and Docs To Go, Mobireader, Wordsmith on the closed source side), and there is my shareware FontSmoother that extends smoothed font support to almost all apps, but there is definitely no support in to the OS. Fonts are a definite weakness on the PalmOS side. There is no Unicode support built in, either (and I am not sure if there is any third-party Unicode support).
You do lose data if batteries run out, but hopefully you have sync'ed recently and have a backup there. (There are still some problems with OS updates.) Or better yet, you have automated card backup running at 3 am every night. :-)
There were one or two trojans for PalmOS. It's something nobody really worries about, though. A couple of months ago somebody posted on a dev forum some questions that indicated that he was making a virus scanner, and he got a lot of abuse for it--provoking paranoia, etc., since there is no need for such a product.
Technically, I am sure it would be pretty easy to do something. Of course, I won't talk about the details.
I didn't mean to say that the font system, even with third-party stuff, is superior to what you get on PPC. I suspect that grayscale antialiasing at 320x320 resolution produces roughly the same quality as ClearType at 240x240 (at the cost of some kerning-caused artefacts with FontSmoother), but not having tried a PPC, I don't know.
The use of databases is both a plus and a minus. If one uses the system for what it is designed for, namely storing and editing multiple records, a database system is nice because you can resize data in one record, add a record or delete a record, without having to shift down or up the rest of the data in the database. It makes for neat, compact code for many purposes and on the more traditional PalmOS devices (not the new NVFS ones: T5, Treo 650, TE2), stuff done with databases in RAM is super fast. There is no loading of data when reading--one just locks a memory chunk. Writing is essentially just writing to memory, though one normally calls an OS function that does bound checking and sets a semaphore. For the stuff that PDAs were originally designed for, this is great, unless one happens to be working with databases too big for RAM, in which case one can't avoid the complications coming from working with data on a card where it is stored in a file system.
Most higher end systems in effect combine the two ways of storing data, by having RAM-based databases (or at least ones that the OS makes seem like RAM) for quick retrieval/writing and flash memory (perhaps built-in, as on the T5 or UX50) with a proper file system for multimedia. This is nice technically, but somewhat complicated from the developer point of view, and if the developer is lazy, then also not great from the end-user point of view.
As for crashes, my NX70 hardly ever crashes, except when I am testing buggy versions of my own or other people's software, or perhaps trying legacy software that is no longer compatible with the latest stuff. (Software programmed up to PalmSource spec should continue to work on OS5 (with the exception of the new NVFS systems which are a big screwup from the compatibility point of view, since correctly written old code can fail: one of these days I am going to have to go through all of Plucker and PalmBible+ code and fix most uses of DmQueryRecord(), for instance.). But corners get cut, optimizations made--we know the drill--and so compatibility is sometimes lost.)
Crashes are often a safety mechanism built into PalmOS. The OS could continue blithely ignoring an underlocked chunk. But it crashes lest the software bug that caused the underlocked chunk should cause further damage. Since presumably all data from other apps will have been written out to a database (remember that pre-OS 6 we have essentially a single-threaded system, except for the sound thread), the damage should be minimal. (Except on those Clie NX60/70 units that have a nasty ROM bug.)
The 160x160 (72 DPI) thing is not accurate. Most PalmOS 5 devices are 320x320 (144DPI) or 320x480. Almost all apps that are still being developed use the full 320x320 resolution, and many use 320x480/480x320. Moreover, even legacy apps tend to at least display text in 320x320 (unless they install a custom font that requires 160x160) because PalmOS 5 does that automatically, and standard UI elements like buttons, checkboxes and menus also automatically get upgraded to high resolution. Of course if an app shows bitmaps that haven't been upgraded to 144 DPI, there is nothing the OS can do about that.
2. On fonts:
Agreed--the built-in ones aren't great. But again third-party stuff comes to the rescue. Lubak's Fonts4OS5 provides a bunch of beautiful bitmapped fonts (but not antialiased), while (to give a plug for my own commercial stuff) my own FontSmoother provides antialiased (admittedly, grayscale only) smooth fonts (converted from TTF/Type1 via two different GPL converters, though FontSmoother itself is shareware and closed source).
3. On installing apps in flash:
Actually, non-hackish applications can be installed directly on a flash card without any utilities, though any databases that they use will have to be in RAM unless the app is designed to use databases in flash or unless you use a third-party utility.
4. On the C API:
It may be archaic but it makes for very nice, compact applications and one can develop on basically any platform to which one can port gcc.
5. On OS crashes:
I don't know the PPC world at all, but under PalmOS most crashes aren't a big deal--the system just resets and ten to twenty seconds later you're back up and running. Of course a really bad bug can cause nastier things (reset loops, hard resets, etc.), but that I assume can happen on any platform.
6. On battery life:
Actually, a number of slightly older PalmOS 5 devices have rather poor battery life--three hours or so. But the latest palmOne devices with NVFS have very good battery life.