I would go even further and set up a separate checking account at your bank specifically for PayPal transactions. Remember, PayPal has your checking account info, so they can theoretically withdraw everything from it at any time. (they shouldn't, but given PayPal's record, I wouldn't trust them to keep my lunch money from being stolen).
(my PayPal story - accepted $10 in payment for an item, sent item, got a chargeback AFTER it shipped via untraceable mail, so I'm out the $10, the item, AND the chargeback fee. All for *accepting* a small payment. Thanks, PayPal!)
Your analysis of SS2 is interesting. Personally I was disappointed that it was much easier to win the game as a military/gunfighter character than either of the more "interesting" choices. I remember thinking psi was really cool, but once you get the assault rifle it's trivial. I guess this is a balance problem common to games with complex character systems. There isn't enough time for the developers to iron-clad the game against "exploits" that hard-core gamers will find (e.g. a single skill that's far more useful but cheaper than others).
Fallout Tactics was that way too. It had the entire Fallout character system, but the game seemed to favor sniper/gunfighter types to an extreme extent. (I think there was only one place in the game that required the Science skill).
My personal favorite "open-ended" game was X-Com (the original). The best part was that your only goal was "defend earth from the aliens," and while it always involved doing certain specific things over and over again, there was enough variety in the research and character-development systems to make it worth playing through several times.
This was a long time ago, I think it was either a very late XFree 3.3 or a very early 4.0.
I did traces using one of those kernel-level toolkits that logs interupts and system calls. The most significant problem I noticed was that the X server ignored something like 10% of the mouse interrupts. Also X would sometimes try to update the display twice during one monitor refresh. This causes the "sticky/jumpy" feeling of mouse movement in X compared to Windows. (laggy window movement and resizing is another, unrelated problem, caused by lack of synchronization between clients and the window manager)
I should note that I was just looking at the standard X desktop behavior. I did not investigate the DGA extension. Still I was surprised at how sub-optimal the default behavior was.
I was using a USB mouse which sent interrupts at a fixed frequency (120Hz I think). I tried dropping my monitor resolution so that I could use this as a refresh rate, and that made a big improvement.
I have a feeling that while Linux is probably faster at the "output" side of things (OpenGL rendering, memory management, etc), it might be hobbled at the "input" side (sampling the mouse location). I did some investigations years ago into why XFree86 feels so unresponsive compared to Windows, and discovered some truly horrible stuff going on with the mouse sampling (e.g. X ignoring or doubling mouse updates here and there). I don't know if the kernel side of mouse/keyboard input has been tuned for low latency either. This could easily lead to an impression of sluggishness even if the rendering speed is higher than on Windows.
Would it be too much to ask to get new formats implemented as extensions to suitable existing ones like TIFF or OpenEXR? I can think of very few file-format requirements that can't be taken care of just by adding new metadata tags, pixel formats, or compression algorithms to one of these formats.
(both TIFF and EXR support arbitrary bit depths, channels, and pluggable compression algorithms)
You would have a problem with backwards compatibility - e.g. "I thought Photoshop can open TIFF files, why can't it read this one my new camera spit out?". However this has sort of been the case with TIFF for a while. (virtually no commercial apps actually support *all* possible pixel formats/compression modes of TIFF, the usual culprits being LZW compression or >8bit channels)
Using an existing format has the advantage that all the nitty-gritty of handling metadata has already been hammered out, and most of the common tags are widely recognized. Also you get existing "advanced" features like tiled or multi-resolution images, compression blocking, etc for free. Whereas these would have to be coded and tested one by one for a new format.
I have a JVC D-VHS recorder. It will happily record unencrypted MPEG-2 on the FireWire input.
(However, this is sort of a moot point, since it is almost impossible to find a cable/satellite service that will deliver unencrypted video via FireWire. The only one I know of is a certain hardware-modded satellite receiver)
I wouldn't single out JVC though. D-VHS has been available for at least a year; back when it came out, none of the other interfaces like DVI were standardized yet. You will never see a consumer unit that records via analog HD YPbPr anyway. It will either be encrypted FireWire or (more likely) encrypted DVI.
Regardless of benchmarks, I consider the nasty backwards compatibility issues of GCC a serious problem. Virtually all of my Linux tech support time over the last two years has been spent messing with libstdc++ or libgcc_s versions to get various software packages to run. The problem is exacerbated because these libraries in turn are coupled tightly to glibc and pthreads, leading to more versioning headaches. My #1 wish for GCC is to get these libraries set in stone and make them as independent of glibc/pthread versioning as possible. I really want to be able to install a random C++ binary and have it work the first time.
Also, the ability to compile a C++ DSO without requiring the exact same compiler version as the program that will load it, is a major need for commercial Linux software vendors.
Depending on whom you ask, and on the quality of the processing, 35mm film has equivalent resolution to a 800 to 4,000 pixel wide digital image. Even the worst 35mm material has finer detail and greater dynamic range than can be captured on 720x486 NTSC video. 1920x1080 HD video captures a lot more of that detail. For most 35mm films, HD probably gives you all the useful data you're going to get from the print. In rare cases there may be need for a higher-resolution digital capture, or one with higher dynamic range. This could be useful for future display devices.
If you are curious, try the "T2: Extreme DVD", it includes an HD version of the film at something like 1280x600 compressed with the WMV9 codec. It looks a lot better than the NTSC DVD version.
In George Lucas' interview with Charlie Rose two days ago, he very firmly stated "no more Star Wars movies," he wants to do other films. Take that for what it's worth...
1080p60 is just slightly beyond the bandwidth capabilities of current video tape technology. There is presently no way to do it on 1/2" video tape without applying an excessive amount of lossy compression. Plus you have the problem that very little (no?) editing or display equipment supports 1080p60.
I doubt you will see 1080p24 consumer cameras offered soon, out of fear that they would cut into sales of professional 24p cameras.
The HDV spec involves super-lossy compression so it won't really hold up to the established HD formats. However, it should look excellent when down-sampled to NTSC/PAL resolution. (down-sampling will minimize CCD noise and compression artifacts). That might be the primary use of this camera - a cheap substitute for Digital Betacam, or a superior replacement for standard DV.
I would like to see more focus on delivering a higher-quality audio path from game developer to consumer, as opposed to gimmicky post-processing to make things sound "better". (e.g. we want to deliver N channels of 24-bit/96KHz audio with low CPU overhead, rather than a DSP that tries to "enhance" existing audio). Real-time Dolby Digital encoding is great, funky "spatialization" of 2-channel audio is not.
Not to name names, but I have switched away from a formerly reliable company's sound hardware because they got too "creative" (ahem) with their gimmicks and forgot about the basics.
Don't advertise version number
on
Hardening Apache
·
· Score: 5, Insightful
I wish web servers wouldn't advertise their version number be default (e.g. in directory listings or HTTP headers). It's like giving an attacker an exact list of the exploits that will work on your server.
Re:Whose task is copy&paste
on
The Power of X
·
· Score: 1
If you mount tmpfs (or is it shmfs?) on/tmp, you get persistent (until reboot) file storage that is backed by the system page file.
Nobody takes on a project without having a fallback approach. I am absolutely sure their attitude was "we'd LIKE to develop a nice new water system, but if we HAVE to, we'll just use good old displacement maps (or whatever)."
Currently PRMan is the de-facto fallback for pretty much every big studio that doesn't have its own renderer.*
I am in the position right now of trying out several renderers but I almost always have to fall back to PRMan. It's nice to test out new software in the confined environment of one element in one shot. But there is a HUGE leap between "just testing" and "relying on as a fallback." I can do an element in Aqsis or Pixie and have fun with it, but when something breaks it's back to PRMan.
*(which is another interesting note: PDI/Dreamworks and Blue Sky both developed their own renderers which are probably just as sophisticated as PRMan, yet you don't hear much about these because they are not sold as products. So there is some precedent for putting together a production renderer on your own. On the other hand, both of these studios probably consider their software a competitive advantage and would not be willing to give it away)
I highly doubt Pixar would just throw away the $10 million they make annually from PRMan..
I think there is room in the market for a lower-cost or open-source drop-in replacement, but it's a chicken-and-egg problem. Studios cannot use a renderer that is not "production-quality" (by which I mean all the tiny little corner cases and rarely-used code paths have been fully debugged). But it takes years for software to mature to that point. (when you get PRMan you aren't paying for the renderer itself as much as you are paying for ~20 years of bug-fixing). I have tried every alternative RenderMan-compatible renderer I could get my hands on, and while some show a lot of promise, I always find a couple of show-stopper problems that make it impossible to switch.
Again I must emphasize that a production renderer is 10% features and 90% "polish." Many of the alternative renderers have more buzzword features than PRMan (e.g. automatic ambient occlusion baking, automatic network texture caching), but turn out to be completely unusable when you hit an untested corner case (e.g. stuff breaks when you turn on depth of field, or you get pathological memory usage with large motion blur, or the shader compiler has bugs, etc).
The question is, can you convince 3D studios to invest tens of millions of dollars in labor over several years in the hope of replacing something that already exists? I think the time horizon and cost of that investment make it a difficult business case.
Re:RGBCMY is more marketing factoid than it isreal
on
RGB to become RGBCMY
·
· Score: 1
Cb/Cr subsampling is not all that noticeable and is not a problem unless you intend to post-process the pixels.
Uncompressed digital Y'CbCr video can look really good. The major problems for TV consumers are MPEG-2 compression, 8-bit quantization artifacts, and poor displays.
FreeBSD's kqueue/kevent system would be a good model for this. It handles all the traditional UNIX events (file descriptors, signals, child processes, etc) in a single blocking call.
(IMHO asynchronous signal delivery was a mistake and should have been replaced by some kind of file descriptor event)
Well there's a difference between "real/pro" 1920x1080 and "consumer" 1920x1080 displays where it all blurs out into effectively 1024x576 or less. Movie theatres will be using "real" equipment. So there is a bit of extra margin due to equipment quality.
My prediction is that we will see 3840x2160 in common use in 5-10 years and beyond that we'll have to move to a different way of representing images (like vectors and wavelets, something resolution-independent that would be rasterized to an arbitrary resolution by the display itself).
I'm pretty sure the main reason NVIDIA is reluctant to release driver source code is that they use the driver itself to differentiate between their "low-end" and "high-end" products.
e.g. if(is_quadro()) {
enable_fast_wireframes(); } else {
make_wireframes_slow(); }
If you had the source code it'd be pretty easy to hack this so you could get Quadro-level performance at a GeForce price:)
You should read Joel Spolsky's "Why Microsoft lost the API war" http://joelonsoftware.com/articles/APIWar.html. Microsoft is just fine with encouraging lazy developers, because a lazy Windows developer is still a Windows developer. Microsoft realized that if an OS upgrade breaks an application, the public will see it as Microsoft's fault, even if the breakage was due to poor programming by the application vendor. So they decided to make sure upgrades break as little as possible.
I don't mind a crufty API that works forwards and backwards for years.
A LOT of OSX software broke between the incremental 10.2 and 10.3 releases. This was due to Apple "cleaning up" APIs without preserving backwards compatibility.
Slashdot Mirror
I would go even further and set up a separate checking account at your bank specifically for PayPal transactions. Remember, PayPal has your checking account info, so they can theoretically withdraw everything from it at any time. (they shouldn't, but given PayPal's record, I wouldn't trust them to keep my lunch money from being stolen).
(my PayPal story - accepted $10 in payment for an item, sent item, got a chargeback AFTER it shipped via untraceable mail, so I'm out the $10, the item, AND the chargeback fee. All for *accepting* a small payment. Thanks, PayPal!)
Your analysis of SS2 is interesting. Personally I was disappointed that it was much easier to win the game as a military/gunfighter character than either of the more "interesting" choices. I remember thinking psi was really cool, but once you get the assault rifle it's trivial. I guess this is a balance problem common to games with complex character systems. There isn't enough time for the developers to iron-clad the game against "exploits" that hard-core gamers will find (e.g. a single skill that's far more useful but cheaper than others).
Fallout Tactics was that way too. It had the entire Fallout character system, but the game seemed to favor sniper/gunfighter types to an extreme extent. (I think there was only one place in the game that required the Science skill).
My personal favorite "open-ended" game was X-Com (the original). The best part was that your only goal was "defend earth from the aliens," and while it always involved doing certain specific things over and over again, there was enough variety in the research and character-development systems to make it worth playing through several times.
This was a long time ago, I think it was either a very late XFree 3.3 or a very early 4.0.
I did traces using one of those kernel-level toolkits that logs interupts and system calls. The most significant problem I noticed was that the X server ignored something like 10% of the mouse interrupts. Also X would sometimes try to update the display twice during one monitor refresh. This causes the "sticky/jumpy" feeling of mouse movement in X compared to Windows. (laggy window movement and resizing is another, unrelated problem, caused by lack of synchronization between clients and the window manager)
I should note that I was just looking at the standard X desktop behavior. I did not investigate the DGA extension. Still I was surprised at how sub-optimal the default behavior was.
I was using a USB mouse which sent interrupts at a fixed frequency (120Hz I think). I tried dropping my monitor resolution so that I could use this as a refresh rate, and that made a big improvement.
I have a feeling that while Linux is probably faster at the "output" side of things (OpenGL rendering, memory management, etc), it might be hobbled at the "input" side (sampling the mouse location). I did some investigations years ago into why XFree86 feels so unresponsive compared to Windows, and discovered some truly horrible stuff going on with the mouse sampling (e.g. X ignoring or doubling mouse updates here and there). I don't know if the kernel side of mouse/keyboard input has been tuned for low latency either. This could easily lead to an impression of sluggishness even if the rendering speed is higher than on Windows.
Would it be too much to ask to get new formats implemented as extensions to suitable existing ones like TIFF or OpenEXR? I can think of very few file-format requirements that can't be taken care of just by adding new metadata tags, pixel formats, or compression algorithms to one of these formats.
(both TIFF and EXR support arbitrary bit depths, channels, and pluggable compression algorithms)
You would have a problem with backwards compatibility - e.g. "I thought Photoshop can open TIFF files, why can't it read this one my new camera spit out?". However this has sort of been the case with TIFF for a while. (virtually no commercial apps actually support *all* possible pixel formats/compression modes of TIFF, the usual culprits being LZW compression or >8bit channels)
Using an existing format has the advantage that all the nitty-gritty of handling metadata has already been hammered out, and most of the common tags are widely recognized. Also you get existing "advanced" features like tiled or multi-resolution images, compression blocking, etc for free. Whereas these would have to be coded and tested one by one for a new format.
I think it's the sunk cost fallacy - "we've already spent $X billion on this, let's throw a few more billion at it until it works."
I have a JVC D-VHS recorder. It will happily record unencrypted MPEG-2 on the FireWire input.
(However, this is sort of a moot point, since it is almost impossible to find a cable/satellite service that will deliver unencrypted video via FireWire. The only one I know of is a certain hardware-modded satellite receiver)
I wouldn't single out JVC though. D-VHS has been available for at least a year; back when it came out, none of the other interfaces like DVI were standardized yet. You will never see a consumer unit that records via analog HD YPbPr anyway. It will either be encrypted FireWire or (more likely) encrypted DVI.
Regardless of benchmarks, I consider the nasty backwards compatibility issues of GCC a serious problem. Virtually all of my Linux tech support time over the last two years has been spent messing with libstdc++ or libgcc_s versions to get various software packages to run. The problem is exacerbated because these libraries in turn are coupled tightly to glibc and pthreads, leading to more versioning headaches. My #1 wish for GCC is to get these libraries set in stone and make them as independent of glibc/pthread versioning as possible. I really want to be able to install a random C++ binary and have it work the first time.
Also, the ability to compile a C++ DSO without requiring the exact same compiler version as the program that will load it, is a major need for commercial Linux software vendors.
Depending on whom you ask, and on the quality of the processing, 35mm film has equivalent resolution to a 800 to 4,000 pixel wide digital image. Even the worst 35mm material has finer detail and greater dynamic range than can be captured on 720x486 NTSC video. 1920x1080 HD video captures a lot more of that detail. For most 35mm films, HD probably gives you all the useful data you're going to get from the print. In rare cases there may be need for a higher-resolution digital capture, or one with higher dynamic range. This could be useful for future display devices.
If you are curious, try the "T2: Extreme DVD", it includes an HD version of the film at something like 1280x600 compressed with the WMV9 codec. It looks a lot better than the NTSC DVD version.
In George Lucas' interview with Charlie Rose two days ago, he very firmly stated "no more Star Wars movies," he wants to do other films. Take that for what it's worth...
Edward Tufte would be proud!
1080p60 is just slightly beyond the bandwidth capabilities of current video tape technology. There is presently no way to do it on 1/2" video tape without applying an excessive amount of lossy compression. Plus you have the problem that very little (no?) editing or display equipment supports 1080p60.
I doubt you will see 1080p24 consumer cameras offered soon, out of fear that they would cut into sales of professional 24p cameras.
The HDV spec involves super-lossy compression so it won't really hold up to the established HD formats. However, it should look excellent when down-sampled to NTSC/PAL resolution. (down-sampling will minimize CCD noise and compression artifacts). That might be the primary use of this camera - a cheap substitute for Digital Betacam, or a superior replacement for standard DV.
I would like to see more focus on delivering a higher-quality audio path from game developer to consumer, as opposed to gimmicky post-processing to make things sound "better". (e.g. we want to deliver N channels of 24-bit/96KHz audio with low CPU overhead, rather than a DSP that tries to "enhance" existing audio). Real-time Dolby Digital encoding is great, funky "spatialization" of 2-channel audio is not.
Not to name names, but I have switched away from a formerly reliable company's sound hardware because they got too "creative" (ahem) with their gimmicks and forgot about the basics.
I wish web servers wouldn't advertise their version number be default (e.g. in directory listings or HTTP headers). It's like giving an attacker an exact list of the exploits that will work on your server.
If you mount tmpfs (or is it shmfs?) on /tmp, you get persistent (until reboot) file storage that is backed by the system page file.
Nobody takes on a project without having a fallback approach. I am absolutely sure their attitude was "we'd LIKE to develop a nice new water system, but if we HAVE to, we'll just use good old displacement maps (or whatever)."
Currently PRMan is the de-facto fallback for pretty much every big studio that doesn't have its own renderer.*
I am in the position right now of trying out several renderers but I almost always have to fall back to PRMan. It's nice to test out new software in the confined environment of one element in one shot. But there is a HUGE leap between "just testing" and "relying on as a fallback." I can do an element in Aqsis or Pixie and have fun with it, but when something breaks it's back to PRMan.
*(which is another interesting note: PDI/Dreamworks and Blue Sky both developed their own renderers which are probably just as sophisticated as PRMan, yet you don't hear much about these because they are not sold as products. So there is some precedent for putting together a production renderer on your own. On the other hand, both of these studios probably consider their software a competitive advantage and would not be willing to give it away)
I highly doubt Pixar would just throw away the $10 million they make annually from PRMan..
I think there is room in the market for a lower-cost or open-source drop-in replacement, but it's a chicken-and-egg problem. Studios cannot use a renderer that is not "production-quality" (by which I mean all the tiny little corner cases and rarely-used code paths have been fully debugged). But it takes years for software to mature to that point. (when you get PRMan you aren't paying for the renderer itself as much as you are paying for ~20 years of bug-fixing). I have tried every alternative RenderMan-compatible renderer I could get my hands on, and while some show a lot of promise, I always find a couple of show-stopper problems that make it impossible to switch.
Again I must emphasize that a production renderer is 10% features and 90% "polish." Many of the alternative renderers have more buzzword features than PRMan (e.g. automatic ambient occlusion baking, automatic network texture caching), but turn out to be completely unusable when you hit an untested corner case (e.g. stuff breaks when you turn on depth of field, or you get pathological memory usage with large motion blur, or the shader compiler has bugs, etc).
The question is, can you convince 3D studios to invest tens of millions of dollars in labor over several years in the hope of replacing something that already exists? I think the time horizon and cost of that investment make it a difficult business case.
Cb/Cr subsampling is not all that noticeable and is not a problem unless you intend to post-process the pixels.
Uncompressed digital Y'CbCr video can look really good. The major problems for TV consumers are MPEG-2 compression, 8-bit quantization artifacts, and poor displays.
FreeBSD's kqueue/kevent system would be a good model for this. It handles all the traditional UNIX events (file descriptors, signals, child processes, etc) in a single blocking call.
(IMHO asynchronous signal delivery was a mistake and should have been replaced by some kind of file descriptor event)
IMHO Blu-ray is dead in the water. Why? Because it uses a caddy. Consumers will prefer bare optical disks, regardless of the technical differences.
Well there's a difference between "real/pro" 1920x1080 and "consumer" 1920x1080 displays where it all blurs out into effectively 1024x576 or less. Movie theatres will be using "real" equipment. So there is a bit of extra margin due to equipment quality.
My prediction is that we will see 3840x2160 in common use in 5-10 years and beyond that we'll have to move to a different way of representing images (like vectors and wavelets, something resolution-independent that would be rasterized to an arbitrary resolution by the display itself).
I'm pretty sure the main reason NVIDIA is reluctant to release driver source code is that they use the driver itself to differentiate between their "low-end" and "high-end" products.
:)
e.g.
if(is_quadro()) {
enable_fast_wireframes();
} else {
make_wireframes_slow();
}
If you had the source code it'd be pretty easy to hack this so you could get Quadro-level performance at a GeForce price
You could use a mandatory web proxy that refuses to send replies to IE based on its User-Agent string.
You should read Joel Spolsky's "Why Microsoft lost the API war" http://joelonsoftware.com/articles/APIWar.html. Microsoft is just fine with encouraging lazy developers, because a lazy Windows developer is still a Windows developer. Microsoft realized that if an OS upgrade breaks an application, the public will see it as Microsoft's fault, even if the breakage was due to poor programming by the application vendor. So they decided to make sure upgrades break as little as possible.
I don't mind a crufty API that works forwards and backwards for years.
A LOT of OSX software broke between the incremental 10.2 and 10.3 releases. This was due to Apple "cleaning up" APIs without preserving backwards compatibility.