Mobile service providers are playing the only game they can to get more money off the same data. It's crap and it really pisses me off. They charge more for the same bits depending on how you plan on using those bits.
Example: the new iPhone plans go something like this:
$40 (voice) + $30 (data) + $20 (messaging)
WTF? Give me a data connection and I'll figure the rest out myself, thank you. Maybe Clearwire/WIMAX will suck less, but since it's owned by a Telecom company (Sprint, 51%), I have little hope.
I didn't see any mention of a battery, charging station either.
Re:IRC with lots of logging
on
Enterprise IM?
·
· Score: 1
That's not true. Look at how gaim and trillian handle it - even without being in a chat room, they show up when connected. You can private chat with individuals or create a chat room.
FYI, we use IRC at work for R&D discussion. We have our own server and run bots that can rebuild libraries during the day. It's extremely useful.
Hmm... the D-Link 900 does wireless repeating too and costs about $70 (according to pricewatch.com). I would bet that at least one of LinkSys, Netgear, SMC and Siemens has one too.
Yep, it would be nice. I'll get around to it in due time. The i840 and other "server" chipsets would not have fit properly in this comparison. We'll save those for later. There are plenty of chipsets to compare, and this article was meant to just get my feet wet in chipset benchmarking with the standard consumer Pentium III chipsets. I've learned a lot from writing this article, and it'll help when I get to writing about more chipsets in the future.
Actually, that's not correct. Look at the memory benchmarks again. The Nbench results show the BX as falling in second place (but only by a slight amount) while the Unixbench results show it actually beating out both the 815 and the VIA chipsets. Memory bandwidth is one of the larger chipset limiting factors in kernel compilation, so the BX winning the kernel compilation only reflects the scores in memory performance.
Note that the BX didn't beat the 815 by much in the kernel compilation tests, while the VIA performed notably worse than the other two chipsets. This is similar to other benchmarks involving memory performance (in the same article) in which the VIA lost every one.
Yes and no. There are converters to take care of the VGA->sync-on-green problem as well as the conversion to 13w3, which is probably what the connection to the Sun monitor uses. BUT - that thing is going to only be able to run a few resolutions. If it's like my two Sun GDM-20D10's, then it'll work at 1024x768-75Hz through 1280x1024-76Hz or so.. give or take a few Hz. If you could get 640x480 running at 284823479827472934 Hz refresh, it would probably work. Otherwise, it will be out of the sync band the monitor supports. (usually those fixed freq monitors were not really fixed freq, but multisync within a REALLY small clock range)
1. Cost -- those things cost $120 and up for PCMCIA versions. Even on-board, it's going to make the cost per unit significantly higher.
2. Battery life. 802.11 based products are known for killing your battery life. Tests done at my university showed they dropped battery life by about an hour for most notebooks (with those "4 hour" batteries).
Actually, there's no reason you can't run DRI on a 2.2.x kernel. The review I wrote on Anandtech was running 2.2.16 from Red Hat. You just need to have agpgart for the kernel, which is a patch for kernels = 2.2.17 and will be included in 2.2.18 I believe.
But, it's really not quite fair to complain about DRI and the other recent X technologies not working. In a lot of ways, they're still extremely "in development." Most things on Linux are this way, if you want to settle for technology that has been around for a while, everything works fine, but to get newer things working, it's a pain in the butt. Think USB, DRI, the bttv drivers (my card JUST got supported in the later 2.3.x kernels), my SCSI card (ugh),...
Anyway, point being, distributions will have this sorted out for you in their next revisions. Debian will probably take another two years, but it'll happen.:)
Yeah, that would actually work very well. You don't need Xinerama for it either so you'd probably be able to get some 3D hardware acceleration, though I'm not sure about that.
Further, you could even have separate keyboards and mice if you have USB in your kernel or have use serial keyboards/mice.:)
However, the response from people on the mailing list (can't remember if it was XFree's Xpert list or the DRI list) was that it works much better at the same resolution.
The same bitdepth is a requirement though. That can be tricky because some cards work at 24 bpp while others do 32 bpp and some run at 15 bpp while others run at 16bpp.
Actually, that's not quite correct. The Matrox drivers released on their site are completely OSS and all changes in them will be incorporated into the next release of XFree86. Hallib, the closed-source library that you mention, is necessary ONLY for Dual Head, DVI and TV out. As distributed with XFree86, the driver will work fine, provide 2D AND 3D acceleration.
The library only handles:
1. Setting the card's clock
2. Initializing screens properly for
TV, DVI or Dual Head output.
This comes straight from a Matrox Linux developer too, by the way.
Consider the Matrox "released" drivers to be nothing more than the code in DRI's CVS tree linked with Hallib. That's not quite accurate, but it's close to the case.
You are talking about the G400's Dual Head feature, right? I didn't realize that existed back in 3.9.16. I was under the impression that it was a recently added feature with the latest Matrox releases and that it requires their hallib.a binary only library.
Interesting, very interesting..
Anyway, might want to give it another shot if you have that G400 still. It worked great for me. It's the first time that the Millennium II actually felt that much slower.
As for 2D, both screens are accelerated. Using the G450 was faster than using my G200/Millennium II combo I used to use.
As for 3D, forget it, you don't get acceleration under either head unless you forego Xinerama.
Yes, you still have a software cursor on the second head though.
You weren't using the kernel's framebuffer drivers were you? That's the old school way of doing things and left the second head completely unaccelerated.
It's a LONG way off. Evas is 90% done by the looks of it, and Raster even has the first app using it, Etcher. Check out screenshots on http://www.rasterman.com/
As for EFM and Enlightenment, they're BOTH going to be rewritten and combined. Hopefully enough code will carry over that it won't be THAT major of an effort, but I wouldn't expect to see anything for a while.
The alpha blended, transparent window thing wont work even with Evas due to X limitations. Check out the Render extension though, http://www.xfree86.org/~keithp/ -- it'll do it and they almost have it working with normal X servers judging from teh mailing list.
Evas is good for things like actually drawing out the windows. If you've used EFM, you know that it can start slowing down with a lot of icons -- and it should, that's a lot of alpha blending going on. With Evas, every icon will be drawn with hardware acceleration. (evas_test goes from 10fps in Imlib2 software mode to over 100 using OpenGL typically).
Nope, not yet, but I did talk to them yesterday about clocking to make sure I had it right.
As for Win2k, it works fine. I have a tri boot machine (need MICROS~1 to use the admin stuff at anandtech). In fact, the Win2k drivers are interesting in that unlike typical Windows dual-head, the two screens are COMPLETELY joined. You can even have a mouse cursor in between the two monitors. It did not reverse the outputs for me.
More interestingly, DRI's CVS stuff linked with Hallib won't even let you change the XF86Config file to reverse the displays back to normal, it's stuck at being backwards. At least, that's my experiences at home. With XFree86 4.0.1 and the Matrox drivers (as used in the article), I just gave the primary display Screen 1 and the secondary Screen 0, and that worked fine.
Actually, they've been getting MUCH better. I typically get responses on the forums in an hour or so now. (forums on matrox.com) BUT, this is by customer service reps that have pieces of paper describing what they support and what they don't. Still, there's SOME useful information.
Yeah, next up is to figure out how to get the Millennium II and the G450 to play nice together to enjoy a three headed display.:)
BTW - for those interested, the trick is that once you link with Hallib, you throw old-Matrox card support out the window. This includes both the drivers from Matrox's site and the drivers in DRI's CVS (which support Dual Head if you link with hallib).
I found someone who has recompiled Matrox's drivers and rewritten all the symbols to be mgc. Now he can use one driver with his G400 and one with the Millennium II. Here's a link:
Those aren't my pictures actually, I didn't even put them in the article. The "senior editors" added that to break up the text a little bit after I submitted it.
The card I have is actually a Twin View 1 VGA 1 DVI connector card. Anand tried getting it to work with a DVI->VGA adapter and had a lot of trouble. Then again, he only had a few minutes to play with it before I grabbed the thing for the article.:)
Actually, I wrote the article, the GeForce2 MX DOES support Twin View (the Windows drivers didn't implement it until recently), the card I had was a Twin View capable card, but it's not suppored under XFree86 yet.
Actually, the Matrox drivers are open source, but rely on a closed source library (hallib) to achieve dual head or TV/DVI out. This is because
copyrighted code (by Macrovision) in the library.
So, you can get any Matrox card working with OSS drivers, but if you want dual head, you'll have to link with that library (its distributed in the drivers from their site).
NVIDIA's drivers, on the other hand, are closed source. I regret not bringing this point up in the article actually.
Slashdot Mirror
Mobile service providers are playing the only game they can to get more money off the same data. It's crap and it really pisses me off. They charge more for the same bits depending on how you plan on using those bits.
Example: the new iPhone plans go something like this:
$40 (voice) + $30 (data) + $20 (messaging)
WTF? Give me a data connection and I'll figure the rest out myself, thank you. Maybe Clearwire/WIMAX will suck less, but since it's owned by a Telecom company (Sprint, 51%), I have little hope.
Where's the power cord?
I didn't see any mention of a battery, charging station either.
That's not true. Look at how gaim and trillian handle it - even without being in a chat room, they show up when connected. You can private chat with individuals or create a chat room.
FYI, we use IRC at work for R&D discussion. We have our own server and run bots that can rebuild libraries during the day. It's extremely useful.
Hmm... the D-Link 900 does wireless repeating too and costs about $70 (according to pricewatch.com). I would bet that at least one of LinkSys, Netgear, SMC and Siemens has one too.
Yep, it would be nice. I'll get around to it in due time. The i840 and other "server" chipsets would not have fit properly in this comparison. We'll save those for later. There are plenty of chipsets to compare, and this article was meant to just get my feet wet in chipset benchmarking with the standard consumer Pentium III chipsets. I've learned a lot from writing this article, and it'll help when I get to writing about more chipsets in the future.
Jeff Brubaker
Linux Tech Writer
AnandTech
Actually, that's not correct. Look at the memory benchmarks again. The Nbench results show the BX as falling in second place (but only by a slight amount) while the Unixbench results show it actually beating out both the 815 and the VIA chipsets. Memory bandwidth is one of the larger chipset limiting factors in kernel compilation, so the BX winning the kernel compilation only reflects the scores in memory performance.
Note that the BX didn't beat the 815 by much in the kernel compilation tests, while the VIA performed notably worse than the other two chipsets. This is similar to other benchmarks involving memory performance (in the same article) in which the VIA lost every one.
Jeff Brubaker
Linux Tech Writer
AnandTech
Yes and no. There are converters to take care of the VGA->sync-on-green problem as well as the conversion to 13w3, which is probably what the connection to the Sun monitor uses. BUT - that thing is going to only be able to run a few resolutions. If it's like my two Sun GDM-20D10's, then it'll work at 1024x768-75Hz through 1280x1024-76Hz or so.. give or take a few Hz. If you could get 640x480 running at 284823479827472934 Hz refresh, it would probably work. Otherwise, it will be out of the sync band the monitor supports. (usually those fixed freq monitors were not really fixed freq, but multisync within a REALLY small clock range)
Jeff
Two reasons that I can think of:
1. Cost -- those things cost $120 and up for PCMCIA versions. Even on-board, it's going to make the cost per unit significantly higher.
2. Battery life. 802.11 based products are known for killing your battery life. Tests done at my university showed they dropped battery life by about an hour for most notebooks (with those "4 hour" batteries).
Actually, there's no reason you can't run DRI on a 2.2.x kernel. The review I wrote on Anandtech was running 2.2.16 from Red Hat. You just need to have agpgart for the kernel, which is a patch for kernels = 2.2.17 and will be included in 2.2.18 I believe.
...
:)
But, it's really not quite fair to complain about DRI and the other recent X technologies not working. In a lot of ways, they're still extremely "in development." Most things on Linux are this way, if you want to settle for technology that has been around for a while, everything works fine, but to get newer things working, it's a pain in the butt. Think USB, DRI, the bttv drivers (my card JUST got supported in the later 2.3.x kernels), my SCSI card (ugh),
Anyway, point being, distributions will have this sorted out for you in their next revisions. Debian will probably take another two years, but it'll happen.
Yeah, that would actually work very well. You don't need Xinerama for it either so you'd probably be able to get some 3D hardware acceleration, though I'm not sure about that.
:)
Further, you could even have separate keyboards and mice if you have USB in your kernel or have use serial keyboards/mice.
Personally, I wouldn't want to waste the monitor.
Jeff
3Dfx Voodoo cards (you mentioned 3dLabs, they're supported too, but you got the names mixed up, I think)
Also, ATI's Rage128 based cards and teh Intel i810/815 chipsets (onboard video, crappy, but it works).
There's a few more too, but I can't remember off the top of my head.
Jeff
Yes Xinerama can handle that.
However, the response from people on the mailing list (can't remember if it was XFree's Xpert list or the DRI list) was that it works much better at the same resolution.
The same bitdepth is a requirement though. That can be tricky because some cards work at 24 bpp while others do 32 bpp and some run at 15 bpp while others run at 16bpp.
Jeff Brubaker
Linux Tech Writer
AnandTech
Actually, that's not quite correct. The Matrox drivers released on their site are completely OSS and all changes in them will be incorporated into the next release of XFree86. Hallib, the closed-source library that you mention, is necessary ONLY for Dual Head, DVI and TV out. As distributed with XFree86, the driver will work fine, provide 2D AND 3D acceleration.
The library only handles:
1. Setting the card's clock
2. Initializing screens properly for
TV, DVI or Dual Head output.
This comes straight from a Matrox Linux developer too, by the way.
Consider the Matrox "released" drivers to be nothing more than the code in DRI's CVS tree linked with Hallib. That's not quite accurate, but it's close to the case.
Jeff Brubaker
Linux Tech Writer
AnandTech
You are talking about the G400's Dual Head feature, right? I didn't realize that existed back in 3.9.16. I was under the impression that it was a recently added feature with the latest Matrox releases and that it requires their hallib.a binary only library.
Interesting, very interesting..
Anyway, might want to give it another shot if you have that G400 still. It worked great for me. It's the first time that the Millennium II actually felt that much slower.
As for 2D, both screens are accelerated. Using the G450 was faster than using my G200/Millennium II combo I used to use.
As for 3D, forget it, you don't get acceleration under either head unless you forego Xinerama.
Yes, you still have a software cursor on the second head though.
You weren't using the kernel's framebuffer drivers were you? That's the old school way of doing things and left the second head completely unaccelerated.
Jeff Brubaker
Linux Tech Writer
AnandTech
Since everyone seems to be reading the wrong article, there must be something counter-intuitive with AnandTech's interface. So here's the direct link.
http://www.anandtech.com/showdoc.html?i=1322
Actually, the drivers SHOULD work with FreeBSD too, so it's not just Linux. As for DRI support, I really don't know.
It's a LONG way off. Evas is 90% done by the looks of it, and Raster even has the first app using it, Etcher. Check out screenshots on http://www.rasterman.com/
As for EFM and Enlightenment, they're BOTH going to be rewritten and combined. Hopefully enough code will carry over that it won't be THAT major of an effort, but I wouldn't expect to see anything for a while.
The alpha blended, transparent window thing wont work even with Evas due to X limitations. Check out the Render extension though, http://www.xfree86.org/~keithp/ -- it'll do it and they almost have it working with normal X servers judging from teh mailing list.
Evas is good for things like actually drawing out the windows. If you've used EFM, you know that it can start slowing down with a lot of icons -- and it should, that's a lot of alpha blending going on. With Evas, every icon will be drawn with hardware acceleration. (evas_test goes from 10fps in Imlib2 software mode to over 100 using OpenGL typically).
Jeff Brubaker
Linux Tech Writer
AnandTech
Nope, not yet, but I did talk to them yesterday about clocking to make sure I had it right.
As for Win2k, it works fine. I have a tri boot machine (need MICROS~1 to use the admin stuff at anandtech). In fact, the Win2k drivers are interesting in that unlike typical Windows dual-head, the two screens are COMPLETELY joined. You can even have a mouse cursor in between the two monitors. It did not reverse the outputs for me.
More interestingly, DRI's CVS stuff linked with Hallib won't even let you change the XF86Config file to reverse the displays back to normal, it's stuck at being backwards. At least, that's my experiences at home. With XFree86 4.0.1 and the Matrox drivers (as used in the article), I just gave the primary display Screen 1 and the secondary Screen 0, and that worked fine.
Jeff Brubaker
Linux Tech Writer
AnandTech
Actually, they've been getting MUCH better. I typically get responses on the forums in an hour or so now. (forums on matrox.com) BUT, this is by customer service reps that have pieces of paper describing what they support and what they don't. Still, there's SOME useful information.
Yeah, next up is to figure out how to get the Millennium II and the G450 to play nice together to enjoy a three headed display. :)
t ember/001438.html
BTW - for those interested, the trick is that once you link with Hallib, you throw old-Matrox card support out the window. This includes both the drivers from Matrox's site and the drivers in DRI's CVS (which support Dual Head if you link with hallib).
I found someone who has recompiled Matrox's drivers and rewritten all the symbols to be mgc. Now he can use one driver with his G400 and one with the Millennium II. Here's a link:
http://www.xfree86.org/pipermail/xpert/2000-Sep
haha.. good catch.
:)
Those aren't my pictures actually, I didn't even put them in the article. The "senior editors" added that to break up the text a little bit after I submitted it.
The card I have is actually a Twin View 1 VGA 1 DVI connector card. Anand tried getting it to work with a DVI->VGA adapter and had a lot of trouble. Then again, he only had a few minutes to play with it before I grabbed the thing for the article.
I think you read the wrong article.
:)
Jeff Brubaker
Linux Tech Writer
Anandtech
Actually, I wrote the article, the GeForce2 MX DOES support Twin View (the Windows drivers didn't implement it until recently), the card I had was a Twin View capable card, but it's not suppored under XFree86 yet.
Jeff Brubaker
Linux Tech Writer
Anandtech
That's not QUITE true.
Actually, the Matrox drivers are open source, but rely on a closed source library (hallib) to achieve dual head or TV/DVI out. This is because
copyrighted code (by Macrovision) in the library.
So, you can get any Matrox card working with OSS drivers, but if you want dual head, you'll have to link with that library (its distributed in the drivers from their site).
NVIDIA's drivers, on the other hand, are closed source. I regret not bringing this point up in the article actually.
Jeff Brubaker
Linux Tech Writer
Anandtech