if you want to allow fast syscalls (trust me, you do) you need to keep the kernel mapped permanently to cheapen the context switch from app to kernel. You also probbly want to separate physical memory (mapped into the kernel space directly) and virtual space, so that you can have swap and mmap'ed files. You also probably need to keep some address space to map I/O devices into, and some for DMA buffers (unless you really want to give up DMA to get that last memory). What with all the memory on modern video cards, mapping them (to say nothing of the AGP window) is pretty huge too.
So, unless you want to rewrite a lot of stuff, and throw performance completely down the toilet, you need most of that 4GB address space for things other than app VM space. The current linux split is 1G/3G (1 gig to map physical ram into the kernel and store kernel data structures), 3G of total app address space into which devices, files, swap, or physical ram pages can get mapped. You can also set linxu up for 2/2 I think (which gives you more physical ram at the expense of what each app can use) or 4G/PAE (which takes the performance hit and separates the app and kernel the apps get all 4G themselves, and the kernel uses PAE to map up to 32G in a separate way). But the performance hit is very significant unless your app uses almost no system calls or I/O (device I/O has to get copied around into lowmem for this case).
n64 was a powerpc (an odd one, but a powerpc), dunno about the gamecube. The PS2 was MIPS, but I think power is being mooted for PS3 (not that sony is saying much yet)
you don't even have to work this hard... just picking en_US instead of us as your keyboard layout when configuring Xkb (XkbLayout in the config file) means the right win key is compose, and the right alt key is mode_switch.
stealing? hardly. The list of contributions covers a very impressive number of optimizations and TODO's in KHTML, and the code was submitted with an excellent changelog. If this is stealing KHTML, we could sure do with more thieves like this:-)
They are doing exactly what the LGPL (as chosen by the KHTML authors) wanted them to do... improve KHTML, and use it.
Re:Spielberg Over the Hill?
on
Taken?
·
· Score: 1
wow, I too had missed this interpretation... and it makes the ending so much better. Damned movies that do have endings that bad, that made me miss what this one really was.
Well, if nothing else, he clearly failed to get most of us to understand the ending;-)
R250 is very similar to R200 (though you're right, not identical).
Close enough that the R200 driver runs it just fine. Basically, it's an R200 with fewer pixel pipelines (it was cut down a bit to make it cheaper) and a little bit higher clock (due to a process shrink IIRC).
Not many differences from the driver's point of view, just a little less performance and a lot cheaper.
radeon 9000 is also supported by latest X/DRI cvs, so you should be fine. I've heard about some glitches (support is still very new) but it looks like it should come together pretty nicely by 4.3.
well, that seagate Barracude IV is a dead-silent Hard drive (I have one) so I wouldn't worry on that front. But yes, the PSU fan didn't look like a particularly quiet arrangement, and I have also heard complaints about the shuttle boxes noise (which this looks to be a system built from).
Re:This is This is the exact opposite of my findin
on
New Linux 2.5 Benchmarks
·
· Score: 3, Interesting
well, this guy is apparently a troll, but just for the sake of argument... Anyone repeating his test would probably find very similar results. HZ (the constant controlling how often the scheduler runs) has been changed from 100 to 1000, improving smoothness for many things (multimedia apps espescially) at the cost of making the schduler overhead 10 times what it was before.
Luckily, it was very small before, and it's still very small. Maybe it went from taking 0.001% of your CPU power to 0.01%:-). The *only* times the scheduler was really a problem before were a) when it made bad choices and b) when there was gazillions of tasks. The rest of the time, it was totally negligible.
So, even if the scheduler did slow down by a factor of 2 as he claimed (and in fact, it would have slowed down by a factor of 10 due to the HZ changes so his claim would leave O(1) 5 times faster than the old scheduler) it really wouldn't matter to an ordinary desktop/server. The scheduler time is too small to be important on normal machines .
There is also the machine & IP which used to be J, which is still present, will be kept up-to-date, and will still answer you (for some period of time), though it is no longer the official J root nameserver.
It says anything normall distributed with the major components of the OS (specifically listing compilers) need not be provided. So, all the libraries that came with your copy of the OS, and all the utilities that came with your SDK from metrowerks or whoever, are specifically exempted. It does not assume that the compiler comes with the OS, it specifically exempts both anything that came with the OS _and_ anything that came with your compiler, as examples of major components which you are not responsible for supplying.
in kde3 (kde2 was just buggy in this regard, no apologies for its clipboard) that's exactly what you have. control-c/x/v have are nonvoliatle, select/middleclick is voliatle.
Klipper still exists mostly to let people who actually liked the kde2 way use it. But if you want a more normal model, just go with the default, not klipper:-)
yes, I would much prefer that:-). Though I seldom buy the popcorn or the coke.
At least if it was $$->better vs. free->worse experience they'd win one count. Right now it's pretty questionable whether the theater wins either.
Right now, my couch, stereo, 'TV' (actually an old celeron with a old, but nice sun fixed-sync 1024x768 monitor), and nachos beats the hell out of their theater & popcorn in terms of enjoyability.
well, if they haven't figured in the revenue loss from this, they should. The annoyance of cell-phones (though at least this part is much better than a year or so ago, people are getting more considerate), along with the fscking 20 minutes of previews (and commercials between previews even sometimes) are why I almost never go to the theatre anymore and just wait for it to be $2 at the movie rental place (or the dollar theater in the mall, which oddly enough is much better in both respects):-)
If the pirates get the DVD rip up months before they will let me pay them to rent it, how can they seriously expect that I want to give them money so badly that I'll wait (or go through the less and less pleasant experience that is the theater) just to give them the money? If they'd sell it to me, I'd rent (or better yet, download direct from them!) to avoid dealing with the rips that turn out to be camcorder (which aren't even worth doing anything about, they suck too bad to watch even for free). But when they won't? Well then. Sorry.
ext3 is available only as a separate patch for 2.2 kernels, and that will not change. If you want to use it, you're really best off upgrading to 2.4. If you want to use it without patching, you'll have to use 2.4 kernels. If you're really interested in feature work like ext3, you probably want to anyway.
to be more precise, there's a small (but nonzero) chance that bad AGP cacheing will bite you and cause a crash due to odd athlon cache behavior (not sure if duron works the same way, but I'd expect it to). mem=nopentium will force off large page mode and make the bug much, much rarer (if you see it with this on, buy a lotto ticket). I thought 2.4.19 did this automatically now but nobody else seems to think so, so I may be wrong.
The bug affects windows also, current drivers supposedly work around it the same way mem=nopentium does (by disabling 4meg memory pageing for pages overlapping with AGP). So, though not technically a 'fix' the workound is seems to be quite adequate to prevent the bug from manifesting in real life...
actually, it was only just fixed in linux, and only in a fairly recent 2.4.19-pre (ie in no release yet). Not exactly an Athlon bug, but certainly a very odd caching behavior...
5-600W is a big range. How about some real numbers just for grins:-)
As viewed from my 650VA UPS (which will tell me the wall power consumption, including all losses in the PSU etc) my dual athlon (2xMP1600) +17" monitor sits at approx 400VA load. When the CPU's idle to C2 (most of the time) it drops about 80VA, and if the monitor sleeps it dropsanother 110VA or so.
So the fixed (ie PSU+HD+video+mobo+CPU idle) comsumption+etc is about 200VA, each CPU is about 40VA (different from C2 idle to max load), and the monitor is about 110VA.
Making the (basically reasonable, though not perfect) assumption that a switching power supply's power factor is close to 1 (shouldn't be far from that I wouldn't think) 1VA=1W. If the power factor is not one, then a VA is less than a watt (ie, all my numbers are too high in that case).
So it's a good heater, but not as bad as you feared. The lights in the room are using as much power as the idling computer, the computer edges them out during a good quakin' session:-)
and bnetd doesn't support WC3. There is some work based on it that does, but their main page clearly stated that the people distributing warcraft3 servers had not released source and were not affiliated with the bnetd project.
arts - no, and arts likes alsa rather better than it liked OSS. Alsa lets it see much more of the soundcard's abilities, so it can stop doing simple things itself and focus in effects and codec work (ie, it's real purpose).
if you want to allow fast syscalls (trust me, you do) you need to keep the kernel mapped permanently to cheapen the context switch from app to kernel. You also probbly want to separate physical memory (mapped into the kernel space directly) and virtual space, so that you can have swap and mmap'ed files. You also probably need to keep some address space to map I/O devices into, and some for DMA buffers (unless you really want to give up DMA to get that last memory). What with all the memory on modern video cards, mapping them (to say nothing of the AGP window) is pretty huge too.
So, unless you want to rewrite a lot of stuff, and throw performance completely down the toilet, you need most of that 4GB address space for things other than app VM space. The current linux split is 1G/3G (1 gig to map physical ram into the kernel and store kernel data structures), 3G of total app address space into which devices, files, swap, or physical ram pages can get mapped. You can also set linxu up for 2/2 I think (which gives you more physical ram at the expense of what each app can use) or 4G/PAE (which takes the performance hit and separates the app and kernel the apps get all 4G themselves, and the kernel uses PAE to map up to 32G in a separate way). But the performance hit is very significant unless your app uses almost no system calls or I/O (device I/O has to get copied around into lowmem for this case).
n64 was a powerpc (an odd one, but a powerpc), dunno about the gamecube. The PS2 was MIPS, but I think power is being mooted for PS3 (not that sony is saying much yet)
you don't even have to work this hard... just picking en_US instead of us as your keyboard layout when configuring Xkb (XkbLayout in the config file) means the right win key is compose, and the right alt key is mode_switch.
stealing? hardly. The list of contributions covers a very impressive number of optimizations and TODO's in KHTML, and the code was submitted with an excellent changelog. If this is stealing KHTML, we could sure do with more thieves like this :-)
They are doing exactly what the LGPL (as chosen by the KHTML authors) wanted them to do... improve KHTML, and use it.
wow, I too had missed this interpretation... and it makes the ending so much better. Damned movies that do have endings that bad, that made me miss what this one really was.
;-)
Well, if nothing else, he clearly failed to get most of us to understand the ending
fwiw, the new ones have a dramatically revamped cooling setup (invloving heat-pipes) that is supposed to be lots quieter than the SV24/25 was.
But I don't own either one, so I can't give a firsthand impression.
R250 is very similar to R200 (though you're right, not identical).
Close enough that the R200 driver runs it just fine. Basically, it's an R200 with fewer pixel pipelines (it was cut down a bit to make it cheaper) and a little bit higher clock (due to a process shrink IIRC).
Not many differences from the driver's point of view, just a little less performance and a lot cheaper.
radeon 9000 is also supported by latest X/DRI cvs, so you should be fine. I've heard about some glitches (support is still very new) but it looks like it should come together pretty nicely by 4.3.
well, that seagate Barracude IV is a dead-silent Hard drive (I have one) so I wouldn't worry on that front. But yes, the PSU fan didn't look like a particularly quiet arrangement, and I have also heard complaints about the shuttle boxes noise (which this looks to be a system built from).
well, this guy is apparently a troll, but just for the sake of argument... Anyone repeating his test would probably find very similar results. HZ (the constant controlling how often the scheduler runs) has been changed from 100 to 1000, improving smoothness for many things (multimedia apps espescially) at the cost of making the schduler overhead 10 times what it was before.
:-). The *only* times the scheduler was really a problem before were a) when it made bad choices and b) when there was gazillions of tasks. The rest of the time, it was totally negligible.
Luckily, it was very small before, and it's still very small. Maybe it went from taking 0.001% of your CPU power to 0.01%
So, even if the scheduler did slow down by a factor of 2 as he claimed (and in fact, it would have slowed down by a factor of 10 due to the HZ changes so his claim would leave O(1) 5 times faster than the old scheduler) it really wouldn't matter to an ordinary desktop/server. The scheduler time is too small to be important on normal machines .
there is a new J, in a different block.
There is also the machine & IP which used to be J, which is still present, will be kept up-to-date, and will still answer you (for some period of time), though it is no longer the official J root nameserver.
read it before you panic
It says anything normall distributed with the major components of the OS (specifically listing compilers) need not be provided. So, all the libraries that came with your copy of the OS, and all the utilities that came with your SDK from metrowerks or whoever, are specifically exempted. It does not assume that the compiler comes with the OS, it specifically exempts both anything that came with the OS _and_ anything that came with your compiler, as examples of major components which you are not responsible for supplying.
it's for LCDs that can pivot on their base, so that you can turn the screen the right way after rotating the monitor.
in kde3 (kde2 was just buggy in this regard, no apologies for its clipboard) that's exactly what you have. control-c/x/v have are nonvoliatle, select/middleclick is voliatle.
:-)
Klipper still exists mostly to let people who actually liked the kde2 way use it. But if you want a more normal model, just go with the default, not klipper
yes, I would much prefer that :-). Though I seldom buy the popcorn or the coke.
At least if it was $$->better vs. free->worse experience they'd win one count. Right now it's pretty questionable whether the theater wins either.
Right now, my couch, stereo, 'TV' (actually an old celeron with a old, but nice sun fixed-sync 1024x768 monitor), and nachos beats the hell out of their theater & popcorn in terms of enjoyability.
well, if they haven't figured in the revenue loss from this, they should. The annoyance of cell-phones (though at least this part is much better than a year or so ago, people are getting more considerate), along with the fscking 20 minutes of previews (and commercials between previews even sometimes) are why I almost never go to the theatre anymore and just wait for it to be $2 at the movie rental place (or the dollar theater in the mall, which oddly enough is much better in both respects) :-)
If the pirates get the DVD rip up months before they will let me pay them to rent it, how can they seriously expect that I want to give them money so badly that I'll wait (or go through the less and less pleasant experience that is the theater) just to give them the money? If they'd sell it to me, I'd rent (or better yet, download direct from them!) to avoid dealing with the rips that turn out to be camcorder (which aren't even worth doing anything about, they suck too bad to watch even for free). But when they won't? Well then. Sorry.
$5000 per seat, IIRC.
:-)
So plenty
ext3 is available only as a separate patch for 2.2 kernels, and that will not change. If you want to use it, you're really best off upgrading to 2.4. If you want to use it without patching, you'll have to use 2.4 kernels. If you're really interested in feature work like ext3, you probably want to anyway.
to be more precise, there's a small (but nonzero) chance that bad AGP cacheing will bite you and cause a crash due to odd athlon cache behavior (not sure if duron works the same way, but I'd expect it to). mem=nopentium will force off large page mode and make the bug much, much rarer (if you see it with this on, buy a lotto ticket). I thought 2.4.19 did this automatically now but nobody else seems to think so, so I may be wrong.
The bug affects windows also, current drivers supposedly work around it the same way mem=nopentium does (by disabling 4meg memory pageing for pages overlapping with AGP). So, though not technically a 'fix' the workound is seems to be quite adequate to prevent the bug from manifesting in real life...
actually, it was only just fixed in linux, and only in a fairly recent 2.4.19-pre (ie in no release yet). Not exactly an Athlon bug, but certainly a very odd caching behavior...
5-600W is a big range. How about some real numbers just for grins :-)
:-)
As viewed from my 650VA UPS (which will tell me the wall power consumption, including all losses in the PSU etc) my dual athlon (2xMP1600) +17" monitor sits at approx 400VA load. When the CPU's idle to C2 (most of the time) it drops about 80VA, and if the monitor sleeps it dropsanother 110VA or so.
So the fixed (ie PSU+HD+video+mobo+CPU idle) comsumption+etc is about 200VA, each CPU is about 40VA (different from C2 idle to max load), and the monitor is about 110VA.
Making the (basically reasonable, though not perfect) assumption that a switching power supply's power factor is close to 1 (shouldn't be far from that I wouldn't think) 1VA=1W. If the power factor is not one, then a VA is less than a watt (ie, all my numbers are too high in that case).
So it's a good heater, but not as bad as you feared. The lights in the room are using as much power as the idling computer, the computer edges them out during a good quakin' session
and bnetd doesn't support WC3. There is some work based on it that does, but their main page clearly stated that the people distributing warcraft3 servers had not released source and were not affiliated with the bnetd project.
esd - yes, it can die. It was only a mixer.
arts - no, and arts likes alsa rather better than it liked OSS. Alsa lets it see much more of the soundcard's abilities, so it can stop doing simple things itself and focus in effects and codec work (ie, it's real purpose).
which would be why it is a capitalized proper noun
he wrote the rmap VM, so he's definitely the right guy to answer a lot of questions about it
:-)
doesn't answer why he's getting modded to high heaven tho