Ah, as "you" said, then. Regardless, take your own advice. CPU isn't going to cause a 15 second delay to search 25,000 items when searching 5,000 is perceptively instantaneous. Searching will be, at worst, linear, and at best much better. Lack of memory will cause such vastly non-linear behavior, though. Since, as you say, memory is cheap, get more memory.
A 40" 720x480 image at 7 feet will look about the same as about an 11.5 inch (9.6x6.4) image on a 75dpi monitor at 2 feet. It isn't really that impressive, it's about the same as those portable DVD players. In addition, they didn't even say it is that high a resolution, it may be a 360x240 resolution image!
You're right that they aren't aiming this at people who want a virtual computer monitor, and that's why I'm not interested in it. You also missed that what I'd like most about a heads-up display is the ability to do true 3D imaging without shutters or polarization or color filters or any of the other tricks used to do 3D. Yup, they're not aiming for that either, so I'm not interested. I do hope they find a market, though, maybe it will convince someone to come out with what I AM interested in.
The primary advantage they're touting besides weight seems to be that you get a perfectly aligned image to both eyes by splitting a single video source. What I want is the exact opposite - I want two independent video sources being presented so that true 3D can be done. Combine with good virtual 3D sound and you'd really have an "immersive" gaming environment.
A display like this also needs to have HD resolution - everyone doing displays like this talk about "40 inch screen at 7 feet", but conveniently fail to mention resolution, which makes me think it has NTSC resolution or worse. I want something that can replace a monitor, along with a portable input device (e.g. one of those projectable keysets, or a dataglove-type thing with a virtual keyset, or maybe use voice recognition along with that sub-vocal NASA technology), and you'd really be able to have a true portable computer.
There are uses for notifyAll(), just as there are uses for notify(). notifyAll() would typically be used in cases where there is a status change that multiple threads might be waiting for, for example a multiplexed communications channel where the underlying transport layer has been unavailable. notify() would typically be used where one or more threads are waiting for a request (and you've just made one), or where one or more threads are waiting for a resource (and you've just released one). Doesn't make sense to wake up more than one thread when only one of them is going to be able to continue. If you release two, you do two notify() calls, etc. If requests are variable sized and you released something that could satisfy more than one request, you need to do notifyAll() (e.g. a memory pool with variable sized blocks). Remember, when you do notifyAll(), all of the threads waiting on that object except one immediately switch from doing the wait() to trying to acquire the mutex again (the other one is the one that actually GETS the mutex), and then those each wake up in turn as the previous one releases the mutex.
Note that if more than one thread wants multiple resources, and those resources are limited, you could have deadlock problems (and they won't be detected even if you have deadlock detection turned on for the mutex). You'll have to do deadlock avoidance yourself.
Basically, design as if notifyAll() is your only option, but then use notify() when you know that only one thread is going to be able to proceed as a result of what you've just changed. Don't think of it as waking up a specific thread, think of it as signalling a condition, and whatever needs to happen in response to that condition will happen. In fact, when you signal, there might not be ANY threads waiting at that moment, but it doesn't matter - the next thread that WOULD wait will check, find that you've already set the condition so it doesn't need to wait, and continue from there EXACTLY as if it had waited and then you did the notify(). Since it's all protected by the mutex of the object you're waiting/notifying on, everything works out.
In fact, it is probably (though not necessarily) a design error unless every single waiting thread is in exactly the same piece of code in exactly the same state, so it doesn't matter which one is woken up. If you have different threads waiting on different conditions, they should be using different objects to do the waiting. If you have a bunch of threads and always want to just wake up one specific one, then have an object per thread. Depending on the program logic, you may even be able to just use a simple mutex ("synchronized") rather than condition variables (which require a bit more careful attention to exception handling, which is taken care of for you automatically with synchronized methods and blocks).
If your wait() loop is properly written, you can ALWAYS use a notifyAll(), notify() is just an optimization that suggests that it would be redundant to wake more than one thread. In fact, most implementations of condition variables indicate that notify() (or the equivalent) MAY wake more than one thread, though it only guarantees to wake one.
What I don't like about Java's concurrency is a) it forces ALL objects to have a mutex/condition variable structure (stupid wasteful overhead), and b) the condition variable support doesn't allow you to do things like share a mutex for separate condition variables. Yes, it makes it easier to not screw up (by using the wrong mutex entirely), but it also takes away a lot of flexibility.
For example, it is more difficult and less efficient to implement reader/writer interlock models without the ability to have a single mutex with two separate condition variables.
I'd rather have explicit semaphore, mutex and condition variable objects, explicit requests for atomic operations and memory barriers, and explicit support for a conditional-write (can be protected with a mutex on platforms that don't support it in hardware). This avoids the overhead on the majority of operations that just don't need it, and allows a 2GHz processor to actually run as if its fast.
Then include a good native inter-thread message-queue facility with support for single and multiple readers/writers, blocking/non-blocking with waiting on multiple queues, and you thread synchronization would be a snap. Of course, you'd still have to understand what you're doing, or the multi-threading isn't going to gain you anything, but that's going to be true no matter what facilities are available.
I think you're right that Blu-Ray has an advantage because of the name, but not because one is an acronym. It' s just easier to say. DVD isn't too bad by itself, but HD-DVD isn't nearly as pleasant sounding as Blu-Ray. When we start to have to deal with HD-DVD-RW, Blu-Ray will shorten that to BD-RW. I think all around, Blu-Ray will simply end up having a friendlier image to the consumer.
There may also be some negative for HD-DVD because it won't be distinguished enough from DVD. People don't pay that much attention. They'll pick up a DVD, they may even buy an HD-DVD for their regular DVD player, connected to a 21" TV through coax, and decide "this doesn't even play, this new technology sucks", or they'll buy a regular DVD for their brand new $5000 HDTV, say "that doesn't look that much better, this new technology sucks". They won't distinguish HD-DVD from DVD, but they'll recognize the difference between Blu-Ray and DVD just fine.
"selling at a loss" doesn't include R&D, etc. You need to use marginal cost. Obviously, you still need to recover the other sunk costs, but if you're selling at a loss, you'll NEVER make up those costs without another income stream. If you're selling slightly above your marginal costs, you might not be making enough to pay off your other costs, but at least you're not getting further behind with every unit sold.
"I absolutely think that that is an idea that is worth pursuing," an aide to Whitfield said in an interview on Thursday. "If those files were retained for a longer period of time, it would help in the uncovering and prosecution of these crimes."
If we mandate microphones and cameras in every room in every house, it would help in the uncovering and prosecution of these crimes as well. Ends and means, anyone?
There are also third-party sites that do currency exchange (including in-game ATMs - object scripts can communicate with external services). The fee for the LL Currency Exchange is US$0.30 plus 3.5%.
Specifically, your avatar can have the current animation be set and changed by an object, either by giving that object permission, or by sitting on it. A standard way of doing such things is to have "pose balls" or similar (e.g. a "sit" on a couch, or a bed, and it then gets to animate you). There are lots of combo pose balls where one person "sits" on one, the other on the other, and it puts both avatars into a posed position, typically sexual.
Since objects can also communicate, and can be controlled by a player (under control of a script), this allows for as complex interaction between two avatars as you can think of. Either or both can select how they want to act or respond, and a script can select the appropriate synchronized animations to do the appropriate interaction.
ALL avatar motion is controlled by such animations, such as normal sitting, standing, flying, jumping, walking, running, falling. You can also trigger animations on yourself, it isn't only through objects. Besides animations, you can also trigger sounds (which can also be uploaded).
Combined with the ability to upload skin details and attach objects to your body (and said objects can now move as well, e.g. twitching tails, flapping wings), and reshape body details (male or female), the possibilities seem fairly unbounded. Certainly for someone who gets off on phone sex, something like this can add a whole new element.
There also seems to be a big market in selling skins, pose balls, animations and sounds to implement all of this, i.e. the support structure behind the sex trade. Gambling also seems to be big in SL; think of it, you could script a slot machine that allowed anyone to copy it, they run it, and it automatically gives you (the programmer) a cut of the action, without even having to put up any money (and payouts come out of the account of the person who is running the machine, not you). You can do that without needing to actually pay ANY real money, just with the basic free account, and if your slot machine becomes popular, you'll start getting game money rolling in, which you can then trade for real money.
The ambiguity here is whether a negative consequence for exercising a right that you have under the GPL constitutes an "additional restriction" - if it is, a contract that terminates access to future releases if you do exercise your rights under the GPL would be incompatible with the GPL itself. Myself, I can't see how a negative consequence could be considered anything but a restriction, but I can see how it could be interpreted the other way. It sure seems to violate the spirit of the license, though.
a written offer, valid for at least three years, to give any third party
There has been some disagreement about what exactly that phrase means. It could mean that if you are aware that such an offer exists, you can ask the original distributor for a copy of the source, code, or it could mean that you can get a copy of the source code only if you have such a written offer, or a copy of said written offer in the case of a non-commercial distribution as per subsection c:
the information you received as to the offer to distribute corresponding source code
Clearly the intent is that if someone gets a copy of the binary with a written offer, they are allowed to redistribute it non-commercially, along with "the information", and clearly that information must be something that can be acted upon by the third-party recipient in order to get a copy of the source from the original distributor. What isn't clear is if the original recipient of the binary/offer DOESN'T pass it along, is anyone else entitled to get a copy of the source code from the original distributor simply by knowing that it exists and was distributed as a binary-only w/offer. Some people have tried to interpret it as meaning the only obligation the original distributor has is to those that directly received a binary-only distribution from them, but I think that is a flawed understanding.
IIRC, Stallman/FSF sided with a distributor who was making "private" pre-releases, under a restrictive license that said they'd cut you off if you re-distributed it, in other words you had the right to re-distribute, but if you did they'd terminate your paid-for access to such releases in the future. I think this was an ADA compiler? I don't recall the details; there was something similar with a company modifying firmware for a Linksys router.
The easiest way out of all this is to always distribute the source along with the binary; at that point you have no further obligation to anyone. Even easier is to not even distribute the binary, just the source! Pretty difficult to run afoul of the GPL if all you ever distribute is source code.
Macrovision on a DVD is enabled by setting a bit. The manufacturer has to pay royalties to be allowed to set the bit that tells your DVD player to enable Macrovision. If you strip off the CSS, you can turn off the bit, or you can hack the player or access a secret menu to turn off Macrovision. Seems like DRM to me.
Funny - I go to the bookstore, then I go to the fiction section, then I narrow in on the Science Fiction section, then I look for the paperback section, then look up by author, then I find the book I want. We use hierarchies all the time in organizing things.
Usenet uses the reverse order from DNS, and it seems really natural there. rec.aviation is about flying in general, rec.aviation.soaring is about flying gliders.
Using search tools is one way of solving the problem of cross-indexing. Cross-posting in Usenet is another way. Tagging, as you suggest, is another way (but a hierarchy of tags would also be useful, possibly with explicit cross-linking of tags).
Yeah, the CP/M file system had the sector interleave built in as I recall, but disk controllers could format with an interleave as well. Using the wrong formatted interleave with software interleave would make things really slow. Besides interleave, you also used track skew, so that after a head seek after the last sector on a track, the first sector of the next track would just about be getting around. I wrote some routines to do timing on sector reads to determine the formatted interleave and track skew.
Similar techniques were used in hard disk drives as well, before all that stuff was subsumed into the controller and cache buffers started to be used to avoid needing to do most of that stuff, or at least to avoid having anything but the disk hardware be aware of it. UNIX file system may still have vestiges of that stuff left over as part of the disk read scheduling routines.
I don't recall there even being "shell scripts". I do remember that "the shell" would move/relocate itself to high memory, so short programs could be loaded without overwriting it. Longer programs that wanted to use all of memory would then take longer after exit because the command shell would need to be reloaded.
The coolest thing I ever did with the BIOS was to take the print driver from the supplied sample source for a daisy-wheel printer and insert it into the PRN output driver, so for instance Control-P would start properly printing to the daisy-wheel, programs that wanted to print could do so by using the PRN: device instead of having to directly support the printer, etc. Of course, to do anything really pretty with it, e.g. offset-overstrike (bold), or sub-character justification, you needed to talk directly to the printer, but Wordstar supported it so that was all you needed.
Amazing what you could do with 64KB of memory (including screen text buffer) and a 360KB diskette on a, what, 1MHz 8-bit processor?
20 years!? You have NO concept of how fast things change. 20 years ago, a large hard drive was 50MB, you could get 720K on a diskette (800K if you used a Mac), really decked out computers had 4MB of RAM and ran at 10MHz (maybe even 20!). A really good video setup gave you 800x600 with 256 colors, and a 2400 bps dial-up connection was a welcome relief over 300 and 1200 (but getting access to the Internet was not very easy - when NCSA Telnet first came out, it had the SLIP and TCP/IP protocols built in, not part of the OS).
How long have burnable DVDs been out? How fast did the price drop? How long have burnable CDs been out, and how fast did THOSE drop? Remember ZIP disks? Those ALMOST took over for a short while, then burnable CDs got so cheap that most people turned to that. Any format that might challenge Blu-Ray and HD-DVD would have to be the same form factor, so that combo drives can be built that handle all your old media plus the new. I don't see anything like that coming out in the next 2 years, which is about how long it will take for the media prices and burners to come down to reasonable levels where it no longer makes sense to get just a CD burner or DVD burner with a new computer.
Another way of looking at it is: How long ago was it that computers first started coming out with CD readers? How many computers are sold now that have only a CD reader? How much did CD recordable media cost when it first came out? How much did burners cost? How long ago was it that computers first started coming out with DVD readers? How many compuers are now sold with DVD burners instead of just readers? How much did DVD recordable media cost just 2 years ago, and how much does it cost now?
20 years is an eternity these days, in 20 years time I fully expect to have something like a memory stick that stores 500 Terabytes for about $100 (after inflation). And it will be full.
The new DVDs aren't big enough to make an impact on the backup market (where you need 100s of GB per disk to even be considered)
That's just silly. Plenty of companies have backup needs of a few hundred MB of data per day, and CDs are just fine for that. Plenty of companies have backup needs of a few GB of data per day, DVDs are just fine for that. With 25-50GB media, once the price drops a bit, companies that have backup needs of a few 10's of GB per day will find that just fine as well.
When I can back up everything on my parent's hard drive to one disc, I can probably get them to make regular backups more often. Most people are going to be able to fit everything they have on their computer onto one 50GB disc, unless they have lots of video or LOTS of music or photos. Sure, professional photographers, video editors (or people with baby videos) or major music collectors might still want more, but most of that stuff is fairly easy to archive as projects or collections on a disc, unlike the chaos that is the typical hard drive filled with stuff accumulated over 10-20 years which you never quite have time to sort through, but the thought of losing some of it without knowing what it might be fills you with dread. So you want to just back the whole thing up. 4.7GB is not enough for a growing number of people, 50GB is going to be plenty for some time to come.
The artist doesn't LOSE money because someone makes an infringing copy - the artist, the studio, etc. only "lose" money if someone who WOULD have paid money for an authorized copy chooses to not do so because they already have a copy (they don't actually lose money, they fail to MAKE money - the only way they could lose money is if they have some sort of contractual obligation to pay someone per copy made, authorized or not, paid for or not).
Haven't looked at the patent yet, so I don't know exactly what they're claiming, but I wrote an on-line spectator mode for the PLATO game Empire in around 1981. It allowed for changing view (by choosing which ship to follow), and also recorded the game for later playback (in 5 minute increments). The earliest game I still have recorded that I know about is from 1984.
I would think that any enhancements to the basic concept (such as moveable cameras, looking at stats, live replaying as opposed to waiting until the game is over, ability to choose from multiple games) are all obvious, and the methods for doing so are essentially trivial. We didn't do those mods because we cranked it out as a modification to the original game in a very short time, there wasn't a huge audience for it, it wasn't a 3-D shooter, etc. Given a 3-D multi-player shooter, doing all of those things would be obvious, probably even "patently obvious".
Now, if the patent is on some particularly clever method of implementing such a spectator mode, say one that reduces network bandwidth or server load or improves the viewing of the game in some way, I'm all for that (if it truly is innovative, clever, and useful). If it is a patent on the IDEA of a spectator mode, I don't see how it can stand.
I've wondered for some time now what would happen if someone would create a short clip of someone reading those variousversions of DeCSS, possibly with a title scroll, encrypt the whole thing with CSS. Encrypt a copy of a CSS encryption program and a brute-force CSS key break, using a different key. Include a copy of DeCSS source code, and the key to the second file, and a notice that the contents are copyrighted, and that anyone who wants to decrypt the files is free to do so for any purpose other than suing someone for copyright infringement.
If the MPAA tries to sue you, sue them for violating your license, invoking the DMCA against them.
If you can figure it out without doing something illegal, like stealing the specs from the company, violating an NDA or license you've signed, then it isn't a trade secret any more. To be a trade secret, it has to be KEPT secret. DMCA doesn't protect trade secrets that are obfuscated through cryptography, it protects copyrighted content. If the ex-trade-secrets that you discover don't allow you to infringe copyright, then DMCA doesn't fall into it either (remember the garage door opener case?).
Slashdot Mirror
Ah, as "you" said, then. Regardless, take your own advice. CPU isn't going to cause a 15 second delay to search 25,000 items when searching 5,000 is perceptively instantaneous. Searching will be, at worst, linear, and at best much better. Lack of memory will cause such vastly non-linear behavior, though. Since, as you say, memory is cheap, get more memory.
A 40" 720x480 image at 7 feet will look about the same as about an 11.5 inch (9.6x6.4) image on a 75dpi monitor at 2 feet. It isn't really that impressive, it's about the same as those portable DVD players. In addition, they didn't even say it is that high a resolution, it may be a 360x240 resolution image!
You're right that they aren't aiming this at people who want a virtual computer monitor, and that's why I'm not interested in it. You also missed that what I'd like most about a heads-up display is the ability to do true 3D imaging without shutters or polarization or color filters or any of the other tricks used to do 3D. Yup, they're not aiming for that either, so I'm not interested. I do hope they find a market, though, maybe it will convince someone to come out with what I AM interested in.
Then you probably need more memory! As he said, memory is cheap.
The primary advantage they're touting besides weight seems to be that you get a perfectly aligned image to both eyes by splitting a single video source. What I want is the exact opposite - I want two independent video sources being presented so that true 3D can be done. Combine with good virtual 3D sound and you'd really have an "immersive" gaming environment.
A display like this also needs to have HD resolution - everyone doing displays like this talk about "40 inch screen at 7 feet", but conveniently fail to mention resolution, which makes me think it has NTSC resolution or worse. I want something that can replace a monitor, along with a portable input device (e.g. one of those projectable keysets, or a dataglove-type thing with a virtual keyset, or maybe use voice recognition along with that sub-vocal NASA technology), and you'd really be able to have a true portable computer.
There are uses for notifyAll(), just as there are uses for notify(). notifyAll() would typically be used in cases where there is a status change that multiple threads might be waiting for, for example a multiplexed communications channel where the underlying transport layer has been unavailable. notify() would typically be used where one or more threads are waiting for a request (and you've just made one), or where one or more threads are waiting for a resource (and you've just released one). Doesn't make sense to wake up more than one thread when only one of them is going to be able to continue. If you release two, you do two notify() calls, etc. If requests are variable sized and you released something that could satisfy more than one request, you need to do notifyAll() (e.g. a memory pool with variable sized blocks). Remember, when you do notifyAll(), all of the threads waiting on that object except one immediately switch from doing the wait() to trying to acquire the mutex again (the other one is the one that actually GETS the mutex), and then those each wake up in turn as the previous one releases the mutex.
Note that if more than one thread wants multiple resources, and those resources are limited, you could have deadlock problems (and they won't be detected even if you have deadlock detection turned on for the mutex). You'll have to do deadlock avoidance yourself.
Basically, design as if notifyAll() is your only option, but then use notify() when you know that only one thread is going to be able to proceed as a result of what you've just changed. Don't think of it as waking up a specific thread, think of it as signalling a condition, and whatever needs to happen in response to that condition will happen. In fact, when you signal, there might not be ANY threads waiting at that moment, but it doesn't matter - the next thread that WOULD wait will check, find that you've already set the condition so it doesn't need to wait, and continue from there EXACTLY as if it had waited and then you did the notify(). Since it's all protected by the mutex of the object you're waiting/notifying on, everything works out.
In fact, it is probably (though not necessarily) a design error unless every single waiting thread is in exactly the same piece of code in exactly the same state, so it doesn't matter which one is woken up. If you have different threads waiting on different conditions, they should be using different objects to do the waiting. If you have a bunch of threads and always want to just wake up one specific one, then have an object per thread. Depending on the program logic, you may even be able to just use a simple mutex ("synchronized") rather than condition variables (which require a bit more careful attention to exception handling, which is taken care of for you automatically with synchronized methods and blocks).
If your wait() loop is properly written, you can ALWAYS use a notifyAll(), notify() is just an optimization that suggests that it would be redundant to wake more than one thread. In fact, most implementations of condition variables indicate that notify() (or the equivalent) MAY wake more than one thread, though it only guarantees to wake one.
What I don't like about Java's concurrency is a) it forces ALL objects to have a mutex/condition variable structure (stupid wasteful overhead), and b) the condition variable support doesn't allow you to do things like share a mutex for separate condition variables. Yes, it makes it easier to not screw up (by using the wrong mutex entirely), but it also takes away a lot of flexibility.
For example, it is more difficult and less efficient to implement reader/writer interlock models without the ability to have a single mutex with two separate condition variables.
I'd rather have explicit semaphore, mutex and condition variable objects, explicit requests for atomic operations and memory barriers, and explicit support for a conditional-write (can be protected with a mutex on platforms that don't support it in hardware). This avoids the overhead on the majority of operations that just don't need it, and allows a 2GHz processor to actually run as if its fast.
Then include a good native inter-thread message-queue facility with support for single and multiple readers/writers, blocking/non-blocking with waiting on multiple queues, and you thread synchronization would be a snap. Of course, you'd still have to understand what you're doing, or the multi-threading isn't going to gain you anything, but that's going to be true no matter what facilities are available.
I think you're right that Blu-Ray has an advantage because of the name, but not because one is an acronym. It' s just easier to say. DVD isn't too bad by itself, but HD-DVD isn't nearly as pleasant sounding as Blu-Ray. When we start to have to deal with HD-DVD-RW, Blu-Ray will shorten that to BD-RW. I think all around, Blu-Ray will simply end up having a friendlier image to the consumer.
There may also be some negative for HD-DVD because it won't be distinguished enough from DVD. People don't pay that much attention. They'll pick up a DVD, they may even buy an HD-DVD for their regular DVD player, connected to a 21" TV through coax, and decide "this doesn't even play, this new technology sucks", or they'll buy a regular DVD for their brand new $5000 HDTV, say "that doesn't look that much better, this new technology sucks". They won't distinguish HD-DVD from DVD, but they'll recognize the difference between Blu-Ray and DVD just fine.
"selling at a loss" doesn't include R&D, etc. You need to use marginal cost. Obviously, you still need to recover the other sunk costs, but if you're selling at a loss, you'll NEVER make up those costs without another income stream. If you're selling slightly above your marginal costs, you might not be making enough to pay off your other costs, but at least you're not getting further behind with every unit sold.
If we mandate microphones and cameras in every room in every house, it would help in the uncovering and prosecution of these crimes as well. Ends and means, anyone?
There are also third-party sites that do currency exchange (including in-game ATMs - object scripts can communicate with external services). The fee for the LL Currency Exchange is US$0.30 plus 3.5%.
Specifically, your avatar can have the current animation be set and changed by an object, either by giving that object permission, or by sitting on it. A standard way of doing such things is to have "pose balls" or similar (e.g. a "sit" on a couch, or a bed, and it then gets to animate you). There are lots of combo pose balls where one person "sits" on one, the other on the other, and it puts both avatars into a posed position, typically sexual.
Since objects can also communicate, and can be controlled by a player (under control of a script), this allows for as complex interaction between two avatars as you can think of. Either or both can select how they want to act or respond, and a script can select the appropriate synchronized animations to do the appropriate interaction.
ALL avatar motion is controlled by such animations, such as normal sitting, standing, flying, jumping, walking, running, falling. You can also trigger animations on yourself, it isn't only through objects. Besides animations, you can also trigger sounds (which can also be uploaded).
Combined with the ability to upload skin details and attach objects to your body (and said objects can now move as well, e.g. twitching tails, flapping wings), and reshape body details (male or female), the possibilities seem fairly unbounded. Certainly for someone who gets off on phone sex, something like this can add a whole new element.
There also seems to be a big market in selling skins, pose balls, animations and sounds to implement all of this, i.e. the support structure behind the sex trade. Gambling also seems to be big in SL; think of it, you could script a slot machine that allowed anyone to copy it, they run it, and it automatically gives you (the programmer) a cut of the action, without even having to put up any money (and payouts come out of the account of the person who is running the machine, not you). You can do that without needing to actually pay ANY real money, just with the basic free account, and if your slot machine becomes popular, you'll start getting game money rolling in, which you can then trade for real money.
The ambiguity here is whether a negative consequence for exercising a right that you have under the GPL constitutes an "additional restriction" - if it is, a contract that terminates access to future releases if you do exercise your rights under the GPL would be incompatible with the GPL itself. Myself, I can't see how a negative consequence could be considered anything but a restriction, but I can see how it could be interpreted the other way. It sure seems to violate the spirit of the license, though.
There has been some disagreement about what exactly that phrase means. It could mean that if you are aware that such an offer exists, you can ask the original distributor for a copy of the source, code, or it could mean that you can get a copy of the source code only if you have such a written offer, or a copy of said written offer in the case of a non-commercial distribution as per subsection c:
Clearly the intent is that if someone gets a copy of the binary with a written offer, they are allowed to redistribute it non-commercially, along with "the information", and clearly that information must be something that can be acted upon by the third-party recipient in order to get a copy of the source from the original distributor. What isn't clear is if the original recipient of the binary/offer DOESN'T pass it along, is anyone else entitled to get a copy of the source code from the original distributor simply by knowing that it exists and was distributed as a binary-only w/offer. Some people have tried to interpret it as meaning the only obligation the original distributor has is to those that directly received a binary-only distribution from them, but I think that is a flawed understanding.IIRC, Stallman/FSF sided with a distributor who was making "private" pre-releases, under a restrictive license that said they'd cut you off if you re-distributed it, in other words you had the right to re-distribute, but if you did they'd terminate your paid-for access to such releases in the future. I think this was an ADA compiler? I don't recall the details; there was something similar with a company modifying firmware for a Linksys router.
The easiest way out of all this is to always distribute the source along with the binary; at that point you have no further obligation to anyone. Even easier is to not even distribute the binary, just the source! Pretty difficult to run afoul of the GPL if all you ever distribute is source code.
Macrovision on a DVD is enabled by setting a bit. The manufacturer has to pay royalties to be allowed to set the bit that tells your DVD player to enable Macrovision. If you strip off the CSS, you can turn off the bit, or you can hack the player or access a secret menu to turn off Macrovision. Seems like DRM to me.
Funny - I go to the bookstore, then I go to the fiction section, then I narrow in on the Science Fiction section, then I look for the paperback section, then look up by author, then I find the book I want. We use hierarchies all the time in organizing things.
Usenet uses the reverse order from DNS, and it seems really natural there. rec.aviation is about flying in general, rec.aviation.soaring is about flying gliders.
Using search tools is one way of solving the problem of cross-indexing. Cross-posting in Usenet is another way. Tagging, as you suggest, is another way (but a hierarchy of tags would also be useful, possibly with explicit cross-linking of tags).
Yeah, the CP/M file system had the sector interleave built in as I recall, but disk controllers could format with an interleave as well. Using the wrong formatted interleave with software interleave would make things really slow. Besides interleave, you also used track skew, so that after a head seek after the last sector on a track, the first sector of the next track would just about be getting around. I wrote some routines to do timing on sector reads to determine the formatted interleave and track skew.
Similar techniques were used in hard disk drives as well, before all that stuff was subsumed into the controller and cache buffers started to be used to avoid needing to do most of that stuff, or at least to avoid having anything but the disk hardware be aware of it. UNIX file system may still have vestiges of that stuff left over as part of the disk read scheduling routines.
I don't recall there even being "shell scripts". I do remember that "the shell" would move/relocate itself to high memory, so short programs could be loaded without overwriting it. Longer programs that wanted to use all of memory would then take longer after exit because the command shell would need to be reloaded.
The coolest thing I ever did with the BIOS was to take the print driver from the supplied sample source for a daisy-wheel printer and insert it into the PRN output driver, so for instance Control-P would start properly printing to the daisy-wheel, programs that wanted to print could do so by using the PRN: device instead of having to directly support the printer, etc. Of course, to do anything really pretty with it, e.g. offset-overstrike (bold), or sub-character justification, you needed to talk directly to the printer, but Wordstar supported it so that was all you needed.
Amazing what you could do with 64KB of memory (including screen text buffer) and a 360KB diskette on a, what, 1MHz 8-bit processor?
20 years!? You have NO concept of how fast things change. 20 years ago, a large hard drive was 50MB, you could get 720K on a diskette (800K if you used a Mac), really decked out computers had 4MB of RAM and ran at 10MHz (maybe even 20!). A really good video setup gave you 800x600 with 256 colors, and a 2400 bps dial-up connection was a welcome relief over 300 and 1200 (but getting access to the Internet was not very easy - when NCSA Telnet first came out, it had the SLIP and TCP/IP protocols built in, not part of the OS).
How long have burnable DVDs been out? How fast did the price drop? How long have burnable CDs been out, and how fast did THOSE drop? Remember ZIP disks? Those ALMOST took over for a short while, then burnable CDs got so cheap that most people turned to that. Any format that might challenge Blu-Ray and HD-DVD would have to be the same form factor, so that combo drives can be built that handle all your old media plus the new. I don't see anything like that coming out in the next 2 years, which is about how long it will take for the media prices and burners to come down to reasonable levels where it no longer makes sense to get just a CD burner or DVD burner with a new computer.
Another way of looking at it is: How long ago was it that computers first started coming out with CD readers? How many computers are sold now that have only a CD reader? How much did CD recordable media cost when it first came out? How much did burners cost? How long ago was it that computers first started coming out with DVD readers? How many compuers are now sold with DVD burners instead of just readers? How much did DVD recordable media cost just 2 years ago, and how much does it cost now?
20 years is an eternity these days, in 20 years time I fully expect to have something like a memory stick that stores 500 Terabytes for about $100 (after inflation). And it will be full.
That's just silly. Plenty of companies have backup needs of a few hundred MB of data per day, and CDs are just fine for that. Plenty of companies have backup needs of a few GB of data per day, DVDs are just fine for that. With 25-50GB media, once the price drops a bit, companies that have backup needs of a few 10's of GB per day will find that just fine as well.
When I can back up everything on my parent's hard drive to one disc, I can probably get them to make regular backups more often. Most people are going to be able to fit everything they have on their computer onto one 50GB disc, unless they have lots of video or LOTS of music or photos. Sure, professional photographers, video editors (or people with baby videos) or major music collectors might still want more, but most of that stuff is fairly easy to archive as projects or collections on a disc, unlike the chaos that is the typical hard drive filled with stuff accumulated over 10-20 years which you never quite have time to sort through, but the thought of losing some of it without knowing what it might be fills you with dread. So you want to just back the whole thing up. 4.7GB is not enough for a growing number of people, 50GB is going to be plenty for some time to come.
1984, 10-pack of 400K diskettes was about $50.
The artist doesn't LOSE money because someone makes an infringing copy - the artist, the studio, etc. only "lose" money if someone who WOULD have paid money for an authorized copy chooses to not do so because they already have a copy (they don't actually lose money, they fail to MAKE money - the only way they could lose money is if they have some sort of contractual obligation to pay someone per copy made, authorized or not, paid for or not).
Uh, hthe question asked was if a non-down-rezzed video would be sent over non-HDCP DVI if the ICT bit is NOT enabled.
Haven't looked at the patent yet, so I don't know exactly what they're claiming, but I wrote an on-line spectator mode for the PLATO game Empire in around 1981. It allowed for changing view (by choosing which ship to follow), and also recorded the game for later playback (in 5 minute increments). The earliest game I still have recorded that I know about is from 1984.
I would think that any enhancements to the basic concept (such as moveable cameras, looking at stats, live replaying as opposed to waiting until the game is over, ability to choose from multiple games) are all obvious, and the methods for doing so are essentially trivial. We didn't do those mods because we cranked it out as a modification to the original game in a very short time, there wasn't a huge audience for it, it wasn't a 3-D shooter, etc. Given a 3-D multi-player shooter, doing all of those things would be obvious, probably even "patently obvious".
Now, if the patent is on some particularly clever method of implementing such a spectator mode, say one that reduces network bandwidth or server load or improves the viewing of the game in some way, I'm all for that (if it truly is innovative, clever, and useful). If it is a patent on the IDEA of a spectator mode, I don't see how it can stand.
I've wondered for some time now what would happen if someone would create a short clip of someone reading those various versions of DeCSS, possibly with a title scroll, encrypt the whole thing with CSS. Encrypt a copy of a CSS encryption program and a brute-force CSS key break, using a different key. Include a copy of DeCSS source code, and the key to the second file, and a notice that the contents are copyrighted, and that anyone who wants to decrypt the files is free to do so for any purpose other than suing someone for copyright infringement.
If the MPAA tries to sue you, sue them for violating your license, invoking the DMCA against them.
If you can figure it out without doing something illegal, like stealing the specs from the company, violating an NDA or license you've signed, then it isn't a trade secret any more. To be a trade secret, it has to be KEPT secret. DMCA doesn't protect trade secrets that are obfuscated through cryptography, it protects copyrighted content. If the ex-trade-secrets that you discover don't allow you to infringe copyright, then DMCA doesn't fall into it either (remember the garage door opener case?).