excuse me? I have beautiful accelerated 2d AND 3d on my Radeon 7500, using the opensource drivers included in XFree 4.2.
The opensource ATI drivers are IN XFree86! they do very much exist, and they rock it up (about 90 FPS in quake3 at 1024x768, the 'pretties' all on:-). Nothing groundbreaking, but at $99 OEM not shabby. The card even does dualhead (and I'm using that, so it's not wasted).
Plus, I have decent 2d performance, unlike my roomate GeForce3, which could get pasted to the wall by my old mach64 in 2d, much less anything current. The GeForce mad-fast in 3d, I admit; but that's all you get, and it is plenty unstable too:-(
Matrox has weak 3d cards (albiet spectacular 2d), but quit lying about the radeon support. It is right there, in the standard XFree86 and kernel codebases, without needing any extra parts. It could hardly get any simpler:-)
don't do that on the basis of one bug - at least read the errata for both chips first:-) There are quite a few errata notices in both pentiums and athlon's I'm sure. This one,/. locked on to for some unknown reason (btw - linux was never affected by sheer luck that we always aligned such pages, which avoids the bug). That's why it took so long to be found. It looks like maybe nVidia's closed drivers manage to trigger it (from a quick read through kernel-traffic), so something will probably be done for those soon.
chip bugs aren't common, but there's barely a chip out there that doesn't have a few. Don't scrap AMD on the basis of just one.
now, styles aren't using it yet, but qt3 has more or less ripped out all of the hacks it used to have and is using RENDER extensively throughout it's codebase for these kinds of operations. KDE2 uses RENDER as well, in a more limited fashion, to allow antialiased text.
The new X11 Rendering model is here, and it's real, and apps are using it already. Not all of them, not to it's full abilities, but that's changing fast already.
ati provides driver docs instead, which is better. ATI's cards work out-of-box on linux, instead of needing new drivers from nVidia. they direct you to the sourceforge page, because they support the standard XFree86 DRI interface, which is maintained on sourceforge. But really, all you need is a recent enough version of XFree (4.1.0 for Radeon DDR, 4.1.99.x/released-as-4.2.0 really soon for 7500).
Now, I'll have to admit in fairness that the 8500 isn't supported yet (for 3d). But my 7500 is kickin' ass and takin' names in linux, and (unlike nVidia's cards) actually runs 2d well too:-)
I found a crash about 3 days back - now it's already fixed in X CVS, and I have a new build:-) Try that with nVidia's closed drivers.
there is indeed a/proc entry (/proc/sys/vm/overcommit_memory) to disable VM overcommit. In which case, it's impossible to reach the scenario where the OOM is needed (some process gets a null from malloc instead).
However, as it stands, linux by default is willing to overcommit (via copy-on-write). This is a good, and beneficial thing - when one forks, the pages don't need to be allocated and copied until they are changeed (as most never are). This saves memory, saves time, and vastly improves scalability of many tasks. Ditto for many, many other situations. But, it means when everything goes to hell in a handbasket, you have promised memory to processes that you simply do not have, and you've already told them they can have it. So you have to produce something, and that means someone gets tossed.
as far as reservving special memory, the mlock call does just that. It tells the VM that these pages can't be messed with, they need to be ready immediately.
You can't just suspend, because you already did that - OOM doesn't occur until you are also out of swap. OOM is a last-ditch, we have *nowhere* left to put this. If you ever see OOM, you need more swap. Simple as that.
(Now, one thing that would be very nice would be dynamically resizing swapfiles, so that if you had disk space left not currently being used for swap, the swaparea could grow. But even then, there is such a thing as out of disk as well. The only way to completely avoid OOM is to avoid overcommit/copy-on-write and allocate any pages that could potentially be used by a call every time (even when, as in fork/exec they very rarely are). That way you could make the calls fail in this worst of worst-cases and the applications could respond.
except that perl's not compiled:-) But yes, I think a perl interpreter in perl would be very easy.
open FILE,";
eval $code;
Re:In response to others...
on
Flying on Mars
·
· Score: 1
seems reasonable... if the sky is red because of
dust, then the ambient light is also is also
going to be reddish, casting a shade on the
probe/etc. Filter that ambient color cast out,
using a control sample of known color (well,
somewhat known... after all, on Earth it should
have a slight blue cast, though probably less of
one) and what's left should be the wavelength
scattering as seen right here on Earth (ie, blue).
Shorter wavelengths bend more, that shouldn't change
just because the atmosphere is thinner (though
everything should bend less, so the color would be
less pronounced)
Not that the sky would be blue when you looked
at it, but that effect should be there underneath
the red dust.
Face it... many games optimize special cases for specific cards, many cards optimize special cases for specific games. Mostly the cards optimize for the current generation of games (since they can't know about new games), the games optimize for the current generation of cards (since they cant' know about new cards). It common practice, and it improves performance quite significantly. nVidia's new drivers delivered a 30% boost in performance for a lot of apps... care to guess at what they did underneath?
Admittedly, ATI did this to a fairly upacceptable degree in this case (since there was significant image quality damage), but they probably didn't optimize Quake because it was a benchmark, they probably did so because it's a popular game full of framerate-freaks who do things like hack their drivers to turn off texturing anyway:-). Read Carmack's comments on the issue before you burn them at the stake for giving you a significant performance boost. The one thing they did wrong was not provide the ability to turn optimization off for benchmarking.
I wish it would do this too (so I could have plucker spider slashdot for my palm in light mode with custom settings other than what my account usually uses) but if you have a login account, you can change to light mode via account prefs.
Yes, it originates in the old ssh1 codebase. But everything since then (ssh1.5, ssh2, sftp, lots more that I don't use daily and thus don't remember) in openssh has been developed by the openBSD team in order to have an Free software ssh client.
They have done their share of work too, and are more than a cheap ripoff of the ssh1 codebase.
None of those are features HP doesn't have... my 48G can do symbolic math, 3d graphing, (what processor it uses is irrelvant), and has a gcc target. Try again?
Read his actual comment (like anyone on/. ever does that anymore). He's not getting out of kernel development, he's just not maintaining the stable series this time around. He says he's gonna be working on other kernel projects - a.k.a., he wants his shot at the fun in the devel tree:-)
This was a rule of thumb, because under most ordinary loads it was all the swap the system could ever make any reasonably use of. More RAM (for the same workload) means less swap needed - but if you're going for maximum peak worload you want as much VM space as possible. However, Anything much beyond 2xRAM makes no sense - the system will pretty much totally disintegrate if you've got that that much more data than RAM. Hence the recommendation - that's about as much swap as 2.2's vm could really make use of.
FWIW, I think that Andrea's setup is modeled after the 2.2 VM (which he did a fair amount of work on tuning). So this is really more of a pragmatic revive-the-old-approach than it might initially seem.
We all know this simplistic setup had scalability problems (like much of 2.2) but at least it worked right. Hopefully given some more time, Rik can really get his to go, since it seems more sophisticated/scalable long-term.
kde3 is a much smaller change than kde2, which was a complete rewrite. Think of it as kde2.3, ported to qt3 and prepared for gcc3. This means two things to app developers and compatibility.
1) most of the differences are very minor, and in almost every case can be handled by a small bit of preprocessor magic. Most apps I know of that are converting to kde3 are taking this route first, making it possible to build for either platform.
2) kde3's release cycle will be *much* shorter than kde2's was, where there was no release for a tremendous amount of time.
In any case, there is at least one point release still planned for the kde2.2.x series, which should wrap up a last few outstanding issues before everyone moves on.
One thing to keep in mind is that KDE *does* use these higher-level things, as QT's QObject's implement them. It may not be quite as slick as having them in the language, but QT's moc does a lot to alieviate the shortcomings of C++.
but you can... just type in the dir name and hit return, and there you are.
No tabcompleting the names though (unless you use the other field). I admit that. It would be a small, nice feature for kde3 to add, now that you mention it. Maybe I'll file a wishlist on that, or even just write it myself:-)
Re:Gods you fiends! Here's your changelog...
on
XFree 4.1.0 Out
·
· Score: 1
antialiased fonts were in 4.0.1, though admittedly kinda buggy until 4.0.3.
Re:please let it work on my dear old mac
on
XFree 4.1.0 Out
·
· Score: 2
my X4 debs have annex's unofficial ppc drivers in them, and can do mach64. 4.1. will also have these fixes in them afaik (it has all of his other work, so I'd assume).
http://www.penguinppc.org/~puetzk, you want the xserver-xfree86 4.0.1-7puetzk package.
The rest you can getfun testing (it should work, even though testing is now on 4.0.3 - ymmv, I moved on and am running pre-4.1 cvs).
or, as I said, 4.1 oughta work out-of-box, I can't see any reason his mach64/ppc fixes wouldn't be in when all the other cards I have made it.
yes. there are.
Is there more to say than that? Perl/Python are there, java (I think), basically most languages that have enough of an object model to support it. One could do C wrappers (as have been done for some specific parts of the API, like DCOP and artsd, to allow easy interoperability with C apps), but very few platforms have C and no (simple, QT doesn't really stretch new features) C++, so there's really no point in doing a full wrapper. It would be much less clean to code in C with a pseudo-object model than to just use C++.
Slashdot Mirror
sure, I'd expect each is in a patch file packed in the SRPM
picking the right ones is, as you said, the trick. And RH's stresstest labs are pretty godo at it
excuse me? I have beautiful accelerated 2d AND 3d on my Radeon 7500, using the opensource drivers included in XFree 4.2.
:-). Nothing groundbreaking, but at $99 OEM not shabby. The card even does dualhead (and I'm using that, so it's not wasted).
:-(
:-)
The opensource ATI drivers are IN XFree86! they do very much exist, and they rock it up (about 90 FPS in quake3 at 1024x768, the 'pretties' all on
Plus, I have decent 2d performance, unlike my roomate GeForce3, which could get pasted to the wall by my old mach64 in 2d, much less anything current. The GeForce mad-fast in 3d, I admit; but that's all you get, and it is plenty unstable too
Matrox has weak 3d cards (albiet spectacular 2d), but quit lying about the radeon support. It is right there, in the standard XFree86 and kernel codebases, without needing any extra parts. It could hardly get any simpler
don't do that on the basis of one bug - at least read the errata for both chips first :-) There are quite a few errata notices in both pentiums and athlon's I'm sure. This one, /. locked on to for some unknown reason (btw - linux was never affected by sheer luck that we always aligned such pages, which avoids the bug). That's why it took so long to be found. It looks like maybe nVidia's closed drivers manage to trigger it (from a quick read through kernel-traffic), so something will probably be done for those soon.
chip bugs aren't common, but there's barely a chip out there that doesn't have a few. Don't scrap AMD on the basis of just one.
all of KDE3 :-)
now, styles aren't using it yet, but qt3 has more or less ripped out all of the hacks it used to have and is using RENDER extensively throughout it's codebase for these kinds of operations. KDE2 uses RENDER as well, in a more limited fashion, to allow antialiased text.
The new X11 Rendering model is here, and it's real, and apps are using it already. Not all of them, not to it's full abilities, but that's changing fast already.
ati provides driver docs instead, which is better. ATI's cards work out-of-box on linux, instead of needing new drivers from nVidia. they direct you to the sourceforge page, because they support the standard XFree86 DRI interface, which is maintained on sourceforge. But really, all you need is a recent enough version of XFree (4.1.0 for Radeon DDR, 4.1.99.x/released-as-4.2.0 really soon for 7500).
:-)
:-) Try that with nVidia's closed drivers.
Now, I'll have to admit in fairness that the 8500 isn't supported yet (for 3d). But my 7500 is kickin' ass and takin' names in linux, and (unlike nVidia's cards) actually runs 2d well too
I found a crash about 3 days back - now it's already fixed in X CVS, and I have a new build
there is indeed a /proc entry (/proc/sys/vm/overcommit_memory) to disable VM overcommit. In which case, it's impossible to reach the scenario where the OOM is needed (some process gets a null from malloc instead).
However, as it stands, linux by default is willing to overcommit (via copy-on-write). This is a good, and beneficial thing - when one forks, the pages don't need to be allocated and copied until they are changeed (as most never are). This saves memory, saves time, and vastly improves scalability of many tasks. Ditto for many, many other situations. But, it means when everything goes to hell in a handbasket, you have promised memory to processes that you simply do not have, and you've already told them they can have it. So you have to produce something, and that means someone gets tossed.
as far as reservving special memory, the mlock call does just that. It tells the VM that these pages can't be messed with, they need to be ready immediately.
You can't just suspend, because you already did that - OOM doesn't occur until you are also out of swap. OOM is a last-ditch, we have *nowhere* left to put this. If you ever see OOM, you need more swap. Simple as that.
(Now, one thing that would be very nice would be dynamically resizing swapfiles, so that if you had disk space left not currently being used for swap, the swaparea could grow. But even then, there is such a thing as out of disk as well. The only way to completely avoid OOM is to avoid overcommit/copy-on-write and allocate any pages that could potentially be used by a call every time (even when, as in fork/exec they very rarely are). That way you could make the calls fail in this worst of worst-cases and the applications could respond.
oops, indeed.
actually, I meant to do join <FILE%gt;
but forgot to. Your solution's better anyway.
part (not all) of this is the fact that it's usually CAS2 ram, but basically yeah, theyr're just charging a lot for it :-)
bleh, /. eat's <> when in plain old text? eww..
:-) But yes, I think a perl interpreter in perl would be very easy.
trying again.
except that perl's not compiled
open FILE,"<$ARGV[0]";
$code = <FILE>
eval $code;
except that perl's not compiled :-) But yes, I think a perl interpreter in perl would be very easy.
open FILE,";
eval $code;
seems reasonable... if the sky is red because of
dust, then the ambient light is also is also
going to be reddish, casting a shade on the
probe/etc. Filter that ambient color cast out,
using a control sample of known color (well,
somewhat known... after all, on Earth it should
have a slight blue cast, though probably less of
one) and what's left should be the wavelength
scattering as seen right here on Earth (ie, blue).
Shorter wavelengths bend more, that shouldn't change
just because the atmosphere is thinner (though
everything should bend less, so the color would be
less pronounced)
Not that the sky would be blue when you looked
at it, but that effect should be there underneath
the red dust.
Face it... many games optimize special cases for specific cards, many cards optimize special cases for specific games. Mostly the cards optimize for the current generation of games (since they can't know about new games), the games optimize for the current generation of cards (since they cant' know about new cards). It common practice, and it improves performance quite significantly. nVidia's new drivers delivered a 30% boost in performance for a lot of apps... care to guess at what they did underneath?
:-). Read Carmack's comments on the issue before you burn them at the stake for giving you a significant performance boost. The one thing they did wrong was not provide the ability to turn optimization off for benchmarking.
Admittedly, ATI did this to a fairly upacceptable degree in this case (since there was significant image quality damage), but they probably didn't optimize Quake because it was a benchmark, they probably did so because it's a popular game full of framerate-freaks who do things like hack their drivers to turn off texturing anyway
I wish it would do this too (so I could have plucker spider slashdot for my palm in light mode with custom settings other than what my account usually uses) but if you have a login account, you can change to light mode via account prefs.
Yes, it originates in the old ssh1 codebase. But everything since then (ssh1.5, ssh2, sftp, lots more that I don't use daily and thus don't remember) in openssh has been developed by the openBSD team in order to have an Free software ssh client.
They have done their share of work too, and are more than a cheap ripoff of the ssh1 codebase.
None of those are features HP doesn't have... my 48G can do symbolic math, 3d graphing, (what processor it uses is irrelvant), and has a gcc target. Try again?
Read his actual comment (like anyone on /. ever does that anymore). He's not getting out of kernel development, he's just not maintaining the stable series this time around. He says he's gonna be working on other kernel projects - a.k.a., he wants his shot at the fun in the devel tree :-)
Rik van Reil's (-ac series kernels) is somewhat modeled off the FreeBSD VM. How much so I don't know.
This was a rule of thumb, because under most ordinary loads it was all the swap the system could ever make any reasonably use of. More RAM (for the same workload) means less swap needed - but if you're going for maximum peak worload you want as much VM space as possible. However, Anything much beyond 2xRAM makes no sense - the system will pretty much totally disintegrate if you've got that that much more data than RAM. Hence the recommendation - that's about as much swap as 2.2's vm could really make use of.
FWIW, I think that Andrea's setup is modeled after the 2.2 VM (which he did a fair amount of work on tuning). So this is really more of a pragmatic revive-the-old-approach than it might initially seem.
We all know this simplistic setup had scalability problems (like much of 2.2) but at least it worked right. Hopefully given some more time, Rik can really get his to go, since it seems more sophisticated/scalable long-term.
kde3 is a much smaller change than kde2, which was a complete rewrite. Think of it as kde2.3, ported to qt3 and prepared for gcc3. This means two things to app developers and compatibility.
1) most of the differences are very minor, and in almost every case can be handled by a small bit of preprocessor magic. Most apps I know of that are converting to kde3 are taking this route first, making it possible to build for either platform.
2) kde3's release cycle will be *much* shorter than kde2's was, where there was no release for a tremendous amount of time.
In any case, there is at least one point release still planned for the kde2.2.x series, which should wrap up a last few outstanding issues before everyone moves on.
One thing to keep in mind is that KDE *does* use these higher-level things, as QT's QObject's implement them. It may not be quite as slick as having them in the language, but QT's moc does a lot to alieviate the shortcomings of C++.
but you can... just type in the dir name and hit return, and there you are.
:-)
No tabcompleting the names though (unless you use the other field). I admit that. It would be a small, nice feature for kde3 to add, now that you mention it. Maybe I'll file a wishlist on that, or even just write it myself
antialiased fonts were in 4.0.1, though admittedly kinda buggy until 4.0.3.
my X4 debs have annex's unofficial ppc drivers in them, and can do mach64. 4.1. will also have these fixes in them afaik (it has all of his other work, so I'd assume).
http://www.penguinppc.org/~puetzk, you want the xserver-xfree86 4.0.1-7puetzk package.
The rest you can getfun testing (it should work, even though testing is now on 4.0.3 - ymmv, I moved on and am running pre-4.1 cvs).
or, as I said, 4.1 oughta work out-of-box, I can't see any reason his mach64/ppc fixes wouldn't be in when all the other cards I have made it.
yes. there are. Is there more to say than that? Perl/Python are there, java (I think), basically most languages that have enough of an object model to support it. One could do C wrappers (as have been done for some specific parts of the API, like DCOP and artsd, to allow easy interoperability with C apps), but very few platforms have C and no (simple, QT doesn't really stretch new features) C++, so there's really no point in doing a full wrapper. It would be much less clean to code in C with a pseudo-object model than to just use C++.