DRI drivers for the Matrox- not even beta yet?
on
Linux Sin Demo
·
· Score: 2
It was my understanding that anything other than Voodoo support was still a "developer's release"- that could be wrong (and any of the VA Linux team working on it right now are more than welcome to correct me!:-). Developer's releases aren't guaranteed to do anything- they might sit there and do nada and they might just melt down your entire system.
As for Shogo, try with the +GLZReverse 1 option in the advanced settings- I had the same problems with it on my G400 and RagePRO machines until I plugged that in.
By the way...
The reason why the drivers all seem to work for Q3 and qforge is that all of the G400 code was written with Q3 as a reference app (I know, I bought a copy with that in mind when I was working up to doing RagePRO and other chipsets under Utah-GLX!) so it's going to work cleanly under these. Other applications stress the OpenGL layer differently and might find untested/incomplete pathways in the drivers. It's why I've been trying to work with the companies that are working on getting games out- to see where the holes are in Utah... Right now, I'm snowed under with work, personal obligations (performances in a play, etc...), and a raftload of bugs that Loki handed me on a platter recently.
WWine's slow compared to other options...
on
Linux Sin Demo
·
· Score: 2
Like making an OpenGL rendering layer to a DirectX engine. After all, that's what Hyperion did with the Monolith LithTech engine. The Shogo:MAD demo plays as well as the Windows version and at the same speed. Running under the WINE layer would make it slow compared to a Windows game (like it would be under the WINE emulation app...) and since games are all about speed and interactivity- that's going to go over like a lead balloon.
Went to your color management page, looked at the potential patent issues info referenced and have some comments that are germane to the discussion that you've started here. (And we ought to use the/. effect for good purposes in this situation...:-)
The Schriber patent (US4500919) seems extremely overbroad- may or may not be valid and seems to describe something slightly different than what we're looking for in a calibration system upon a detailed reading of what is exactly claimed in the patent. May apply, may not. Expires sometime in 2005 in any case.
The Walowit patent (US4941038) should probably be overturned- I've some nagging prior art suspicions on this one as it simply describes a system that does RGB to CMY conversion, adjusting for gamut differences in the original image and the target environ. (Now, where do I remember seeing code for that... Perhaps this one should be submitted for a bounty.)
The Arazi patent (US5212546) looks to be obvious (verging on common sense) and I'd think that it'd be covered by prior art anyhow (Wasn't Kodak or Fuji doing this sort of thing years ago, prior to the patent grant?)
(By the way, you might want to change the URLs to refer to 'http://www.delphion.com/' instead of 'http://www.patents.ibm.com/' as IBM's basically given the services to the Delphion IP Network...)
Uhh, migration does cause problems, but when done properly, the help desk won't take the blunt of it.
Problem is that it never gets done "properly" even when it is. Ask any major company's IT helpdesk. Even when there's weeks of warning, they still make calls about the issue.
I think the best bet is going to be doing an OpenGL tunnel for the time being. Trying to emulate something as complex as a video card (and then coming up with GDI drivers for Windows to use for that emulation) is going to be a bear to do and most likely be evil slow.
...for people to quit saying this or that is "desperately" needed. Why do I say this? Look at your comment. It implies that there's nothing in the way of RAD tools for Linux.
There are already RAD tools out for Linux.
JBuilder.
Forte.
VisualAge Java.
Visual TCL.
BigForth/Minos.
Phoenix Basic.
XBasic.
(And many others out there- I just remember these off the top of my head.)
Yes, Delphi/C++ Builder would be MOST welcome as an addition to the Linux community's available options. One, that if Delphi came available, I'd buy a copy- I'm a Delphi fan, after all...
Does Linux "desperately" need RAD tools? No. It HAS them already.
One of the complaints that he made was that there was no "friendly" IDEs for UNIX (which is patently WRONG)- if you go about what you're suggesting, you're going to do the same thing.
With Linux (and to a lesser extent, UNIX) you can have your cake and eat it too. The friendly IDE, compiler, debugger (which, I seriously doubt is free from MS in the case of Windows code- and without it, better not be doing COM/DCOM stuff, you'll need that debugger if you run into problems!), the bounds checking tools, etc. for FREE.
"if not more unfriendly (this may change when the KDE IDE is finished)"
Ok, define "friendly".
Is it an IDE? Linux has several mature ones- SourceNavigator and Code Crusader come immediately to mind (Not to mention that SourceNavigator's cross-platform and will work under Windows...). There's several less mature ones that are immediately usable (KDE's one included in that list...) If you're using the criterion, "works exactly like Visual Studio" as "friendly" you're in for a rude awakening- most of that environ is NOT easy or friendly past the simplest of applications.
"text-based debugging sucks ass."
Uh, let's see how many non-text based debuggers for UNIX/Linux I can name right off the top of my head...
KDebug, Code Medic, Source Insight, and DDD.
That's four of them. All "GUI", source level debuggers- with DDD being able to display graphs of data areas.
They're a function of the antenna size and RF power they're irradiated with...
The originators of this technology, Amtech, formerly a division of Intermec, now a division of TransCore, developed this technology during the Regan years to monitor the body temp, etc. of cattle to pick out sick animals before they went to the slaughterhouse.
One of the more common applications of this is the tags on each and every rail car in the US and Europe. These have a unique ID that identifies the rail car as it passes a zone antenna at speeds up to 160 MPH. Another one is the TollTags that many of the toll bridges, toll roads, etc. have taken to using worldwide. These are designed to be read at up to 40' away at speeds in excess of 100 MPH- through the window of your car.
If they want to, this same chip could be designed around a system that does what the seemingly paranoid claims about what could be done with the technology.
Concentrating energy like that only works with light because of it's small wavelength. At these frequencies, your wavelength is measured in centimeters- you're not going to get a smaller spot than the wavelength without a LOT of trouble. Since a couple of milliwats per centimeter isn't enough to overwhelm the chip or burn anything, you're back to square one.
My former employer had a similar chip- I was designing enterprise class systems around the use of it.
The name of Intermec's product line using it is Intellitag 500[tm]. Little chip not much bigger than a glass head pin in diameter. Put it on stickers, etc. for inventory control, parking access/billing, etc. What makes Motorola's BiStatix chip special is that it doesn't need a foil antenna- conductive inks will do for most close-range applications.
Jamming them isn't going to be easy. They work off of RF backscatter- they don't transmit anything. They impress a modulation on a reflected carrier. They're basically a very fancy RF mirror and reflect ANY RF in the range that they're tuned for.
Overloading them isn't going to be very easy. The power levels are in the ball park of 500-1000 watts of RF power. Most of these units operate in the 900MHz, 2GHz, or somewhere around 5GHz in Europe. You'll cook yourself with these power levels.
Oh, and the original trade-press releases from Motorola were around the January/February timeframe. I believe that EE Times originally covered this sometime around June, if memory serves.
The RF power that would nose these chips over will cook you and anything you blast with it. That would be something on the order of 1kW or more of RF power somewhere around the 2GHz area.
As for jamming, it's possible, but really only at close range- this stuff works by way of RF backscatter. Think of it being a sophisticated mirror of RF energy that encodes the carrier with information. The noise level's going to have to be up there to jam these at the ranges they're designed to operate at.
Voodoo5 support proper is still an "unreleased" product from what I understand about the DRI work so far (If I'm mistaken, would someone a little more associated with the DRI project correct...). I'd be surprised (pleasantly, mind) that Mandrake included Utah-GLX, which is rather stable with the RagePRO and is moderately stable with the G200/G400 (I'm working on that- the texture stuff's toast right now...). Suffice it to say, if it's not at least an official beta, don't expect them to include it by "default".
Yes, they've had Linux on the shelves for some time- problem is that they've been pushing the previous version of the distributions they were selling (incl. Mandrake) since they started. To beat everyone else with the latest version of any distribution is something of a coup for Linux and a change of pace for Wal-Mart.
This doesn't mean that Crusoe is a sorry product- that it sucks.
It all depends on the design. If you've got a really efficient simple CPU that runs really fast, you in theory gain over the CISC CPUs because while you're a little slower by emulating them, you're consuming much less power than they are. If it looks like a 700MHz CPU when I'm running 900-1000MHz, consume only a watt or two while doing that (note: At full tilt, the PIII consumes something on the order of 20 or so...) then it's more efficient- no matter HOW you slice it. Will it make a dent in a laptop? Sort of. You don't eat 20 or so watts in CPU power another couple for the fan/heatsink combo. You end up being able to get away with more batteries if you choose (the heatsink's no longer weighing you down...) or smaller ones (slightly- you're able to kill roughly a fourth of the power consumption by doing things this way.). However, having said this, you've got the HD, floppy, CD, sound card amplifier, and display all eating power as well, with the HD and display being the consumers of the remainder of the lion's share of power use by a laptop. If they get OLEDs out soon, that will cut the power consumption much the same way as Transmeta's attempting to do with the Crusoe.
As for me being scared of knocking them? I'm not. But, in the same breath, I'm also not pathalogically attacking them either. I'm adopting a wait-and-see attitude about the Crusoe line.
Extreme low-g conditions allow for the cheap manufacture of substances and devices that would be nigh impossible in the gravity well of the earth. Some processes could be managed on the much lower well of the moon, but some things will be done at one of the Lagrange points where it's essentially null-g conditions. The moon is a vast resource of metals that are actually somewhat rare on the Earth and are actually useful. The moon has enough Helium-3 trapped in the regolith to power the earth for hundreds of years.
Sounds like the conditions of the New World expressed in modern times with modern needs.
I seem to have missed where they mention which states are in process with this BS. We can't battle this crap if we don't know who needs to act now on it.
Because I've been seeing it for years and it's not been THAT much of a problem- and certainly less than the problems of the differing versions of Windows present to a developer or user.
"Something is proprietary if someone owns it and has legal authority to tell you what you may and may not do with it."
That also meets the criteria of closed. Closed means that you can't extend it, change it, etc. If they have control over what you can/can't do with a protocol, API, etc. they can change it out from underneath you, etc. It's CLOSED.
Slashdot Mirror
It was my understanding that anything other than Voodoo support was still a "developer's release"- that could be wrong (and any of the VA Linux team working on it right now are more than welcome to correct me! :-). Developer's releases aren't guaranteed to do anything- they might sit there and do nada and they might just melt down your entire system.
As for Shogo, try with the +GLZReverse 1 option in the advanced settings- I had the same problems with it on my G400 and RagePRO machines until I plugged that in.
By the way...
The reason why the drivers all seem to work for Q3 and qforge is that all of the G400 code was written with Q3 as a reference app (I know, I bought a copy with that in mind when I was working up to doing RagePRO and other chipsets under Utah-GLX!) so it's going to work cleanly under these. Other applications stress the OpenGL layer differently and might find untested/incomplete pathways in the drivers. It's why I've been trying to work with the companies that are working on getting games out- to see where the holes are in Utah... Right now, I'm snowed under with work, personal obligations (performances in a play, etc...), and a raftload of bugs that Loki handed me on a platter recently.
Like making an OpenGL rendering layer to a DirectX engine. After all, that's what Hyperion did with the Monolith LithTech engine. The Shogo:MAD demo plays as well as the Windows version and at the same speed. Running under the WINE layer would make it slow compared to a Windows game (like it would be under the WINE emulation app...) and since games are all about speed and interactivity- that's going to go over like a lead balloon.
Went to your color management page, looked at the potential patent issues info referenced and have some comments that are germane to the discussion that you've started here. (And we ought to use the /. effect for good purposes in this situation... :-)
The Schriber patent (US4500919) seems extremely overbroad- may or may not be valid and seems to describe something slightly different than what we're looking for in a calibration system upon a detailed reading of what is exactly claimed in the patent. May apply, may not. Expires sometime in 2005 in any case.
The Walowit patent (US4941038) should probably be overturned- I've some nagging prior art suspicions on this one as it simply describes a system that does RGB to CMY conversion, adjusting for gamut differences in the original image and the target environ. (Now, where do I remember seeing code for that... Perhaps this one should be submitted for a bounty.)
The Arazi patent (US5212546) looks to be obvious (verging on common sense) and I'd think that it'd be covered by prior art anyhow (Wasn't Kodak or Fuji doing this sort of thing years ago, prior to the patent grant?)
(By the way, you might want to change the URLs to refer to 'http://www.delphion.com/' instead of 'http://www.patents.ibm.com/' as IBM's basically given the services to the Delphion IP Network...)
This is the same people backing HelixCode, CodeWeavers, MetroLink, others.
Uhh, migration does cause problems, but when done properly, the help desk won't take the blunt of it.
Problem is that it never gets done "properly" even when it is. Ask any major company's IT helpdesk. Even when there's weeks of warning, they still make calls about the issue.
I think the best bet is going to be doing an OpenGL tunnel for the time being. Trying to emulate something as complex as a video card (and then coming up with GDI drivers for Windows to use for that emulation) is going to be a bear to do and most likely be evil slow.
...for people to quit saying this or that is "desperately" needed. Why do I say this? Look at your comment. It implies that there's nothing in the way of RAD tools for Linux.
There are already RAD tools out for Linux.
JBuilder.
Forte.
VisualAge Java.
Visual TCL.
BigForth/Minos.
Phoenix Basic.
XBasic.
(And many others out there- I just remember these off the top of my head.)
Yes, Delphi/C++ Builder would be MOST welcome as an addition to the Linux community's available options. One, that if Delphi came available, I'd buy a copy- I'm a Delphi fan, after all...
Does Linux "desperately" need RAD tools? No. It HAS them already.
One of the complaints that he made was that there was no "friendly" IDEs for UNIX (which is patently WRONG)- if you go about what you're suggesting, you're going to do the same thing.
With Linux (and to a lesser extent, UNIX) you can have your cake and eat it too. The friendly IDE, compiler, debugger (which, I seriously doubt is free from MS in the case of Windows code- and without it, better not be doing COM/DCOM stuff, you'll need that debugger if you run into problems!), the bounds checking tools, etc. for FREE.
"if not more unfriendly (this may change when the KDE IDE is finished)"
Ok, define "friendly".
Is it an IDE? Linux has several mature ones- SourceNavigator and Code Crusader come immediately to mind (Not to mention that SourceNavigator's cross-platform and will work under Windows...). There's several less mature ones that are immediately usable (KDE's one included in that list...) If you're using the criterion, "works exactly like Visual Studio" as "friendly" you're in for a rude awakening- most of that environ is NOT easy or friendly past the simplest of applications.
"text-based debugging sucks ass."
Uh, let's see how many non-text based debuggers for UNIX/Linux I can name right off the top of my head...
KDebug, Code Medic, Source Insight, and DDD.
That's four of them. All "GUI", source level debuggers- with DDD being able to display graphs of data areas.
They're a function of the antenna size and RF power they're irradiated with...
The originators of this technology, Amtech, formerly a division of Intermec, now a division of TransCore, developed this technology during the Regan years to monitor the body temp, etc. of cattle to pick out sick animals before they went to the slaughterhouse.
One of the more common applications of this is the tags on each and every rail car in the US and Europe. These have a unique ID that identifies the rail car as it passes a zone antenna at speeds up to 160 MPH. Another one is the TollTags that many of the toll bridges, toll roads, etc. have taken to using worldwide. These are designed to be read at up to 40' away at speeds in excess of 100 MPH- through the window of your car.
If they want to, this same chip could be designed around a system that does what the seemingly paranoid claims about what could be done with the technology.
You apparently don't understand a lot about RF...
Concentrating energy like that only works with light because of it's small wavelength. At these frequencies, your wavelength is measured in centimeters- you're not going to get a smaller spot than the wavelength without a LOT of trouble. Since a couple of milliwats per centimeter isn't enough to overwhelm the chip or burn anything, you're back to square one.
That's how Intermec was doing most of the systems. There's notable exceptions (something VERY much like the TollTag systems in use...)
That was the range that Intermec's IntelliTag 500 series tags were getting- and they're almost identical in ability.
My former employer had a similar chip- I was designing enterprise class systems around the use of it.
The name of Intermec's product line using it is Intellitag 500[tm]. Little chip not much bigger than a glass head pin in diameter. Put it on stickers, etc. for inventory control, parking access/billing, etc. What makes Motorola's BiStatix chip special is that it doesn't need a foil antenna- conductive inks will do for most close-range applications.
Jamming them isn't going to be easy. They work off of RF backscatter- they don't transmit anything. They impress a modulation on a reflected carrier. They're basically a very fancy RF mirror and reflect ANY RF in the range that they're tuned for.
Overloading them isn't going to be very easy. The power levels are in the ball park of 500-1000 watts of RF power. Most of these units operate in the 900MHz, 2GHz, or somewhere around 5GHz in Europe. You'll cook yourself with these power levels.
Oh, and the original trade-press releases from Motorola were around the January/February timeframe. I believe that EE Times originally covered this sometime around June, if memory serves.
But it requires so much RF power that it'd be dangerous to burn them out.
The RF power that would nose these chips over will cook you and anything you blast with it. That would be something on the order of 1kW or more of RF power somewhere around the 2GHz area.
As for jamming, it's possible, but really only at close range- this stuff works by way of RF backscatter. Think of it being a sophisticated mirror of RF energy that encodes the carrier with information. The noise level's going to have to be up there to jam these at the ranges they're designed to operate at.
"Default" == "What is supported"
Voodoo5 support proper is still an "unreleased" product from what I understand about the DRI work so far (If I'm mistaken, would someone a little more associated with the DRI project correct...). I'd be surprised (pleasantly, mind) that Mandrake included Utah-GLX, which is rather stable with the RagePRO and is moderately stable with the G200/G400 (I'm working on that- the texture stuff's toast right now...). Suffice it to say, if it's not at least an official beta, don't expect them to include it by "default".
Walked in, needing to buy some spray paint for a house project I was going to do. Spotted the box and snagged it.
Yes, they've had Linux on the shelves for some time- problem is that they've been pushing the previous version of the distributions they were selling (incl. Mandrake) since they started. To beat everyone else with the latest version of any distribution is something of a coup for Linux and a change of pace for Wal-Mart.
Yes, transistors draw current.
Yes, processing uses transistors.
This doesn't mean that Crusoe is a sorry product- that it sucks.
It all depends on the design. If you've got a really efficient simple CPU that runs really fast, you in theory gain over the CISC CPUs because while you're a little slower by emulating them, you're consuming much less power than they are. If it looks like a 700MHz CPU when I'm running 900-1000MHz, consume only a watt or two while doing that (note: At full tilt, the PIII consumes something on the order of 20 or so...) then it's more efficient- no matter HOW you slice it. Will it make a dent in a laptop? Sort of. You don't eat 20 or so watts in CPU power another couple for the fan/heatsink combo. You end up being able to get away with more batteries if you choose (the heatsink's no longer weighing you down...) or smaller ones (slightly- you're able to kill roughly a fourth of the power consumption by doing things this way.). However, having said this, you've got the HD, floppy, CD, sound card amplifier, and display all eating power as well, with the HD and display being the consumers of the remainder of the lion's share of power use by a laptop. If they get OLEDs out soon, that will cut the power consumption much the same way as Transmeta's attempting to do with the Crusoe.
As for me being scared of knocking them? I'm not. But, in the same breath, I'm also not pathalogically attacking them either. I'm adopting a wait-and-see attitude about the Crusoe line.
Oh, and it's "electricity", not "electronicty".
Extreme low-g conditions allow for the cheap manufacture of substances and devices that would be nigh impossible in the gravity well of the earth. Some processes could be managed on the much lower well of the moon, but some things will be done at one of the Lagrange points where it's essentially null-g conditions. The moon is a vast resource of metals that are actually somewhat rare on the Earth and are actually useful. The moon has enough Helium-3 trapped in the regolith to power the earth for hundreds of years.
Sounds like the conditions of the New World expressed in modern times with modern needs.
I seem to have missed where they mention which states are in process with this BS. We can't battle this crap if we don't know who needs to act now on it.
Because I've been seeing it for years and it's not been THAT much of a problem- and certainly less than the problems of the differing versions of Windows present to a developer or user.
There's also Win32s, the failed first attempt to trick, er, decieve, er, convince people to make Windows NT applications that ran under Win 3.1/3.11
"Something is proprietary if someone owns it and has legal authority to tell you what you may and may not do with it."
That also meets the criteria of closed. Closed means that you can't extend it, change it, etc. If they have control over what you can/can't do with a protocol, API, etc. they can change it out from underneath you, etc. It's CLOSED.