Imagine ImageMagick ported to that... No really, I've been waiting ~15 minutes for the output of identify -verbose on a 25MPixel 48bit RGB image. I'm sure glad I didn't use the 100MPixel scan.
But it will run Duke Nukem really smoothly until enough silicon decays into phosphorus to make it stop running, or the owner gets tired of Duke Nukem, whichever comes first.
Most likely 4d single precision vectors or 2d double precision vectors if they want to market it to researchers who had been cooking their own stream processors from FPGAs
Data-Journalled filesystems (eg Reiser4) keep data in the journal too, not just metadata (those are metadata-journaled filesystems eg Ext3FS), so each block may have parts of several files, and each file may be spread across many more blocks than it would fill on it's own.
You eventually have to consolidate the data of each file. Not nescesarily to sequential blocks, but so files are not sharing blocks.
For flash memory, non-journalled filesystems like Ext2 (mounted -o noatime) may be best. Although that still tries to keep large chunks of files sequential. It might be better to have a non-journalled filesystem that does not pre-allocate inodes and data blocks, but just keeps a free block list and allocates from it in Least-Recently-Used order.
Some filesystems (ie Reiser4) move or consolidate files (aka "defrag") in the background , and don't know what kind of block device they're on. You'd want to tell it not to do bother doing that then. Except the kernel/ATA interface still reads and writes by the block, but a block in some filesystems (Reiser4) may contain parts of several files, so you'd want to eventually consolidate files so you don't have to read/write a whole lot of blocks to access a single file which might be smaller than a block.
A worst case scenario would be a filesystem similar to Reiser4 with consolidation turned off, and lots of files growing by small amounts frequently.
Flash memory that works has a much longer MTBF than hard drives, but each cell fails at approximately 10000 writes. HDDs fail randomly, Flash fails predictably, so this can be a good thing. Just make sure your filesystem rarely does or needs defragging, and does not log every read.
They market them in different market segments. If they did that with identical chips, people would cry foul.
It may also be that they have multiple shader units and the ones that have more shaders fail get down-graded and sold at a lower price. Thus increasing process yields since they have to throw out fewer chips. Sort of like the difference between a 386/33 and a 386/25 in the old days.
With Qt4 out and KDE 4 in the works, this card amy just hit the spot for a non-gaming desktop. Just enough 3d goodness to speed things up, but no overkill.
He's a reviewer. Would you want the review of someone who's not tried a bunch of distributions? How would they know if it was good? Chances are pretty good it's a testing machine, but his desktop doesn't change as often.
Just like the Car and Driver writers probably have their own reliable car that they use to get groceries, even though they get to try out all kinds of new ones.
Does he have this concern with soundcards, HDD controllers and network cards too? They've all got DMA capability, coprocessors, and firmware. Network cards even have network connectivity, making them potentially WAY more dangerous than a video card.
Give the character an Omnicient (in the now) TARDIS that's very precice, but very brief in what it tells them. Tell them to go back into the past to right some minor wrong that snowballs into world-changing events, like burning down a minor library or something. Then watch as they keep going back in time just far enough to cause the events they're observing.
Player1:
Tardis, where is player 2 right now and what is she doing?
Tardis:
3.2 kilometers, 30degrees east-north-east of our current time-position, rolling over and over and over
Player1:
Take me there.
Tardis:
When?
Player1:
15 seconds Ago.
Tardis appears in the middle of the road directly in front of Player2's truck...
Player2:
Meeeerde! (fails driving check...)
Non-root, user-level access to IO ports (by authorized programs) is not evil; it's what allows non-kernel level display servers. It keeps some really complicated stuff out of the kernel, thus improving system stability.
I've been using it for a dreadfully long time (fortunately, with a couple of breaks) and I've never found it ugly. It is functional. It does exacly what it's supposed to, without embellishment, and without confusion. This is ellegance. The only thing about it that I find ugly is the needless stock photography at the top of the page.
Slashdot Mirror
There are schools in Jordan and Syria.
But it could, as most of it's algorythms are highly parallelizeable, and modern graphics cards can be used as stream processors.
Imagine ImageMagick ported to that... No really, I've been waiting ~15 minutes for the output of identify -verbose on a 25MPixel 48bit RGB image. I'm sure glad I didn't use the 100MPixel scan.
But it will run Duke Nukem really smoothly until enough silicon decays into phosphorus to make it stop running, or the owner gets tired of Duke Nukem, whichever comes first.
Most likely 4d single precision vectors or 2d double precision vectors if they want to market it to researchers who had been cooking their own stream processors from FPGAs
Stream processor, not vector processor. The programming models are different.
Datasheet for AT29C256. It's an old design though.
Data-Journalled filesystems (eg Reiser4) keep data in the journal too, not just metadata (those are metadata-journaled filesystems eg Ext3FS), so each block may have parts of several files, and each file may be spread across many more blocks than it would fill on it's own.
You eventually have to consolidate the data of each file. Not nescesarily to sequential blocks, but so files are not sharing blocks.
For flash memory, non-journalled filesystems like Ext2 (mounted -o noatime) may be best. Although that still tries to keep large chunks of files sequential. It might be better to have a non-journalled filesystem that does not pre-allocate inodes and data blocks, but just keeps a free block list and allocates from it in Least-Recently-Used order.
On my G4 iBook, for instance, it fails.
Assuming your filesystem keeps parts of only a single file in each block. Not all filesystems do.
On Data-Journaled filesystems, yes.
Some filesystems (ie Reiser4) move or consolidate files (aka "defrag") in the background , and don't know what kind of block device they're on. You'd want to tell it not to do bother doing that then. Except the kernel/ATA interface still reads and writes by the block, but a block in some filesystems (Reiser4) may contain parts of several files, so you'd want to eventually consolidate files so you don't have to read/write a whole lot of blocks to access a single file which might be smaller than a block.
A worst case scenario would be a filesystem similar to Reiser4 with consolidation turned off, and lots of files growing by small amounts frequently.
Flash memory that works has a much longer MTBF than hard drives, but each cell fails at approximately 10000 writes. HDDs fail randomly, Flash fails predictably, so this can be a good thing. Just make sure your filesystem rarely does or needs defragging, and does not log every read.
That's nothing... Gentoo's already up to 2006.0 .
They market them in different market segments. If they did that with identical chips, people would cry foul.
It may also be that they have multiple shader units and the ones that have more shaders fail get down-graded and sold at a lower price. Thus increasing process yields since they have to throw out fewer chips. Sort of like the difference between a 386/33 and a 386/25 in the old days.
And this is ifferent from Debian, Ubuntu, FreeBSD, Gentoo, etc... because?
With Qt4 out and KDE 4 in the works, this card amy just hit the spot for a non-gaming desktop. Just enough 3d goodness to speed things up, but no overkill.
He's a reviewer. Would you want the review of someone who's not tried a bunch of distributions? How would they know if it was good? Chances are pretty good it's a testing machine, but his desktop doesn't change as often.
Just like the Car and Driver writers probably have their own reliable car that they use to get groceries, even though they get to try out all kinds of new ones.
Does he have this concern with soundcards, HDD controllers and network cards too? They've all got DMA capability, coprocessors, and firmware. Network cards even have network connectivity, making them potentially WAY more dangerous than a video card.
It's raining IT Security Surveys
Hallelujah
It's raining IT Security Surveys
Just doesn't work.
Give the character an Omnicient (in the now) TARDIS that's very precice, but very brief in what it tells them. Tell them to go back into the past to right some minor wrong that snowballs into world-changing events, like burning down a minor library or something. Then watch as they keep going back in time just far enough to cause the events they're observing.
Player1: Tardis, where is player 2 right now and what is she doing? Tardis: 3.2 kilometers, 30degrees east-north-east of our current time-position, rolling over and over and over Player1: Take me there. Tardis: When? Player1: 15 seconds Ago. Tardis appears in the middle of the road directly in front of Player2's truck... Player2: Meeeerde! (fails driving check...)
Non-root, user-level access to IO ports (by authorized programs) is not evil; it's what allows non-kernel level display servers. It keeps some really complicated stuff out of the kernel, thus improving system stability.
www.gpgpu.org
Why does this require SLI? You can do stream processing on most relatively-modern accelerated 3d video cards.
I've been using it for a dreadfully long time (fortunately, with a couple of breaks) and I've never found it ugly. It is functional. It does exacly what it's supposed to, without embellishment, and without confusion. This is ellegance. The only thing about it that I find ugly is the needless stock photography at the top of the page.