A gent by the name of R. G. LeTourneau (The same one that founded LeTourneau University) invented this idea ages ago for very, very large earth moving machines that they made. They still make some of these and everybody uses the same basic design nowadays on these monsters.
"I don't know about anyone else, but my IE has been crashing quite a lot since I installed Macromedia Flash 7. This isn't obviously Microsofts fault, but they might be able to tell Macromedia what crashes are occuring and how they were caused."
It's not obviously Macromedia's fault either. Microsoft might have changed the behavior of a crucial DLL/OCX or introduced a bug in an SP or a new version of IE that Flash 7 steps on. All you do know is that there's a problem that was induced by installing Flash 7 at this point. And, if you think MS is going to honestly care at all to inform Macromedia about the crashes, you're mistaken.
"What have me a bit worried right now, is that MS will include this patch in the service pack."
The problem is that hotfixes, etc. should NEVER break other things. If you're breaking other, unrelated things with an update, it's a good sign that your code's just too complex and desperately needs serious refactoring and/or redesign.
Of course, I'll insert the obligatory, "I don't generally worry about updates breaking unrelated things on my system...", comment. But then, Linux updates tend to not be so disruptive and when they are, it's usually spelled out in detail what will break and why, etc.
...published on the Internet by way of the alleged inclusions into Linux. It's no longer a Trade Secret and prior precedents say as much. I have trouble believing Blake Stowell's clams and I would have even more trouble with the court letting that one go down.
Transmission conditions would be fine- but then you're talking about a transmitter with a lot of power compared to the BPL system. The transmitter might even jam the BPL system if it were working.
What they're worried about is reception. Over long distances, while the signals are detectable, they're really pretty weak comparatively speaking. The stuff that the BPL systems are generating are in the ballpark of the signal levels that might be detectable, so the signals from the BPL will be most likely the ones you detect.
So, you might be in a FEMA office, say like in Denton, Texas, where the power is on- but the emergency is in Corpus Christi or Brownsville. Power's out THERE because of a disaster- but the locally running BPL system's causing merry hob with your reception of the signal from that location.
Afterall, the HAM operators have been saying that the test markets for the current set of BPL services were generating RF trash that could interfere with various longwave services since they resided in the same spectrum. Since this is all Subpart 15 stuff, they're probably going to get told to lower the emissions to practically nothing or don't do it.
It's not really a transmitter as such. It's a backscatter device and as such, it's not transmitting- it's reflecting.
What do I mean by this? Picture a mirror. Now, picture putting an LCD immediately in front of the mirror. Operating the LCD impinges a modulation on the light, conveying information back to the light source.
In the above example, the mirror did not transmit any energy to convey information back to the carrier power source (the light...). It merely reflected it back.
With an EZ Pass style tag, it's the same sort of thing, only with RF power instead of light. Of course, the tag pulls some energy to power itself up and drive the modulation circuitry, but it's not actually transmitting in the traditional sense of the concept.
For more info, I suggest reading the following links:
More RF power causes it's own set of issues. The reason why the licenses have been granted for the RFID systems in question is that they won't interfere with other services. Raising the power exceeds the limits set by the licenses and causes interference with other services. You might find someone in the FCC willing to bend the rules for you and increase the allowed power for the reader units, but that's not likely. Secondly, raising the RF power doesn't do much for you with these tags. There is the very real fact that pushing more RF energy out doesn't 100% correlate to more range. Most of the RFID devices out there are maxed out for range because of the frequencies chosen, antenna sizes on the tags, etc. Raising the RF power with these passive or battery assisted tags as are used with the EZ Pass systems will merely shorten the response time for the tag to turn on and broadcast it's ID info.
And, before you say I don't know what I'm talking about, I might want to point you to my resume and point out that one of my previous jobs was with Amtech who is now a division of TransCore. Amtech makes most of the tags used by these systems and I developed one of the EZ-Pass type systems in use for parking and ground transportation management at DFW International Airport.
I don't know why your post was moderated up as Informative. It's not very informative at all.
"E-Z Pass boxes are designed to work through large metalic objects, probably because they have to be able to do so to operate."
The E-Z Pass card happens to be just yet another RF ID tag. Place the tag behind a metal shield and the thing won't work. Put it in a metalized anti-static bag (Instant Faraday Cage...) and it worn't work. So, how would the EZ Pass readers see a tag through large metallic objects, hm?
"Those trucks are perfect for jamming a standard RFID signal, but E-X Pass still operates."
How are they perfect? EZ Pass works by placing a tag in the windshield or front bumper of the vehicle in question. Better yet, how would they "jam" the signal. Jamming implies emitting interfering RF energy- the trucks might shield the signal coming from the reader if the tag's not in the proper place (windshield or bumper), but that's not the same thing and isn't really applicable in this context.
"Hiding the box will most likley put it closer to the ground where the speeding sensors are, not farther."
Okay, what "speeding sensors"? It doesn't take special sensors or rocket science to determine that someone was speeding by computing the time it should take from one reader point to another and then determining how long the tag took (by way of being on the vehicle) to go from one read point to another. Shorter times implies speeding at or above a given average speed at some point on the trip.
Their case against IBM gets dropped, but IBM's and Red Hat's goes forward with the extra little tidbit that they can't prove that they weren't in violation with the Lanham Act now (If they come up with that later on, then they directly defied an ORDER to produce the same for the discovery phase of their own suit... Not a pretty picture for SCO at that point...).
...what they're claiming is happening isn't or shouldn't be. They're claiming it is a SYN flood attack. Linux has SYN flood protection built in and has had this support since the middle-to-late 2.0.X kernels. Their website would be accessable, but slow to respond if it were an attempted SYN flood.
I believe that a page request attack would saturate the links so you couldn't hit the FTP server, as would Fraggles and other DoS attacks. Most of them rely on the link being saturated or the IP stack being so overwhelmed by bandwidth that it just quits responding or the packets never get to the machine.
If the FTP server is accessable, it's a low-bandwidth attack, and unless there's something new it's not a DoS- and if it's something new, the idiots at SCO can't tell their *sses from a hole in the ground because it's not a SYN flood.
...and I'm not doing anything work project related with my computer. (It's a PAIN holding down essentially three jobs- two startups(One based in the UK...) and a day job...)
I'm just annoyed that they don't provide a downloadable ISO for the AMD64 distribution so I can fire and forget the thing as I've only got so much HD space and part of it is dedicated to XP and a 32-bit distribution (for testing purposes of the games...) so I can only keep ONE dedicated and ONE floating install of AMD64 Linux. Right now the dedicated one is Mandrake since I've got to move forward with my dev efforts and I've found most of the sharp edges in that distribution. Doing the boot ISO and FTP is okay if you're not having to work with re-installing on a regular basis.
I can't add anything to that other than "thanks" for the PS you put. We're doing things slowly- perhaps too slowly for some people's tastes, but we're trying to avoid some of the crucial business mis-steps Scott did with Loki. Our only complaint is the "Loki Effect", where there's been some doors closed to us, short to medium term, and there's been more resistance to our getting ahold of titles.
We're going to be having a spring/summer lineup that we think people will like a lot. Not quite enough to satisfy everyone's desires, but if these titles sell decently enough, we've got at least a half dozen more that will hit the shelves by next Christmas- but only if the titles that we're about to roll out sell well.
It all takes time to build up. Something Loki never quite managed to come to grips with.
...too bad it doesn't consider the fact of the extreme probability of the Linux distribution that they're running on having SYN-cookies turned on, meaning that the site would still be reachable except in the condition of the pipe being flooded- it'd just be sluggish in response at that point.
Since their own distribution ships with SYN-cookies turned on (most everyone does to avoid getting zapped by one of the oldest DoS exploits in the book...) unless they recompiled the kernel and turned that feature off for whatever insane reasoning they might have had then either their pipe is saturated or they're lying.
Since adjacent sites are up and accessable, either they recompiled or they're lying. Given their past track record for whoppers, what do YOU think the probability of the latter of the two is?
A thorough analysis that has been gone over on GrokLaw has shown that it's NOT likely to be a DoS attack.
They (SCO) claim it's a SYNflood of all things- that should get everybody's bullsh*t alarms going off in the first place. If it IS a SYNflood, then they're awfully damn incompetent technology-wise since Cisco routers have a solution for that that can be turned on and their webserver is a Linux box with SYN-cookies turned on (they'd have to deliberately turn it off and recompile the kernel on that machine since most distributions, themselves included, have it turned on in the kernel...).
Secondly, if it were a DDoS, like they claim, why is their mail and FTP servers responding (note: they claimed they were having problems with those being accessable too- not the case.)
Please people, don't be repeating SCO's BS without doing a check to verify what they're saying- they can not be trusted to say a single truthful thing at this point.
Well, some of us ARE working on that very thing. (In all honesty, there's another distribution that I know of that we're working with, but since it's not public knowlege, I can't point people that way- YET.)
Shortly, with the efforts of companies like ourselves, SCI and hopefully others, that is going to change.
(Oh, and on a different note, HOW did you get the ability to have links without the [foo.com] after them?:-)
Linux is really largely ready for the "Desktop" now. It's all you claim and more- so WHY hasn't there been anything other than a slowly growing desktop market?
Because of a lack of some "critical" apps and driver support for devices that keep many people from forsaking Windows forevermore. The drivers can only be helped, I'm afraid by education and a much larger clamor for the same than we already have. The apps is a much easier to fix thing, though- and what's one of the LEADING app classes that comes up each time as the subject gets broached?
GAMES
It's not the only answer, nor is it one of the largest ones. Though for home use, it's one of the top ten all the time.
64-bit games and other applications which can be as much as 40% faster over the 32-bit code (of which, execution on an Athlon64, is already VERY fast...) can win people over.
Just because YOU don't see it as part of the problem to be solved, doesn't mean it isn't one all the same.
"Included with the T6000 is an ATI Radeon 9600 graphics card with 128MB of on-board memory, a CD burner, a DVD-ROM drive, an 8-in-1 memory card reader, seven USB (universal serial bus) ports and two IEEE 1394 or FireWire ports."
Uh, seems like a deviation in their typical fare- at least on the surface.
It sounds more like they scored a volume deal with one of the bargain makers of mobos (say ECS or similar) and the other suppliers. The only thing that MIGHT be noisy would be the HD and possibly the DVD-ROM if they went on the cheap on those. The rest of the parts are high-end or high-mid-end.
Considering that it'll set you back anywhere from about $1600-2000 to obtain an Athlon64 machine with 512Mb of DDR memory, etc. it's not such a bad deal if it weren't for the fact that they load the poor damn thing down with all kinds of crap software.
...with technology the way it is these days, you can extract the crap out of the second and end up with a barrel of wine again. May not be fine wine, but it'd be very drinkable (Well, as well as the wine was in the first place- we can't do THAT miracle yet...:-) again once you got past the thoughts of the crap being in it.
In the case of an Athlon 64 eMachine Craputer, you take any Linux distribution disc set you care to use (Mandrake 9.2 AMD64, or SuSE 9.0 AMD64, preferably...) and burn the SOB down and purify the box of all Craputer aspects- so long as the box happened to have an NVidia or mid-to-low end ATI Radeon since there's 64-bit support for those (If you use a 32-bit distribution, all Radeons are supported in one way or another...).
The alternative choice would be to take a copy of XP Pro and do the same thing, but it does cost quite a bit more to do things that way and might not be profitable for someone to do things that way.
eMachines with the software they're bundled with are Craputers. The hardware itself is relatively decent. Especially on the high-end (and an Athlon64 definitely qualifies there...).
Now, I happen to have gotten one on the cheap (Not tellin'- I'd lose my toy that way...:-) and they're nicely fast with Mandrake 9.2 RC1 (Though there's definitely some sharp edges present through no fault of their own.) at least.
No telling how SuSE runs- they've not provided a download version of 9.0 that I can see yet and budget precludes either my becoming a developer partner ($1500...got to be kidding me...) or an off-the-shelf copy ($70-ish, including shipping, etc. I can't afford the $70 nor can I wait for the thing to arrive mailorder...). So that'll have to wait for a later day (When they either figure out it's in their best interests to SUPPORT me without the $1500 BS or I get the cash for the desktop version...)
Slashdot Mirror
This is, by and far, NOT a new idea.
A gent by the name of R. G. LeTourneau (The same one that founded LeTourneau University) invented this idea ages ago for very, very large earth moving machines that they made. They still make some of these and everybody uses the same basic design nowadays on these monsters.
It's not obviously Macromedia's fault either. Microsoft might have changed the behavior of a crucial DLL/OCX or introduced a bug in an SP or a new version of IE that Flash 7 steps on. All you do know is that there's a problem that was induced by installing Flash 7 at this point. And, if you think MS is going to honestly care at all to inform Macromedia about the crashes, you're mistaken.
They say MS is including a "REAL" firewall in the SP2 release.
What odds does anyone want to lay that ZDN won't be printing a retraction about that?
The problem is that hotfixes, etc. should NEVER break other things. If you're breaking other, unrelated things with an update, it's a good sign that your code's just too complex and desperately needs serious refactoring and/or redesign.
Of course, I'll insert the obligatory, "I don't generally worry about updates breaking unrelated things on my system...", comment. But then, Linux updates tend to not be so disruptive and when they are, it's usually spelled out in detail what will break and why, etc.
The register store on an AMD64 machine doubles. That's about a 20% or more speed boost right there.
There's more than that to be sure, but do not compare 64-bit experiences other than with the same architechtures- each one's going to be different.
X isn't needed for operation if you're doing server duty.
Mandrake RC1 went on FINE on my Athlon64 machine- no hassles whatsoever.
SuSE is installing as I type this- no glitches past having to do this over an FTP session so far...
A lot of standard packages seem to compile and run just FINE.
NVidia support is there and works just fine for 64-bit apps.
There's no AMD64 version of Windows64 currently available for end-user OR developer use.
The only spinning that I see is the spinning you're doing right at the moment.
...published on the Internet by way of the alleged inclusions into Linux. It's no longer a Trade Secret and prior precedents say as much. I have trouble believing Blake Stowell's clams and I would have even more trouble with the court letting that one go down.
Transmission conditions would be fine- but then you're talking about a transmitter with a lot of power compared to the BPL system. The transmitter might even jam the BPL system if it were working.
What they're worried about is reception. Over long distances, while the signals are detectable, they're really pretty weak comparatively speaking. The stuff that the BPL systems are generating are in the ballpark of the signal levels that might be detectable, so the signals from the BPL will be most likely the ones you detect.
So, you might be in a FEMA office, say like in Denton, Texas, where the power is on- but the emergency is in Corpus Christi or Brownsville. Power's out THERE because of a disaster- but the locally running BPL system's causing merry hob with your reception of the signal from that location.
Afterall, the HAM operators have been saying that the test markets for the current set of BPL services were generating RF trash that could interfere with various longwave services since they resided in the same spectrum. Since this is all Subpart 15 stuff, they're probably going to get told to lower the emissions to practically nothing or don't do it.
It's not really a transmitter as such. It's a backscatter device and as such, it's not transmitting- it's reflecting.
m l 6 80b.pdf f
What do I mean by this? Picture a mirror. Now, picture putting an LCD immediately in front of the mirror. Operating the LCD impinges a modulation on the light, conveying information back to the light source.
In the above example, the mirror did not transmit any energy to convey information back to the carrier power source (the light...). It merely reflected it back.
With an EZ Pass style tag, it's the same sort of thing, only with RF power instead of light. Of course, the tag pulls some energy to power itself up and drive the modulation circuitry, but it's not actually transmitting in the traditional sense of the concept.
For more info, I suggest reading the following links:
http://www.rfid-handbook.de/rfid/types_of_rfid.ht
http://www.microchip.com/download/appnote/rfid/00
http://legwww.epfl.ch/research/pdf/back_scattf.pd
More RF power causes it's own set of issues. The reason why the licenses have been granted for the RFID systems in question is that they won't interfere with other services. Raising the power exceeds the limits set by the licenses and causes interference with other services. You might find someone in the FCC willing to bend the rules for you and increase the allowed power for the reader units, but that's not likely. Secondly, raising the RF power doesn't do much for you with these tags. There is the very real fact that pushing more RF energy out doesn't 100% correlate to more range. Most of the RFID devices out there are maxed out for range because of the frequencies chosen, antenna sizes on the tags, etc. Raising the RF power with these passive or battery assisted tags as are used with the EZ Pass systems will merely shorten the response time for the tag to turn on and broadcast it's ID info.
And, before you say I don't know what I'm talking about, I might want to point you to my resume and point out that one of my previous jobs was with Amtech who is now a division of TransCore. Amtech makes most of the tags used by these systems and I developed one of the EZ-Pass type systems in use for parking and ground transportation management at DFW International Airport.
The E-Z Pass card happens to be just yet another RF ID tag. Place the tag behind a metal shield and the thing won't work. Put it in a metalized anti-static bag (Instant Faraday Cage...) and it worn't work. So, how would the EZ Pass readers see a tag through large metallic objects, hm?
How are they perfect? EZ Pass works by placing a tag in the windshield or front bumper of the vehicle in question. Better yet, how would they "jam" the signal. Jamming implies emitting interfering RF energy- the trucks might shield the signal coming from the reader if the tag's not in the proper place (windshield or bumper), but that's not the same thing and isn't really applicable in this context.
Okay, what "speeding sensors"? It doesn't take special sensors or rocket science to determine that someone was speeding by computing the time it should take from one reader point to another and then determining how long the tag took (by way of being on the vehicle) to go from one read point to another. Shorter times implies speeding at or above a given average speed at some point on the trip.
...no evidence, NO CASE.
Their case against IBM gets dropped, but IBM's and Red Hat's goes forward with the extra little tidbit that they can't prove that they weren't in violation with the Lanham Act now (If they come up with that later on, then they directly defied an ORDER to produce the same for the discovery phase of their own suit... Not a pretty picture for SCO at that point...).
...what they're claiming is happening isn't or shouldn't be. They're claiming it is a SYN flood attack. Linux has SYN flood protection built in and has had this support since the middle-to-late 2.0.X kernels. Their website would be accessable, but slow to respond if it were an attempted SYN flood.
I believe that a page request attack would saturate the links so you couldn't hit the FTP server, as would Fraggles and other DoS attacks. Most of them rely on the link being saturated or the IP stack being so overwhelmed by bandwidth that it just quits responding or the packets never get to the machine.
If the FTP server is accessable, it's a low-bandwidth attack, and unless there's something new it's not a DoS- and if it's something new, the idiots at SCO can't tell their *sses from a hole in the ground because it's not a SYN flood.
Hmph... A frigging 28.8k modem could SYN flood a machine.
You don't NEED to distribute the attack, per se, it'd be done that way to completely cover their tracks...
...and I'm not doing anything work project related with my computer. (It's a PAIN holding down essentially three jobs- two startups(One based in the UK...) and a day job...)
I'm just annoyed that they don't provide a downloadable ISO for the AMD64 distribution so I can fire and forget the thing as I've only got so much HD space and part of it is dedicated to XP and a 32-bit distribution (for testing purposes of the games...) so I can only keep ONE dedicated and ONE floating install of AMD64 Linux. Right now the dedicated one is Mandrake since I've got to move forward with my dev efforts and I've found most of the sharp edges in that distribution. Doing the boot ISO and FTP is okay if you're not having to work with re-installing on a regular basis.
Er...um...
I can't add anything to that other than "thanks" for the PS you put. We're doing things slowly- perhaps too slowly for some people's tastes, but we're trying to avoid some of the crucial business mis-steps Scott did with Loki. Our only complaint is the "Loki Effect", where there's been some doors closed to us, short to medium term, and there's been more resistance to our getting ahold of titles.
We're going to be having a spring/summer lineup that we think people will like a lot. Not quite enough to satisfy everyone's desires, but if these titles sell decently enough, we've got at least a half dozen more that will hit the shelves by next Christmas- but only if the titles that we're about to roll out sell well.
It all takes time to build up. Something Loki never quite managed to come to grips with.
...too bad it doesn't consider the fact of the extreme probability of the Linux distribution that they're running on having SYN-cookies turned on, meaning that the site would still be reachable except in the condition of the pipe being flooded- it'd just be sluggish in response at that point.
Since their own distribution ships with SYN-cookies turned on (most everyone does to avoid getting zapped by one of the oldest DoS exploits in the book...) unless they recompiled the kernel and turned that feature off for whatever insane reasoning they might have had then either their pipe is saturated or they're lying.
Since adjacent sites are up and accessable, either they recompiled or they're lying. Given their past track record for whoppers, what do YOU think the probability of the latter of the two is?
A thorough analysis that has been gone over on GrokLaw has shown that it's NOT likely to be a DoS attack.
They (SCO) claim it's a SYNflood of all things- that should get everybody's bullsh*t alarms going off in the first place. If it IS a SYNflood, then they're awfully damn incompetent technology-wise since Cisco routers have a solution for that that can be turned on and their webserver is a Linux box with SYN-cookies turned on (they'd have to deliberately turn it off and recompile the kernel on that machine since most distributions, themselves included, have it turned on in the kernel...).
Secondly, if it were a DDoS, like they claim, why is their mail and FTP servers responding (note: they claimed they were having problems with those being accessable too- not the case.)
Please people, don't be repeating SCO's BS without doing a check to verify what they're saying- they can not be trusted to say a single truthful thing at this point.
Well, some of us ARE working on that very thing. (In all honesty, there's another distribution that I know of that we're working with, but since it's not public knowlege, I can't point people that way- YET.)
:-)
Shortly, with the efforts of companies like ourselves, SCI and hopefully others, that is going to change.
(Oh, and on a different note, HOW did you get the ability to have links without the [foo.com] after them?
Linux is really largely ready for the "Desktop" now. It's all you claim and more- so WHY hasn't there been anything other than a slowly growing desktop market?
Because of a lack of some "critical" apps and driver support for devices that keep many people from forsaking Windows forevermore. The drivers can only be helped, I'm afraid by education and a much larger clamor for the same than we already have. The apps is a much easier to fix thing, though- and what's one of the LEADING app classes that comes up each time as the subject gets broached?
GAMES
It's not the only answer, nor is it one of the largest ones. Though for home use, it's one of the top ten all the time.
64-bit games and other applications which can be as much as 40% faster over the 32-bit code (of which, execution on an Athlon64, is already VERY fast...) can win people over.
Just because YOU don't see it as part of the problem to be solved, doesn't mean it isn't one all the same.
Oh, I missed a detail- 128Mb of DDR. Geez. XP will be slowish with that low an amount of memory. Sweet spot's more like 256Mb with XP.
Still, that only shaves about $40 or so off the retail value of the parts in the box.
Uh, seems like a deviation in their typical fare- at least on the surface.
It sounds more like they scored a volume deal with one of the bargain makers of mobos (say ECS or similar) and the other suppliers. The only thing that MIGHT be noisy would be the HD and possibly the DVD-ROM if they went on the cheap on those. The rest of the parts are high-end or high-mid-end.
Considering that it'll set you back anywhere from about $1600-2000 to obtain an Athlon64 machine with 512Mb of DDR memory, etc. it's not such a bad deal if it weren't for the fact that they load the poor damn thing down with all kinds of crap software.
...with technology the way it is these days, you can extract the crap out of the second and end up with a barrel of wine again. May not be fine wine, but it'd be very drinkable (Well, as well as the wine was in the first place- we can't do THAT miracle yet... :-) again once you got past the thoughts of the crap being in it.
In the case of an Athlon 64 eMachine Craputer, you take any Linux distribution disc set you care to use (Mandrake 9.2 AMD64, or SuSE 9.0 AMD64, preferably...) and burn the SOB down and purify the box of all Craputer aspects- so long as the box happened to have an NVidia or mid-to-low end ATI Radeon since there's 64-bit support for those (If you use a 32-bit distribution, all Radeons are supported in one way or another...).
The alternative choice would be to take a copy of XP Pro and do the same thing, but it does cost quite a bit more to do things that way and might not be profitable for someone to do things that way.
eMachines with the software they're bundled with are Craputers. The hardware itself is relatively decent. Especially on the high-end (and an Athlon64 definitely qualifies there...).
:-) and they're nicely fast with Mandrake 9.2 RC1 (Though there's definitely some sharp edges present through no fault of their own.) at least.
Now, I happen to have gotten one on the cheap (Not tellin'- I'd lose my toy that way...
No telling how SuSE runs- they've not provided a download version of 9.0 that I can see yet and budget precludes either my becoming a developer partner ($1500...got to be kidding me...) or an off-the-shelf copy ($70-ish, including shipping, etc. I can't afford the $70 nor can I wait for the thing to arrive mailorder...). So that'll have to wait for a later day (When they either figure out it's in their best interests to SUPPORT me without the $1500 BS or I get the cash for the desktop version...)