Since they are providing the movie as an individual download from their server, each download should be unique. I would be very surprised if they did not watermark each download in such a way that it could be traced back to whoever originally paid for the movie (credit card, or whatever). This should make it harder to pirate the movie, because of the danger of being caught if the pirate failed to strip the watermark completely (not easy, if hidden well and the original is unavailable).
Also, I would be very surprised if they did not require an Internet connection to activate the movie once it has finished downloading. The 24-hour timer could then start at that point. It would be extremely unfair to start the 24-hour timer before the movie has completely finished downloading, as many of those hours could be used up by a slow download! Each viewing of the movie probably also requires an Internet connection, as pointed out earlier, if only to connect to an external trusted clock (it would be otherwise trivial to change the computer's clock to defeat the 24-hour timer).
Think it will succeed? $3.99 is a competitive price with Blockbuster and other conventional video stores. However, the selection is very poor. HP is clearly an experiment by the studio, as they released it on DVD without Macrovision. They took a leap of faith there, and they are doing it again with this Internet download offer. They are waiting for results before offering any other major film (hence their padding of the service with only obscure B-movies).
I'd be interested in knowing the piracy rates for HP versus a similiar major film; my bet is that the lack of certain copy protection measures doesn't make a difference, as the DVD format has already been cracked six ways from Sunday. Affordable downloads are the way to go to defeat P2P, making it easier and less frustrating to get the content legitimately!
While MS definitely tried to pollute Java and split the Java community, they are not solely to blame for Java's lack of mainstream acceptance.
I believe Netscape's slow loading time and poor performance had a lot to do with it. Back in the days of Netscape 4, I watched a lot of non-techie people groan when seeing the "Starting Java..." message appear at the bottom of their browser. It meant a guaranteed wait of over 30 seconds, during which they could do nothing at all (not even click on another page). Netscape 3 was worse: there was no message, so the browser would just freeze and the user wouldn't know why!
When the Java applets eventually appeared on the page, users learned that Java equals a long wait. After suffering through this a few times, users came to dread Java pages. Note that all of this was on Netscape, before Microsoft's MSIE became prominent! The uselessness of many Java applets, many just simple animations to draw attention, also turned many people away: "I waited all that time, just for this silly animation?" Flash has replaced Java for these things, to the relief of many users.
So don't just have the kneejerk reaction of blaming Microsoft.... I firmly believe this poor implementation from Netscape is what originally caused Java's downfall.
More than a recovery disk/CD, of which several already exist, I would love a comparison disk. It would be for use after suspecting an attack.
It would boot from floppy or CD, guaranteeing that it would be in control and not trusting the hard drive for anything at all.
It would contain Tripwire-style keys for every system-installed file in the distribution. When booted, it would check each file against these keys, and output a list of files that do not match.
So, if one has been rooted with a good rootkit that modifies the operating system to cloak hacked files, one could then boot this disk/CD and be sure of being completely in control with a known good operating system. All files on the hard disk would be able to be accessed honestly, for a true comparison!
Does such a tool exist already?
It would be fairly easy to add this to the Red Hat installer. In addition to having an option to install, it would have an option to compare an existing system. It would go through the standard installation steps (choosing partitions, etc.) but compare instead of copy. A byte-for-byte comparison could then be done, for true honesty. If any mismatches are found, it would complain loudly, and give you the option at the end of simply overwriting the changed files (under your control, of course, and on an individual basis).
What do you think? Does such a tool already exist? I would love to use it if it does.
Too much excess capacity, not enough fiber was a myth, etc.
There would have been demand for the capacity... if organizations like the RIAA had not ruled it illegal!
As more and more of the good new uses of computers are being made illegal, demand for bandwidth is dropping. The same is happening for CPU power (DVD ripping, music encoding, etc.). End users are afraid to upgrade their computers, for fear of triggering Windows Product Activation. The whole tech economy is in a tailspin, caused by copyright greed....
It's 9/7-9/8 in San Jose, and they have tons of good restored pinball and video games on free play for the entire weekend. So get in your chance to play pinball on machines that are [b]not[/b] broken:-)
I thought of this as well, back when I interviewed at ReplayTV (I didn't get in, but that's neither here nor there).
Why not make a hard drive with two arms? They would be located 180 degrees apart from each other, so they would never bump into each other.
Each arm would be able to access the entire range of the hard drive.
One would be read-write and the other would be read-only, or both of them could be read-write if there would be no significant increase in cost.
This would be great for TiVo and ReplayTV units, which need to read large continuous amounts of data while writing large continuous amounts of different data! And it would be much quieter than the current one-arm drives, that have to thrash, making the units more appealing in a residential environment (one of the main complaints about the units is that the drives are too loud).
Considering the large quantities of drives that TiVo or ReplayTV use, is a special order out of the question? I'm sure this has been thought of before, and with a large enough order, anything is possible within reason. Western Digital made a custom drive for a large order, and found it to have such a good idea that it was officially added to their product line! (It's the larger 8MB cache in a "special edition" of their 100GB drive.)
Unfortunately this kind of drive would not work well with IDE. IDE is designed to wait for one command to complete before executing another command. So this means that the gain of being able to execute read-write commands in parallel would be neutered by this protocol. A solution is to use a SCSI drive that supports Tagged Command Queuing (TCQ)! This drive, if the controller and OS software support it, can stack up multiple commands that can be resolved in any order, as fast as the drive allows. This means that multiple outstanding commands could be sent to the drive, and the drive firmware would be free to execute them in the optimal order.
This would be a great advantage, as it could allow a slower drive to be used (less power consumption, less heat, less chance of failure). The slowness of the drive would be offset by the two arm design, making the drive effectively twice as fast. It might be even faster than that, as seek time would be reduced to almost nothing when reading or writing simultaneously from two different places!
The only disadvantage would be increased cost of having to use a SCSI drive (including controller) versus an IDE drive, and a one-time cost of having to add support for TCQ to whatever OS that is being used.
I wonder if a two-arm drive is being planned for use in ReplayTV or TiVo units? It seems like too good of an idea to pass up....
I used to work there! Compression Labs (CLI) made equipment for digital video compression. They were the company behind the short-lived AT&T "videophone" that appeared in the early 1990's. Their main bread and butter was video conferencing systems for businesses and hotels. They were dedicated boxes on wheels, complete with TV and camera and computer, that looked like those old TV carts you see in schools. The idea was that you rolled them to whatever meeting room your company used, then hooked up to a T1 or ISDN line for the videoconference. They also made some other units, such as standalone systems for permanent installation, but the wheeled systems were the most popular.
Unfortunately as the generic PC became faster and better at handling video, there became less and less of a need for dedicated video compression hardware. The company started losing sales and going downhill. Compression Labs did have an industry niche, a very easy to use system that was completely turnkey, but as with so many things, low cost won out in the end.
VTEL, a competitor, bought Compression Labs. VTEL made similar videoconferencing machines, but they were integrated with a PC. They were harder to use, but had PC niceties such as the ability to share PC files and access over the videoconference. Unfortunately they weren't selling very well either.
I left the company around the time CLI was bought out by VTEL. It seems they've renamed themselves to Forgent, and set up a business model of providing services instead of selling boxes. Probably a smart move. It is a dumb move to enforce this patent, though!
While CLI had a lot of good patents, they applied mostly to video and the way it was compressed before transmission and restored after reception. They used the H.* standards for digital video transmission, but there is a lot of leeway in how you process the video signal at both ends to make the most use of the bandwidth, and this is where CLI's patents came in.
I don't believe this patent could apply to still images such as JPEG. Reading the patent, I see it mentions successive video frames quite often. Maybe there are some parts that deal with JPEG-like encoding methods, but IANAL. Honestly, I don't believe this patent can be valid, especially after the company submarined for so long and is only now claiming enforcement. They were a company I was once proud to be a part of, and it makes me sad to see them stooping to this level.
Have you played Visual Pinball? It is a modern equivalent of Pinball Construction Set, with a 3-D table appearance, supporting ramps and multiple levels and such. It uses VBS (gasp) as the scripting language... the first non-viral use of VBS that I've ever seen!
Unfortunately there is no way to make a standalone player yet. It is a free program (closed source), but it runs only on Windows, and the author has plans to take it commercial someday so get it while you can.
I loved Pinball Construction Set, and made several Apple ][ disks full of games. Bill Budge recently did a very wonderful thing: he declared all of his past Apple ][ games to be in the public domain! A great thing, and I wish more authors of classic software would do the same.
It's actually a phrase from English -- "Dot Com Mode". When abbreviated in that cute Japanese syllabic way, DoCoMo!
It's a happy coincidence that it is pronounced similar to dokomo (everywhere), as you said. I hope that comes true. I can't wait for DoCoMo to be available in the USA!!
An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.
A patch to aggressively cache the disk in memory, for instance, might be good for servers but not for embedded systems. So, I could understand how a patch would be rejected in this case.
As an example, a company I once worked for made many minor changes to the Linux kernel. Since Linux is GPL, I made a webpage publishing these changes, and unlike the company, my webpage is still in existence!
True, most webcasting uses UDP. (Broadcast to listeners behind firewalls is the main exception.)
For UDP, you could simply consider start and end time to be the time the first and last UDP packets were sent. Note that they require duration of transmission, not reception! An acknowledgement mechanism is not necessary. (In practice, most streaming protocols do require a periodic ACK generated by the client, to avoid uselessly sending packets once the listener closes the client.)
My take on each of these required fields, in order....
A) The name of the service, B) The channel of the program (AM/FM stations use station id), C) The type of program (Archived/Looped/Live): These are constants. Easy.
D) Date of Transmission, E) Time of Transmission: Simple timestamping, which most stations already do in their internal logs.
F) Time zone of origination of Transmission: Another constant, for small organizations with a single server. For large broadcasters that use geographically distributed server-side caching networks such as Akamai, this translates to "F) The local streaming server the listener is connected to".
G) Numeric designation of the place of the sound recording within the program: This seems to be worded to apply if the song is part of a predetermined set of songs (e.g. a prerecorded program being rebroadcast). For live stations, whose program is continuous, this will simply equal the timestamp.
H) Duration of transmission (to nearest second), I) Sound Recording Title: FreeDB, anyone? Regardless, these should already be represented in the music files that are broadcast, as song length and filename.
J) The ISRC code of the recording: Tricky. There are some CD drives out there that can read barcode and ISRC numbers, but this is rare. A paid subscription to a large commercial database might be necessary (another fee!), as has been pointed out. No doubt this is the intention of the RIAA, as they already know this information and simply want to make it a burden to collect.
K) The release year of the album per copyright notice and in the case of compilation albums, the release year of the album and copyright date of the track, L) Featured recording artist, M) Retail album title, N) The recording Label, : More information that should already be in a fully populated FreeDB entry. If it isn't, the gaps will have to be filled in, either by database subscription or manual retyping from the CD liner notes.
O) The UPC code of the retail album: Another standard tracking number. See ISRC above. How much would you like to bet that the few record companies that put barcode and ISRC numbers on their CD's will stop doing this, just to make it harder for independent online radio stations to learn these numbers?
P) The catalog number, Q) The copyright owner information, : More database information. I assume by "catalog number" that they mean the catalog of a record company (the number they assign for each release).
At least almost all of these statistics are constants for a given recording. Enter the data once, and that's it. There is no extra recurring cost to use the information after it has been obtained, which is good. Besides, most radio stations don't have a very large playlist! A few nights of data entry should be all it takes to comply with these requirements.
R) The musical genre of the channel or program (station format): The list is closed off by another easy constant.
For online stations, though, they start tightening the screws:
1) The name of the service or entity, 2) The channel or program, : Some simple constants, to lull you into thinking that compliance will be easy.
3) the date and time that the user logged in, 4) the date and time that the user logged out: With existing unicast stations, this is easy: connection start and stop times are already logged by almost all online radio stations. With multicast, it would be hard, though. The server might not even be notified if a distant client joins the stream, if a downstream router performs the multiplexing! In this case, it would be impossible to gather this information.
The RIAA might have a hidden agenda here, to kill multicasting before it can get off the ground. This ensures that only the well-funded huge corporate stations, friends of the RIAA, can broadcast online.
5) The time zone where the signal was received (user): This is the biggie. Subscriptions to a geolocation service, such as Quova, are now mandatory! Another large fee. (This time zone requirement also applies to the user timestamping requirements above.)
6) Unique User identifier: This is very vague. At the least, it could simply be a cookie that is sent to the user's browser. Privacy-disregarding corporate media players such as RA and WMP already upload user tracking information, as we have seen. Still, there is no way to track users that is 100% certain. And this is another category that will be impossible to determine if multicasting is used!
7) The country in which the user received the transmissions: Confirmation that a geolocation subscription is now required.
Well, these are lame, but they seem to have their intended effect: scaring off all competitors to RIAA-approved prolefeed. Online radio stations, rather than pay for two database services (geolocation and CD identification), would find it easier just to give up.
Well, that's it, folks. It's been nice having online radio while we could.
With these new regs, it will be the death knell of webcasting. Expect Live365 to fold within a month once these new regs take effect. Nullsoft Shoutcast and Spinner will hold on a little longer, as they are subsidized by AOL, but it too will disappear. The smaller independent stations? *poof*, as another poster put it! Considering the new fees are retroactive to 1998, if I were an online broadcaster, I'd be scrambling to dismantle my setup before they find me and send me the bill!
A shame this has to happen just when SSM, Source-Specific Multicast, was getting off the ground. Finally, an almost complete rearchitecturing of the failed Internet Multicast protocol. It addresses the two primary shortcomings of existing multicast -- address shortage and DoS attacks -- and looks like it actually could have worked.
To anyone who's watched developments in online radio technology, SSM is like nirvana. The Class D multicast address shortage is solved, by effectively using 64-bit addresses: a station's existing unicast IP address is simply concatenated with a multicast address in SSM's address range (232.x.x.x, equivalent to a big fat Class A!). And there's no central authority to go through, the station just simply chooses one of these address! This effectively gives the station the capability for 16 million channels (different SSM trees of listeners).
That's right, it's finally a tree! The many-to-many multicast model has been replaced with one-to-many. Formerly, a rogue client could simply inject data into the stream, and that data would be replicated to all other listeners. Not good. Since SSM is a tree, with the originating station at the root, this problem is solved. It will become much more difficult to "jam" a SSM station (a router close to the source would have to be hacked). With these two main problems solved, Internet multicasting would finally be good to go...!
It would have been a wonderful thing, had these new rules not been enacted. This new SSM protocol might have taken off, helping to alleviate the enourmous waste of bandwidth caused by having to repeatedly unicast the same stream to each individual listener.
Possibly the only good thing that can come out of this is more exposure for unsigned garage bands. If SSM helps to reduce the bandwidth cost of streaming, and the garage band owns their own copyrights (not a member of ASCAP/BMI/SESAC/RIAA), then it might be affordable for them to broadcast online....
In a perfect world there would be no copyright, but it isn't. So I propose a compromise.
Overturn the Sonny Bono Copyright Extension Act, thus restoring copyright lengths to their traditional duration (death plus 75 years if a person, a flat 75 years if a corporation). (This is one of the few areas of law where a person has more power than a corporation!)
However, make it possible for Congress to authorize an exemption, if a certain work proves to have significant commercial value. Perhaps a high fee (at least thousands of dollars) could be charged to grant the exemption, proving that the work still has commercial value enough to justify doing this.
This way, works that are forgotten nowadays could gracefully enter the public domain when their copyrights lapse. A good example is "Oswald The Lucky Rabbit". This cartoon character was popular around 1928, and should be due to enter the public domain soon. Another certain cartoon character of this time, who has a fondness for whistling while steering steamboats down the Mississippi, would be protected by Congress.
This is similar to what the UK did for the Peter Pan copyright. However, in this case, I propose simply extending the copyright term for another 50 years or so -- not forever as the UK did.
With this compromise, it wouldn't be necessary to perpetually extend copyright for all works... just the few rare ones that are still commercially valuable in the present day. And the public domain could continue to be enriched by the thousands of forgotten items that trickle in each year as their copyright expires. And perhaps this could help the government get some extra money without raising taxes, too!
They are working on a new technology to replace CCD, to answer your question.
Claimed on their website: DPS technology, in contrast, intelligently combines both image capture and image processing into a single system, which allows for both design simplicity and improved image quality. By marrying the quality of CCDs, the low-cost, mass production capabilities of CMOS and the power of image processing in a single system, Pixim's DPS platform revolutionizes image-making in both video and still cameras.
From what I gather, it's a way of measuring light directly onto a chip, without having to go through the CCD process. Sounds good to me. Hopefully it will make it so digital cameras don't drink batteries:-)
This is very common on the Game Show Network, and has been going on for months.
Note all the complaining about their "time machine" in the
newsgroup.
It is especially noticeable during Press Your Luck, due to the fast repetitive action of the game board. Michael Larsen would have a hard time using his VCR to beat the game today, as the frames now don't appear as smoothly and consistently as they once did!
I lived and grew up there, and went to high school in Mendocino. (Hi Bob and Dylan!)
It's true that the village has successfully kept cellphone towers out. (It's not a town, as it's not incorporated.) The whole area is one big dead zone. Much of the entire county is strictly analog, anyway -- it seems to have been passed by when digital service was brought to other areas. Instead of talking on a cellphone, there are other fine
activities to do in Mendocino County.
It's a small area dependent on tourism. One of the major draws is that it is a place to get away from all the hustle and bustle of larger cities. The Historical (some say Hysterical) Review Board strictly enforces the cellphone ban and other ordinances that seem silly, such as not allowing any remodeling that changes the look of the village! It is a unique area very popular with artists and hippies, and has a completely different culture than what most Slashdotters are used to.
But the electronics lab and computer lab in the high school kicks ass:-)
IP header compression that "can compress a typical IPv4 header from 40 bytes to as little as 2 bytes", according to the EETimes article?
Can you say Van Jacobson? His header compression algorithm has been used by many thankful dialup SLIP and PPP users for years now. RFC 1332. I just hope the company that developed this "new" IP header compression technology doesn't try to patent this!
(There may be a slight breakthrough here after all. The EETimes article claims that a 40-byte TCP/IP header can be compressed down to 2 bytes, while VJ compression can only compress to 3 bytes....)
It's about uploading. Download speed doesn't really factor into it.
The traditional powers that be are trying to prevent end users from having upload bandwidth. Up to and including 28.8 modems, upload and download speeds were the same. Starting with 56K, this has changed: download speed has dramatically improved while upload speed remains slow. DSL providers artifically cap upload speeds to a low rate, compared with available bandwidth -- cable providers even more so.
Note that the services providing symmetrical upload and download speeds, ISDN and T1 among them, are priced out of the range of ordinary residential users.
Why do the companies do this? 3 reasons:
Piracy - Most don't want to admit this, but most of the massive uploading that is done by users with fast upload speeds is of pirated content. This was clearly seen during the early days of cable modems. The few users who upload are drowned out by those who pirate.
Affordability - Businesses who want to offer VPN access to their employees can more easily afford to pay for the required upload speed, unlike residential users who just want access for personal use.
Competition - If end users were able to distribute their homemade content as effectively and widely as the large media corporations, it might get popular, and there might be real competition for the established companies! So they naturally want to nip this in the bud and prevent this from occurring. As with radio and TV, ordinary people and small businesses are being priced out of transmission ability in favor of large media corporations.
There's a reason the industry calls their customers "consumers": they want them to only consume, not produce. Sad but true.
This is wonderful. The ability to operate at specific bitrates, especially low bitrates, is critical for streaming.
Having a flexible range, with definable minimum and maximum bounds, is a very good way to go. You get the bandwidth efficency during silence and other easily compressible sounds, without the unpredictable bitrate spiking of unbounded VBR.
Ogg Vorbis is a step well taken in resurrecting online music and radio streaming. After the losses in 2001 (RIAA fees, AFTRA fees, MP3 patent fees, increasing bandwidth costs, copyright concerns), we need all the help we can get....
I would love to find how to model the physics for a pinball machine.
Bumpers, posts, and the like are easy. The hard part is the flipper, of course.
It's angular movement, and overall the flipper accelerates as it moves up. This acceleration allows the flipper to maintain contact with the ball and push the ball away. The angle the ball leaves the flipper is dependent on when the flipper meets the ball, and the ball position at the time of the flip.
Does anyone have some good pinball physics that could be used? There are more elaborate situations as well, such as balls hitting flippers that are in the process of being lowered (a "drop catch").
For packages from Canada, they do not mention UPS Ground at all! The lowest class available in their list is Standard. In the page for UPS
Ground, they explicitly mention "within the 48 contiguous states".
So, UPS made a mistake here, selling you UPS Ground service when it officially isn't supported. They are partly at fault here. If the packages are valuable to you, you should have opted for a higher class of service that can be insured, as you no doubt realized as soon as you saw those boxes. Caveat emptor....
Slashdot Mirror
Since they are providing the movie as an individual download from their server, each download should be unique. I would be very surprised if they did not watermark each download in such a way that it could be traced back to whoever originally paid for the movie (credit card, or whatever). This should make it harder to pirate the movie, because of the danger of being caught if the pirate failed to strip the watermark completely (not easy, if hidden well and the original is unavailable).
Also, I would be very surprised if they did not require an Internet connection to activate the movie once it has finished downloading. The 24-hour timer could then start at that point. It would be extremely unfair to start the 24-hour timer before the movie has completely finished downloading, as many of those hours could be used up by a slow download! Each viewing of the movie probably also requires an Internet connection, as pointed out earlier, if only to connect to an external trusted clock (it would be otherwise trivial to change the computer's clock to defeat the 24-hour timer).
Think it will succeed? $3.99 is a competitive price with Blockbuster and other conventional video stores. However, the selection is very poor. HP is clearly an experiment by the studio, as they released it on DVD without Macrovision. They took a leap of faith there, and they are doing it again with this Internet download offer. They are waiting for results before offering any other major film (hence their padding of the service with only obscure B-movies).
I'd be interested in knowing the piracy rates for HP versus a similiar major film; my bet is that the lack of certain copy protection measures doesn't make a difference, as the DVD format has already been cracked six ways from Sunday. Affordable downloads are the way to go to defeat P2P, making it easier and less frustrating to get the content legitimately!
While MS definitely tried to pollute Java and split the Java community, they are not solely to blame for Java's lack of mainstream acceptance.
I believe Netscape's slow loading time and poor performance had a lot to do with it. Back in the days of Netscape 4, I watched a lot of non-techie people groan when seeing the "Starting Java..." message appear at the bottom of their browser. It meant a guaranteed wait of over 30 seconds, during which they could do nothing at all (not even click on another page). Netscape 3 was worse: there was no message, so the browser would just freeze and the user wouldn't know why!
When the Java applets eventually appeared on the page, users learned that Java equals a long wait. After suffering through this a few times, users came to dread Java pages. Note that all of this was on Netscape, before Microsoft's MSIE became prominent! The uselessness of many Java applets, many just simple animations to draw attention, also turned many people away: "I waited all that time, just for this silly animation?" Flash has replaced Java for these things, to the relief of many users.
So don't just have the kneejerk reaction of blaming Microsoft.... I firmly believe this poor implementation from Netscape is what originally caused Java's downfall.
More than a recovery disk/CD, of which several already exist, I would love a comparison disk. It would be for use after suspecting an attack.
It would boot from floppy or CD, guaranteeing that it would be in control and not trusting the hard drive for anything at all.
It would contain Tripwire-style keys for every system-installed file in the distribution. When booted, it would check each file against these keys, and output a list of files that do not match.
So, if one has been rooted with a good rootkit that modifies the operating system to cloak hacked files, one could then boot this disk/CD and be sure of being completely in control with a known good operating system. All files on the hard disk would be able to be accessed honestly, for a true comparison!
Does such a tool exist already?
It would be fairly easy to add this to the Red Hat installer. In addition to having an option to install, it would have an option to compare an existing system. It would go through the standard installation steps (choosing partitions, etc.) but compare instead of copy. A byte-for-byte comparison could then be done, for true honesty. If any mismatches are found, it would complain loudly, and give you the option at the end of simply overwriting the changed files (under your control, of course, and on an individual basis).
What do you think? Does such a tool already exist? I would love to use it if it does.
Too much excess capacity, not enough fiber was a myth, etc.
There would have been demand for the capacity... if organizations like the RIAA had not ruled it illegal! As more and more of the good new uses of computers are being made illegal, demand for bandwidth is dropping. The same is happening for CPU power (DVD ripping, music encoding, etc.). End users are afraid to upgrade their computers, for fear of triggering Windows Product Activation. The whole tech economy is in a tailspin, caused by copyright greed....
Don't forget, if you are in the SF Bay Area and like pinball (and classic video games):
California Extreme!
It's 9/7-9/8 in San Jose, and they have tons of good restored pinball and video games on free play for the entire weekend. So get in your chance to play pinball on machines that are [b]not[/b] broken :-)
Two hard drives isn't a complete solution, because what if the data you are reading and the data you are writing are *both* on the *same* drive?
I thought of this as well, back when I interviewed at ReplayTV (I didn't get in, but that's neither here nor there).
Why not make a hard drive with two arms? They would be located 180 degrees apart from each other, so they would never bump into each other.
Each arm would be able to access the entire range of the hard drive.
One would be read-write and the other would be read-only, or both of them could be read-write if there would be no significant increase in cost.
This would be great for TiVo and ReplayTV units, which need to read large continuous amounts of data while writing large continuous amounts of different data! And it would be much quieter than the current one-arm drives, that have to thrash, making the units more appealing in a residential environment (one of the main complaints about the units is that the drives are too loud).
Considering the large quantities of drives that TiVo or ReplayTV use, is a special order out of the question? I'm sure this has been thought of before, and with a large enough order, anything is possible within reason. Western Digital made a custom drive for a large order, and found it to have such a good idea that it was officially added to their product line! (It's the larger 8MB cache in a "special edition" of their 100GB drive.)
Unfortunately this kind of drive would not work well with IDE. IDE is designed to wait for one command to complete before executing another command. So this means that the gain of being able to execute read-write commands in parallel would be neutered by this protocol. A solution is to use a SCSI drive that supports Tagged Command Queuing (TCQ)! This drive, if the controller and OS software support it, can stack up multiple commands that can be resolved in any order, as fast as the drive allows. This means that multiple outstanding commands could be sent to the drive, and the drive firmware would be free to execute them in the optimal order.
This would be a great advantage, as it could allow a slower drive to be used (less power consumption, less heat, less chance of failure). The slowness of the drive would be offset by the two arm design, making the drive effectively twice as fast. It might be even faster than that, as seek time would be reduced to almost nothing when reading or writing simultaneously from two different places!
The only disadvantage would be increased cost of having to use a SCSI drive (including controller) versus an IDE drive, and a one-time cost of having to add support for TCQ to whatever OS that is being used.
I wonder if a two-arm drive is being planned for use in ReplayTV or TiVo units? It seems like too good of an idea to pass up....
I used to work there! Compression Labs (CLI) made equipment for digital video compression. They were the company behind the short-lived AT&T "videophone" that appeared in the early 1990's. Their main bread and butter was video conferencing systems for businesses and hotels. They were dedicated boxes on wheels, complete with TV and camera and computer, that looked like those old TV carts you see in schools. The idea was that you rolled them to whatever meeting room your company used, then hooked up to a T1 or ISDN line for the videoconference. They also made some other units, such as standalone systems for permanent installation, but the wheeled systems were the most popular.
Unfortunately as the generic PC became faster and better at handling video, there became less and less of a need for dedicated video compression hardware. The company started losing sales and going downhill. Compression Labs did have an industry niche, a very easy to use system that was completely turnkey, but as with so many things, low cost won out in the end.
VTEL, a competitor, bought Compression Labs. VTEL made similar videoconferencing machines, but they were integrated with a PC. They were harder to use, but had PC niceties such as the ability to share PC files and access over the videoconference. Unfortunately they weren't selling very well either.
I left the company around the time CLI was bought out by VTEL. It seems they've renamed themselves to Forgent, and set up a business model of providing services instead of selling boxes. Probably a smart move. It is a dumb move to enforce this patent, though!
While CLI had a lot of good patents, they applied mostly to video and the way it was compressed before transmission and restored after reception. They used the H.* standards for digital video transmission, but there is a lot of leeway in how you process the video signal at both ends to make the most use of the bandwidth, and this is where CLI's patents came in.
I don't believe this patent could apply to still images such as JPEG. Reading the patent, I see it mentions successive video frames quite often. Maybe there are some parts that deal with JPEG-like encoding methods, but IANAL. Honestly, I don't believe this patent can be valid, especially after the company submarined for so long and is only now claiming enforcement. They were a company I was once proud to be a part of, and it makes me sad to see them stooping to this level.
GWBASIC: http://www.geocities.com/rhinorc/gwbasic.html
QBASIC: http://www.geocities.com/Area51/5967/qbasic.html
Have you played Visual Pinball? It is a modern equivalent of Pinball Construction Set, with a 3-D table appearance, supporting ramps and multiple levels and such. It uses VBS (gasp) as the scripting language... the first non-viral use of VBS that I've ever seen!
Unfortunately there is no way to make a standalone player yet. It is a free program (closed source), but it runs only on Windows, and the author has plans to take it commercial someday so get it while you can.
http://www.randydavis.com/vp/
http://www.vpforums.com/
I loved Pinball Construction Set, and made several Apple ][ disks full of games. Bill Budge recently did a very wonderful thing: he declared all of his past Apple ][ games to be in the public domain! A great thing, and I wish more authors of classic software would do the same.
Actually it's spelled DoCoMo, not dokomo.
It's actually a phrase from English -- " Dot Com Mode ". When abbreviated in that cute Japanese syllabic way, DoCoMo!
It's a happy coincidence that it is pronounced similar to dokomo (everywhere), as you said. I hope that comes true. I can't wait for DoCoMo to be available in the USA!!
An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.
A patch to aggressively cache the disk in memory, for instance, might be good for servers but not for embedded systems. So, I could understand how a patch would be rejected in this case.
As an example, a company I once worked for made many minor changes to the Linux kernel. Since Linux is GPL, I made a webpage publishing these changes, and unlike the company, my webpage is still in existence!
Splash Open Source Page
These changes would be too narrow in focus to apply to the Linux kernel for everybody, so we never submitted them.
True, most webcasting uses UDP. (Broadcast to listeners behind firewalls is the main exception.)
For UDP, you could simply consider start and end time to be the time the first and last UDP packets were sent. Note that they require duration of transmission, not reception! An acknowledgement mechanism is not necessary. (In practice, most streaming protocols do require a periodic ACK generated by the client, to avoid uselessly sending packets once the listener closes the client.)
My take on each of these required fields, in order....
A) The name of the service, B) The channel of the program (AM/FM stations use station id), C) The type of program (Archived/Looped/Live): These are constants. Easy.
D) Date of Transmission, E) Time of Transmission: Simple timestamping, which most stations already do in their internal logs.
F) Time zone of origination of Transmission: Another constant, for small organizations with a single server. For large broadcasters that use geographically distributed server-side caching networks such as Akamai, this translates to "F) The local streaming server the listener is connected to".
G) Numeric designation of the place of the sound recording within the program: This seems to be worded to apply if the song is part of a predetermined set of songs (e.g. a prerecorded program being rebroadcast). For live stations, whose program is continuous, this will simply equal the timestamp.
H) Duration of transmission (to nearest second), I) Sound Recording Title: FreeDB, anyone? Regardless, these should already be represented in the music files that are broadcast, as song length and filename.
J) The ISRC code of the recording: Tricky. There are some CD drives out there that can read barcode and ISRC numbers, but this is rare. A paid subscription to a large commercial database might be necessary (another fee!), as has been pointed out. No doubt this is the intention of the RIAA, as they already know this information and simply want to make it a burden to collect.
K) The release year of the album per copyright notice and in the case of compilation albums, the release year of the album and copyright date of the track, L) Featured recording artist, M) Retail album title, N) The recording Label, : More information that should already be in a fully populated FreeDB entry. If it isn't, the gaps will have to be filled in, either by database subscription or manual retyping from the CD liner notes.
O) The UPC code of the retail album: Another standard tracking number. See ISRC above. How much would you like to bet that the few record companies that put barcode and ISRC numbers on their CD's will stop doing this, just to make it harder for independent online radio stations to learn these numbers?
P) The catalog number, Q) The copyright owner information, : More database information. I assume by "catalog number" that they mean the catalog of a record company (the number they assign for each release).
At least almost all of these statistics are constants for a given recording. Enter the data once, and that's it. There is no extra recurring cost to use the information after it has been obtained, which is good. Besides, most radio stations don't have a very large playlist! A few nights of data entry should be all it takes to comply with these requirements.
R) The musical genre of the channel or program (station format): The list is closed off by another easy constant.
For online stations, though, they start tightening the screws:
1) The name of the service or entity, 2) The channel or program, : Some simple constants, to lull you into thinking that compliance will be easy.
3) the date and time that the user logged in, 4) the date and time that the user logged out: With existing unicast stations, this is easy: connection start and stop times are already logged by almost all online radio stations. With multicast, it would be hard, though. The server might not even be notified if a distant client joins the stream, if a downstream router performs the multiplexing! In this case, it would be impossible to gather this information.
The RIAA might have a hidden agenda here, to kill multicasting before it can get off the ground. This ensures that only the well-funded huge corporate stations, friends of the RIAA, can broadcast online.
5) The time zone where the signal was received (user): This is the biggie. Subscriptions to a geolocation service, such as Quova, are now mandatory! Another large fee. (This time zone requirement also applies to the user timestamping requirements above.)
6) Unique User identifier: This is very vague. At the least, it could simply be a cookie that is sent to the user's browser. Privacy-disregarding corporate media players such as RA and WMP already upload user tracking information, as we have seen. Still, there is no way to track users that is 100% certain. And this is another category that will be impossible to determine if multicasting is used!
7) The country in which the user received the transmissions: Confirmation that a geolocation subscription is now required.
Well, these are lame, but they seem to have their intended effect: scaring off all competitors to RIAA-approved prolefeed. Online radio stations, rather than pay for two database services (geolocation and CD identification), would find it easier just to give up.
Well, that's it, folks. It's been nice having online radio while we could.
With these new regs, it will be the death knell of webcasting. Expect Live365 to fold within a month once these new regs take effect. Nullsoft Shoutcast and Spinner will hold on a little longer, as they are subsidized by AOL, but it too will disappear. The smaller independent stations? *poof*, as another poster put it! Considering the new fees are retroactive to 1998, if I were an online broadcaster, I'd be scrambling to dismantle my setup before they find me and send me the bill!
A shame this has to happen just when SSM, Source-Specific Multicast, was getting off the ground. Finally, an almost complete rearchitecturing of the failed Internet Multicast protocol. It addresses the two primary shortcomings of existing multicast -- address shortage and DoS attacks -- and looks like it actually could have worked.
To anyone who's watched developments in online radio technology, SSM is like nirvana. The Class D multicast address shortage is solved, by effectively using 64-bit addresses: a station's existing unicast IP address is simply concatenated with a multicast address in SSM's address range (232.x.x.x, equivalent to a big fat Class A!). And there's no central authority to go through, the station just simply chooses one of these address! This effectively gives the station the capability for 16 million channels (different SSM trees of listeners).
That's right, it's finally a tree! The many-to-many multicast model has been replaced with one-to-many. Formerly, a rogue client could simply inject data into the stream, and that data would be replicated to all other listeners. Not good. Since SSM is a tree, with the originating station at the root, this problem is solved. It will become much more difficult to "jam" a SSM station (a router close to the source would have to be hacked). With these two main problems solved, Internet multicasting would finally be good to go...!
It would have been a wonderful thing, had these new rules not been enacted. This new SSM protocol might have taken off, helping to alleviate the enourmous waste of bandwidth caused by having to repeatedly unicast the same stream to each individual listener.
Possibly the only good thing that can come out of this is more exposure for unsigned garage bands. If SSM helps to reduce the bandwidth cost of streaming, and the garage band owns their own copyrights (not a member of ASCAP/BMI/SESAC/RIAA), then it might be affordable for them to broadcast online....
In a perfect world there would be no copyright, but it isn't. So I propose a compromise.
Overturn the Sonny Bono Copyright Extension Act, thus restoring copyright lengths to their traditional duration (death plus 75 years if a person, a flat 75 years if a corporation). (This is one of the few areas of law where a person has more power than a corporation!)
However, make it possible for Congress to authorize an exemption, if a certain work proves to have significant commercial value. Perhaps a high fee (at least thousands of dollars) could be charged to grant the exemption, proving that the work still has commercial value enough to justify doing this.
This way, works that are forgotten nowadays could gracefully enter the public domain when their copyrights lapse. A good example is "Oswald The Lucky Rabbit". This cartoon character was popular around 1928, and should be due to enter the public domain soon. Another certain cartoon character of this time, who has a fondness for whistling while steering steamboats down the Mississippi, would be protected by Congress.
This is similar to what the UK did for the Peter Pan copyright. However, in this case, I propose simply extending the copyright term for another 50 years or so -- not forever as the UK did.
With this compromise, it wouldn't be necessary to perpetually extend copyright for all works... just the few rare ones that are still commercially valuable in the present day. And the public domain could continue to be enriched by the thousands of forgotten items that trickle in each year as their copyright expires. And perhaps this could help the government get some extra money without raising taxes, too!
Have you heard of Pixim?
http://www.pixim.com/pt/pt_dps.htm
They are working on a new technology to replace CCD, to answer your question.
Claimed on their website: DPS technology, in contrast, intelligently combines both image capture and image processing into a single system, which allows for both design simplicity and improved image quality. By marrying the quality of CCDs, the low-cost, mass production capabilities of CMOS and the power of image processing in a single system, Pixim's DPS platform revolutionizes image-making in both video and still cameras.
From what I gather, it's a way of measuring light directly onto a chip, without having to go through the CCD process. Sounds good to me. Hopefully it will make it so digital cameras don't drink batteries :-)
This is very common on the Game Show Network, and has been going on for months.
Note all the complaining about their "time machine" in the newsgroup.
It is especially noticeable during Press Your Luck, due to the fast repetitive action of the game board. Michael Larsen would have a hard time using his VCR to beat the game today, as the frames now don't appear as smoothly and consistently as they once did!
I lived and grew up there, and went to high school in Mendocino. (Hi Bob and Dylan!)
It's true that the village has successfully kept cellphone towers out. (It's not a town, as it's not incorporated.) The whole area is one big dead zone. Much of the entire county is strictly analog, anyway -- it seems to have been passed by when digital service was brought to other areas. Instead of talking on a cellphone, there are other fine activities to do in Mendocino County.
It's a small area dependent on tourism. One of the major draws is that it is a place to get away from all the hustle and bustle of larger cities. The Historical (some say Hysterical) Review Board strictly enforces the cellphone ban and other ordinances that seem silly, such as not allowing any remodeling that changes the look of the village! It is a unique area very popular with artists and hippies, and has a completely different culture than what most Slashdotters are used to.
But the electronics lab and computer lab in the high school kicks ass :-)
IP header compression that "can compress a typical IPv4 header from 40 bytes to as little as 2 bytes", according to the EETimes article?
Can you say Van Jacobson? His header compression algorithm has been used by many thankful dialup SLIP and PPP users for years now. RFC 1332. I just hope the company that developed this "new" IP header compression technology doesn't try to patent this!
(There may be a slight breakthrough here after all. The EETimes article claims that a 40-byte TCP/IP header can be compressed down to 2 bytes, while VJ compression can only compress to 3 bytes....)
It's about uploading. Download speed doesn't really factor into it.
The traditional powers that be are trying to prevent end users from having upload bandwidth. Up to and including 28.8 modems, upload and download speeds were the same. Starting with 56K, this has changed: download speed has dramatically improved while upload speed remains slow. DSL providers artifically cap upload speeds to a low rate, compared with available bandwidth -- cable providers even more so.
Note that the services providing symmetrical upload and download speeds, ISDN and T1 among them, are priced out of the range of ordinary residential users.
Why do the companies do this? 3 reasons:
There's a reason the industry calls their customers "consumers": they want them to only consume, not produce. Sad but true.
Wrongo!
In California, at least, it is explicitly legal to breastfeed in public.
http://www.gentlebirth.org/archives/cabreast.html
The page states that California is the "13th state to make such an affirmation".
So, breastfeeding is legal in at least 13 states in the US.
This is wonderful. The ability to operate at specific bitrates, especially low bitrates, is critical for streaming.
Having a flexible range, with definable minimum and maximum bounds, is a very good way to go. You get the bandwidth efficency during silence and other easily compressible sounds, without the unpredictable bitrate spiking of unbounded VBR.
Ogg Vorbis is a step well taken in resurrecting online music and radio streaming. After the losses in 2001 (RIAA fees, AFTRA fees, MP3 patent fees, increasing bandwidth costs, copyright concerns), we need all the help we can get....
I listen to Dr. Demento online and keep track of what stations remain: http://krellan.com/demento/
I would love to find how to model the physics for a pinball machine.
Bumpers, posts, and the like are easy. The hard part is the flipper, of course.
It's angular movement, and overall the flipper accelerates as it moves up. This acceleration allows the flipper to maintain contact with the ball and push the ball away. The angle the ball leaves the flipper is dependent on when the flipper meets the ball, and the ball position at the time of the flip.
Does anyone have some good pinball physics that could be used? There are more elaborate situations as well, such as balls hitting flippers that are in the process of being lowered (a "drop catch").
Krellan
According to the UPS webpages, they offer optional "Excess Value Insurance" on UPS Standard and UPS 3 Day Select from Canada.
For packages from Canada, they do not mention UPS Ground at all! The lowest class available in their list is Standard. In the page for UPS Ground, they explicitly mention "within the 48 contiguous states".
So, UPS made a mistake here, selling you UPS Ground service when it officially isn't supported. They are partly at fault here. If the packages are valuable to you, you should have opted for a higher class of service that can be insured, as you no doubt realized as soon as you saw those boxes. Caveat emptor....