As an owner of a Qualcomm CDMA phone, I know that this isn't the case. Yes, it attempts to connect to the tower, but only if it can see a carrier signal that it can connect up with. It doesn't attempt anything (and, in fact, in the case of the current phones, it will will power itself down if it can't see the carrier signal from the tower in about 15 minutes.). Also, the connect is more of an ID handshake that's performed something like once a minute or so. When not being used, the phone will pop out a packet to let the system know the phone's exact cell location; the operational time with most Qualcomm phones in this mode is upwards of 48-72 hours with the lithium-ion batteries. Not quite like what you describe, now is it?
Could be what you think- could be something else. One thing to note, we're doing this inefficiently- through the traditional X pathways. DRI is bound to bring more speed to the picture...:->
It's not "3D" support that's an issue. It's accelerated support that's the issue here. Intel's not the only Linux platform, yes. But this stuff's so sophistiated that software only GL, even on the Alpha, will bog the game down to 10 or so FPS- it NEEDS acceleration support.
Realize that Macs HAVE Q3:Arena- but LinuxPPC does not. Why? It's not because of magic hand-tuned Intel assembly code as you imply- the machine language and framebuffer access is largely the same under both OSes. It's because accelerated GL support's not there under LinuxPPC. When we have the modular drivers ready for XFree86, etc. then Zoid is likely to make the ports to Alpha and PPC, but not before.
The lack of proper 3D accel support under Linux- there's currently no accel support for 3D on Alpha or PPC. Zoid said as much on one of his finger updates.
John's been working on something in his spare time that will remove that restriction along with others in the Open Source community- it's the G200/G400 GLX driver. I don't know if the ATI chips will work right in the Alpha motherboards (they should, but you never know until you try...), but if they do, the ATI driver which has recently started will also fit that bill.
As soon as Zoid has a stable version of acceleration support to work with, I'm pretty sure that Zoid will be right at it making an Alpha version of Q3 (which would rock!).
I'm sure that he'll have his own take on things, but here goes my take on it...
It's not done by a longshot (these beasts are complicated!)
Work is progressing tuning and stabilizing it as we speak.
For some things, on the G400, it is faster than the Windows version by a couple of FPS- under Quake II and q3test are two instances of a performance improvement over the Windows ICD version.
While it's faster under some things, it's slower under others or doesn't work right- this is still much the developer's playtoy right at the moment.
Work has not started on the DRI drivers as we're trying to get a relatively stable point release for the older technology before moving on to the DRI work (Not everyone is going to want to switch immediately to XFree4.0 and 2.4, which is what DRI is going to require...).
We've had them for about a month and a half now. The members working on it were delayed (myself, included- had my vacation in that timeframe, ah Scotland!) and we're getting seriously into it at this point. ATI's rep's been fairly helpful.
And I've had them for about a month and a half now. ATI just didn't make a big deal out of the release of info. We're beginning the work on the GLX support as I write this.
The Open GLX project is currently beginning on ATI RAGE drivers for the Pro and soon the 128. This is courtesy of them providing technical data about a month ago to us in the same manner Matrox gave it to us. We're working on a driver for the Pro (since everybody and his dog's got one!:-) and we'll follow up with the 128 once the Pro driver's relatively stable.
Makes many exercises in Origami look clumsy by comparison. Some of those folds he did are an amazing piece of art unto themselves- they're unbelievably beautiful. If you haven't followed up that link, http://www.sgi.com/grafica/huffman/ do so now- if you like geometric artforms, you're in for a treat.
I know, I used it as my personal machine OS for years (Tandy did this unusual thing- they coupled a _real_ OS with their little toy computers. OS-9 was available for something like $200 for the Color Computer and it was like night and day compared to MS-DOS of that day.). It literally unlocked the horsepower lurking in the dinky case of the CoCo.
It had a K & R C compliant C compiler, a Pascal compiler, and a block structured Basic that was something of a cross between C and Pascal on steroids. With the CoCo 3, it unleashed a memory space of up to 512k, allowing the user unprecedented levels of power (the 6809 instruction set was more space and speed efficient than the 8086 processor, making 512k seem more like 1-2M in comparison...).
OS-9 was the first modular, multitasking OS to grace the microcomputer scene. It made 6809's rock.
I'll be impressed if the demo were multiplatform.
on
QNX OS on a floppy
·
· Score: 1
We COULD achieve something like it- the GUI's smaller. I'd bet with MicroX or something razor thin we could pull off the same stunt with something like the LRP disk. While it's impressive, it's not THAT impressive. Price per seat is high for the X86 distribution of their product (I looked at this OS back when I was in college, nearly 15 years ago, and decided that something like $5-10K was too much for anyone...) and there is no access to source. While it may be news to some, it's kind of out of the reach of most people just the same.
It's not the latest one- which, I believe is 6.X if memory serves. I think NT's up to 3-4 at this point. Fact: Millenium, the consumer version of Windows 2000 is NOT based off of NT- it's a 95/98 derived "OS". Why do you suppose that is? Could it be because they can't get DirectX effectively on NT and keep it stable AND secure?
They originated from England (Just like the US, hence the term "English" or "imperial" units...) and you're not QUITE right- in the UK, distances appear to not be measured in kilometers, they appear to be measured in miles and speeds are measured in miles per hour. I know, I was just over there for a week and a half touring Scotland.
If the building's trashed, they're not going to stay up or be able to come back up after the storm roars through. This is a CYA, let's keep things as "up" as possible throughout the the situation.
Dave's been preaching this one for years now- I know, it was one of the things he was talking about at the first CDGC mini-conference in Austin. It's the thing he kept thinking about and going on about in his log files (not that I blame him- the consistency between accel cards is pathetic; how could any game designer really like this sort of BS?)
Of course, that could be why he's working at Transmeta...:-) We'll just have to wait and see, now won't we?:->
Never fails... I go and try to be "helpful" and I end up being "helpful" to one of the people that's working hard to make everyone else's day.:->
Guess it's a consequence of trying to be an advocate with this stuff- there's so many of us coders and engineers working to make a difference, it's sometimes hard to keep up with everyone.
Anyhow, I've little doubt that the SGI implementation of the GLX layer will be the one we're bolting the driver to- but that means we're likely to be going even faster than we are now (since some of the indirection we're laboring with goes away...).
Ignored? What's the GLX-dev team working on, then, chopped liver? G200 is far from forgotten and the G400's a rocker- under Linux, we're going to be faster than Windows with the G400.
It took about a half dozen people (some of the best and brightest out there) something like 4-6 months of work to achieve what we've done so far with the G200/G400 driver for GLX- and we're not done yet... (Note: I've been a lurker on the list for the development team- I have done no coding for the GLX project...YET.). When it officially ships as a GLX driver, I honestly think it will make Linux look good.
(As for the ATI 3D support... Well, be looking for it soon... How soon? Depends...:-)
A proper Faraday Cage will BLOCK the signal totally unless the HERF is exactly on of the outside of the cage. A fix for this maneuver is to have two cages nested like nesting dolls with a small distance apart. I would think that something suitably Tempest "hardened" would be immune to a HERF attack.
Slashdot Mirror
As an owner of a Qualcomm CDMA phone, I know that this isn't the case. Yes, it attempts to connect to the tower, but only if it can see a carrier signal that it can connect up with. It doesn't attempt anything (and, in fact, in the case of the current phones, it will will power itself down if it can't see the carrier signal from the tower in about 15 minutes.). Also, the connect is more of an ID handshake that's performed something like once a minute or so. When not being used, the phone will pop out a packet to let the system know the phone's exact cell location; the operational time with most Qualcomm phones in this mode is upwards of 48-72 hours with the lithium-ion batteries. Not quite like what you describe, now is it?
It's in work as we speak and is an improvement over the OSS system while maintaining compatibility with it for old apps.
If you're working admin on boxen, and you're not skimming Rootshell, Bugtraq, etc. you're just asking to be "owned".
Could be what you think- could be something else. One thing to note, we're doing this inefficiently- through the traditional X pathways. DRI is bound to bring more speed to the picture... :->
It's not "3D" support that's an issue. It's accelerated support that's the issue here. Intel's not the only Linux platform, yes. But this stuff's so sophistiated that software only GL, even on the Alpha, will bog the game down to 10 or so FPS- it NEEDS acceleration support.
Realize that Macs HAVE Q3:Arena- but LinuxPPC does not. Why? It's not because of magic hand-tuned Intel assembly code as you imply- the machine language and framebuffer access is largely the same under both OSes. It's because accelerated GL support's not there under LinuxPPC. When we have the modular drivers ready for XFree86, etc. then Zoid is likely to make the ports to Alpha and PPC, but not before.
The lack of proper 3D accel support under Linux- there's currently no accel support for 3D on Alpha or PPC. Zoid said as much on one of his finger updates.
John's been working on something in his spare time that will remove that restriction along with others in the Open Source community- it's the G200/G400 GLX driver. I don't know if the ATI chips will work right in the Alpha motherboards (they should, but you never know until you try...), but if they do, the ATI driver which has recently started will also fit that bill.
As soon as Zoid has a stable version of acceleration support to work with, I'm pretty sure that Zoid will be right at it making an Alpha version of Q3 (which would rock!).
I'm sure that he'll have his own take on things, but here goes my take on it...
It's not done by a longshot (these beasts are complicated!)
Work is progressing tuning and stabilizing it as we speak.
For some things, on the G400, it is faster than the Windows version by a couple of FPS- under Quake II and q3test are two instances of a performance improvement over the Windows ICD version.
While it's faster under some things, it's slower under others or doesn't work right- this is still much the developer's playtoy right at the moment.
Work has not started on the DRI drivers as we're trying to get a relatively stable point release for the older technology before moving on to the DRI work (Not everyone is going to want to switch immediately to XFree4.0 and 2.4, which is what DRI is going to require...).
We've had them for about a month and a half now. The members working on it were delayed (myself, included- had my vacation in that timeframe, ah Scotland!) and we're getting seriously into it at this point. ATI's rep's been fairly helpful.
Writing drivers isn't easy- it takes time.
And I've had them for about a month and a half now. ATI just didn't make a big deal out of the release of info. We're beginning the work on the GLX support as I write this.
The Open GLX project is currently beginning on ATI RAGE drivers for the Pro and soon the 128. This is courtesy of them providing technical data about a month ago to us in the same manner Matrox gave it to us. We're working on a driver for the Pro (since everybody and his dog's got one! :-) and we'll follow up with the 128 once the Pro driver's relatively stable.
Makes many exercises in Origami look clumsy by comparison. Some of those folds he did are an amazing piece of art unto themselves- they're unbelievably beautiful. If you haven't followed up that link, http://www.sgi.com/grafica/huffman/ do so now- if you like geometric artforms, you're in for a treat.
I know, I used it as my personal machine OS for years (Tandy did this unusual thing- they coupled a _real_ OS with their little toy computers. OS-9 was available for something like $200 for the Color Computer and it was like night and day compared to MS-DOS of that day.). It literally unlocked the horsepower lurking in the dinky case of the CoCo.
It had a K & R C compliant C compiler, a Pascal compiler, and a block structured Basic that was something of a cross between C and Pascal on steroids. With the CoCo 3, it unleashed a memory space of up to 512k, allowing the user unprecedented levels of power (the 6809 instruction set was more space and speed efficient than the 8086 processor, making 512k seem more like 1-2M in comparison...).
OS-9 was the first modular, multitasking OS to grace the microcomputer scene. It made 6809's rock.
We COULD achieve something like it- the GUI's smaller. I'd bet with MicroX or something razor thin we could pull off the same stunt with something like the LRP disk. While it's impressive, it's not THAT impressive. Price per seat is high for the X86 distribution of their product (I looked at this OS back when I was in college, nearly 15 years ago, and decided that something like $5-10K was too much for anyone...) and there is no access to source. While it may be news to some, it's kind of out of the reach of most people just the same.
It's not the latest one- which, I believe is 6.X if memory serves. I think NT's up to 3-4 at this point. Fact: Millenium, the consumer version of Windows 2000 is NOT based off of NT- it's a 95/98 derived "OS". Why do you suppose that is? Could it be because they can't get DirectX effectively on NT and keep it stable AND secure?
They originated from England (Just like the US, hence the term "English" or "imperial" units...) and you're not QUITE right- in the UK, distances appear to not be measured in kilometers, they appear to be measured in miles and speeds are measured in miles per hour. I know, I was just over there for a week and a half touring Scotland.
If the building's trashed, they're not going to stay up or be able to come back up after the storm roars through. This is a CYA, let's keep things as "up" as possible throughout the the situation.
It makes a LOT of sense, what they did...
Don't know if this is a leak...
:-) We'll just have to wait and see, now won't we? :->
Dave's been preaching this one for years now- I know, it was one of the things he was talking about at the first CDGC mini-conference in Austin. It's the thing he kept thinking about and going on about in his log files (not that I blame him- the consistency between accel cards is pathetic; how could any game designer really like this sort of BS?)
Of course, that could be why he's working at Transmeta...
Never fails... I go and try to be "helpful" and I end up being "helpful" to one of the people that's working hard to make everyone else's day. :->
Guess it's a consequence of trying to be an advocate with this stuff- there's so many of us coders and engineers working to make a difference, it's sometimes hard to keep up with everyone.
Anyhow, I've little doubt that the SGI implementation of the GLX layer will be the one we're bolting the driver to- but that means we're likely to be going even faster than we are now (since some of the indirection we're laboring with goes away...).
Ignored? What's the GLX-dev team working on, then, chopped liver? G200 is far from forgotten and the G400's a rocker- under Linux, we're going to be faster than Windows with the G400.
3D accel support's not as easy as it looks.
:-)
It took about a half dozen people (some of the best and brightest out there) something like 4-6 months of work to achieve what we've done so far with the G200/G400 driver for GLX- and we're not done yet... (Note: I've been a lurker on the list for the development team- I have done no coding for the GLX project...YET.). When it officially ships as a GLX driver, I honestly think it will make Linux look good.
(As for the ATI 3D support... Well, be looking for it soon... How soon? Depends...
Who knows, though- it might get there.
After all, the patents expired on it and GPG uses it right now (besides, I've heard that it's better than RSA anyhow...)
A proper Faraday Cage will BLOCK the signal totally unless the HERF is exactly on of the outside of the cage. A fix for this maneuver is to have two cages nested like nesting dolls with a small distance apart. I would think that something suitably Tempest "hardened" would be immune to a HERF attack.