um, bootsplash? The Penguin in the upper left corner of the screen?
Clearly, the Linux developers need to take a cue from Windows and put graphics drivers in the kernel, permitting a 3d-accelerated Tux at bootup, along with 64-voice software synthesized music. We're falling behind!
And also, hardness != either of the above, and *hardness* is the material property diamonds are known for (in addition to having a reasonably high index of refraction, although not the highest by any means.)
The most typical test of hardness is attempting to scratch a material. (To measure a material's hardness on the Mohs scale, essentially a series of scratch tests are performed, and a material's place on the Mohs scale was determined by what it could scratch vs. what would scratch it.)
I don't know about stiffness, but diamonds are definately not *tough*. As your links above show, "toughness" is resistance to fracturing under stress, and one of the ways diamonds are cut and shaped is by fracturing them along their crystal lattice planes. There are plenty of materials (Including, I believe, many plastics) that are *tougher* than diamond, but not necessarily harder. (For example, I believe ABS plastic and polycarbonate plastic are extremely tough, but neither are hard - i.e. they are VERY difficult to break via stress and impact, but scratch easily.)
Go to Wal-Mart. Get one of the new 2C or 2D Mag LEDs. (Not the best example, admittedly. Mag managed to botch the heatsinking of their converter despite the fact that their product is a huge fucking chunk of aluminum - the converter has no thermal path to the rest of the flashlight.)
Also www.theledguy.com sells a wide variety of Luxeon-based drop-in modules for Mini-Mags and lights with a similar form factor (Such as the 2AA Brinkmann model).
Stop using shitty wiring (Autonegotiation only deals with endpoint capabilities, not with cable quality), stop connecting forced full duplex equipment to autonegotiated equipment (why? go read the 802.3 spec or just take my word that it isn't going to work well).
My guess is that the new gear you brought home was a managed switch. Rather than having an ASIC dedicated solely to basic Ethernet switching, managed switches typically have a similar ASIC coupled with a general purpose CPU that controls the thing.
The per-port power (especially for idle unconnected ports) was probably negligible compared to the difference between managed "big iron" Ethernet switches and a basic "dumb" switch.
"But while DC-DC transformers that transform voltage DOWN have been available for some years now, I haven't seen a good approach to get voltage UP."
Flyback converters, boost converters - there are a large variety of efficient step-up DC/DC converter architectures.
Have you ever seen a high-power LED flashlight that ran on 2 AAs (or 2 Cs?) - wonder how they fed a 3.6v DC device (white LED) with 3v or 2.4v worth of batteries?
There are only two cases I know of where autonegotiation will cause failures: a) You are using shitty wiring not capable of the maximum common speed of both endpoints. (i.e. wiring only capable of 10M, endpoints can both do 100) Unfortunately autonegotiation only deals with endpoint capabilities, not wiring. b) You have devices that are in forced 100M full duplex. Forcing 100M full duplex should only be done by a device if the forcing is done by someone who knows EXACTLY what they're doing, as combining an autonegotiating endpoint with a forced full duplex endpoint results in a duplex mismatch. The IEEE standards explicitly state that 100M full duplex should never be used with an autonegotiating endpoint, and in fact forcing full duplex should be avoided in nearly all situations.
That said - the power differences between the various Ethernet modes are negligible. The common aspects of all modes (MAC/PHY chipsets, the computer doing the communications) are going to be FAR more than the difference in power consumption between the modes. There is little to no benefit to trying to "throttle back" Ethernet, unless they intend to create entirely new 10M and 100M modes. (If you applied all of the new signal processing algorithms used for GigE and reduced the clock rates, you could also reduce the output voltage swing, and as a result save power.)
"Not always. If the channel is coming in to the box digitally, it does not usually get transcoded."
I'd like to amend that a bit - in consumer DVRs, high-def content NEVER gets transcoded. It is always simply dumped to disc without decoding and/or reencoding. The transport stream is only decoded for playback.
Realtime high definition encoders simply do not exist, at least not at the price points needed to be put into a consumer device. The closest thing is the Slingbox PRO, but that downscales to SD before compression.
"The nice thing about AVRs is that they're fairly robust and hard to permanently kill. I've abused AVRs pretty badly, and I've NEVER had one permanently die on me. There were a few I'd thought were dead, but ultimately they were all resurrected via high-voltage programming or by supplying an external clock signal to them. I've grossly exceeded the i/o pins' current-draw capabilities, connected power backwards, created pin-to-pin shorts, and still lived to tell about it. From what I've read, other platforms aren't quite as forgiving and wantonly abusable as AVRs. I know people who've driven 5v-relays straight from AVR i/o pins."
I recall one story from my ECE 476 professor regarding their robustness - At one point he accidentally connected power in reverse, the AVR overheated significantly and melted the plastic of the protoboard it was plugged into.
He shut it down, pulled the AVR, and plugged it in correctly into a different protoboard.
While the protoboard it had been previously used in was now destroyed, the AVR worked flawlessly.
The way you describe it, it sounds like Microchip is fixing the kludginess of their CPUs with workarounds in their development tools (MPLAB).
And the original poster was reccommending Atmel AVRs - how the hell did you get on your Motorola rant? He only mentioned Motorola tools as an example of a "traditional" design and then went into a number of reasons NOT to use them because more modern variants exist.
I have to admit, while I usually prefer open-source tools, CodevisionAVR is an EXCELLENT tool with amazing support.
CVAVR was what my undergrad microcontrollers class (Cornell's ECE 476) used, and I believe still uses. In the rare cases when our professor found a compiler bug, he would often have a one-day turnaround on bugfixes.
Admittedly, we were a pretty big customer with a large site license, but I've heard many good things about CVAVR.
"It's almost as if the linux devs give a shit about the drivers they're writing, but the manufacturers don't..."
Developers are more motivated when their reputation is on the line.
Driver devs for a "commercial" driver are usually insulated from the public, nameless and faceless. Thus they have no real motivation to take pride in their work.
Open-source driver devs, on the other hand, usually have their name plastered all over the headers of every file, and probably quite a few mailing list postings. As a result, if the drivers are crap, instead of "Company Foo's drivers are junk, don't buy from them.", it's "fimbulvetr's driver for Widget Foo is junk, what kind of an idiot is fimbulvetr?", thus fimbulvetr has a very personal incentive NOT to write a crap driver and instead write one that has people saying "fimbulvetr is a genius, look at the amazing job he did with the driver for Widget Foo!"
"If you are, then you probably ought to have more pixels (i.e., a better camera). I'm okay with digital pictures down to about 150dpi, others swear that you need 300+. Then again, there are people who swear that $3000 unobtainium coated silver strands wrapped in virgin PTFE and assembled when the planets are in alignement make their music sound better."
More pixels is not necessarily better. More sensor area is usually more important.
This is why high-end DSLRs with only 4-5 megapixel resolution deliver better images than 7-8 megapixel consumer cameras - larger sensor elements result in higher signal to noise ratio at the sensor, which means less image noise. Considering the submitter's problem is image noise, a higher resolution camera with the same sensor size is NOT going to help them.
"Doesn't this make H.264 only free of the two patents held by Qualcomm?"
The article doesn't have many details, but since Qualcomm is (or at least used to be) an IC manufacturer among other things and Broadcom's infringing products are ICs, these patents could easily be specific only to a specific method of implementing H.264 in hardware. The MPEG-4 LA covers licensing of patents that cover the algorithm, but I wouldn't be surprised if there are additional patents out there covering specific unique implementations of H.264. i.e. the MPEG4-LA covers the MPEG-4 related patents that you absolutely can't avoid infringing if you create a compliant MPEG-4 implementation, but not necessarily implementation-specific patents.
It reminds me a lot of the article a few weeks ago where a university was suing some manufacturers of Bluetooth chipsets. Everyone on Slashdot went postal with comments like "How could they patent Bluetooth. Prior art! Prior art!", when in fact the patent was not in ANY way Bluetooth-specific at all but for a method of designing a low-cost RF receiver, a method which a number of Bluetooth silicon manufacturers happened to use in their receiver designs.
My suspicion (the article doesn't have enough details) is that this court decision has absolutely zero effect on anyone who implements H.264 in software as there is a good chance they weren't even infringing in the first place.
If that's the sort of offer you're getting, then start looking for another offer with someone else. An offer like that is a bad sign.
For my current job, I had a 30 day deadline to accept if I wanted a small (insignificant enough for me that I didn't go for the deadline) "signing bonus", and a 60 day hard deadline to accept. My relocation bonus WAS spelled out in writing in the offer.
Some companies love to play hardball, but many don't. I work for a large traditional multinational company, and they treat their employees VERY well.
"Also, for chem it's perfect. Often you need to add up different steps of a reaction seperately then sum them. With RPN, there's no retyping! Also, there are tons of libraries including a molecular weight calculator and much much more. And there's even a remote control program for the built in infra-red tranceiver so you can mess around with the televisions in class;)"
If I didn't know any better, I'd swear from your description that you were me.:)
My poor, poor high school chem teacher. Great guy, but my friends and I couldn't resist pulling a prank on him one day.
I turned the classroom TV on, and he noticed and went to turn it off.
A few minutes later, I clicked it on again. He was somewhat puzzled, as he did not see a remote anywhere in the room, just students diligently working on their chem lab, with some of his top students grinding through equations on their super-high-end HP calculators. He didn't notice the IR ports on those calculators. He was on the lookout for the infamous "remote control watches" but not students holding their calculators out like a remote control in the direction of the TV.
When his finger was about six inches from the TV (he didn't have a remote so was physically hitting the power button), I clicked it off. You should have seen the look on his face!
At the end of the class, we came clean about our little prank, he took it pretty well.
That battery lifetime isn't necessarily a good thing.
Batteries in a device for a long time = high risk of battery leakage. (Not charge leakage, electrolyte leakage)
My precious 48GX has had a few close calls with battery electrolyte.
That said, it's an amazing testament to the calculator that battery life is so long that the batteries physically degrade before the calculator is unable to run. Just be careful to change the batteries in your precious calculator every two years or so.
I would love an updated version, but everything I've heard about the 48GX's successors has not been very good. It seems like the legend of the HP calculator reached its pinnacle with the 48GX and has died since then.
The fact that the 48GX (if you can find one) is still one of the most highly reccommended and highly desirable calculators on the market even after being discontinued for nearly a decade says a lot about just how well it was designed.
I remember back in high school when the TI-92 or 93 came out (I don't recall the exact model number - it was the big one with the QWERTY keyboard), a few friends initially were raving about how much better it was than my "old and pokey" 48GX. Within two years all of them had moved to HP48s themselves!
I don't know about the keyspace, but I recall seeing somewhere that the revocation table is only one megabyte.
Thus while the keyspace is very large (otherwise it would be easy to crack), the storage space for revoked keys isn't.
Whether a DOS attack is viable depends on whether a given player has different keys assigned to different units. i.e. if 20 different keys are assigned to PowerDVD 7.1, then an attack against PDVD will likely result in 20 keys added to the revocation list before PDVD gets shored up. (And most likely, even after it gets shored up it'll get cracked again eventually.)
If only one key is assigned to a particular player (i.e. all copies of PowerDVD 7.1 share keys, and more importantly, all versions of some hardware player do), then there's a much higher penalty for the MPAA if they have to revoke a key - there's no way to do it without pissing off the consumers, and who wants to be the first to be in the news that a whole batch of your players was essentially bricked? That's one BIG disadvantage for the media companies of there being a format war (and actually a potential advantage for consumers) - neither format's backers are going to want the bad PR of a large-scale revocation.
"Why does liscencing a patent require closed source drivers?"
As I posted in a previous reply, that is at the patent owner's discretion, even though it might not make sense.
Either way, the drivers are closed due to intellectual property licensed in such a way as to forbid implementation of some features in an open-source driver. Whatever the exact details are, it's a fact that ATI's first closed-source Linux drivers were released shortly after the UT2003 S3TC fiasco, and S3TC support (and hence UT2K3 compatibility) was initially about the only feature that set the two drivers apart (open-source vs. closed).
Possibly because their patent agreement with the patent owner requires the implementation to be closed source? Or the easiest way to obtain a license to use the patent was to purchase someone else's implementation?
While the patent description is itself "open", nothing says that the licensing agreements to use that patent can't force closed source.
Slashdot Mirror
um, bootsplash? The Penguin in the upper left corner of the screen?
Clearly, the Linux developers need to take a cue from Windows and put graphics drivers in the kernel, permitting a 3d-accelerated Tux at bootup, along with 64-voice software synthesized music. We're falling behind!
And also, hardness != either of the above, and *hardness* is the material property diamonds are known for (in addition to having a reasonably high index of refraction, although not the highest by any means.)
The most typical test of hardness is attempting to scratch a material. (To measure a material's hardness on the Mohs scale, essentially a series of scratch tests are performed, and a material's place on the Mohs scale was determined by what it could scratch vs. what would scratch it.)
I don't know about stiffness, but diamonds are definately not *tough*. As your links above show, "toughness" is resistance to fracturing under stress, and one of the ways diamonds are cut and shaped is by fracturing them along their crystal lattice planes. There are plenty of materials (Including, I believe, many plastics) that are *tougher* than diamond, but not necessarily harder. (For example, I believe ABS plastic and polycarbonate plastic are extremely tough, but neither are hard - i.e. they are VERY difficult to break via stress and impact, but scratch easily.)
Go to Wal-Mart. Get one of the new 2C or 2D Mag LEDs. (Not the best example, admittedly. Mag managed to botch the heatsinking of their converter despite the fact that their product is a huge fucking chunk of aluminum - the converter has no thermal path to the rest of the flashlight.)
Also www.theledguy.com sells a wide variety of Luxeon-based drop-in modules for Mini-Mags and lights with a similar form factor (Such as the 2AA Brinkmann model).
Stop using shitty wiring (Autonegotiation only deals with endpoint capabilities, not with cable quality), stop connecting forced full duplex equipment to autonegotiated equipment (why? go read the 802.3 spec or just take my word that it isn't going to work well).
Problem solved.
My guess is that the new gear you brought home was a managed switch. Rather than having an ASIC dedicated solely to basic Ethernet switching, managed switches typically have a similar ASIC coupled with a general purpose CPU that controls the thing.
The per-port power (especially for idle unconnected ports) was probably negligible compared to the difference between managed "big iron" Ethernet switches and a basic "dumb" switch.
"But while DC-DC transformers that transform voltage DOWN have been available for some years now, I haven't seen a good approach to get voltage UP."
Flyback converters, boost converters - there are a large variety of efficient step-up DC/DC converter architectures.
Have you ever seen a high-power LED flashlight that ran on 2 AAs (or 2 Cs?) - wonder how they fed a 3.6v DC device (white LED) with 3v or 2.4v worth of batteries?
There are only two cases I know of where autonegotiation will cause failures:
a) You are using shitty wiring not capable of the maximum common speed of both endpoints. (i.e. wiring only capable of 10M, endpoints can both do 100) Unfortunately autonegotiation only deals with endpoint capabilities, not wiring.
b) You have devices that are in forced 100M full duplex. Forcing 100M full duplex should only be done by a device if the forcing is done by someone who knows EXACTLY what they're doing, as combining an autonegotiating endpoint with a forced full duplex endpoint results in a duplex mismatch. The IEEE standards explicitly state that 100M full duplex should never be used with an autonegotiating endpoint, and in fact forcing full duplex should be avoided in nearly all situations.
That said - the power differences between the various Ethernet modes are negligible. The common aspects of all modes (MAC/PHY chipsets, the computer doing the communications) are going to be FAR more than the difference in power consumption between the modes. There is little to no benefit to trying to "throttle back" Ethernet, unless they intend to create entirely new 10M and 100M modes. (If you applied all of the new signal processing algorithms used for GigE and reduced the clock rates, you could also reduce the output voltage swing, and as a result save power.)
"Not always. If the channel is coming in to the box digitally, it does not usually get transcoded."
I'd like to amend that a bit - in consumer DVRs, high-def content NEVER gets transcoded. It is always simply dumped to disc without decoding and/or reencoding. The transport stream is only decoded for playback.
Realtime high definition encoders simply do not exist, at least not at the price points needed to be put into a consumer device. The closest thing is the Slingbox PRO, but that downscales to SD before compression.
"The nice thing about AVRs is that they're fairly robust and hard to permanently kill. I've abused AVRs pretty badly, and I've NEVER had one permanently die on me. There were a few I'd thought were dead, but ultimately they were all resurrected via high-voltage programming or by supplying an external clock signal to them. I've grossly exceeded the i/o pins' current-draw capabilities, connected power backwards, created pin-to-pin shorts, and still lived to tell about it. From what I've read, other platforms aren't quite as forgiving and wantonly abusable as AVRs. I know people who've driven 5v-relays straight from AVR i/o pins."
I recall one story from my ECE 476 professor regarding their robustness - At one point he accidentally connected power in reverse, the AVR overheated significantly and melted the plastic of the protoboard it was plugged into.
He shut it down, pulled the AVR, and plugged it in correctly into a different protoboard.
While the protoboard it had been previously used in was now destroyed, the AVR worked flawlessly.
The way you describe it, it sounds like Microchip is fixing the kludginess of their CPUs with workarounds in their development tools (MPLAB).
And the original poster was reccommending Atmel AVRs - how the hell did you get on your Motorola rant? He only mentioned Motorola tools as an example of a "traditional" design and then went into a number of reasons NOT to use them because more modern variants exist.
I have to admit, while I usually prefer open-source tools, CodevisionAVR is an EXCELLENT tool with amazing support.
CVAVR was what my undergrad microcontrollers class (Cornell's ECE 476) used, and I believe still uses. In the rare cases when our professor found a compiler bug, he would often have a one-day turnaround on bugfixes.
Admittedly, we were a pretty big customer with a large site license, but I've heard many good things about CVAVR.
"It's almost as if the linux devs give a shit about the drivers they're writing, but the manufacturers don't..."
Developers are more motivated when their reputation is on the line.
Driver devs for a "commercial" driver are usually insulated from the public, nameless and faceless. Thus they have no real motivation to take pride in their work.
Open-source driver devs, on the other hand, usually have their name plastered all over the headers of every file, and probably quite a few mailing list postings. As a result, if the drivers are crap, instead of "Company Foo's drivers are junk, don't buy from them.", it's "fimbulvetr's driver for Widget Foo is junk, what kind of an idiot is fimbulvetr?", thus fimbulvetr has a very personal incentive NOT to write a crap driver and instead write one that has people saying "fimbulvetr is a genius, look at the amazing job he did with the driver for Widget Foo!"
"Also, if I'm not mistaken, the ones offering this service, are more organized than just the standard 'linux dev' community."
If they were, this announcement wouldn't be some Linux kernel developers' personal blog entry. Which is what it appears to be.
It looks to me like a personal "look at what we have available" posting, not an official press release in any way.
If they want official acknowledgement from hardware vendors, they need to have a more official-looking announcement than a blog entry.
Other than the public announcement, how is this any different from the way things already work?
The community already writes free drivers for vendors who provide specs and (even better in some cases) loan some hardware.
There are already situations where Linux devs have been able to work out NDA-acceptable solutions.
Really, all the announcement is saying is, "Look, we do this. We've been doing this for years. Just letting you know how things work over here."
"If you are, then you probably ought to have more pixels (i.e., a better camera). I'm okay with digital pictures down to about 150dpi, others swear that you need 300+. Then again, there are people who swear that $3000 unobtainium coated silver strands wrapped in virgin PTFE and assembled when the planets are in alignement make their music sound better."
More pixels is not necessarily better. More sensor area is usually more important.
This is why high-end DSLRs with only 4-5 megapixel resolution deliver better images than 7-8 megapixel consumer cameras - larger sensor elements result in higher signal to noise ratio at the sensor, which means less image noise. Considering the submitter's problem is image noise, a higher resolution camera with the same sensor size is NOT going to help them.
"Doesn't this make H.264 only free of the two patents held by Qualcomm?"
The article doesn't have many details, but since Qualcomm is (or at least used to be) an IC manufacturer among other things and Broadcom's infringing products are ICs, these patents could easily be specific only to a specific method of implementing H.264 in hardware. The MPEG-4 LA covers licensing of patents that cover the algorithm, but I wouldn't be surprised if there are additional patents out there covering specific unique implementations of H.264. i.e. the MPEG4-LA covers the MPEG-4 related patents that you absolutely can't avoid infringing if you create a compliant MPEG-4 implementation, but not necessarily implementation-specific patents.
It reminds me a lot of the article a few weeks ago where a university was suing some manufacturers of Bluetooth chipsets. Everyone on Slashdot went postal with comments like "How could they patent Bluetooth. Prior art! Prior art!", when in fact the patent was not in ANY way Bluetooth-specific at all but for a method of designing a low-cost RF receiver, a method which a number of Bluetooth silicon manufacturers happened to use in their receiver designs.
My suspicion (the article doesn't have enough details) is that this court decision has absolutely zero effect on anyone who implements H.264 in software as there is a good chance they weren't even infringing in the first place.
If that's the sort of offer you're getting, then start looking for another offer with someone else. An offer like that is a bad sign.
For my current job, I had a 30 day deadline to accept if I wanted a small (insignificant enough for me that I didn't go for the deadline) "signing bonus", and a 60 day hard deadline to accept. My relocation bonus WAS spelled out in writing in the offer.
Some companies love to play hardball, but many don't. I work for a large traditional multinational company, and they treat their employees VERY well.
"Also, for chem it's perfect. Often you need to add up different steps of a reaction seperately then sum them. With RPN, there's no retyping! Also, there are tons of libraries including a molecular weight calculator and much much more. And there's even a remote control program for the built in infra-red tranceiver so you can mess around with the televisions in class ;)"
:)
If I didn't know any better, I'd swear from your description that you were me.
My poor, poor high school chem teacher. Great guy, but my friends and I couldn't resist pulling a prank on him one day.
I turned the classroom TV on, and he noticed and went to turn it off.
A few minutes later, I clicked it on again. He was somewhat puzzled, as he did not see a remote anywhere in the room, just students diligently working on their chem lab, with some of his top students grinding through equations on their super-high-end HP calculators. He didn't notice the IR ports on those calculators. He was on the lookout for the infamous "remote control watches" but not students holding their calculators out like a remote control in the direction of the TV.
When his finger was about six inches from the TV (he didn't have a remote so was physically hitting the power button), I clicked it off. You should have seen the look on his face!
At the end of the class, we came clean about our little prank, he took it pretty well.
That battery lifetime isn't necessarily a good thing.
Batteries in a device for a long time = high risk of battery leakage. (Not charge leakage, electrolyte leakage)
My precious 48GX has had a few close calls with battery electrolyte.
That said, it's an amazing testament to the calculator that battery life is so long that the batteries physically degrade before the calculator is unable to run. Just be careful to change the batteries in your precious calculator every two years or so.
I would love an updated version, but everything I've heard about the 48GX's successors has not been very good. It seems like the legend of the HP calculator reached its pinnacle with the 48GX and has died since then.
The fact that the 48GX (if you can find one) is still one of the most highly reccommended and highly desirable calculators on the market even after being discontinued for nearly a decade says a lot about just how well it was designed.
I remember back in high school when the TI-92 or 93 came out (I don't recall the exact model number - it was the big one with the QWERTY keyboard), a few friends initially were raving about how much better it was than my "old and pokey" 48GX. Within two years all of them had moved to HP48s themselves!
They just don't build em' like they used to...
LMAO.
Where are my mod points when I need them?
Not like it matters, since +funny = no karma and AC = can't get karma anyway.
Read the forums. You'll note that this particular DVD did not implement "BD+" which is an ADDITIONAL layer of "protection" on top of AACS.
BD+ discs are potentially going to be much harder. Why BD+ isn't used on all discs, I don't know.
I don't know about the keyspace, but I recall seeing somewhere that the revocation table is only one megabyte.
Thus while the keyspace is very large (otherwise it would be easy to crack), the storage space for revoked keys isn't.
Whether a DOS attack is viable depends on whether a given player has different keys assigned to different units. i.e. if 20 different keys are assigned to PowerDVD 7.1, then an attack against PDVD will likely result in 20 keys added to the revocation list before PDVD gets shored up. (And most likely, even after it gets shored up it'll get cracked again eventually.)
If only one key is assigned to a particular player (i.e. all copies of PowerDVD 7.1 share keys, and more importantly, all versions of some hardware player do), then there's a much higher penalty for the MPAA if they have to revoke a key - there's no way to do it without pissing off the consumers, and who wants to be the first to be in the news that a whole batch of your players was essentially bricked? That's one BIG disadvantage for the media companies of there being a format war (and actually a potential advantage for consumers) - neither format's backers are going to want the bad PR of a large-scale revocation.
Who said it had to be a teenager?
Andrew "Bunnie" Huang was a grad student when he reverse engineered the Xbox.
"Why does liscencing a patent require closed source drivers?"
As I posted in a previous reply, that is at the patent owner's discretion, even though it might not make sense.
Either way, the drivers are closed due to intellectual property licensed in such a way as to forbid implementation of some features in an open-source driver. Whatever the exact details are, it's a fact that ATI's first closed-source Linux drivers were released shortly after the UT2003 S3TC fiasco, and S3TC support (and hence UT2K3 compatibility) was initially about the only feature that set the two drivers apart (open-source vs. closed).
Possibly because their patent agreement with the patent owner requires the implementation to be closed source? Or the easiest way to obtain a license to use the patent was to purchase someone else's implementation?
While the patent description is itself "open", nothing says that the licensing agreements to use that patent can't force closed source.