It's a lot harder to get a switching transistor (for digital circuitry) to operate at high speeds than for a transistor to show gain as an RF amplifier.
26 GHz is incredible for switching circuitry, but it's nothing if you're talking RF signals nowadays. I'm guessing that this was an RF amp given the comments of other transistors being faster in the article summary.
There is a comment about "clocked at" which implies digital switching, but that could easily be a clueless journalist that has no idea of the difference between transistors in clocked digital circuitry and transistors as RF amplifiers.
I'm not sure what the laws are, but there are plenty of technical barriers to messing with the modem.
The radio portion of these devices is NOT like modern WLAN cards or Winmodems where the host O/S controls most functionality - it's like the classic modems/printers where there is a clearly defined interface between the host and the device, and the device has its own firmware/regulatory functions.
In the case of GSM modems, the GSM module itself has a lot of anti-tamper functionality in it, and can only be accessed by predefined interfaces. There's not much hacking you can do.
Note: Some devices do allow you to update the firmware for the modem section, but while many devices allow for unsigned host O/Ses, nearly all devices still require signed radio firmware. See for example the HTC Kaiser (aka TyTn II aka AT&T Tilt) - Removing the host O/S locks were easy and happened quickly, but getting modified radio ROMs (for the purposes of removing SIMlocks) were a whole different story.
For a little bit I avoided Python because of the whitespace sensitivity.
At some point I gave it a try, at which point I was already using emacs. It took 5 minutes to get used to the whitespace sensitivity since emacs took care of indentation for me.
Coca-Cola? Pepsi? They've probably sold a billion+ of a variety of their individual product lines (i.e. over 1 billion bottles of Mountain Dew AND over 1 billion bottles of Pepsi Cola), as opposed to Logitech who sold a billion from a category of products that encompasses multiple products.
Same for Budweiser - I wouldn't be surprised if they've hit 10 billion units or more.
Look at it from a different perspective - 100 people want one file of size A megabytes, and you start with one person seeding.
With classic unicast distribution, 100*A needs to be sent by that one person.
With P2P, much less needs to be sent, but still 100*A needs to traverse the network. It may or may not traverse fewer hops - it may in fact traverse more.
With multicast, A megabytes leave the single origin, and that gets multipled by routers as needed in the most efficient manner. In the end, the least amount of data needs to be sent in order for everyone to achieve completion. Yes, in the short term the network load will probably not be reduced much, but the time that high load occurs for will be far less before everyone has the file and there is little need for lots of bandwidth.
There is little to no support for multicast by last-mile ISPs.
It would be nice - ISPs keep bitching about how P2P is eating their bandwidth, but they don't bother implementing multicast which would make P2P use a fraction of the bandwidth it currently does.
Admittedly, in addition to lack of support, IPv4 multicast is pretty "meh" - there aren't many multicast addresses available and I have yet to see a good way of choosing/assigning them on a global network.
The DP1 is NOT by any means a 3CCD camera. It uses a single special sensor that can resolve each color at each photo site (but with some limitations, a lot of postprocessing needs to be done).
3CCD cameras use a set of dichroic prisms to split colors and three separate CCD sensors, one for each colors. It's a completely different approach than the Foveon X3 sensor design, and so far one that has only been used in video cameras and not stills, probably because video cameras typically have lower resolution and that makes it much easier to align the three CCDs to within a good percentage of a single pixel. Also, to my knowledge, the Foveon is not used in any dedicated video cameras.
90% of the benefits of an improved TCP congestion control algorithm come from improvements on the sender side - very few improvements need to be done on a receive side, and most OSes do have those few improvements (window scaling, etc, SACK is one of the few extensions that it is beneficial for a receiver to have that isn't widespread).
Thus, for example, a connection between a Linux webserver that has CUBIC as its congestion control algorithm and a Windows XP client with NewReno gets 90%+ of the benefits of CUBIC.
Also, the historical workaround for congestion control algorithm flaws has been to use multiple parallel TCP streams - guess what BitTorrent has always done? Multiple TCP connections, in this case to multiple servers (multiple parallel to one is beneficial for servers with "meh" TCP implementations.)
Moving BitTorrent to UDP for congestion control purposes can be done without negative effect, but is extremely dangerous. Moving it for the purposes of adding transport protocol header authentication (i.e. "is this a legit RST flag from the other endpoint") is a much better reason to do this, but it still has the risks of a broken congestion control mechanism that interferes with other users - not necessarily to the point of "internet meltdown" but still "bad".
Not quite. Even if implemented EXACTLY the same as a typical TCP congestion control algorithm, a UDP-based approach will have a significant advantage in the current environment if it has one feature - control flag authentication.
In TCP, there is no way to authenticate whether an RST packet came from the other endpoint or from a MITM attacker. This vulnerability has been abused by a number of ISPs (notably Comcast).
With UDP, it is possible to add authentication of headers (including protocol control flags) to determine if they are legitimate or from a MITM attacker.
If done right it can be a Very Good Thing with few negative side effects, but most likely a lot of clients won't do it right...
While UDP itself fundamentally has no congestion control, this doesn't mean that the transport protocol layered over it by the application (Almost all uses of UDP have an additional application-based transport protocol layered over them, such as RTP or Sun RPC) doesn't also have congestion control.
Was this meant to bypass congestion control (probably not, TCP congestion control is fine and traffic shaping is usually fine if done right), or was it done in response to Sandvining which has NOTHING to do with congestion control and everything to do with the ability of an attacker to shut down a TCP connection with a Man-In-The-Middle attack (fake RSTs)?
I'm assuming it's a defense against MITM attacks, in which case it doesn't mean the end of the Internet as long as the new congestion control approach is sensible. Unfortunately we can likely expect lots of bugs and misbehaving applications so this could be bad.
The article title is very misleading. The title claims that a good replacement for lead has been found, but then the summary says it is a replacement compound for one specific lead compound.
It doesn't seem to address the issue of lead-free solder, which would have been great for my company. We produce mission-critical components that have to endure very harsh environments - as others have said, not a good place for RoHS parts. As "classic" lead-containing parts get harder to find it would be nice if someone could identify a suitable lead-free replacement. Currently the situation is that the chance of lead in one of our products (aircraft avionics) poisoning someone is FAR less than the chance of a component failure due to lead-free techniques causing multiple deaths.
"If I had a no-name brand capture card from some fly-by-night taiwanese company, this might make sense, but there is NO excuse for Linux not supporting hardware from one of the two big players in the industry." There is plenty of excuse. The biggest players in the industry tend to be the ones that don't give a damn about Linux and hence refuse to provide documentation. ATI TV cards are notorious in this regard - The AMD purchase/merger seems to be helping in this regard, but ATI cards (not just TV cards but graphics in general) had a very long track record of poor Linux support due to lack of manufacturer cooperation.
Maybe you should've given your business to a vendor that actually cares about Linux and has even given sample hardware to select Linux driver/application developers for driver development and testing. Hauppauge is a good place to start - they don't officially support Linux but are VERY cooperative as far as giving driver developers documentation, support, and even in some cases early access to new hardware (such as with the HD-PVR 1212).
Have you ever heard of Internet2? There's quite a large number of schools that are involved with I2, and I'm 90% certain that I2 requires IPv6 capability.
I think it's more likely due to the fact that Apple has typically had an advantage in educational institutions. Most residential ISPs still don't provide IPv6 support, but I would not be surprised if nearly every college and university in the U.S. supported IPv6 to the end user.
Doesn't matter if your router supports IPv6 if your ISP does not.
The Blackberry probably can be configured with a different ringtone.
My Windows Mobile phone (AT&T Tilt) was configured for a long time with a ringer that was a semi-high-pitched piercing series of beeps - you could hear it from across the building at work if I forgot to put it on vibrate.
I updated the ROM and the new default ringtone is some pleasing Microsoft melody, I really need to change it back...
I only shopped at CC when I needed something short notice and it wasn't too much of a penalty (small-ticket items usually, stuff for which online purchases would get nailed with shipping fees).
I hope the Vestal, NY CC is one that gets bought out by BB. I'd much prefer a BB there than a CC (I'm in one of the few areas that has one store but not the other - Ithaca has BB but no CC, Vestal has CC but no BB.) CC got a reasonable amount of business from me just because of location.
I'm not surprised they're bankrupt though - they tried to make too much profit per item which utterly killed sales volume. For example, a Pentax K20D was listed for a long time as $1900 - MSRP was $1300 and street was $1150 then! Eventualy the camera went on "sale" for MSRP - you "saved" $600 and paid $200+ more than anyone else (street price from reputable dealers like Amazon and B&H had dropped below $1100 by then.)
"We're just glad you didn't elect the 3rd incarnation of the fucking antichrist."
Even though I voted Obama and am VERY glad he won, I think that's overly harsh on McCain. Every impression I got was that he was more intelligent and sane than the Texas Village Idiot.
The problem is that McCain and Palin ran on a platform that catered to the same uneducated religious nutjobs that Bush appealed to. That platform backfired on them, when their "This is Real America" small-town speeches pissed off the (according to them) educated "Fake Americans" living in suburbs and cities. I may live in a small town now, but I grew up in the suburbs and many of their speeches implied that I was not a "Real American", which I found quite insulting.
Maybe it's technically possible to do this without a/boot partition, but/boot makes it a LOT easier. I'm not even sure if it's possible without a small/boot partition
Slashdot Mirror
It's a lot harder to get a switching transistor (for digital circuitry) to operate at high speeds than for a transistor to show gain as an RF amplifier.
26 GHz is incredible for switching circuitry, but it's nothing if you're talking RF signals nowadays. I'm guessing that this was an RF amp given the comments of other transistors being faster in the article summary.
There is a comment about "clocked at" which implies digital switching, but that could easily be a clueless journalist that has no idea of the difference between transistors in clocked digital circuitry and transistors as RF amplifiers.
Oops: I looked again and it seems like the G1 actually does 2100 also, for some reason I thought it was a 1700-only device.
T-Mo isn't much better, I'm fairly certain they do UMTS in the 1700 MHz band, not the 2100 MHz band.
So the G1's 3G won't work in most of the rest of the world either. I do believe a small handful of countries do use the 1700 MHz band but not many.
I'm not sure what the laws are, but there are plenty of technical barriers to messing with the modem.
The radio portion of these devices is NOT like modern WLAN cards or Winmodems where the host O/S controls most functionality - it's like the classic modems/printers where there is a clearly defined interface between the host and the device, and the device has its own firmware/regulatory functions.
In the case of GSM modems, the GSM module itself has a lot of anti-tamper functionality in it, and can only be accessed by predefined interfaces. There's not much hacking you can do.
Note: Some devices do allow you to update the firmware for the modem section, but while many devices allow for unsigned host O/Ses, nearly all devices still require signed radio firmware. See for example the HTC Kaiser (aka TyTn II aka AT&T Tilt) - Removing the host O/S locks were easy and happened quickly, but getting modified radio ROMs (for the purposes of removing SIMlocks) were a whole different story.
For a little bit I avoided Python because of the whitespace sensitivity.
At some point I gave it a try, at which point I was already using emacs. It took 5 minutes to get used to the whitespace sensitivity since emacs took care of indentation for me.
Coca-Cola? Pepsi? They've probably sold a billion+ of a variety of their individual product lines (i.e. over 1 billion bottles of Mountain Dew AND over 1 billion bottles of Pepsi Cola), as opposed to Logitech who sold a billion from a category of products that encompasses multiple products.
Same for Budweiser - I wouldn't be surprised if they've hit 10 billion units or more.
Look at it from a different perspective - 100 people want one file of size A megabytes, and you start with one person seeding.
With classic unicast distribution, 100*A needs to be sent by that one person.
With P2P, much less needs to be sent, but still 100*A needs to traverse the network. It may or may not traverse fewer hops - it may in fact traverse more.
With multicast, A megabytes leave the single origin, and that gets multipled by routers as needed in the most efficient manner. In the end, the least amount of data needs to be sent in order for everyone to achieve completion. Yes, in the short term the network load will probably not be reduced much, but the time that high load occurs for will be far less before everyone has the file and there is little need for lots of bandwidth.
There is little to no support for multicast by last-mile ISPs.
It would be nice - ISPs keep bitching about how P2P is eating their bandwidth, but they don't bother implementing multicast which would make P2P use a fraction of the bandwidth it currently does.
Admittedly, in addition to lack of support, IPv4 multicast is pretty "meh" - there aren't many multicast addresses available and I have yet to see a good way of choosing/assigning them on a global network.
The DP1 is NOT by any means a 3CCD camera. It uses a single special sensor that can resolve each color at each photo site (but with some limitations, a lot of postprocessing needs to be done).
3CCD cameras use a set of dichroic prisms to split colors and three separate CCD sensors, one for each colors. It's a completely different approach than the Foveon X3 sensor design, and so far one that has only been used in video cameras and not stills, probably because video cameras typically have lower resolution and that makes it much easier to align the three CCDs to within a good percentage of a single pixel. Also, to my knowledge, the Foveon is not used in any dedicated video cameras.
You forgot one:
Transport protocol header authentication, preventing Man-In-The-Middle connection denial-of-service attacks, aka Sandvining, aka Bogus RSTs
90% of the benefits of an improved TCP congestion control algorithm come from improvements on the sender side - very few improvements need to be done on a receive side, and most OSes do have those few improvements (window scaling, etc, SACK is one of the few extensions that it is beneficial for a receiver to have that isn't widespread).
Thus, for example, a connection between a Linux webserver that has CUBIC as its congestion control algorithm and a Windows XP client with NewReno gets 90%+ of the benefits of CUBIC.
Also, the historical workaround for congestion control algorithm flaws has been to use multiple parallel TCP streams - guess what BitTorrent has always done? Multiple TCP connections, in this case to multiple servers (multiple parallel to one is beneficial for servers with "meh" TCP implementations.)
Moving BitTorrent to UDP for congestion control purposes can be done without negative effect, but is extremely dangerous. Moving it for the purposes of adding transport protocol header authentication (i.e. "is this a legit RST flag from the other endpoint") is a much better reason to do this, but it still has the risks of a broken congestion control mechanism that interferes with other users - not necessarily to the point of "internet meltdown" but still "bad".
I think he means 3CCD dedicated still camera, not a 3CCD video camera that can do stills.
"Still Alive" by Jonathan Coulton?
Not quite. Even if implemented EXACTLY the same as a typical TCP congestion control algorithm, a UDP-based approach will have a significant advantage in the current environment if it has one feature - control flag authentication.
In TCP, there is no way to authenticate whether an RST packet came from the other endpoint or from a MITM attacker. This vulnerability has been abused by a number of ISPs (notably Comcast).
With UDP, it is possible to add authentication of headers (including protocol control flags) to determine if they are legitimate or from a MITM attacker.
If done right it can be a Very Good Thing with few negative side effects, but most likely a lot of clients won't do it right...
While UDP itself fundamentally has no congestion control, this doesn't mean that the transport protocol layered over it by the application (Almost all uses of UDP have an additional application-based transport protocol layered over them, such as RTP or Sun RPC) doesn't also have congestion control.
Was this meant to bypass congestion control (probably not, TCP congestion control is fine and traffic shaping is usually fine if done right), or was it done in response to Sandvining which has NOTHING to do with congestion control and everything to do with the ability of an attacker to shut down a TCP connection with a Man-In-The-Middle attack (fake RSTs)?
I'm assuming it's a defense against MITM attacks, in which case it doesn't mean the end of the Internet as long as the new congestion control approach is sensible. Unfortunately we can likely expect lots of bugs and misbehaving applications so this could be bad.
"For example lead-free solders that work well in a thermal cycling environment tend to not perform as well under shock conditions."
What happens when you have both extensive thermal cycling AND vibration?
The article title is very misleading. The title claims that a good replacement for lead has been found, but then the summary says it is a replacement compound for one specific lead compound.
It doesn't seem to address the issue of lead-free solder, which would have been great for my company. We produce mission-critical components that have to endure very harsh environments - as others have said, not a good place for RoHS parts. As "classic" lead-containing parts get harder to find it would be nice if someone could identify a suitable lead-free replacement. Currently the situation is that the chance of lead in one of our products (aircraft avionics) poisoning someone is FAR less than the chance of a component failure due to lead-free techniques causing multiple deaths.
Yup, as the other poster said, bismuth salicylate. Kind of implied by your parent post in "is a component of certain medicines".
"If I had a no-name brand capture card from some fly-by-night taiwanese company, this might make sense, but there is NO excuse for Linux not supporting hardware from one of the two big players in the industry."
There is plenty of excuse. The biggest players in the industry tend to be the ones that don't give a damn about Linux and hence refuse to provide documentation. ATI TV cards are notorious in this regard - The AMD purchase/merger seems to be helping in this regard, but ATI cards (not just TV cards but graphics in general) had a very long track record of poor Linux support due to lack of manufacturer cooperation.
Maybe you should've given your business to a vendor that actually cares about Linux and has even given sample hardware to select Linux driver/application developers for driver development and testing. Hauppauge is a good place to start - they don't officially support Linux but are VERY cooperative as far as giving driver developers documentation, support, and even in some cases early access to new hardware (such as with the HD-PVR 1212).
Have you ever heard of Internet2? There's quite a large number of schools that are involved with I2, and I'm 90% certain that I2 requires IPv6 capability.
I think it's more likely due to the fact that Apple has typically had an advantage in educational institutions. Most residential ISPs still don't provide IPv6 support, but I would not be surprised if nearly every college and university in the U.S. supported IPv6 to the end user.
Doesn't matter if your router supports IPv6 if your ISP does not.
The Blackberry probably can be configured with a different ringtone.
My Windows Mobile phone (AT&T Tilt) was configured for a long time with a ringer that was a semi-high-pitched piercing series of beeps - you could hear it from across the building at work if I forgot to put it on vibrate.
I updated the ROM and the new default ringtone is some pleasing Microsoft melody, I really need to change it back...
I only shopped at CC when I needed something short notice and it wasn't too much of a penalty (small-ticket items usually, stuff for which online purchases would get nailed with shipping fees).
I hope the Vestal, NY CC is one that gets bought out by BB. I'd much prefer a BB there than a CC (I'm in one of the few areas that has one store but not the other - Ithaca has BB but no CC, Vestal has CC but no BB.) CC got a reasonable amount of business from me just because of location.
I'm not surprised they're bankrupt though - they tried to make too much profit per item which utterly killed sales volume. For example, a Pentax K20D was listed for a long time as $1900 - MSRP was $1300 and street was $1150 then! Eventualy the camera went on "sale" for MSRP - you "saved" $600 and paid $200+ more than anyone else (street price from reputable dealers like Amazon and B&H had dropped below $1100 by then.)
"We're just glad you didn't elect the 3rd incarnation of the fucking antichrist."
Even though I voted Obama and am VERY glad he won, I think that's overly harsh on McCain. Every impression I got was that he was more intelligent and sane than the Texas Village Idiot.
The problem is that McCain and Palin ran on a platform that catered to the same uneducated religious nutjobs that Bush appealed to. That platform backfired on them, when their "This is Real America" small-town speeches pissed off the (according to them) educated "Fake Americans" living in suburbs and cities. I may live in a small town now, but I grew up in the suburbs and many of their speeches implied that I was not a "Real American", which I found quite insulting.
Signed,
"Fake American" (aka educated ex-suburban-resident)
Maybe it's technically possible to do this without a /boot partition, but /boot makes it a LOT easier. I'm not even sure if it's possible without a small /boot partition