A "firmware redesign"? What the hell is that? Firmware is software, no matter how you'd like to define it. If it's well-designed software (i.e., modular), and the BF functionality is implemented in software (which, IIRC, it's not), it's a simple matter of pulling out or disabling the BF bits (or modifying the surrounding code to ignore the BF code path).
Video processing chips have embedded microprocessors, either general (ARM or MIPS) or DSP (several types). For nontrivial functions there are often both. The code for these is, however, not stored in off-chip memory -- it's internal, in mask ROMS. A change to those ROMS requires new masks for the device, although the mask changes can usually be confined to the upper layers and therefore cost less to implement.
That's assuming the BF circuitry is on its own chip. Depending on the device manufacturer's resources, that could go either way, as it's much cheaper (NRE-wise, anyway) to design a secondary device to handle the BF instead of redesigning the entire capture/processing device to accomodate the BF.
That's assuming that there are any external "hooks" that would allow an external device to process the BF. Considering the economics of keeping the whole video processing pipe in one chip, that's unlikely. It's certainly not the kind of thing that would have been done without the expectation of a need for a disableable BF function, and if that's all it would also be easier to include other means to disable it.
The big ugly is that most of these chips aren't designed for use on tuner cards -- there aren't that many of them sold in a year. The big bucks are in the DVD boxes etc. The tuner cards have a bigger problem: how to allow viewing but not recording, when the card can't even tell which is going on.
Factor in that it costs money to add a chip and now you see why everyone was waiting this one out.
This isn't a case of "add a chip." Products of this type are pretty much single-chip systems any more; the function is a matter of changing the design of that chip, not adding one.
The process for designing the chip, fabricating the prototypes, setting up manufacturing, etc. takes between a year and two years. By now, it's far too late to make the decision. The entire supply chain was switched over months ago at the latest.
I'm guessing you don't really know how this kind of product development process works.
The cow-orkers are wondering why I'm laughing so hard.
As soon as a new design or board rev is on the drawing boards, they'll be quick to notice they can shave 50c or a dollar off the cost by leaving out the silicon that handles the broadcast flag, and poof - it's gone.
The cost of implementing it is in creating the decoder for the stupid bit -- which, at current IC design rates, runs somewhere close to $2 million. Once it's in the decoder, the firmware (note, not software) to use it is somewhat less expensive to change but far from free.
The original design costs are spent. Making a design change to the firmware will only cost a few hundred thousand for the design, plus all of the issues for supply management, inventory, support, etc. Figure a half-million more or less to take out the BF function.
Now, how many extra units does the manufacturer have to sell to break even, assuming that the MPAA doesn't file suit?
For extra credit, how many extra units does the manufacturer have to sell if the MPAA does file suit? What are the odds that the MPAA will file suit? How many extra units does the manufacturer have to sell to cover the risk?
Actually it's not a DMCA violation, it's a contractual violation.
No, none of the parties in question were DVD-CCA licensees. The lawsuit was over the fact that the chipmaker sold chips to DVD player manufacturers who weren't DVD-CCA licensees.
The DVD manufacturers are not allowed to make "DVD player"s unless they agree to enforce CSS. It's not a DMCA violation.
Yeah, and who is "not allowing" the manufacture of those DVD players? US Courts. The statutory authority cited is the DMCA.
When their competitor takes the 5 minutes to disable the flag and starts selling more product, they'll all disable it.
Not if their competitor is watching all of their product rot in a warehouse under preliminary injunction and spending more on legal defense every month than they make in profits for a year.
This is a case of the consumer electronics companies all hanging together or the MPAA will hang them all separately. There's a huge risk to being the first to break ranks, and it's very hard to see the marginal sales coming close to making up the staggering legal costs -- which are going to be gone even if the MPAA loses.
Nobody wants to be the first to buck the MPAA. Being the second one, in case the first actually wins, is a much better strategy --- let your competitor bear the legal expenses while you take advantage of the results.
how is ignoring the flag a violation of the DMCA? Seems like a stretch to me.
In the same way that selling a DVD-player chip to any manufacturer that doesn't toe the DVD-CCA line is a DMCA violation -- and that's been upheld in court.
The MPAA can make the argument that since there are lots and lots of BF-compliant devices out there, so making something that ignores the BF has as its main "commercial use" the bypassing of the BF (you can look up the DMCA wording if you like.) That's enough to get them into court.
It doesn't matter if it's BS because the MPAA can afford to spend enough money on the lawsuit to suck all the profits out of anyone bucking them. They needed the FCC to do the initial dirty work but now they can handle any rebels on their own.
I'd hope that the consumer electronics lobby is stronger than the MPAA, but I fear it isn't so.
They don't care. Now that they've spent the money to implement it, it's all the same to them. Regardless of what we'd like to think, their sales are going to be the same either way.
Keep in mind that all devices now in manufacturing are BF-compliant. The MPAA has what it wants, and pressuring Congress for more may not be a good ROI proposition.
When there weren't anything but non-BF devices on the market, the MPAA couldn't use the DMCA against the manufacturers. Now that everything is BF-compliant any device that isn't can easily be painted as a circumvention device under the DMCA and the manufacturer sued out of existence.
By now, all of the designs have been changed and all of the product in the pipeline has been switched over. Even if the manufacturers are legally allowed to do so, they won't take the expense of switching back.
What's more, they won't take the risk. Now that the BC has become a "standard" feature, building anything without it is almost certain to be attacked by the MPAA under the DMCA.
If you have a BC-free tuner card, treasure it. They ain't making no more, ever again.
the board members and the Canopy Group that owns SCO
The Canopy Group does not own SCOX. In the ugly little affair to oust Ralph Yarro, Canopy gave him all of its interest in SCOX. Since he's the chairman anyway, that might let Canopy off the hook ("beneficial control" becomes the standard.)
I don't know how much Ralph has besides his (worthless) share in SCOX but I suspect that IBM would be content to suck him dry along with Darl.
Are we talking about "Code signing" in the sense of "here is a binary that some third party can trust you to use" sense? The Fritz Hollings/MPAA/Microsoft sense where any other compile of the same source code is useless?
If so, your problems go a lot deeper than key management.
For those of you who weren't potty-trained at the time, I'll point out that IBM published the source code for their BIOS in the famous "Purple Book:" the IBM PC Technical Reference Manual.
So, among other things, it was harder for Phoenix to explain away any similarities in source code than if the only available BIOS code was binary.
how IBM should have entered into "good-faith negotiations" with SCOX.
Me, I've read the correspondence filed with the Court on the subject. IBM asked what they were supposed to have done wrong so that they could remedy the problem, SCOX told them they'd see them in court.
Yeah, that's bad faith on IBM's part all right. Here we are more than two years later and IBM is still trying to get the Court to make SCOX tell them what IBM is supposed to have done wrong, so far with no luck.
I think the confusion on this(and why I support the US spelling) is that mathematics is a singular noun.
That's why I included physics.
Actually, "mathematics" is originally plural, as is physics. In the present, though, it's treated as a collective noun primarily used as a singleton. (What is the plural of physics? What is the plural of mathematics?)
Please note that the long form is "mathematics" not "mathematic." The US form is odd in that way. Even in the States the subject is "physics" not "physic."
I've either worked with or have seen (usually via resume) a large number of hardware guys who have moved over to software. I know of exactly 0 who have done the reverse. FWIW I've been in the industry for over 20 years.
Well, here's the exception. BSCS degree, but I'm pushing polygons down at the silicon level and doing timing analyses at the count-the-picoseconds-on-your-toes level.
Then again, I tend to think of SPICE as a programming language that compiles to silicon. Working on my fourth decade in this business, too.
What if you tried doing what you enjoy and have a passion for, rather than what's in demand.
In another message I answered the question as posed, but the parent post is what I should have written.
I have over thirty years in electronics, both hardware and software, and it's taught me this: Do what you love and you'll find a way to make a living. Do what other people want from you and you not only will end up hating it, you'll end up hating yourself and broke besides.
As I move into my second year, I would like to know, are hardware people going to be far more in demand than the software people, or would software still be a better choice than a hardware-centred degree?
If I had the answer to that question, I wouldn't be worrying so much about where the money will come from for my own kids' college.
Background: I have a BSCS, an extra 40+ hours of physics and EE, and I'm currently working as a circuit design engineer. Go figure.
As for advice, I'll give you the same advice my own kids got from the faculties at three different universities in CS, EE, and Physics: You can never get too much maths or physics. From my own experience of more than 30 years in electronics, the basics are what last. Anything else you learn as needed.
So, FWIW, one of the boys is finishing his junior year as a dual-major EE and physics (with a maths minor), the other is wrapping up sophomore year as CS and physics. Make of all that what you will.
Yes. KHML is a fully GPLed engine, and Safari is based on that for all HTML rendering. It would be a breach of licence for Apple not to release any fixes
It's only a license breach if they distribute the altered Safari. If it's just a skunk-works one-off, they can toss gasoline on the changes and toss a match in as they walk away.
No, seriously, what kinds of thumbdrives have problems in Linux?
Lately, all of them. The only box that actually works is an ancient HP notebook (also Gentoo.)
They're OK as long as you don't unplug them. Once you unplug them (even after waiting hours following umount) they get corrupted. Seems to happen on both the Gentoo boxen at home and the RHEL3 boxen at $WORK.
Slashdot Mirror
Video processing chips have embedded microprocessors, either general (ARM or MIPS) or DSP (several types). For nontrivial functions there are often both. The code for these is, however, not stored in off-chip memory -- it's internal, in mask ROMS. A change to those ROMS requires new masks for the device, although the mask changes can usually be confined to the upper layers and therefore cost less to implement.
That's assuming the BF circuitry is on its own chip. Depending on the device manufacturer's resources, that could go either way, as it's much cheaper (NRE-wise, anyway) to design a secondary device to handle the BF instead of redesigning the entire capture/processing device to accomodate the BF.
That's assuming that there are any external "hooks" that would allow an external device to process the BF. Considering the economics of keeping the whole video processing pipe in one chip, that's unlikely. It's certainly not the kind of thing that would have been done without the expectation of a need for a disableable BF function, and if that's all it would also be easier to include other means to disable it.
The big ugly is that most of these chips aren't designed for use on tuner cards -- there aren't that many of them sold in a year. The big bucks are in the DVD boxes etc. The tuner cards have a bigger problem: how to allow viewing but not recording, when the card can't even tell which is going on.
Or include it in the chip that already does all the work. That "flag" doesn't show up on signals outside of most tuner chips.
This isn't a case of "add a chip." Products of this type are pretty much single-chip systems any more; the function is a matter of changing the design of that chip, not adding one.
The process for designing the chip, fabricating the prototypes, setting up manufacturing, etc. takes between a year and two years. By now, it's far too late to make the decision. The entire supply chain was switched over months ago at the latest.
The cow-orkers are wondering why I'm laughing so hard.
As soon as a new design or board rev is on the drawing boards, they'll be quick to notice they can shave 50c or a dollar off the cost by leaving out the silicon that handles the broadcast flag, and poof - it's gone.
The cost of implementing it is in creating the decoder for the stupid bit -- which, at current IC design rates, runs somewhere close to $2 million. Once it's in the decoder, the firmware (note, not software) to use it is somewhat less expensive to change but far from free.
The original design costs are spent. Making a design change to the firmware will only cost a few hundred thousand for the design, plus all of the issues for supply management, inventory, support, etc. Figure a half-million more or less to take out the BF function.
Now, how many extra units does the manufacturer have to sell to break even, assuming that the MPAA doesn't file suit?
For extra credit, how many extra units does the manufacturer have to sell if the MPAA does file suit? What are the odds that the MPAA will file suit? How many extra units does the manufacturer have to sell to cover the risk?
No, none of the parties in question were DVD-CCA licensees. The lawsuit was over the fact that the chipmaker sold chips to DVD player manufacturers who weren't DVD-CCA licensees.
The DVD manufacturers are not allowed to make "DVD player"s unless they agree to enforce CSS. It's not a DMCA violation.
Yeah, and who is "not allowing" the manufacture of those DVD players? US Courts. The statutory authority cited is the DMCA.
Not if their competitor is watching all of their product rot in a warehouse under preliminary injunction and spending more on legal defense every month than they make in profits for a year.
This is a case of the consumer electronics companies all hanging together or the MPAA will hang them all separately. There's a huge risk to being the first to break ranks, and it's very hard to see the marginal sales coming close to making up the staggering legal costs -- which are going to be gone even if the MPAA loses.
Nobody wants to be the first to buck the MPAA. Being the second one, in case the first actually wins, is a much better strategy --- let your competitor bear the legal expenses while you take advantage of the results.
In the same way that selling a DVD-player chip to any manufacturer that doesn't toe the DVD-CCA line is a DMCA violation -- and that's been upheld in court.
The MPAA can make the argument that since there are lots and lots of BF-compliant devices out there, so making something that ignores the BF has as its main "commercial use" the bypassing of the BF (you can look up the DMCA wording if you like.) That's enough to get them into court.
It doesn't matter if it's BS because the MPAA can afford to spend enough money on the lawsuit to suck all the profits out of anyone bucking them. They needed the FCC to do the initial dirty work but now they can handle any rebels on their own.
They don't care. Now that they've spent the money to implement it, it's all the same to them. Regardless of what we'd like to think, their sales are going to be the same either way.
When there weren't anything but non-BF devices on the market, the MPAA couldn't use the DMCA against the manufacturers. Now that everything is BF-compliant any device that isn't can easily be painted as a circumvention device under the DMCA and the manufacturer sued out of existence.
What's more, they won't take the risk. Now that the BC has become a "standard" feature, building anything without it is almost certain to be attacked by the MPAA under the DMCA.
If you have a BC-free tuner card, treasure it. They ain't making no more, ever again.
The Canopy Group does not own SCOX. In the ugly little affair to oust Ralph Yarro, Canopy gave him all of its interest in SCOX. Since he's the chairman anyway, that might let Canopy off the hook ("beneficial control" becomes the standard.)
I don't know how much Ralph has besides his (worthless) share in SCOX but I suspect that IBM would be content to suck him dry along with Darl.
Anyone who would sell WinXP deserves any punishment imaginable. Now if they could only work their way up to Dell, HP, ...
If so, your problems go a lot deeper than key management.
So, among other things, it was harder for Phoenix to explain away any similarities in source code than if the only available BIOS code was binary.
Me, I've read the correspondence filed with the Court on the subject. IBM asked what they were supposed to have done wrong so that they could remedy the problem, SCOX told them they'd see them in court.
Yeah, that's bad faith on IBM's part all right. Here we are more than two years later and IBM is still trying to get the Court to make SCOX tell them what IBM is supposed to have done wrong, so far with no luck.
That's why I included physics.
Actually, "mathematics" is originally plural, as is physics. In the present, though, it's treated as a collective noun primarily used as a singleton. (What is the plural of physics? What is the plural of mathematics?)
British, Canadian, Australian, etc. Yuppers.
Please note that the long form is "mathematics" not "mathematic." The US form is odd in that way. Even in the States the subject is "physics" not "physic."
Number agreement, eh? Presumably you can't get too much physic.
Hint: more English speakers shorten "mathematics" to "maths" than shorten it to "math."
Well, here's the exception. BSCS degree, but I'm pushing polygons down at the silicon level and doing timing analyses at the count-the-picoseconds-on-your-toes level.
Then again, I tend to think of SPICE as a programming language that compiles to silicon. Working on my fourth decade in this business, too.
In another message I answered the question as posed, but the parent post is what I should have written.
I have over thirty years in electronics, both hardware and software, and it's taught me this: Do what you love and you'll find a way to make a living. Do what other people want from you and you not only will end up hating it, you'll end up hating yourself and broke besides.
If I had the answer to that question, I wouldn't be worrying so much about where the money will come from for my own kids' college.
Background: I have a BSCS, an extra 40+ hours of physics and EE, and I'm currently working as a circuit design engineer. Go figure.
As for advice, I'll give you the same advice my own kids got from the faculties at three different universities in CS, EE, and Physics: You can never get too much maths or physics. From my own experience of more than 30 years in electronics, the basics are what last. Anything else you learn as needed.
So, FWIW, one of the boys is finishing his junior year as a dual-major EE and physics (with a maths minor), the other is wrapping up sophomore year as CS and physics. Make of all that what you will.
No guarantee, but she did.
It's only a license breach if they distribute the altered Safari. If it's just a skunk-works one-off, they can toss gasoline on the changes and toss a match in as they walk away.
Will the patches appear in Konqueror (KHTML)?
Lately, all of them. The only box that actually works is an ancient HP notebook (also Gentoo.)
They're OK as long as you don't unplug them. Once you unplug them (even after waiting hours following umount) they get corrupted. Seems to happen on both the Gentoo boxen at home and the RHEL3 boxen at $WORK.