For those who are saying that the term "Code Generator" isn't applicable - it is. Consider a C++ compiler. It may generate asm code, which then gets converted into machine code.
(generic) C++ -> (specific) asm -> executable bits
(obviuosly, the C/C++ compiler doesn't need to generate asm, but it's still code generation if it does)
Code generators just take this a level higher, so the code "life cycle" looks like this:
Code generators have a great potential for easing coding and documentation. Just like GCC has many backends to generate code for different processor architectures, the code compilers can have different backends to make source code in different languages (C, C++, Fortran, whatever). Even better, you can run a different translator and get documentation out of the "source" - in HTML, DocBook, XML, or any other format you want.
There are tools to let you make UML diagrams (Google for "Executable UML" for great goodness), and generate real-time C code for an application, a C++ app simulator that runs on a PC, and documentation for the system, all from the same diagram. The tools are expensive (like $15k-$30k), but for large projects, they can be a great savings.
I saw a program called BridgePoint (from Project Technologies), which was able to generate embedded, real-time code that was as efficient (more in some areas, less in others, but it averaged out the same) as hand-optimized code done by expert programmers. It all depends on how goo dyour translator is (and this program lets you write your own).
Some books on the subject: "Executable UML: A Foundation for Model-Driven Architecture", by Stephen J. Mellor and Marc J. Balcer "Executable UML: The Models are the Code", by Leon Starr "Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition", by Bruce Powel Douglass
... about 5% of instructions will execute about 20% faster, so you'll see about a 4% improvement...
Not a flame, but your math is off. If 5% of instructions execute 20% faster, then you save 20% of 5%, or 1% of the time. (those 5% of instructions execute in 4% of the time, instead of 5%)
They have all the features you're looking for, except the weight, and they are all available without Windows.
If you think 2.8Kg is a "brick", then I think you're up a creek. (My M-Tech is a 10.8-pound cinderblock by that standard:)
The 25RG is the smallest. It's also damned expensive, since it's their "semi-ruggedized" model (spill-resistant, gel-coated screen, etc).
I have bought two computers from them, and have been very happy with them. Both run Linux just fine, though I haven't tried the newer hardware out under Linux lately.
FTP has a great advantage in that you can request multiple files at the same time: mget instead of get. Additionally, you can use wildcards in the names, so you can select categories / directories of files with very short commands. (mget *.mp3 *.m3u...)
Modern browsers allow you to transfer multiple files simultaneously, but they don't queue files for you - FTP will. This may be important if connections might get dropped - the FTP transfer will complete the first file, then move on to the next. In the event of an interruption, you will have some complete files, and one partial (which you can likely resume). For multiple simultaneous transfers - from an http browser - you may have some smaller files finished, but it's likely that all larger files will be partials, and will need to be retransmitted in their entirety, since http doesn't quite support resuming a previous download.
So, if you're going to have a web page with many individual links, and you think that most people will download one or two files, http will probably suffice. If you expect people to want multiple files, or that they will want to be able to select groups of files with wildcards (tortuous with pointy-clicky things), then you should have FTP.
It's not that hard to set up both, and that's probably the best solution.
I'm not sure that this problem is with the black box mentality - it seems to be with those coders.
Logging scheme: Should be part of the interface definition (the format of log messages should be part of the spec). The logging functionality should be another black box module (with a suitable interface for all portions of the project).
Configuration scheme: Should also be part of the spec. If it's done wrong, then the module doesn't meet spec, and the programmer(s) should be reminded that their paychecks are dependent on writing modules to spec.
Admin Alerting: Like logging, if there is a specific format / function to use, then this should be part of the spec.
Design pattern: The spec should incorporate any company coding standards (by reference, if it's too long:). It is then up to the programmers to follow this standard. (I see that as a different issue than the black box thing, though)
Global data: This should never be touched, unless the access is defined in the spec.
It looks to me like: 1) the specs are not complete; and 2) that the programmers in question don't adequately communicate when they encounter problems coding to the spec. (It's perfectly valid to discuss changes to a black box specification if problems are encountered).
Actually, there are several applications, albeit specialized ones:
1) Databases - a lot of databases are too big for a pointer offset to fit into 32 bits. Ever notice that the 120Gig hard drive you just bought has more than 2^32 bytes on it? (yes - I know that the hard drive is split into 512-byte sectors, and that you won't overflow 32 bits until you get drives larger than 2 TB, but how long will that take:)
2) Video (editing, encoding, etc) - a single layer of a single side of a DVD is more than can be addressed by a 32-bit pointer. The amount of source data used to create the highly compressed DVD data is mind-boggling. (A high quality transfer from film is about 100M per frame. A 2-hour film has 172800 frames [assuming it's not IMax - that's higer resolution and more frames per second] - that's 17 terabytes of raw data!)
3) High dynamic range images (including photographs and extrme high color video games) - the data types being used by the GeForce FX (similar to the EXR format released by ILM) have 16 bits of data per channel - this totals 64 bits for each RGBA pixel.
I'm sure there are more - these few just jumped into mind quickly.
Of course, for those who use Windows, you'll need 64-bit CPU's to be able to load those Word XP-2004.Net documents:)
Don't forget "Path of the Fury" and "The Apocalypse Troll".
Path of the Fury is an interesting read, because it actually combines sci-fi with greek mythology (yes, it's those furies:).
The Apocalypse Troll is set in the same universe as the Honor Harrington series (though it takes place at a time long before the star kingdom of Maticore exists). I only assumed the same universe because the physics / ships are the same, there's no connection between this story and Honor Harrington.
Re:but no reall thrill
on
Robocoaster
·
· Score: 5, Interesting
The current form of this ride may not be much, but combine it with audio/video (VR-style), and it can be VERY convincing.
My wife and I went to Universal Studios Florida, and rode a couple of rides that have little motion (relative to a rollercoaster)
The first was the "Back to the Future" ride. The ride consists of a fake DeLorean on an articulated mount. The car never moved more than 3 feet, but the IMAX-like screen in front of us and the slight motion cues from the small movements of the car were very convincing.
The other ride was "Spider-Man". The basic construction was just a (mostly) flat track with cars on it. The cars would shake and rattle a bit, they could swing around very quickly, and there were other effects (like a flamethrower and water spray) to go along with the action. The main attraction was a series of 3D projected movies. This ride was AWESOME. My wife never managed to keep her eyes open during one particular sequence - she got too queasy (even though we rode the thing 3 times and she knew what was coming:).
Properly done (with surround video and audio), this can be an amazing ride.
Applying a little physics (but not too much, since I don't have the references or the desire/ability to go through the really rough calculations:):
The "average" air molecule travels at about 300 meters/sec at room temperature. This speed is a multiple of the temperature T, divided by the mass m of the molecule - E=3/2kT=1/2 mv^2 (so CO is a little faster than average, since Carbon is lighter than Oxygen or Nitrogen)
So, if they can build room temperature versions of this (the sample was at 4-10 K), and the size remains about the same (17nm across), and the molecules travel say half their speed in atmosphere, and the computational nodes get "recharged" as fast as they calculate, then the thing would be able to go at about 4.4 GHz.
Not too bad, actually.
Probably within an order of magnitude, at least (ie, wrong:)
Actually, USB on-the-go isn't really a part of USB 2. It's a second layer protocol that allows devices to act as either a master or a slave, depending on the task at hand. Although the on-the-go spec is an addendum to USB 2, there is nothing in it that requires 2.0 functionality to work.
An example: a digital camera that can act as a master when connected to a printer (pretending to be a computer), and as a slave when connected to a computer (pretending to be a storage device).
There is still a master and a slave, and the cable determines which unit starts out as the master. This is done with a new type of USB connector - the mini-AB. (the old ones were type A, the flat ones, and type B, the square-ish ones).
The Mini-AB jack can accept either a mini-A or a mini-B plug. The device that the mini-A is plugged into acts as master, and the device that gets the mini-B is the slave. (The protocol allows the master to pass control to another device) There are other cables for connecting these devices to "legacy" USB ports - mini-AB to A or B cables. These cables are wired so that the OTG device knows whether it should be master or slave.
As for the devices only working with one manufacturer's peripherals (someone mentioned an HP camera only printing to an HP printer), that may happen. Although the "class" drivers are more likely to be implemented in embedded devices, there are probably features that won't work when mixing and matching devices from different manufacturers.
When I got married (5 years ago), we hired a professional photographer we knew to shoot the wedding. His standard contract was for a proof sheet, several wedding albums, and extra prints (different quantities of albums and extras dependent on what level you paid for). Also, after 2 years, we got the negatives.
This allowed us to get albums for ourselves and our parents, and some extra prints for the family. He was able to sell more prints and albums to people who wanted them in the short term. We ended up with the negatives, so we can now scan / reprint them ad infinitum.
It's easy to find 400-speed film with 100-200 grains/mm or better resolution. The resolution varies with film speed (higher speed = larger grains = lower resolution/more graininess).
So, to put that into megapixel terms:
a 35mm frame is 36x24mm (strange, but true)
That's roughly 7200x4800 pixels, or 34.56 MPixels - far and away better than any 35-mm size digital on the market.
This site has interesting information about digital photography vs. film.
The real news here is that the sensor is full-frame 35mm. That means that they can make a digital back for a standard 35mm camera (or a digital camera in a 35mm body, like most small pro cameras), and you will get full frame shots (ie, what you see in the viewfinder is the same as what will be on disk).
The other good news is that they didn't reduce the pixel size to increase the resolution. This gives better image fidelity (contrast and color saturation). That's the funny part about digital camera resolution - they keep increasing the number of pixels in roughly the same sensor area - they get fewer photons per pixel, but more pixels per frame.
This should be cool (I'll check it out at Photokina)
First there was software to do sector copying. Then the publishers got smart and started using errors on the disk as a protection scheme (they would actually burn holes in the media with a laser). Software copiers couldn't duplicate the bad diskettes because they couldn't write physically damaged information. Thus, the Copy II PC hardware - a special controller that sat between the regular disk controller and the drive and could write sectors which looked like (physically) bad sectors - was born.
Now, fast forward to the CD-ROM. When writing a CD with a standard CD-R/RW drive, I don't think you can put intentional errors in the data - the ECC information will be correct for whatever data is written to a sector (even if the data itself is useless). You can still read the data, and you will get valid error information with it. So, all they have to do is write the keys to sectors with specially screwed up ECC data, or just write the codes into the ECC data itself. This data can be read, but not written by consumer grade devices.
Congrats on possibly being able to say your peace to someone who might actually give a damn.
Things to note when (if) speaking to the Judge:
1) As your message title said, "Possible infringing uses don't outlaw a device". Look at guns. The right to bear arms is in the constitution, but there's nothing to say what kind of arms are allowed, so something like a sword or dagger would qualify just as much as an M16. (ie, guns could be outlawed without a constitutional crisis) Obviously, the most efficient method of killing someone with a bullet is by accelerating it with a gun. Yet the gun is not illegal to own (nor the bullet), it is only illegal to use it for - you guessed it - illegal purposes. (Incidentally, a handgun has few legal uses - fewer than a PVR. They may used for target shooting, and for self defense. It's sometimes allowed, but very rare, to hunt with a pistol.)
Of course, it may be wise not to link PVR's with guns - you never know how an MPAA lawyer might twist that one:)
2) The television industry sends out copyrighted information without first licensing it (to the viewer). If I rent/buy a tape or DVD, there is an FBI notice on it, telling me what uses aren't allowed. To say that I have fewer rights to something for which there has been no notice given, nor any license agreed to is insane. Remember - I can pause, rewind, stop, piss, whatever with the tape or DVD.
3) The argument that there is "an implied agreement to watch the commercials" is complete crap. The TV station has agreements with their advertisers, to put the commercials on the air at certain times, or during certain types of shows. There is no agreement with the viewer to watch. None. The TV station pays the network for programming, and the advertisers pay the TV station for product exposure. End of story. I (as a viewer) have always had the right to: a) channel surf; b) take a piss; c) make popcorn; d) turn off the TV; or e) watch the commercial. It is my choice as the viewer. I choose what shows to watch, and what commercials to watch. The TV station chooses what shows to broadcast, and what/when commercials will be broadcast. If they have the right to require us to sit through the commmercials, the obvious next step is to make certain shows mandatory as well. That would be terrible - imagine having to watch reruns of "Rosanne".
4) The industry lawyers claim (from the EFF page about this suit) "... commercial skipping infringes copyright and digital recording aids piracy." Of course, the telephone also aids piracy. So does the post office. And the interstate highway system, and the oil industry, and the auto industry... Basically, any tool that a pirate uses helps piracy.
The really funny part of this is that the TV stations/networks have been broadcasting modified versions of TV shows for years. They cut out segments of the shows so that more commercials can be fit in. One hour TV shows used to be 52 minutes or so, now the same show would be about 42 minutes. It's interesting that the TV stations claim that we are illegally not watching parts of the programming when they are actually preventing us from seeing the whole show in many instances.
The TV market is very different now than it was then.
Today's TV stations are run like most other American corporations - strictly for maximizing profit. This is a change from the "good old days" when companies provided better service to get more customers. The broadcasters are not willing to spend the money on new transmitting equipment until there are more DTV's out there. The manufacturers are not willing to make less expensive DTV's until people buy a lot more. People don't want to buy DTV's until there's more content that uses them (and they're cheaper). Content makers don't want to spend the money on HD production until there is an audience for them....
Remember, TV wasn't really available until the '40s, and wasn't too commonplace until the '50s. The color TV improvement came out when the overall TV market was still young. By contrast, the entrenchment of TV in this country is astounding - there are more than 2 TV's in the average household. (I don't remember where that statistic came from, so it could be off a little) There are hundreds of millions of analog TV's in this country, and probably only 1 or 2 million DTV's. The TV stations aren't going to spend any money on making their viewers' lives better, but they will do anything that gets them more advertising revenue. Remember - they are doing what's necessary to get more customers, but the advertisers are the customers, not the viewers.
Actually, that was the TurboFilter, also made by HoseMaster (Aaron Jones, Inc. - if you want to be pedantic:).
I know that product intimately, since my (former) company designed their revised unit with built-in radio triggers (the PocketWizard, which we also designed), the smaller wheel, and two speeds (I don't remember if their original unit had the two speed modes or not). The TurboFilter had 3 filters - clear, light diffusion, and heavy diffusion. The camera would be set for 1/30 or 1/15 second exposure, and the 3 strobes would fire in sequence, and that was it.
The HoseMaster was a fiber optic light painting device. It was generally used on very long bulb exposures. The photographer could direct a narrow (or shaped, in later versions), controlled intensity light source at a subject, and very carefully "paint" exposure differently for each part of the frame.
The company, Aaron Jones Inc. was known as HoseMaster because of their popular product of the same name. My old company had the same thing happen - the company is LPA Design, a name nobody knows, so people call the company PocketWizard, the name of their most popular product. Go figure.
Aaah - the Vivitar 283. You have no idea how many times I've been shocked by the trigger circuit on those (at about 283 volts, by the way:).... We did a mega-version of that kind of multi-pop photography at the Photo East show in 1999 (or 2000). We shot the Intrpid aircraft carrier from the top of the UPS building across the street from the pier. It was illuminated by thousands of people - about 3000 on board and another 2-3K on the next pier (plus 18 moderate power Metz packs doing multiple full dumps). Each person just walked all over the ship popping their little flashes as fast as they would go. The total exposure time was about 2 minutes, and the shot came out great. You should have seen the faces of the New Yorkers driving by while all the flashing was going on - hilarious.
Have fun (and be careful of the sync jack on that V283:)
Slashdot Mirror
For those who are saying that the term "Code Generator" isn't applicable - it is. Consider a C++ compiler. It may generate asm code, which then gets converted into machine code.
(generic) C++ -> (specific) asm -> executable bits
(obviuosly, the C/C++ compiler doesn't need to generate asm, but it's still code generation if it does)
Code generators just take this a level higher, so the code "life cycle" looks like this:
(generic) Diagram / CG description -> (specific implementation) C++ -> (specific machine) asm -> machine code.
Code generators have a great potential for easing coding and documentation. Just like GCC has many backends to generate code for different processor architectures, the code compilers can have different backends to make source code in different languages (C, C++, Fortran, whatever). Even better, you can run a different translator and get documentation out of the "source" - in HTML, DocBook, XML, or any other format you want.
There are tools to let you make UML diagrams (Google for "Executable UML" for great goodness), and generate real-time C code for an application, a C++ app simulator that runs on a PC, and documentation for the system, all from the same diagram. The tools are expensive (like $15k-$30k), but for large projects, they can be a great savings.
I saw a program called BridgePoint (from Project Technologies), which was able to generate embedded, real-time code that was as efficient (more in some areas, less in others, but it averaged out the same) as hand-optimized code done by expert programmers. It all depends on how goo dyour translator is (and this program lets you write your own).
Some books on the subject:
"Executable UML: A Foundation for Model-Driven Architecture", by Stephen J. Mellor and Marc J. Balcer
"Executable UML: The Models are the Code", by Leon Starr
"Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition", by Bruce Powel Douglass
It's at http://www.zynot.org/.
And there's even an event in my hometown (Burlington, VT).
Not a flame, but your math is off. If 5% of instructions execute 20% faster, then you save 20% of 5%, or 1% of the time. (those 5% of instructions execute in 4% of the time, instead of 5%)
They have all the features you're looking for, except the weight, and they are all available without Windows.
If you think 2.8Kg is a "brick", then I think you're up a creek. (My M-Tech is a 10.8-pound cinderblock by that standard :)
The 25RG is the smallest. It's also damned expensive, since it's their "semi-ruggedized" model (spill-resistant, gel-coated screen, etc).
I have bought two computers from them, and have been very happy with them. Both run Linux just fine, though I haven't tried the newer hardware out under Linux lately.
Geek's Guide to Dating:
Step 1: Find member of opposite sex.
Step 2: ???
Step 3: Date!
As many people have said, it depends.
...)
FTP has a great advantage in that you can request multiple files at the same time: mget instead of get. Additionally, you can use wildcards in the names, so you can select categories / directories of files with very short commands. (mget *.mp3 *.m3u
Modern browsers allow you to transfer multiple files simultaneously, but they don't queue files for you - FTP will. This may be important if connections might get dropped - the FTP transfer will complete the first file, then move on to the next. In the event of an interruption, you will have some complete files, and one partial (which you can likely resume). For multiple simultaneous transfers - from an http browser - you may have some smaller files finished, but it's likely that all larger files will be partials, and will need to be retransmitted in their entirety, since http doesn't quite support resuming a previous download.
So, if you're going to have a web page with many individual links, and you think that most people will download one or two files, http will probably suffice. If you expect people to want multiple files, or that they will want to be able to select groups of files with wildcards (tortuous with pointy-clicky things), then you should have FTP.
It's not that hard to set up both, and that's probably the best solution.
I'm not sure that this problem is with the black box mentality - it seems to be with those coders.
:). It is then up to the programmers to follow this standard. (I see that as a different issue than the black box thing, though)
Logging scheme: Should be part of the interface definition (the format of log messages should be part of the spec). The logging functionality should be another black box module (with a suitable interface for all portions of the project).
Configuration scheme: Should also be part of the spec. If it's done wrong, then the module doesn't meet spec, and the programmer(s) should be reminded that their paychecks are dependent on writing modules to spec.
Admin Alerting: Like logging, if there is a specific format / function to use, then this should be part of the spec.
Design pattern: The spec should incorporate any company coding standards (by reference, if it's too long
Global data: This should never be touched, unless the access is defined in the spec.
It looks to me like:
1) the specs are not complete; and 2) that the programmers in question don't adequately communicate when they encounter problems coding to the spec. (It's perfectly valid to discuss changes to a black box specification if problems are encountered).
Actually, there are several applications, albeit specialized ones:
:)
:)
1) Databases - a lot of databases are too big for a pointer offset to fit into 32 bits. Ever notice that the 120Gig hard drive you just bought has more than 2^32 bytes on it? (yes - I know that the hard drive is split into 512-byte sectors, and that you won't overflow 32 bits until you get drives larger than 2 TB, but how long will that take
2) Video (editing, encoding, etc) - a single layer of a single side of a DVD is more than can be addressed by a 32-bit pointer. The amount of source data used to create the highly compressed DVD data is mind-boggling. (A high quality transfer from film is about 100M per frame. A 2-hour film has 172800 frames [assuming it's not IMax - that's higer resolution and more frames per second] - that's 17 terabytes of raw data!)
3) High dynamic range images (including photographs and extrme high color video games) - the data types being used by the GeForce FX (similar to the EXR format released by ILM) have 16 bits of data per channel - this totals 64 bits for each RGBA pixel.
I'm sure there are more - these few just jumped into mind quickly.
Of course, for those who use Windows, you'll need 64-bit CPU's to be able to load those Word XP-2004.Net documents
I think he meant that performance would increase because the bandwidth requirements would go down - not that the bandwidth capacity would go down.
Path of the Fury is an interesting read, because it actually combines sci-fi with greek mythology (yes, it's those furies :).
The Apocalypse Troll is set in the same universe as the Honor Harrington series (though it takes place at a time long before the star kingdom of Maticore exists). I only assumed the same universe because the physics / ships are the same, there's no connection between this story and Honor Harrington.
The current form of this ride may not be much, but combine it with audio/video (VR-style), and it can be VERY convincing.
:).
My wife and I went to Universal Studios Florida, and rode a couple of rides that have little motion (relative to a rollercoaster)
The first was the "Back to the Future" ride. The ride consists of a fake DeLorean on an articulated mount. The car never moved more than 3 feet, but the IMAX-like screen in front of us and the slight motion cues from the small movements of the car were very convincing.
The other ride was "Spider-Man". The basic construction was just a (mostly) flat track with cars on it. The cars would shake and rattle a bit, they could swing around very quickly, and there were other effects (like a flamethrower and water spray) to go along with the action. The main attraction was a series of 3D projected movies. This ride was AWESOME. My wife never managed to keep her eyes open during one particular sequence - she got too queasy (even though we rode the thing 3 times and she knew what was coming
Properly done (with surround video and audio), this can be an amazing ride.
With a few extra bits, you can make it easy to extract any digit of the number.
... ...
:)
Split the 1.24TB number into triplets, and store each triplet in 10 bits:
(leaving off the initial 3):
141 592 653
encode into 30 bits:
0010001101 1001010000 1010001101
Pack these together (and on and on), and you use only ~517 GB, but you can index to any digit by a simple division, shift, and decimal conversion.
(assuming you decided to put together a RAID array for the storage in the first place
Well...
:) :
:)
Applying a little physics (but not too much, since I don't have the references or the desire/ability to go through the really rough calculations
The "average" air molecule travels at about 300 meters/sec at room temperature. This speed is a multiple of the temperature T, divided by the mass m of the molecule - E=3/2kT=1/2 mv^2 (so CO is a little faster than average, since Carbon is lighter than Oxygen or Nitrogen)
So, if they can build room temperature versions of this (the sample was at 4-10 K), and the size remains about the same (17nm across), and the molecules travel say half their speed in atmosphere, and the computational nodes get "recharged" as fast as they calculate, then the thing would be able to go at about 4.4 GHz.
Not too bad, actually.
Probably within an order of magnitude, at least (ie, wrong
Actually, USB on-the-go isn't really a part of USB 2. It's a second layer protocol that allows devices to act as either a master or a slave, depending on the task at hand. Although the on-the-go spec is an addendum to USB 2, there is nothing in it that requires 2.0 functionality to work.
An example: a digital camera that can act as a master when connected to a printer (pretending to be a computer), and as a slave when connected to a computer (pretending to be a storage device).
There is still a master and a slave, and the cable determines which unit starts out as the master. This is done with a new type of USB connector - the mini-AB. (the old ones were type A, the flat ones, and type B, the square-ish ones).
The Mini-AB jack can accept either a mini-A or a mini-B plug. The device that the mini-A is plugged into acts as master, and the device that gets the mini-B is the slave. (The protocol allows the master to pass control to another device) There are other cables for connecting these devices to "legacy" USB ports - mini-AB to A or B cables. These cables are wired so that the OTG device knows whether it should be master or slave.
As for the devices only working with one manufacturer's peripherals (someone mentioned an HP camera only printing to an HP printer), that may happen. Although the "class" drivers are more likely to be implemented in embedded devices, there are probably features that won't work when mixing and matching devices from different manufacturers.
Yoda for language good is this.
When I got married (5 years ago), we hired a professional photographer we knew to shoot the wedding. His standard contract was for a proof sheet, several wedding albums, and extra prints (different quantities of albums and extras dependent on what level you paid for). Also, after 2 years, we got the negatives.
This allowed us to get albums for ourselves and our parents, and some extra prints for the family. He was able to sell more prints and albums to people who wanted them in the short term. We ended up with the negatives, so we can now scan / reprint them ad infinitum.
Sounds like the best of both worlds to me.
So, to put that into megapixel terms: a 35mm frame is 36x24mm (strange, but true) That's roughly 7200x4800 pixels, or 34.56 MPixels - far and away better than any 35-mm size digital on the market.
This site has interesting information about digital photography vs. film.
The real news here is that the sensor is full-frame 35mm. That means that they can make a digital back for a standard 35mm camera (or a digital camera in a 35mm body, like most small pro cameras), and you will get full frame shots (ie, what you see in the viewfinder is the same as what will be on disk).
The other good news is that they didn't reduce the pixel size to increase the resolution. This gives better image fidelity (contrast and color saturation). That's the funny part about digital camera resolution - they keep increasing the number of pixels in roughly the same sensor area - they get fewer photons per pixel, but more pixels per frame.
This should be cool (I'll check it out at Photokina)
Matrox Parhelia, Baby.
Supports 3 outputs (though I think only 2 can be used at a time in DVI mode).
Cooooool.
Not Necessarily.
Remember the Copy II PC diskett copying system?
First there was software to do sector copying. Then the publishers got smart and started using errors on the disk as a protection scheme (they would actually burn holes in the media with a laser). Software copiers couldn't duplicate the bad diskettes because they couldn't write physically damaged information. Thus, the Copy II PC hardware - a special controller that sat between the regular disk controller and the drive and could write sectors which looked like (physically) bad sectors - was born.
Now, fast forward to the CD-ROM. When writing a CD with a standard CD-R/RW drive, I don't think you can put intentional errors in the data - the ECC information will be correct for whatever data is written to a sector (even if the data itself is useless). You can still read the data, and you will get valid error information with it. So, all they have to do is write the keys to sectors with specially screwed up ECC data, or just write the codes into the ECC data itself. This data can be read, but not written by consumer grade devices.
Good thing they just laid off 1000 people at their Essex Junction, VT fab.
Congrats on possibly being able to say your peace to someone who might actually give a damn.
:)
... Basically, any tool that a pirate uses helps piracy.
Things to note when (if) speaking to the Judge:
1) As your message title said, "Possible infringing uses don't outlaw a device". Look at guns. The right to bear arms is in the constitution, but there's nothing to say what kind of arms are allowed, so something like a sword or dagger would qualify just as much as an M16. (ie, guns could be outlawed without a constitutional crisis) Obviously, the most efficient method of killing someone with a bullet is by accelerating it with a gun. Yet the gun is not illegal to own (nor the bullet), it is only illegal to use it for - you guessed it - illegal purposes. (Incidentally, a handgun has few legal uses - fewer than a PVR. They may used for target shooting, and for self defense. It's sometimes allowed, but very rare, to hunt with a pistol.)
Of course, it may be wise not to link PVR's with guns - you never know how an MPAA lawyer might twist that one
2) The television industry sends out copyrighted information without first licensing it (to the viewer). If I rent/buy a tape or DVD, there is an FBI notice on it, telling me what uses aren't allowed. To say that I have fewer rights to something for which there has been no notice given, nor any license agreed to is insane. Remember - I can pause, rewind, stop, piss, whatever with the tape or DVD.
3) The argument that there is "an implied agreement to watch the commercials" is complete crap. The TV station has agreements with their advertisers, to put the commercials on the air at certain times, or during certain types of shows. There is no agreement with the viewer to watch. None. The TV station pays the network for programming, and the advertisers pay the TV station for product exposure. End of story. I (as a viewer) have always had the right to: a) channel surf; b) take a piss; c) make popcorn; d) turn off the TV; or e) watch the commercial. It is my choice as the viewer. I choose what shows to watch, and what commercials to watch. The TV station chooses what shows to broadcast, and what/when commercials will be broadcast. If they have the right to require us to sit through the commmercials, the obvious next step is to make certain shows mandatory as well. That would be terrible - imagine having to watch reruns of "Rosanne".
4) The industry lawyers claim (from the EFF page about this suit) "... commercial skipping infringes copyright and digital recording aids piracy." Of course, the telephone also aids piracy. So does the post office. And the interstate highway system, and the oil industry, and the auto industry
The really funny part of this is that the TV stations/networks have been broadcasting modified versions of TV shows for years. They cut out segments of the shows so that more commercials can be fit in. One hour TV shows used to be 52 minutes or so, now the same show would be about 42 minutes. It's interesting that the TV stations claim that we are illegally not watching parts of the programming when they are actually preventing us from seeing the whole show in many instances.
Here's to making a difference.
The TV market is very different now than it was then.
...
Today's TV stations are run like most other American corporations - strictly for maximizing profit. This is a change from the "good old days" when companies provided better service to get more customers. The broadcasters are not willing to spend the money on new transmitting equipment until there are more DTV's out there. The manufacturers are not willing to make less expensive DTV's until people buy a lot more. People don't want to buy DTV's until there's more content that uses them (and they're cheaper). Content makers don't want to spend the money on HD production until there is an audience for them.
Remember, TV wasn't really available until the '40s, and wasn't too commonplace until the '50s. The color TV improvement came out when the overall TV market was still young. By contrast, the entrenchment of TV in this country is astounding - there are more than 2 TV's in the average household. (I don't remember where that statistic came from, so it could be off a little) There are hundreds of millions of analog TV's in this country, and probably only 1 or 2 million DTV's. The TV stations aren't going to spend any money on making their viewers' lives better, but they will do anything that gets them more advertising revenue. Remember - they are doing what's necessary to get more customers, but the advertisers are the customers, not the viewers.
Actually, that was the TurboFilter, also made by HoseMaster (Aaron Jones, Inc. - if you want to be pedantic :).
:)....
:)
I know that product intimately, since my (former) company designed their revised unit with built-in radio triggers (the PocketWizard, which we also designed), the smaller wheel, and two speeds (I don't remember if their original unit had the two speed modes or not). The TurboFilter had 3 filters - clear, light diffusion, and heavy diffusion. The camera would be set for 1/30 or 1/15 second exposure, and the 3 strobes would fire in sequence, and that was it.
The HoseMaster was a fiber optic light painting device. It was generally used on very long bulb exposures. The photographer could direct a narrow (or shaped, in later versions), controlled intensity light source at a subject, and very carefully "paint" exposure differently for each part of the frame.
The company, Aaron Jones Inc. was known as HoseMaster because of their popular product of the same name. My old company had the same thing happen - the company is LPA Design, a name nobody knows, so people call the company PocketWizard, the name of their most popular product. Go figure.
Aaah - the Vivitar 283. You have no idea how many times I've been shocked by the trigger circuit on those (at about 283 volts, by the way
We did a mega-version of that kind of multi-pop photography at the Photo East show in 1999 (or 2000). We shot the Intrpid aircraft carrier from the top of the UPS building across the street from the pier. It was illuminated by thousands of people - about 3000 on board and another 2-3K on the next pier (plus 18 moderate power Metz packs doing multiple full dumps). Each person just walked all over the ship popping their little flashes as fast as they would go. The total exposure time was about 2 minutes, and the shot came out great. You should have seen the faces of the New Yorkers driving by while all the flashing was going on - hilarious.
Have fun (and be careful of the sync jack on that V283