Possibly, I was thinking of making a post along similar lines, (A defensive or offensive patent to be used against adware companies, preventing anyone from producing such adware without ANOTHER reason to get sued), but I wouldn't put it past Microsoft to abuse this technology in some of the worst ways imaginable.
Or it could be just something done to inflate the "My patent stack is bigger than yours" even if the company may never turn it into a product or expect anyone else to ever do so - see one of AT&T/Lucent's gems
"I wouldn't worry about Vonage so much. They have 2.4 million subscribers already. Plus, it's not as if the cable company or telcos offering VOIP service have that much more control over the quality of their service either. They're still stuck with the same problems everyone else is in regard to Internet traffic."
Not really. 1) Many of those people are essentially providing "last mile" service and not much more (easier to control), probably one reason they're so much more expensive. 2) Many of the big cable companies and telcos have their own nationwide private networks they DO have control over.
The general idea is that table sugar (sucrose) tends to cause a more rapid blood glucose spike than an equivalent amount of fructose (All sugars and starches input into the body eventually get broken down into glucose, at varying rates. Because sucrose is essentially one fructose and one glucose molecule bound together, the only thing that gets converted to blood glucose faster than sucrose is glucose itself. With the exception of glucose tablets intended for diabetics experiencing a hypoglycemic episode, pure glucose in food intake is nearly unheard of, it's all sucrose or (in the case of fruits and "diabetic-friendly" foods) fructose.
This reduction in absorption rate is good for two reasons: 1) For Type I diabetics like myself, it makes the bloodsugar changes easier to manage. You don't spike up as fast, and you don't crash down as fast once the sugar stops hitting you. 2) For weight management, from what I've heard the bloodsugar spike will result in an given amount of fructose causing less weight gain than an equivalent amount of sucrose.
Now this article claims that fructose isn't all that hot, but as I see it, it's no new news. 1) Claims that fructose is 50% of table sugar. Duh, I knew that. It's the fact that the other 50% of the sucrose molecule is glucose that is the problem. (As compared to sweetening something with 100% fructose and 0% glucose). 2) I don't know the exact details of HFCS, but in general, diabetics are told that while things sweetened with fructose itself are good (as long as you count the calories, of course), HFCS should be considered to be as bad as sucrose itself in terms of blood sugar management. As I said, I don't know the details, but HFCS spikes your bloodsugar WAY faster than pure fructose. Of course, this could be because HFCS is usually found in heavily sweetened liquids, while pure fructose is more often used to provide mild sweetening in baked goods. (In general, anything liquid will spike your bloodsugar far faster than a solid food with equivalent amounts of calories and similar sweeteners, for example a serving of pineapple juice vs. a serving of dried pineapple with equivalent calories.) 3) Note that I've been constantly stating the relative merits of fructose compared to other sweeteners with equivalent calorie counts. In general, stuff that has table sugar or HFCS added has had a LOT of it added. With calorie counts as high as those found in regular sodas, it doesn't matter WHAT the exact absorption profile of the sweetener is, its calorie count alone is going to cause a giant spike in a diabetic's bloodsugar, and potential weight gain in anyone.
I don't know how many times a disc has become unreadable because the TOC was damaged. You can have all the parity data in the world, if the TOC is gone you're screwed.:(
If only there were a DVD format writable/readable with consumer-grade drives that had multiple redundant TOCs.
FFX-II wouldn't be so bad if it weren't so exceedingly cheesy. The gameplay actually isn't that bad, but the way the "Charlie's Angels" characters behave is SO annoying.
For me, it was PS2 at $120, FFXII at $50, and all of the other PS2 FF releeases for $10 each used.
Likewise, I definately will not be buying the PS3 until the PS4 comes out. As opposed to the Wii, which had an opportunity limited only by lack of availability for 6 months before losing the competition to a new DSLR camera and some glass for aforementioned camera. No more room left in the budget for gaming systems anymore...
The FCC is most worried about changing operating frequencies, which would most likely be #defines or tables in the source code.
Easier to read source code and change it than to open up a radio (warranty voided), figure out what circuit trace does what, and then figure out which jumper to clip.
Many WLAN cards load their firmware into RAM on initialization (and in fact these are the ones that have resulted in the most controversy - you never saw people ranting about WLAN firmware back when it was in the card's flash memory and didn't have to be uploaded to the card by the driver, it wasn't until WLAN card vendors started cost optimizing and having the cards load firmware into RAM on initialization.), and so can't even be bricked with a "bad flash". In short, it's a lot more likely you'll void your warranty and brick your radio trying to clip the jumper/figure out which one to clip than by twiddling around with the firmware trying to make it do stuff it shouldn't be doing.
Signed binaries would work, but they fundamentally go against the whole idea of open source.
What's the point of having the source to your WiFi card's firmware if any of your bugfixed builds won't run on your WiFi card because they aren't signed? See RMS's rants about "Tivoization". Unfortunately, as I see it, the only options for SDRs are either closed source drivers (which probably should still be cryptographically signed to avoid modification by clever hex editor users) or open-source "Tivoized" drivers for which only cryptographically signed builds will run on the target hardware.
Nope, the FUD machine isn't at it again, it's just that 90% of readers are failing to understand the kind of security the FCC is talking about here.
The FCC is worried about end users modifying radios to behave differently than how they are certified and type approved. The FCC does not want users to modify the behavior of a type approved device, but enabling end-user modification of software behavior is one of the fundamental premises of open source software. In this regard, open source software has (by definition) opposite design goals from what the FCC requires from a type-approved device.
No peer review needed to verify the type of security they're talking about.
Hook up spectrum analyzer.
Can user easily make device transmit out-of-band? (Yes/No)
If No, security is sufficiently verified as far as the FCC's purposes. Keep in mind that the FCC in the past has been fine with the sale of scanners for which defeating the cellular band reception lockout only required clipping a brightly colored jumper inside the radio - the FCC's standards as far as "Easy" vs. "Hard" are pretty low.
Unfortunately, open-source drivers make such modifications ridiculously easy, easier than even the FCC's very low standards as far as tamper-resistance is concerned. As far as they are concerned, for the type of security (anti-tamper/modification resistance), open source software provides *zero* security as the whole idea behind open source software centers around ease of modification. The only way to provide the sort of security the FCC is looking for with open source software would be with a TiVo-style antitamper mechanism that only allowed FCC-approved builds of the software to run on an SDR, but this fundamentally goes against the whole idea of open source.
The FCC has always required that at least SOME measures are taken to prevent such tampering.
For example, the cellular band reception lockout on most scanners can be defeated by clipping a jumper. It's not TOO hard to defeat, but the fact that such a barrier is there to prevent receiving that locked out band is good enough for the FCC.
You can think of "binary blob" radio control as being like hardware with a jumper that you need to open up the radio and clip. The lockout can still be defeated, but needs reasonable technical expertise. Meanwhile, an open source driver with frequency/power control would be akin to putting a clearly labeled "Turn on to enable cellular band reception" switch on a handheld scanner.
If this is in regards to open-source Wi-Fi firmwares and FCC certification, the FCC has a completely different type of "security" and "hacker" in mind than what most people think of when they think of computer security and crackers.
The article (and summary, and most users) are assuming they are talking about data and computer security - preventing malicious users from spying on other users' data (classic WiFi example - WEP cracking), and from compromising a users' machine (Intel WiFi driver compromises.)
I'm fairly certain that the FCC is talking about a different kind of security - a device licensed by the FCC to transmit is only licensed to transmit on certain frequencies with certain modulation schemes, often with addition restrictions on power levels (some of which may be frequency-dependent.) Also there are sometimes restrictions on what frequencies a device may receive. For example, it was (and likely still is, although it's no longer relevant) illegal to sell radio receivers that covered the 800 MHz cellular bands. In terms of "security", the FCC is talking about preventing licensed transmitters from being modified to transmit out of their licensed band, in unlicensed modulation schemes, at unlicensed power levels, and sometimes receiving frequencies that no one is allowed to sell a receiver for in the United States.
The problem is that in this regard (preventing modifications to hardware functionality), Open Source is indeed fundamentally less secure - The whole idea behind Open Source is giving the user the freedom to modify their software and add functionality, and with modern software-defined radios, and modifying the software fundamentally modifies the behavior of the hardware. This freedom to modify the hardware is EXACTLY what the FCC does not want users to have. It is in theory possible to get tamper-resistance in a manner similar to what the FCC wants (see TiVo for an example of a vendor who has satisfied MAFIAA tamper-resistance requirements while using open-source software), but not without going against the fundamental spirit of Open Source. There's no point in the source being open for a piece of software if the hardware refuses to run it unless it's signed by the vendor (See TiVo again).
So far the open source community has yet to show a workable solution for open-source drivers that prevents the user from "unlocking" additional frequencies/modifications/power levels on existing software defined radios without a simple source change and a recompile. I'm honestly not sure if there is a workable solution to such a problem that doesn't involve anti-tamper via code signing, which as I said before kind of defeats the purpose of open source.
Blocking RF is easy if you don't need optical transparency - others have mentioned that many forms of insulation on the market already have metallized backing, for a theater one would just need a thin layer of metal foil in/on the walls. Paint with metallic particles or graphite powder mixed in would probably also work well.
The big news here appears to be that it's an optically transparent solution, not even tinted. (It's a known fact that automotive window tints are pretty good at blocking RF due to metallic content, which is why GPS receivers without external antennas work much better in some cars than others, although typically front windshields are never tinted, only rear/side windows are.)
I was going to comment that there are already quite inexpensive and effective window films that block RF quite well.
That said, it seems that the big difference between them and this "declassified" one is that it seems to be optically transparent? If you don't need full optical transparency but a darkened tint is acceptable (probably not only acceptable but desirable in many office environments), metallized window tints such as even the cheapo ones sold as aftermarket automotive films will block RF quite well.
For optically transparent - the same conductive coating used for LCD screens would probably block RF well, but that isn't a flexible "add on" film and might be prohibitively expensive for building windows, even when compared to this new stuff.
If you don't need optical transparency, blocking RF is reasonably easy, at least for a building.
Some BT clients attempt to do such a thing (crank up the upstream rate until latency starts increasing, then back off), although it doesn't work nearly as well as a proper QoS setup.
QoS - typically implemented not in the TCP stack but in intermediary routers that prioritize packets (important stuff goes out first and is less likely to be dropped if the connection is saturated, "bulk" data like BitTorrent goes out only if the send queue is empty at the router's WAN connection and is most likely to get dropped if a queue fills up), and in some cases artifically throttle the connection by dropping packets if the sender transmits beyond a set limit.
If you're looking for QoS in a home environment, the easiest solution is likely to replace your router with one capable of running DD-WRT. (This assumes you have a "consumer grade" router. If your gateway to the outside world is a normal PC running Linux, it's just a matter of setting up QoS on that box... Quite a few HOWTOs exist for this.)
"vanilla Linux" isn't a traditional TCP implementation for any reasonably recent kernel. In fact, if one assumes by "traditional TCP" the grandparent meant Reno, then that particular implementation is so obsolete you cannot even choose it as a congestion control algorithm for Linux any more. (Linux allows you to choose between 6-10 pluggable congestion control algorithms, the recent defaults of BIC and later CUBIC are both very nice ones.)
Not really that fancy - the 1990 4.3BSD release was codenamed "Reno" and its TCP stack was widely copied into many other OSes due to its permissive license. Even though I believe that release of BSD as a whole was considered "Reno" (in the same manner as "Feisty Fawn" for Ubuntu or "Zod" for Fedora), in general Reno is now used to refer to its TCP stack and/or TCP implementations that behave the same as Reno's stack. i.e. nearly every OS in the mid-1990s used "TCP Reno".
Reno is so obsolete that you can't even choose it as one of the many pluggable congestion control algorithms in recent Linux kernels.
It doesn't, unless your TCP implementation is from the stone age.
I love how fastsoft likes to compare themselves to Reno. 4.3BSD "Reno" was released in 1990, and the classic Reno implementation is LONG obsolete (and does indeed suck on a wide variety of connections).
I can see how it would be quite easy to achieve 10-20 times the throughput of Reno on a high-loss or high-latency connection, in fact a stock untuned Linux stack will do so in many situations. (For example, a few months ago I was doing TCP throughput tests dealing with some faulty hardware that liked to drop bursts of packets due to a shitty network driver. A machine running VxWorks 5.4, which is pretty much vanilla Reno, could only send 160 kilobytes/second over a 100Base-T LAN to that machine due to the packet loss making it throttle back. An untuned laptop with Linux 2.6.20 managed 1.7 megabytes/second over the same connection to the same destination.)
High latency connections were a major problem for TCP prior to RFC 1323 were a problem, but TCP stack authors have had 15 years to implement RFC 1323.
FastSoft's product may have been big news in the early 1990s, but if a company has to resort to making performance comparisons against the "Reno" TCP implementation, they're a snake oil salesman because Reno is such an obsolete and shitty TCP congestion control implementation.
Yeah, except that all gumstix products put Ethernet on a daughterboard using a Hirose connector that's a complete non-starter in a severe high-vibration environment.
This thing still uses an RJ45 connector which means it still can't be used in such a severe environment in its off-the-shelf form, but it's much easier to desolder a connector and solder a jumper cable to something like a MIL-C-38999 and pot the whole thing in epoxy than try to ruggedize those Hirose connectors (hopeless).
Just one example of something which has no compatible equivalent in Linux.
Note that I say *compatible*. My company uses Nortel Contivity gateways for their VPN system, and so if I want to VPN into work I need to be running Windows.
Contivity is (in theory) an IPSec implementation, but it's so badly mangled that it seems that no "real" IPSec implementations will talk to a Contivity VPN gateway. Non-Windows versions of the Contivity client are extra-cost addons from Nortel, and since my company (like 90% of those on the planet) is a primarily Windows shop on the desktop, if I want to VPN into work I need to be running Windows.
In theory, you don't need Windows any more. In the Real World, sadly, you do, since vendor lock-in is a bitch.
Why? Just because it uses a different medium (cable TV RF channels instead of the POTS voice band) doesn't mean it isn't still a modem.
MODEM originally meant MODulator/DEModulator (with the two Ds mashed into one). That's exactly what a cable modem is - a QAM modulator and a QAM demodulator. (OK, OK, it has a bit more than that, such as an Ethernet bridge in most cases.)
Regarding the last one (S3TC) - removing it WILL break a lot of games.
Unreal Tournament's need for the last one marks the beginning of ATI providing proprietary drivers and partial specs for their cards rather than full specs. There was a huge to-do about Unreal Tournament 2003 only working on NVidia cards in Linux back when UT2K3 was released. Epic's response was basically "we use this feature, it's implemented in all Windows drivers and the NVidia 3D drivers, we cannot work around the lack of this feature in the ATI drivers."
Shortly after, the first binary ATI drivers were released, with the main difference between them and the open-source drivers being S3TC. They have diverged since then, as clearly a number of other encumbered extensions have gone mainstream after looking at your list.
Slashdot Mirror
Do you mean a three year sep between X-2 and XII?
The separation between X and XII was way more than three years, I remember playing it in 2001 after it had been out a while.
Possibly, I was thinking of making a post along similar lines, (A defensive or offensive patent to be used against adware companies, preventing anyone from producing such adware without ANOTHER reason to get sued), but I wouldn't put it past Microsoft to abuse this technology in some of the worst ways imaginable.
Or it could be just something done to inflate the "My patent stack is bigger than yours" even if the company may never turn it into a product or expect anyone else to ever do so - see
one of AT&T/Lucent's gems
"I wouldn't worry about Vonage so much. They have 2.4 million subscribers already. Plus, it's not as if the cable company or telcos offering VOIP service have that much more control over the quality of their service either. They're still stuck with the same problems everyone else is in regard to Internet traffic."
Not really.
1) Many of those people are essentially providing "last mile" service and not much more (easier to control), probably one reason they're so much more expensive.
2) Many of the big cable companies and telcos have their own nationwide private networks they DO have control over.
The general idea is that table sugar (sucrose) tends to cause a more rapid blood glucose spike than an equivalent amount of fructose (All sugars and starches input into the body eventually get broken down into glucose, at varying rates. Because sucrose is essentially one fructose and one glucose molecule bound together, the only thing that gets converted to blood glucose faster than sucrose is glucose itself. With the exception of glucose tablets intended for diabetics experiencing a hypoglycemic episode, pure glucose in food intake is nearly unheard of, it's all sucrose or (in the case of fruits and "diabetic-friendly" foods) fructose.
This reduction in absorption rate is good for two reasons:
1) For Type I diabetics like myself, it makes the bloodsugar changes easier to manage. You don't spike up as fast, and you don't crash down as fast once the sugar stops hitting you.
2) For weight management, from what I've heard the bloodsugar spike will result in an given amount of fructose causing less weight gain than an equivalent amount of sucrose.
Now this article claims that fructose isn't all that hot, but as I see it, it's no new news.
1) Claims that fructose is 50% of table sugar. Duh, I knew that. It's the fact that the other 50% of the sucrose molecule is glucose that is the problem. (As compared to sweetening something with 100% fructose and 0% glucose).
2) I don't know the exact details of HFCS, but in general, diabetics are told that while things sweetened with fructose itself are good (as long as you count the calories, of course), HFCS should be considered to be as bad as sucrose itself in terms of blood sugar management. As I said, I don't know the details, but HFCS spikes your bloodsugar WAY faster than pure fructose. Of course, this could be because HFCS is usually found in heavily sweetened liquids, while pure fructose is more often used to provide mild sweetening in baked goods. (In general, anything liquid will spike your bloodsugar far faster than a solid food with equivalent amounts of calories and similar sweeteners, for example a serving of pineapple juice vs. a serving of dried pineapple with equivalent calories.)
3) Note that I've been constantly stating the relative merits of fructose compared to other sweeteners with equivalent calorie counts. In general, stuff that has table sugar or HFCS added has had a LOT of it added. With calorie counts as high as those found in regular sodas, it doesn't matter WHAT the exact absorption profile of the sweetener is, its calorie count alone is going to cause a giant spike in a diabetic's bloodsugar, and potential weight gain in anyone.
I don't know how many times a disc has become unreadable because the TOC was damaged. You can have all the parity data in the world, if the TOC is gone you're screwed. :(
If only there were a DVD format writable/readable with consumer-grade drives that had multiple redundant TOCs.
Pretty much FFX and FFX-II.
FFX-II wouldn't be so bad if it weren't so exceedingly cheesy. The gameplay actually isn't that bad, but the way the "Charlie's Angels" characters behave is SO annoying.
You bastard!
I resisted the (rather more expensive) Westinghouse 37" 1080p unit in favor of a Gateway 24" monitor back last December.
Now you're sorely tempting me to go for the (now $1300) 42" 1080p unit...
Oh my, you're an early adopter.
For me, it was PS2 at $120, FFXII at $50, and all of the other PS2 FF releeases for $10 each used.
Likewise, I definately will not be buying the PS3 until the PS4 comes out. As opposed to the Wii, which had an opportunity limited only by lack of availability for 6 months before losing the competition to a new DSLR camera and some glass for aforementioned camera. No more room left in the budget for gaming systems anymore...
Who needs to touch the DSP code?
The FCC is most worried about changing operating frequencies, which would most likely be #defines or tables in the source code.
Easier to read source code and change it than to open up a radio (warranty voided), figure out what circuit trace does what, and then figure out which jumper to clip.
Many WLAN cards load their firmware into RAM on initialization (and in fact these are the ones that have resulted in the most controversy - you never saw people ranting about WLAN firmware back when it was in the card's flash memory and didn't have to be uploaded to the card by the driver, it wasn't until WLAN card vendors started cost optimizing and having the cards load firmware into RAM on initialization.), and so can't even be bricked with a "bad flash". In short, it's a lot more likely you'll void your warranty and brick your radio trying to clip the jumper/figure out which one to clip than by twiddling around with the firmware trying to make it do stuff it shouldn't be doing.
Signed binaries would work, but they fundamentally go against the whole idea of open source.
What's the point of having the source to your WiFi card's firmware if any of your bugfixed builds won't run on your WiFi card because they aren't signed? See RMS's rants about "Tivoization". Unfortunately, as I see it, the only options for SDRs are either closed source drivers (which probably should still be cryptographically signed to avoid modification by clever hex editor users) or open-source "Tivoized" drivers for which only cryptographically signed builds will run on the target hardware.
Nope, the FUD machine isn't at it again, it's just that 90% of readers are failing to understand the kind of security the FCC is talking about here.
The FCC is worried about end users modifying radios to behave differently than how they are certified and type approved. The FCC does not want users to modify the behavior of a type approved device, but enabling end-user modification of software behavior is one of the fundamental premises of open source software. In this regard, open source software has (by definition) opposite design goals from what the FCC requires from a type-approved device.
No peer review needed to verify the type of security they're talking about.
Hook up spectrum analyzer.
Can user easily make device transmit out-of-band? (Yes/No)
If No, security is sufficiently verified as far as the FCC's purposes. Keep in mind that the FCC in the past has been fine with the sale of scanners for which defeating the cellular band reception lockout only required clipping a brightly colored jumper inside the radio - the FCC's standards as far as "Easy" vs. "Hard" are pretty low.
Unfortunately, open-source drivers make such modifications ridiculously easy, easier than even the FCC's very low standards as far as tamper-resistance is concerned. As far as they are concerned, for the type of security (anti-tamper/modification resistance), open source software provides *zero* security as the whole idea behind open source software centers around ease of modification. The only way to provide the sort of security the FCC is looking for with open source software would be with a TiVo-style antitamper mechanism that only allowed FCC-approved builds of the software to run on an SDR, but this fundamentally goes against the whole idea of open source.
The FCC has always required that at least SOME measures are taken to prevent such tampering.
For example, the cellular band reception lockout on most scanners can be defeated by clipping a jumper. It's not TOO hard to defeat, but the fact that such a barrier is there to prevent receiving that locked out band is good enough for the FCC.
You can think of "binary blob" radio control as being like hardware with a jumper that you need to open up the radio and clip. The lockout can still be defeated, but needs reasonable technical expertise.
Meanwhile, an open source driver with frequency/power control would be akin to putting a clearly labeled "Turn on to enable cellular band reception" switch on a handheld scanner.
If this is in regards to open-source Wi-Fi firmwares and FCC certification, the FCC has a completely different type of "security" and "hacker" in mind than what most people think of when they think of computer security and crackers.
The article (and summary, and most users) are assuming they are talking about data and computer security - preventing malicious users from spying on other users' data (classic WiFi example - WEP cracking), and from compromising a users' machine (Intel WiFi driver compromises.)
I'm fairly certain that the FCC is talking about a different kind of security - a device licensed by the FCC to transmit is only licensed to transmit on certain frequencies with certain modulation schemes, often with addition restrictions on power levels (some of which may be frequency-dependent.) Also there are sometimes restrictions on what frequencies a device may receive. For example, it was (and likely still is, although it's no longer relevant) illegal to sell radio receivers that covered the 800 MHz cellular bands. In terms of "security", the FCC is talking about preventing licensed transmitters from being modified to transmit out of their licensed band, in unlicensed modulation schemes, at unlicensed power levels, and sometimes receiving frequencies that no one is allowed to sell a receiver for in the United States.
The problem is that in this regard (preventing modifications to hardware functionality), Open Source is indeed fundamentally less secure - The whole idea behind Open Source is giving the user the freedom to modify their software and add functionality, and with modern software-defined radios, and modifying the software fundamentally modifies the behavior of the hardware. This freedom to modify the hardware is EXACTLY what the FCC does not want users to have. It is in theory possible to get tamper-resistance in a manner similar to what the FCC wants (see TiVo for an example of a vendor who has satisfied MAFIAA tamper-resistance requirements while using open-source software), but not without going against the fundamental spirit of Open Source. There's no point in the source being open for a piece of software if the hardware refuses to run it unless it's signed by the vendor (See TiVo again).
So far the open source community has yet to show a workable solution for open-source drivers that prevents the user from "unlocking" additional frequencies/modifications/power levels on existing software defined radios without a simple source change and a recompile. I'm honestly not sure if there is a workable solution to such a problem that doesn't involve anti-tamper via code signing, which as I said before kind of defeats the purpose of open source.
Blocking RF is easy if you don't need optical transparency - others have mentioned that many forms of insulation on the market already have metallized backing, for a theater one would just need a thin layer of metal foil in/on the walls. Paint with metallic particles or graphite powder mixed in would probably also work well.
The big news here appears to be that it's an optically transparent solution, not even tinted. (It's a known fact that automotive window tints are pretty good at blocking RF due to metallic content, which is why GPS receivers without external antennas work much better in some cars than others, although typically front windshields are never tinted, only rear/side windows are.)
I was going to comment that there are already quite inexpensive and effective window films that block RF quite well.
That said, it seems that the big difference between them and this "declassified" one is that it seems to be optically transparent? If you don't need full optical transparency but a darkened tint is acceptable (probably not only acceptable but desirable in many office environments), metallized window tints such as even the cheapo ones sold as aftermarket automotive films will block RF quite well.
For optically transparent - the same conductive coating used for LCD screens would probably block RF well, but that isn't a flexible "add on" film and might be prohibitively expensive for building windows, even when compared to this new stuff.
If you don't need optical transparency, blocking RF is reasonably easy, at least for a building.
Some BT clients attempt to do such a thing (crank up the upstream rate until latency starts increasing, then back off), although it doesn't work nearly as well as a proper QoS setup.
QoS - typically implemented not in the TCP stack but in intermediary routers that prioritize packets (important stuff goes out first and is less likely to be dropped if the connection is saturated, "bulk" data like BitTorrent goes out only if the send queue is empty at the router's WAN connection and is most likely to get dropped if a queue fills up), and in some cases artifically throttle the connection by dropping packets if the sender transmits beyond a set limit.
If you're looking for QoS in a home environment, the easiest solution is likely to replace your router with one capable of running DD-WRT. (This assumes you have a "consumer grade" router. If your gateway to the outside world is a normal PC running Linux, it's just a matter of setting up QoS on that box... Quite a few HOWTOs exist for this.)
"vanilla Linux" isn't a traditional TCP implementation for any reasonably recent kernel. In fact, if one assumes by "traditional TCP" the grandparent meant Reno, then that particular implementation is so obsolete you cannot even choose it as a congestion control algorithm for Linux any more. (Linux allows you to choose between 6-10 pluggable congestion control algorithms, the recent defaults of BIC and later CUBIC are both very nice ones.)
Not really that fancy - the 1990 4.3BSD release was codenamed "Reno" and its TCP stack was widely copied into many other OSes due to its permissive license. Even though I believe that release of BSD as a whole was considered "Reno" (in the same manner as "Feisty Fawn" for Ubuntu or "Zod" for Fedora), in general Reno is now used to refer to its TCP stack and/or TCP implementations that behave the same as Reno's stack. i.e. nearly every OS in the mid-1990s used "TCP Reno".
Reno is so obsolete that you can't even choose it as one of the many pluggable congestion control algorithms in recent Linux kernels.
It doesn't, unless your TCP implementation is from the stone age.
I love how fastsoft likes to compare themselves to Reno. 4.3BSD "Reno" was released in 1990, and the classic Reno implementation is LONG obsolete (and does indeed suck on a wide variety of connections).
I can see how it would be quite easy to achieve 10-20 times the throughput of Reno on a high-loss or high-latency connection, in fact a stock untuned Linux stack will do so in many situations. (For example, a few months ago I was doing TCP throughput tests dealing with some faulty hardware that liked to drop bursts of packets due to a shitty network driver. A machine running VxWorks 5.4, which is pretty much vanilla Reno, could only send 160 kilobytes/second over a 100Base-T LAN to that machine due to the packet loss making it throttle back. An untuned laptop with Linux 2.6.20 managed 1.7 megabytes/second over the same connection to the same destination.)
High latency connections were a major problem for TCP prior to RFC 1323 were a problem, but TCP stack authors have had 15 years to implement RFC 1323.
FastSoft's product may have been big news in the early 1990s, but if a company has to resort to making performance comparisons against the "Reno" TCP implementation, they're a snake oil salesman because Reno is such an obsolete and shitty TCP congestion control implementation.
Yeah, except that all gumstix products put Ethernet on a daughterboard using a Hirose connector that's a complete non-starter in a severe high-vibration environment.
This thing still uses an RJ45 connector which means it still can't be used in such a severe environment in its off-the-shelf form, but it's much easier to desolder a connector and solder a jumper cable to something like a MIL-C-38999 and pot the whole thing in epoxy than try to ruggedize those Hirose connectors (hopeless).
Just one example of something which has no compatible equivalent in Linux.
Note that I say *compatible*. My company uses Nortel Contivity gateways for their VPN system, and so if I want to VPN into work I need to be running Windows.
Contivity is (in theory) an IPSec implementation, but it's so badly mangled that it seems that no "real" IPSec implementations will talk to a Contivity VPN gateway. Non-Windows versions of the Contivity client are extra-cost addons from Nortel, and since my company (like 90% of those on the planet) is a primarily Windows shop on the desktop, if I want to VPN into work I need to be running Windows.
In theory, you don't need Windows any more. In the Real World, sadly, you do, since vendor lock-in is a bitch.
Why? Just because it uses a different medium (cable TV RF channels instead of the POTS voice band) doesn't mean it isn't still a modem.
MODEM originally meant MODulator/DEModulator (with the two Ds mashed into one). That's exactly what a cable modem is - a QAM modulator and a QAM demodulator. (OK, OK, it has a bit more than that, such as an Ethernet bridge in most cases.)
Regarding the last one (S3TC) - removing it WILL break a lot of games.
Unreal Tournament's need for the last one marks the beginning of ATI providing proprietary drivers and partial specs for their cards rather than full specs. There was a huge to-do about Unreal Tournament 2003 only working on NVidia cards in Linux back when UT2K3 was released. Epic's response was basically "we use this feature, it's implemented in all Windows drivers and the NVidia 3D drivers, we cannot work around the lack of this feature in the ATI drivers."
Shortly after, the first binary ATI drivers were released, with the main difference between them and the open-source drivers being S3TC. They have diverged since then, as clearly a number of other encumbered extensions have gone mainstream after looking at your list.