I can't say for sure that Blockbuster has an explicit nationwide policy of not renting out NC-17 movies, but I believe they do.
It may be an explicit "NC-17" marking that triggers the problem. As mentioned above, Blockbuster definitely carries "unrated" versions of some movies. For example just last week I bought used DVDs of "High Tension" and "Lords of Dogtown" at a local Blockbuster, both loudly claiming "UNRATED EDITION" on the front cover.
On the other hand, for a movie like "The Dreamers", which I think has an official "NC-17" on the director's cut instead of just leaving it unrated, I've only seen them carry an R-rated version.
Simple. Same reason you can't buy a PC from Dell without an OS except for a couple of Optiplex lines they target at the corporate users who already have site licenses.
Completely bare workstations may be difficult. They do however sell workstations with
Linux preloaded. They aren't cheap desktops, but they are desktops.
Another data point: from a location near Annapolis, MD, I have occasionally managed to receive solid DTV signals from Philadelphia, PA (a 2.5 hour drive). Meanwhile even analog UHF signals from Washington, DC (a 30 minute drive) can be really difficult to pick up.
If you look at the map you'll see that the line to Philadelphia is almost all over water. There's a low (almost unnoticable) ridge between me and DC, though.
Just a data point: uncompressed SD (standard definition) is 270 Mbit/sec, and uncompressed HD is 1.5 Gbit/sec.
There are industry-standard serial digital protocols and cabling for passing these around in a video production (or high-end home theater) environment. The actual transmit/receive endpoints tend to be fairly expensive, though -- an HD-SDI I/O card can easily cost $1500.
pretty much every compiler around goes through the following steps: (a) make an abstract syntax tree from the source code, (b) optimize it, and (c) output machine code.
I'm not 100% sure about its internal processing, but I believe tcc either skips some of that or has it all so blended together that the steps aren't very distinct.
it's far more useful to support tons of languages at little extra effort than to drop all alternate languages for a minor performance gain.
In the case of tcc, the design and lack of extra functionality (or admittedly even complete standards compliance) provides a huge speedup at compile time.
It's almost shocking to see it blast through code when you're used to working with a recent gcc.
It's so fast that for small programs it can be used as a loader to compile and run C code as if it were a scripting language, with no discernable startup time.
Consider that tcc has demonstrated booting a Linux kernel from source in 15 seconds.
It's not even that. There is nothing about an extra C variable
that necessitates that the variable exist at all in the
generated code. There is nothing that guarantees that the code the
compiler generates bears any resemblance at all to your sourcecode; it
just has to produce the same results. The compiler is free to
reorder, rewrite, and completely remove whatever code it likes, unless
you've done explicit things like use volatile qualifiers to stop it.
gcc for example automatically inlines functions. I think some
compilers have a bunch of "idomatic" things they recognize (that string
copy from K&R would be a good candidate) and will do special things
like perhaps calling strcpy instead of using the code you provided.
Real-life example: I had a benchmark I was using. It did some
basic bit-shifting, logical operations, arithmetic, and other such
things in loops, in order to time some operations. You could feed it
various parameters on the command line at runtime, such as which
algorithm implementation to use, which exact details
(number of iterations, word sizes, etc) of the algorithm you wanted to
test, and so on. This was all spread out across many files, headers,
and object files, with many small functions all calling each other in
various ways. I would run this with various parameters and time how
long it took.
I compiled this benchmark with Intel's C compiler (icc). It
suddenly ran really fast; in fact too fast. Tell it to do
100 billion iterations and it finished instantly. What had happened
is that icc determined that I was never actually using the
results of all those computations, and that there were no
side effects during any of those computations, so it simply removed
all of that from the program. Probably all that was left was the
command-line parser, and I'm not sure if that was even still there
since it only served to provide parameters for code that no longer
existed. C compilers are definitely allowed to do this; I'd just
never encountered one that was so good at it.
I had to go back into that benchmark and rewrite things to ensure
that the results were passed back through the code and used (I think I
just printed them) at the very end, with no way for the compiler to
shortcut the operations.
So when I write C code I usually assume the compiler is going to tear
it apart and rework it as needed. I write the code to be clear and
readable. I throw in a lot of "const" qualifiers to make the
compiler's job easier, and create many single-use variables, because I know the compiler (if it's doing its job) will handle it.
Last I checked, PCL was pretty much the same as postscript and either one required about the same amount of host-side processing.
I've always assumed PCL was a very simple language that required rasterization and processing on the host side to do anything fancy. A quick glance at the PCL manual doesn't obviously indicate any sort of real programming capabilities such as looping and conditional behavior.
I've written label printing programs in PostScript; you specify (within the file) a few simple parameters like the strings to be printed and the rows/columns/margins for a page of labels, and the printer figures out how many pages are needed and where to draw the text on the page. No host software required.
A structured drawing package I used to work with was acutally able to store its drawings as printable PostScript (with embedded comments to make it easier to read back).
I admit that in most cases PostScript is used much like PCL, as a simple move-here draw-letter sort of language; but it does have the ability to do much more than that and people and software do sometimes make use of it.
You can get 3 chips DLP sets out there. Usually 10% more than 1 chip ones.
You sure you don't mean 10 times more? Any particular model numbers you can provide?
A quick search shows 3-chip DLP front projectors starting around $18K and some models are over $100K. Skimming avsforum I see comments from just last week implying that there aren't any 3-chip rear projectors on the market. There are definitely 3-chip LCD and LCoS models, but 3-chip DLP seems to be very rare.
they are using their using Altix system but require an ATI FireGL card.
The very idea of a graphics card in an Altix sounds strange to me, unless perhaps the intent is to use the GPU as a math coprocessor. I guess it depends on the workload you have in mind.
lets say you want to get a cluster with 5 CPU's, along with a host node. each node has a Geforce 6800, 4GB of RAM, 3.6 Ghz CPU's,
Again it depends on the workload. Let's say you want a bunch of CPUs working on a dataset (let's say tens or even hundreds of gigabytes) and you need random access to the data and cross-CPU communication at memory speeds. That's where something like an Altix would come into play.
Without a requirement for large shared memory I'd probably agree that an Altix is not the first choice.
ATSC may require a fixed bitrate, and I think some D-VHS decks are also very picky about this, which is why you might find padding (sometimes quite a lot).
Simulcasting a program in HD and SD would probably be for backwards compatibility with older displays. Some broadcasters also use this ability to send different programs, for example the local PBS station has five subchannels in their stream and they shift the bandwidth allocations around depending on the time of day.
CPU-cycle burning mess
You can demux and filter with very little horsepower, since it doesn't require doing any
MPEG decompression. Stripping out the subprograms you don't want, and removing null packets, can probably be done at recording time with very little overhead. I think the most popular such filter is a Java application, in fact.
decode the video stream into a raw format on disk. Then, play back from the raw format.
Would probably work fine, if you've got 600Gbytes/hour of disk space available.
Uncompressed HD needs around 1.5Gbit/sec. There are systems and software that handle this (intended mainly for studio and production work) but they are very expensive.
I wouldn't be surprised if most modern video cards already come equipped to do MPEG decompression right out of the box.
Many recent cards and drivers support XvMC on Linux, which can be used to hardware-assist MPEG decoding of frames. This mostly works already; it depends on how fast a machine and card you have, and how picky you are about the results.
In the case of the Roku, it has an ATI Xilleon CPU which is specificially designed for this sort of thing. You can pretty much just hand it the entire stream (without demuxing, I think) and it will uncompress and scale the desired subprogram.
forcing the driver either to remain closed
Certainly in the case of the Xilleon, ATI won't tell you squat about how to use it unless you're a partner developer and sign NDAs. They won't even publicly discuss the features present in the chip, so most of what I know about it is based on speculation, inferences from other documents, and a trickle of details from those who do have the knowledge.
No, each channel broadcasts a 19.2 Mbit/sec compressed signal, and you record that directly to disk without decompressing it. It needs about 9 Gbytes/hour.
or a lot of cpu time compressing it to 70 Gigs.
Realtime compression of HDTV is completely infeasible on a home computer. It requires specialized hardware which, if it even exists as something that can be put into a computer, will likely cost tens or hundreds of thousands of dollars. This sort of hardware might exist at the broadcast station, if they want to do things like overlay their logo onto the picture.
Sometimes the data streams contain multiple programs (such as a standard definition simulcast alongside a high definition one). And there might also be null packets to pad out the bitrate. So you can sometimes reduce the storage requirements by filtering out the packets you don't want. There aren't exactly lot of tools on Linux to easily do this, though.
In any case the actual recording doesn't require a very powerful machine at all. I've easily done it with an Athlon 800 while running a desktop full of other applications.
It's the playback of the recorded streams that will cause you trouble. Doing the MPEG decompression to turn the recorded stream into video frames or fields requires a huge amount of horsepower, especially if you actually want to output it at full resolution (since you then have to get all of those decoded pixels into video memory fast enough).
I've tried an Athlon XP 2400+ with an NVIDIA FX5200 with XvMC extensions to do hardware-assisted decompression in the video card, and I still wasn't happy with the results. It could not support 1920x1080 full resolution output without some stuttering in the framerate. The only thing I've found so far that decompressed the video streams really well was the Roku HD1000 set-top box, which has a high definition MPEG decoder integrated into the the CPU. Roku may have other issues with audio decoding and user interface, though.
Bear in mind this is all with Linux. Under Windows there are many other video cards and drivers that claim some level of HD video support, so perhaps it's easier to get good results.
Some consumer devices, such as the Roku Soundbridge, do actually have volume control for their digital audio output. Whether you consider these computers is a judgement call.
However, as you suggest there are issues with specially encoded audio. The Soundbridge normally expects to be handling plain stereo PCM, in which case it can manipulate the digital stream as it passes through. If you want to stream something like DTS or AC3 through it, you have to set the volume to 100% and it will then pass the data through without trying to interpret it.
HDTV is 1080 interlaced lines of resolution. Spider-Man was filmed in 35mm film. It would take 4000+ lines of resolution to match the virgin film stock.
Well, since it's an effects-laden movie, there are probably
plenty of scenes that are no longer anywhere near the original film stock resolution.
But more likely the real issue is the contrast ratio and the settings on the display. The video (even HD) isn't going to have the dynamic range of the film, and the display settings can easily make this even worse. I recall seeing old video tranfers of sci-fi movies where the mattes for spaceships were blatantly obvious, whereas they were probably nearly invisible in a theatrical presentation.
In college, my prof made us write a game in LISP just to prove that some languages are bad at certain things.
Just a data point: Naughty Dog is well-known for the heavy use of Lisp (an in-house dialect called GOAL) in their games, including the Crash Bandicoot and Jak and Daxter series.
so it wouldn't make much sense to "upscale" those--you wouldn't get any better quality than the original SD video.
Big-screen TVs have to apply an internal scaler to incoming standard definition signals. Otherwise they'd have problems with visible scan lines. If you can feed the TV a high-definition signal, you can bypass the TV's internal scaler or at least have more control over how the scaling is done.
For example if your DVD player has a better scaler than the TV, then you probably want to use that instead. This is similar to S-Video output on a Laserdisc player, which in theory provides no benefit but in practice lets you choose between the player's comb filter and the TV's comb filter.
Even if your DVD player's scaler is the same quality as the TV's, doing it in the player is probably still a better choice. The DVD's scaler gets to work with the original digital image. The TV's scaler starts with the SD video which has already gone through a lossy digital-analog-digital conversion.
A similar option is to modify a DVD player to output SDI, which is the sort of fully-digital unencrypted standard definition video normally used in video production environments. You can feed SDI into an outboard scaler -- companies like Extron and Key Digital make these -- or use an SDI input card to make a computer-based scaler.
Uhh, anything with that kind of uptime almost by definition has to be a clustered system.
Or just reasonable hardware. For a project I helped set up around 1998, we put a bunch of Sparc/Solaris systems -- desktop models, some of which were already several years old at the time -- in a data center rack and started various server packages on them. I wouldn't call these clustered, as each is doing a different set of tasks. I took a quick peek last month and I believe some of them hadn't been rebooted since the Y2K patches were applied over 4 years ago.
I am aware of other desktop-model Sparcstations that have been rebooted occasionally but their total power-off time is probably less than 2 hours since they were unpacked in 1995.
BTW: it's easy to demonstrate that aluminum and magnets can interact with each other.
Get a really, really strong magnet.
For example a rare earth magnet from a hard drive head actuator (early 1990's drives with lots of platters are great for this).
Then find something flat made of aluminum, such as a screen door.
Place magnet on aluminum. As expected, it won't
stick.
Now slide the magnet on the aluminum surface.
If the magnet is strong enough, you'll feel it resist the movement. The faster you move it, the harder it'll resist. This should work just as well with copper and other non-ferrous metals.
The motion of the magnet's field through the aluminum generates eddy currents (which other people have mentioned) and a corresponding magnetic field within the aluminum. Google for "magnetic braking" for real applications of this effect.
How you could use this to build a CD rail gun, however, I don't know.
I don't care so much about have a big monitor. What I really want are lots of pixels. A 10" monitor with 200ppi would give me a 1600x1200 display!
Dell claims to have a variety of laptops with 15.4" 1920x1200 (WUXGA) displays. That's about 125ppi.
For some reason they don't offer equivalent densities and resolutions on standalone LCD panels -- only when it's part of a laptop. You can't get 1600x1200 in a standalone from Dell without going to at least 20". Granted that 20" is a very nice display, but I'm already running 1920x1440 on 19" CRTs so in some ways it'd end up being a step down.
I have a Sun SparcStation 10 sitting behind me. It was manufactured in 1993. [...] The SparcStation 2, 10, 20, and several others all supported this kind of configuration. You connect the keyboard and mouse into the monitor rather than the system itself.
I don't recall the "connect into the monitor" configuration, but I'm certainly no expert.
In the case of the Sparc 20, there's usually a keyboard+mouse port and a single video port on the motherboard. To enable the video port requires a special video card which also occupies one of the RAM slots; a more common configuration (at least where I worked) would instead leave that video connection unused and have an SBus card such as a CG6 to provide 8-bit video output.
I still use this SparcStation today. It has a HUGE 128MB of RAM (all eight 200pin SIMM slots filled), a 50Mhz processor,
I think you can put a lot more RAM in there if you can get larger chips.
Up until two weeks ago my primary desktop at work was a dual-75MHz Sparcstation 20 maxed out with 448M of RAM and a 24-bit graphics card (occupying the final RAM slot). It may be about 10 years old but it worked like a champ. With the home directory and most applications on local disk, plus all that lovely lovely RAM, it easily felt faster than much newer systems that were pulling everything over NFS.
a 10baseT build in Ethernet port.
They did make SBus cards with 100baseT ports.
At the very least there was a 4-port Ethernet model (it came in both 10 and 100baseT versions) and a combo Ethernet+SCSI card. eBay has both types but you could probably buy several entire machines for the price of one of those quad cards:-)
However running multiple instances of X on a single computer is pretty new.
Nope. Several years ago I used to regularly log
into a friend's machine when he was away from the console (but still logged in) by temporarily running a second X server under my own uid.
I believe the procedure went like this:
CTRL-ALT-F2 log in as me startx --:1
When I was done I just logged out and switched it back to his still-running X server.
Note that running two X servers as the same uid on the same machine at once can get a little tricky. The X server itself shouldn't care, but sometimes the desktop system (session manager, panel, whatever) might get confused if it sets up a single commmunications channel for each user.
I've seen some weird behavior in this situation, such as the "log out" panel applet on the second display sending a message to the session manager on the first display. If you're running just a bare window manager then it shouldn't be a problem.
On one machine I had a script to start a second medium-res X server with 3D acceleration enabled, because the old graphics card doesn't have enough memory to accelerate my primary high-resolution desktop. Both could be running at once (against the same video card), and I could switch back and forth between them to do OpenGL stuff.
Multiple screens and/or servers on the same box
has been readily supported by the X11 libs and protocol for 15+ years. That's one of the reasons why you have to specify the display number when making a connection.
Slashdot Mirror
I can't say for sure that Blockbuster has an explicit nationwide policy of not renting out NC-17 movies, but I believe they do.
It may be an explicit "NC-17" marking that triggers the problem. As mentioned above, Blockbuster definitely carries "unrated" versions of some movies. For example just last week I bought used DVDs of "High Tension" and "Lords of Dogtown" at a local Blockbuster, both loudly claiming "UNRATED EDITION" on the front cover.
On the other hand, for a movie like "The Dreamers", which I think has an official "NC-17" on the director's cut instead of just leaving it unrated, I've only seen them carry an R-rated version.Completely bare workstations may be difficult. They do however sell workstations with Linux preloaded. They aren't cheap desktops, but they are desktops.
Another data point: from a location near Annapolis, MD, I have occasionally managed to receive solid DTV signals from Philadelphia, PA (a 2.5 hour drive). Meanwhile even analog UHF signals from Washington, DC (a 30 minute drive) can be really difficult to pick up.
If you look at the map you'll see that the line to Philadelphia is almost all over water. There's a low (almost unnoticable) ridge between me and DC, though.
SGI sells single machines with up to 16 GPUs and 96 PCI-X slots. Granted, they are a tad bit more expensive than your average desktop system.
Just a data point: uncompressed SD (standard definition) is 270 Mbit/sec, and uncompressed HD is 1.5 Gbit/sec.
There are industry-standard serial digital protocols and cabling for passing these around in a video production (or high-end home theater) environment. The actual transmit/receive endpoints tend to be fairly expensive, though -- an HD-SDI I/O card can easily cost $1500.
pretty much every compiler around goes through the following steps: (a) make an abstract syntax tree from the source code, (b) optimize it, and (c) output machine code.
I'm not 100% sure about its internal processing, but I believe tcc either skips some of that or has it all so blended together that the steps aren't very distinct.
it's far more useful to support tons of languages at little extra effort than to drop all alternate languages for a minor performance gain.
In the case of tcc, the design and lack of extra functionality (or admittedly even complete standards compliance) provides a huge speedup at compile time. It's almost shocking to see it blast through code when you're used to working with a recent gcc.
It's so fast that for small programs it can be used as a loader to compile and run C code as if it were a scripting language, with no discernable startup time. Consider that tcc has demonstrated booting a Linux kernel from source in 15 seconds.
It's not even that. There is nothing about an extra C variable that necessitates that the variable exist at all in the generated code. There is nothing that guarantees that the code the compiler generates bears any resemblance at all to your sourcecode; it just has to produce the same results. The compiler is free to reorder, rewrite, and completely remove whatever code it likes, unless you've done explicit things like use volatile qualifiers to stop it.
gcc for example automatically inlines functions. I think some compilers have a bunch of "idomatic" things they recognize (that string copy from K&R would be a good candidate) and will do special things like perhaps calling strcpy instead of using the code you provided.
Real-life example: I had a benchmark I was using. It did some basic bit-shifting, logical operations, arithmetic, and other such things in loops, in order to time some operations. You could feed it various parameters on the command line at runtime, such as which algorithm implementation to use, which exact details (number of iterations, word sizes, etc) of the algorithm you wanted to test, and so on. This was all spread out across many files, headers, and object files, with many small functions all calling each other in various ways. I would run this with various parameters and time how long it took.
I compiled this benchmark with Intel's C compiler (icc). It suddenly ran really fast; in fact too fast. Tell it to do 100 billion iterations and it finished instantly. What had happened is that icc determined that I was never actually using the results of all those computations, and that there were no side effects during any of those computations, so it simply removed all of that from the program. Probably all that was left was the command-line parser, and I'm not sure if that was even still there since it only served to provide parameters for code that no longer existed. C compilers are definitely allowed to do this; I'd just never encountered one that was so good at it.
I had to go back into that benchmark and rewrite things to ensure that the results were passed back through the code and used (I think I just printed them) at the very end, with no way for the compiler to shortcut the operations.
So when I write C code I usually assume the compiler is going to tear it apart and rework it as needed. I write the code to be clear and readable. I throw in a lot of "const" qualifiers to make the compiler's job easier, and create many single-use variables, because I know the compiler (if it's doing its job) will handle it.
I've always assumed PCL was a very simple language that required rasterization and processing on the host side to do anything fancy. A quick glance at the PCL manual doesn't obviously indicate any sort of real programming capabilities such as looping and conditional behavior.
I've written label printing programs in PostScript; you specify (within the file) a few simple parameters like the strings to be printed and the rows/columns/margins for a page of labels, and the printer figures out how many pages are needed and where to draw the text on the page. No host software required.
A structured drawing package I used to work with was acutally able to store its drawings as printable PostScript (with embedded comments to make it easier to read back).
I admit that in most cases PostScript is used much like PCL, as a simple move-here draw-letter sort of language; but it does have the ability to do much more than that and people and software do sometimes make use of it.
I believe that's primarily a Solaris convention, not a Unix one (and definitely not a Linux one).
Another one: Audi, Bentley, Bugatti, Lamborghini, Seat, and Skoda are all owned by Volkswagen AG.
According to Wikipedia, Volkswagen and BMW have some sort of joint agreement regarding the Rolls-Royce business and trademarks.
You sure you don't mean 10 times more? Any particular model numbers you can provide?
A quick search shows 3-chip DLP front projectors starting around $18K and some models are over $100K. Skimming avsforum I see comments from just last week implying that there aren't any 3-chip rear projectors on the market. There are definitely 3-chip LCD and LCoS models, but 3-chip DLP seems to be very rare.
they are using their using Altix system but require an ATI FireGL card.
The very idea of a graphics card in an Altix sounds strange to me, unless perhaps the intent is to use the GPU as a math coprocessor. I guess it depends on the workload you have in mind.
lets say you want to get a cluster with 5 CPU's, along with a host node. each node has a Geforce 6800, 4GB of RAM, 3.6 Ghz CPU's,
Again it depends on the workload. Let's say you want a bunch of CPUs working on a dataset (let's say tens or even hundreds of gigabytes) and you need random access to the data and cross-CPU communication at memory speeds. That's where something like an Altix would come into play.
Without a requirement for large shared memory I'd probably agree that an Altix is not the first choice.
but it's a bandwidth-hogging,
ATSC may require a fixed bitrate, and I think some D-VHS decks are also very picky about this, which is why you might find padding (sometimes quite a lot).
Simulcasting a program in HD and SD would probably be for backwards compatibility with older displays. Some broadcasters also use this ability to send different programs, for example the local PBS station has five subchannels in their stream and they shift the bandwidth allocations around depending on the time of day.
CPU-cycle burning mess
You can demux and filter with very little horsepower, since it doesn't require doing any MPEG decompression. Stripping out the subprograms you don't want, and removing null packets, can probably be done at recording time with very little overhead. I think the most popular such filter is a Java application, in fact.
decode the video stream into a raw format on disk. Then, play back from the raw format.
Would probably work fine, if you've got 600Gbytes/hour of disk space available. Uncompressed HD needs around 1.5Gbit/sec. There are systems and software that handle this (intended mainly for studio and production work) but they are very expensive.
I wouldn't be surprised if most modern video cards already come equipped to do MPEG decompression right out of the box.
Many recent cards and drivers support XvMC on Linux, which can be used to hardware-assist MPEG decoding of frames. This mostly works already; it depends on how fast a machine and card you have, and how picky you are about the results.
In the case of the Roku, it has an ATI Xilleon CPU which is specificially designed for this sort of thing. You can pretty much just hand it the entire stream (without demuxing, I think) and it will uncompress and scale the desired subprogram.
forcing the driver either to remain closed
Certainly in the case of the Xilleon, ATI won't tell you squat about how to use it unless you're a partner developer and sign NDAs. They won't even publicly discuss the features present in the chip, so most of what I know about it is based on speculation, inferences from other documents, and a trickle of details from those who do have the knowledge.
If 1080i blasts out at 200 Megs per second
No, each channel broadcasts a 19.2 Mbit/sec compressed signal, and you record that directly to disk without decompressing it. It needs about 9 Gbytes/hour.
or a lot of cpu time compressing it to 70 Gigs.Realtime compression of HDTV is completely infeasible on a home computer. It requires specialized hardware which, if it even exists as something that can be put into a computer, will likely cost tens or hundreds of thousands of dollars. This sort of hardware might exist at the broadcast station, if they want to do things like overlay their logo onto the picture.
Sometimes the data streams contain multiple programs (such as a standard definition simulcast alongside a high definition one). And there might also be null packets to pad out the bitrate. So you can sometimes reduce the storage requirements by filtering out the packets you don't want. There aren't exactly lot of tools on Linux to easily do this, though.
In any case the actual recording doesn't require a very powerful machine at all. I've easily done it with an Athlon 800 while running a desktop full of other applications.
It's the playback of the recorded streams that will cause you trouble. Doing the MPEG decompression to turn the recorded stream into video frames or fields requires a huge amount of horsepower, especially if you actually want to output it at full resolution (since you then have to get all of those decoded pixels into video memory fast enough).
I've tried an Athlon XP 2400+ with an NVIDIA FX5200 with XvMC extensions to do hardware-assisted decompression in the video card, and I still wasn't happy with the results. It could not support 1920x1080 full resolution output without some stuttering in the framerate. The only thing I've found so far that decompressed the video streams really well was the Roku HD1000 set-top box, which has a high definition MPEG decoder integrated into the the CPU. Roku may have other issues with audio decoding and user interface, though.
Bear in mind this is all with Linux. Under Windows there are many other video cards and drivers that claim some level of HD video support, so perhaps it's easier to get good results.
The ultimate would be to compile the program while you run it, i.e. a JIT C compiler.
DynamoRIO
Some consumer devices, such as the Roku Soundbridge, do actually have volume control for their digital audio output. Whether you consider these computers is a judgement call.
However, as you suggest there are issues with specially encoded audio. The Soundbridge normally expects to be handling plain stereo PCM, in which case it can manipulate the digital stream as it passes through. If you want to stream something like DTS or AC3 through it, you have to set the volume to 100% and it will then pass the data through without trying to interpret it.
Well, since it's an effects-laden movie, there are probably plenty of scenes that are no longer anywhere near the original film stock resolution.
But more likely the real issue is the contrast ratio and the settings on the display. The video (even HD) isn't going to have the dynamic range of the film, and the display settings can easily make this even worse. I recall seeing old video tranfers of sci-fi movies where the mattes for spaceships were blatantly obvious, whereas they were probably nearly invisible in a theatrical presentation.
In college, my prof made us write a game in LISP just to prove that some languages are bad at certain things.
Just a data point: Naughty Dog is well-known for the heavy use of Lisp (an in-house dialect called GOAL) in their games, including the Crash Bandicoot and Jak and Daxter series.
Big-screen TVs have to apply an internal scaler to incoming standard definition signals. Otherwise they'd have problems with visible scan lines. If you can feed the TV a high-definition signal, you can bypass the TV's internal scaler or at least have more control over how the scaling is done.
For example if your DVD player has a better scaler than the TV, then you probably want to use that instead. This is similar to S-Video output on a Laserdisc player, which in theory provides no benefit but in practice lets you choose between the player's comb filter and the TV's comb filter.
Even if your DVD player's scaler is the same quality as the TV's, doing it in the player is probably still a better choice. The DVD's scaler gets to work with the original digital image. The TV's scaler starts with the SD video which has already gone through a lossy digital-analog-digital conversion.
A similar option is to modify a DVD player to output SDI, which is the sort of fully-digital unencrypted standard definition video normally used in video production environments. You can feed SDI into an outboard scaler -- companies like Extron and Key Digital make these -- or use an SDI input card to make a computer-based scaler.
Or just reasonable hardware. For a project I helped set up around 1998, we put a bunch of Sparc/Solaris systems -- desktop models, some of which were already several years old at the time -- in a data center rack and started various server packages on them. I wouldn't call these clustered, as each is doing a different set of tasks. I took a quick peek last month and I believe some of them hadn't been rebooted since the Y2K patches were applied over 4 years ago.
I am aware of other desktop-model Sparcstations that have been rebooted occasionally but their total power-off time is probably less than 2 hours since they were unpacked in 1995.
The things are built like tanks.
BTW: it's easy to demonstrate that aluminum and magnets can interact with each other.
Get a really, really strong magnet. For example a rare earth magnet from a hard drive head actuator (early 1990's drives with lots of platters are great for this). Then find something flat made of aluminum, such as a screen door. Place magnet on aluminum. As expected, it won't stick.
Now slide the magnet on the aluminum surface. If the magnet is strong enough, you'll feel it resist the movement. The faster you move it, the harder it'll resist. This should work just as well with copper and other non-ferrous metals. The motion of the magnet's field through the aluminum generates eddy currents (which other people have mentioned) and a corresponding magnetic field within the aluminum. Google for "magnetic braking" for real applications of this effect.How you could use this to build a CD rail gun, however, I don't know.
The Tracer Gun is sort of like this, on a much smaller scale.
Dell claims to have a variety of laptops with 15.4" 1920x1200 (WUXGA) displays. That's about 125ppi.
For some reason they don't offer equivalent densities and resolutions on standalone LCD panels -- only when it's part of a laptop. You can't get 1600x1200 in a standalone from Dell without going to at least 20". Granted that 20" is a very nice display, but I'm already running 1920x1440 on 19" CRTs so in some ways it'd end up being a step down.
I don't recall the "connect into the monitor" configuration, but I'm certainly no expert. In the case of the Sparc 20, there's usually a keyboard+mouse port and a single video port on the motherboard. To enable the video port requires a special video card which also occupies one of the RAM slots; a more common configuration (at least where I worked) would instead leave that video connection unused and have an SBus card such as a CG6 to provide 8-bit video output.
I think you can put a lot more RAM in there if you can get larger chips.
Up until two weeks ago my primary desktop at work was a dual-75MHz Sparcstation 20 maxed out with 448M of RAM and a 24-bit graphics card (occupying the final RAM slot). It may be about 10 years old but it worked like a champ. With the home directory and most applications on local disk, plus all that lovely lovely RAM, it easily felt faster than much newer systems that were pulling everything over NFS.
They did make SBus cards with 100baseT ports. At the very least there was a 4-port Ethernet model (it came in both 10 and 100baseT versions) and a combo Ethernet+SCSI card. eBay has both types but you could probably buy several entire machines for the price of one of those quad cards :-)
Nope. Several years ago I used to regularly log into a friend's machine when he was away from the console (but still logged in) by temporarily running a second X server under my own uid. I believe the procedure went like this:
When I was done I just logged out and switched it back to his still-running X server.
Note that running two X servers as the same uid on the same machine at once can get a little tricky. The X server itself shouldn't care, but sometimes the desktop system (session manager, panel, whatever) might get confused if it sets up a single commmunications channel for each user. I've seen some weird behavior in this situation, such as the "log out" panel applet on the second display sending a message to the session manager on the first display. If you're running just a bare window manager then it shouldn't be a problem.
On one machine I had a script to start a second medium-res X server with 3D acceleration enabled, because the old graphics card doesn't have enough memory to accelerate my primary high-resolution desktop. Both could be running at once (against the same video card), and I could switch back and forth between them to do OpenGL stuff.
Multiple screens and/or servers on the same box has been readily supported by the X11 libs and protocol for 15+ years. That's one of the reasons why you have to specify the display number when making a connection.