I'd guess that improper use of (L)GPL code is pretty wide-spread. It's only been discovered in this case because of the intense scrutiny on Sony's DRM system. I bet there are plenty of other cases out there that haven't been picked up because nobody's bothered to scrutinize the executables.
One could collect the "ransom" deposits into an escrow account. Then if the reserve price isn't reached after a specified time limit (e.g. 1 year), you'd get your deposit back, plus interest.
I wonder if China is attempting to goad the US into spending billions more on space exploration... Money that will come in the form of treasury debt to the Chinese central bank.
Even better if you can find a "pre-ban" VCR without the Macrovision chip (which was required by law starting in the 90s, I think). I have two of them and it will be a sad day when they finally wear out...
If liability were mandatory, software companies would be forced to buy very expensive insurance policies to cover the potential costs of being sued, just like doctors in the US must buy malpractice insurance. The result would be the same as in the medical field - vastly higher prices.
Consumers complain about the poor quality of software right up until they walk into a software shop - then they buy the cheapest product.
I really wish my first trigonometry class had *started* with the circle-coordinate definitions of sin/cos/tan, and derived everything from there. But instead we spent a while playing around solving triangles, treating the trig functions as "magic black boxes," which made a lot less sense. It wasn't until I learned the circle definition that everything clicked into place.
Another shortcoming of the triangle-side-ratio approach is that it doesn't explain what happens when the angle goes negative or exceeds 180 degrees.
How about a course in trig and exponentials that starts with the power-series definitions? That would be interesting (maybe as a joke...). Although you could derive some useful elementary identities using the power series.
Have you read "Visual Complex Analysis?" It advocates using De Moivre's Theorem to remember trig identities, which lessens the amount of material you need to rote memorize.
I don't see how a popular, engrossing game can harm the industry as a whole. It's like saying Star Wars harms the movie industry, because Star Wars fans spend so much time enjoying the films. While it is true some gamers might spend time on WoW that would otherwise be diverted to other games, you also have to consider that WoW will entice more people to become gamers, and to give up non-game activities to play WoW.
With regards to MMORPGS in particular, WoW's dominance is a natural consequence of the network effect. All else being equal, people will prefer an MMORPGS with more players to one with fewer players. It's the same as in the operating system industry - people lament the lack of innovative alternatives to Windows and OSX, but they aren't willing to deal with the consequences of using a "minority" OS (e.g. lack of drivers and software). Game designers might lament their inability to crack WoW's market share, but that's just how things are.
I think Carmack's opposition to procedural textures is for practical, not technical reasons. Developing good-looking shaders requires math and programming skills that most artists do not have. You'd have to tie up a software developer to write the shaders (and possibly an artist too, if the developer doesn't have a good artistic "eye"). So from a manpower perspective, it makes more sense just to have a bunch of artists cranking out texture maps in Photoshop.
Get a stand-alone RAID/JBOD chassis or a cheap PC and stuff it with drives. Back up using rsync over Ethernet. Take the unit home with you or get two and rotate them to a safe location (e.g. bank safe deposit box).
This is way faster and cheaper than a tape or online system of equivalent capacity.
Rendering software is usually licensed per-CPU. It's a decent model since the number of CPUs in a studio roughly indicates how much it can afford to pay for software:). Though it seems likely that "per CPU" will soon become "per box" or "per OS instance" to avoid splitting hairs over the expanding jungle of multiprocessing technologies.
Regarding the Carmack quote - Although I don't know John personally, I have learned a tremendous amount reading his source code and technical essays. It was only fitting to mention him. I had to avoid being specific about his work since the interview was for a children's site:)
I'm going to totally abuse my five minutes of Slashdot fame here - I'm planning an extended trip to Singapore, Hong Kong, and Taiwan this winter. If you live in one of those places and want to get in touch please drop me an email (dmaas at maasdigital.com). I speak semi-decent Mandarin.
Hah pretty funny to wake up and see myself on the front page:).
Three other artists and I are currently working on an IMAX film about the Mars Rover mission, to be released sometime next year. The image quality will be much better than my old NASA animation. We are re-creating the Rovers' actual environments on Mars using returned images and terrain data.
Depending on usage, the seek time of the physical disk could put it behind the solid-state device. Hard disks can only perform on the order of 100 seeks per second. That means you only get 100 read() calls per second if there is enough fragmentation.
It's a risk-reduction measure... Even if you are SURE you are completely innocent, it still makes sense to delete email. If you don't delete it, you could perpetually be liable for something that didn't seem wrong at the time. Ethical standards change; what is considered acceptable today might be criminal or tortious in the future.
Unfortunately OSX still has some problems with NFS...
- mounts disappear occasionally for no apparent reason, and the automounter won't remount them, forcing me to reboot.
- NFS client performance is significantly worse than Linux (~20MB/sec vs ~100MB/sec reading from the same server over the same gigabit network)
- Some (very important to us) OSX apps have significant problems dealing with NFS paths. Final Cut Pro doesn't use symlinks properly, instead it hard-codes the target of the symlink into your project files, making it impossible to change where the link points without breaking your project. FCP also doesn't record projects on NFS shares in its "open recent" menu. (though DVD Studio Pro does).
And while I'm ranting about OSX filesystems:
- their FAT implementation has performance problems when dealing with very large directories. Copying thousands of film frames into a single directory starts quickly but then gets MUCH slower as the directory fills up. Linux's FAT driver does not exhibit this slowdown.
I was told by members of the team that the impact date for the optimal trajectory was like July 3 or 5, so they figured what the hey and aimed for the Fourth.
32-bit pixel support alone is a HUGE improvement and well worth the upgrade for me.
But yes, the only major improvement for me in the "5.x to CS" timeline was better support of 16-bit pixels. Also CS seems to handle massive images (>1GB uncompressed) very well.
As a developer of binary drivers you are used to having complete control over your code, and "pushing" all updates down-stream. But once your code goes in the kernel (which I highly recommend - don't let it languish outside Linus' tree), you'll have to consider how to deal with code changes coming TO you FROM the kernel developers.
This is both a good thing and a bad thing. It's good because you'll get fixes from people testing your code on all sorts of weird platforms you've never heard of. It's bad because you can wake up one morning and discover the kernel API for your type of driver has changed overnight, and your code won't even compile until you re-write half of it (there go your plans for the weekend). A certain amount of lag is acceptable, and you can restrict support to the stable kernel series only if you want, but expect to hear a lot of whining from users who will demand that you keep up with the cutting-edge development code.
Ultimately driver code should conform to kernel norms, but the maintainers do seem willing to accept useful driver code even if it doesn't conform perfectly. It's better to have working but less-pretty code than wait forever for it to get reformatted.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 5, Interesting
This has more to do with the habits of C++ programmers rather than the language itself. If you take a random piece of C code and compile it as C++, it will probably take no more than 2-3x more time (the slowdown being due to a larger compiler binary, more sophisticated type-checking, etc). However what is often considered "good C++ programming style" involves inlining far more code than is the norm for C. (e.g. some STL implementations are entirely inline, whereas it would take a pretty crazy C programmer to implement hash tables and heaps inline). That's what blows up the compile time (and binary size).
The extra compile time buys you more inlining (which can be either good or bad for performance, depending on cache behavior) and also type-safe templates which are not acheivable in C (without ugly hacks).
Re:and how many times...
on
GCC 4.0 Preview
·
· Score: 2, Interesting
YES this is a huge problem. More than half of my Linux troubleshooting time can be traced back to version skew issues in either GCC or GLIBC. (libstdc++ changes, pthreads changes, exception handling changes, etc...)
Now that the C++ ABI is standardized, there is NO excuse for not having backwards- and forwards- compatibility for ordinary C and C++ executables linked against glibc.
The Linux kernel v2 ABI has been mostly backwards- and forwards-compatible since its first release. And Linux kernel guts change a lot more often than the C/C++ standards!
Good filtering is another issue. Currently lots of applications try to do scaling themselves and make stupid mistakes like using point sampling or a box filter.
An ideal scalable graphics system would support both raster and vector primitives, where the raster primitives would be scaled to the appropriate resolution automatically with guaranteed high-quality filtering (like bicubic or better).
Slashdot Mirror
I'd guess that improper use of (L)GPL code is pretty wide-spread. It's only been discovered in this case because of the intense scrutiny on Sony's DRM system. I bet there are plenty of other cases out there that haven't been picked up because nobody's bothered to scrutinize the executables.
One could collect the "ransom" deposits into an escrow account. Then if the reserve price isn't reached after a specified time limit (e.g. 1 year), you'd get your deposit back, plus interest.
I wonder if China is attempting to goad the US into spending billions more on space exploration... Money that will come in the form of treasury debt to the Chinese central bank.
Even better if you can find a "pre-ban" VCR without the Macrovision chip (which was required by law starting in the 90s, I think). I have two of them and it will be a sad day when they finally wear out...
If liability were mandatory, software companies would be forced to buy very expensive insurance policies to cover the potential costs of being sued, just like doctors in the US must buy malpractice insurance. The result would be the same as in the medical field - vastly higher prices.
Consumers complain about the poor quality of software right up until they walk into a software shop - then they buy the cheapest product.
I really wish my first trigonometry class had *started* with the circle-coordinate definitions of sin/cos/tan, and derived everything from there. But instead we spent a while playing around solving triangles, treating the trig functions as "magic black boxes," which made a lot less sense. It wasn't until I learned the circle definition that everything clicked into place.
Another shortcoming of the triangle-side-ratio approach is that it doesn't explain what happens when the angle goes negative or exceeds 180 degrees.
How about a course in trig and exponentials that starts with the power-series definitions? That would be interesting (maybe as a joke...). Although you could derive some useful elementary identities using the power series.
Have you read "Visual Complex Analysis?" It advocates using De Moivre's Theorem to remember trig identities, which lessens the amount of material you need to rote memorize.
I don't see how a popular, engrossing game can harm the industry as a whole. It's like saying Star Wars harms the movie industry, because Star Wars fans spend so much time enjoying the films. While it is true some gamers might spend time on WoW that would otherwise be diverted to other games, you also have to consider that WoW will entice more people to become gamers, and to give up non-game activities to play WoW.
With regards to MMORPGS in particular, WoW's dominance is a natural consequence of the network effect. All else being equal, people will prefer an MMORPGS with more players to one with fewer players. It's the same as in the operating system industry - people lament the lack of innovative alternatives to Windows and OSX, but they aren't willing to deal with the consequences of using a "minority" OS (e.g. lack of drivers and software). Game designers might lament their inability to crack WoW's market share, but that's just how things are.
I think Carmack's opposition to procedural textures is for practical, not technical reasons. Developing good-looking shaders requires math and programming skills that most artists do not have. You'd have to tie up a software developer to write the shaders (and possibly an artist too, if the developer doesn't have a good artistic "eye"). So from a manpower perspective, it makes more sense just to have a bunch of artists cranking out texture maps in Photoshop.
Get a stand-alone RAID/JBOD chassis or a cheap PC and stuff it with drives. Back up using rsync over Ethernet. Take the unit home with you or get two and rotate them to a safe location (e.g. bank safe deposit box).
This is way faster and cheaper than a tape or online system of equivalent capacity.
Rendering software is usually licensed per-CPU. It's a decent model since the number of CPUs in a studio roughly indicates how much it can afford to pay for software :). Though it seems likely that "per CPU" will soon become "per box" or "per OS instance" to avoid splitting hairs over the expanding jungle of multiprocessing technologies.
This is common practice for magazines these days. I got burned by Discover the exact same way.
Regarding the Carmack quote - Although I don't know John personally, I have learned a tremendous amount reading his source code and technical essays. It was only fitting to mention him. I had to avoid being specific about his work since the interview was for a children's site :)
I'm going to totally abuse my five minutes of Slashdot fame here - I'm planning an extended trip to Singapore, Hong Kong, and Taiwan this winter. If you live in one of those places and want to get in touch please drop me an email (dmaas at maasdigital.com). I speak semi-decent Mandarin.
Hah pretty funny to wake up and see myself on the front page :).
Three other artists and I are currently working on an IMAX film about the Mars Rover mission, to be released sometime next year. The image quality will be much better than my old NASA animation. We are re-creating the Rovers' actual environments on Mars using returned images and terrain data.
Depending on usage, the seek time of the physical disk could put it behind the solid-state device. Hard disks can only perform on the order of 100 seeks per second. That means you only get 100 read() calls per second if there is enough fragmentation.
Guys, it all makes sense if you just assume that Obi Wan is getting senile... Years of living alone in the Tatooine desert and all that...
It's a risk-reduction measure... Even if you are SURE you are completely innocent, it still makes sense to delete email. If you don't delete it, you could perpetually be liable for something that didn't seem wrong at the time. Ethical standards change; what is considered acceptable today might be criminal or tortious in the future.
Unfortunately OSX still has some problems with NFS...
- mounts disappear occasionally for no apparent reason, and the automounter won't remount them, forcing me to reboot.
- NFS client performance is significantly worse than Linux (~20MB/sec vs ~100MB/sec reading from the same server over the same gigabit network)
- Some (very important to us) OSX apps have significant problems dealing with NFS paths. Final Cut Pro doesn't use symlinks properly, instead it hard-codes the target of the symlink into your project files, making it impossible to change where the link points without breaking your project. FCP also doesn't record projects on NFS shares in its "open recent" menu. (though DVD Studio Pro does).
And while I'm ranting about OSX filesystems:
- their FAT implementation has performance problems when dealing with very large directories. Copying thousands of film frames into a single directory starts quickly but then gets MUCH slower as the directory fills up. Linux's FAT driver does not exhibit this slowdown.
I was told by members of the team that the impact date for the optimal trajectory was like July 3 or 5, so they figured what the hey and aimed for the Fourth.
32-bit pixel support alone is a HUGE improvement and well worth the upgrade for me.
But yes, the only major improvement for me in the "5.x to CS" timeline was better support of 16-bit pixels. Also CS seems to handle massive images (>1GB uncompressed) very well.
As a developer of binary drivers you are used to having complete control over your code, and "pushing" all updates down-stream. But once your code goes in the kernel (which I highly recommend - don't let it languish outside Linus' tree), you'll have to consider how to deal with code changes coming TO you FROM the kernel developers.
This is both a good thing and a bad thing. It's good because you'll get fixes from people testing your code on all sorts of weird platforms you've never heard of. It's bad because you can wake up one morning and discover the kernel API for your type of driver has changed overnight, and your code won't even compile until you re-write half of it (there go your plans for the weekend). A certain amount of lag is acceptable, and you can restrict support to the stable kernel series only if you want, but expect to hear a lot of whining from users who will demand that you keep up with the cutting-edge development code.
Ultimately driver code should conform to kernel norms, but the maintainers do seem willing to accept useful driver code even if it doesn't conform perfectly. It's better to have working but less-pretty code than wait forever for it to get reformatted.
This has more to do with the habits of C++ programmers rather than the language itself. If you take a random piece of C code and compile it as C++, it will probably take no more than 2-3x more time (the slowdown being due to a larger compiler binary, more sophisticated type-checking, etc). However what is often considered "good C++ programming style" involves inlining far more code than is the norm for C. (e.g. some STL implementations are entirely inline, whereas it would take a pretty crazy C programmer to implement hash tables and heaps inline). That's what blows up the compile time (and binary size).
The extra compile time buys you more inlining (which can be either good or bad for performance, depending on cache behavior) and also type-safe templates which are not acheivable in C (without ugly hacks).
YES this is a huge problem. More than half of my Linux troubleshooting time can be traced back to version skew issues in either GCC or GLIBC. (libstdc++ changes, pthreads changes, exception handling changes, etc...)
Now that the C++ ABI is standardized, there is NO excuse for not having backwards- and forwards- compatibility for ordinary C and C++ executables linked against glibc.
The Linux kernel v2 ABI has been mostly backwards- and forwards-compatible since its first release. And Linux kernel guts change a lot more often than the C/C++ standards!
Good filtering is another issue. Currently lots of applications try to do scaling themselves and make stupid mistakes like using point sampling or a box filter.
An ideal scalable graphics system would support both raster and vector primitives, where the raster primitives would be scaled to the appropriate resolution automatically with guaranteed high-quality filtering (like bicubic or better).