You say you need more than 4GB for video editing and 3D rendering?
Sorry while I rant, but you just stomped on one of my nerves. (Unless your comment about neededing that much RAM was a complaint about Adobe or their direct *cough* compeitors -- sucks to be you.)
<Old Geezer Mode> In one case, not long ago, a fellow lab-rat Eric Mortenson had sold his research and tools to Adobe, but part of the poorly-written agreement said that he couldn't upgrade his work station. So he finished his Ph.D on a 386 with 32-MB of RAM, while the rest of us in the lab were using Pentium 3's, DEC Alpha's, and various SGI boxs. Eric's algorithms ran great on the newer PC's even though he couldn't develop them on the new boxes. Other with Adobe (NOT on that web site interestingly enough) needed the DEC Alphas (64-bit machines) with scads of memory and much more running time to do a similar implementation of Eric's algorithms. </Old Geezer Mode>
3D rendering doesn't take that much RAM. As a 3D graphics researcher and developer, I have worked with models where individual objects were multi-gigabytes (meshes+textures and volumes) but even then, having 1GB of RAM was more than enough for us to reach 20-30 FPS realtime on a box with NT4 and first- and second-generation 3D cards. Software rendering with very realistic detail was a little slower (3-5 fps) but was fine for writing movies. Progressive geometry & texture transmission, continuously calculated view-dependant detail levels, and other current and not-so-current research would solve the memory problems in 3D. Don't believe me? Go to Visualization 2003 and see if the leading researchers are finding RAM as their primary bottleneck. It is a bottleneck of course, but processing speed, caches, and the system BUS limitations are far more troubling.
As for video editing, you only need enough memory for the tools, a few frames, and whatever operations you are performing. In every case that I've had to do video editing, I've seen two classes of tools -- those that take gobs of memory and
try to copy the entire video clip into RAM and end up thrashing for memory -- and those that intellegently figure out what is needed and use only the memory needed for the app.
An example of the first, an Adobe AfterEffects rendering a simple math function over time was only able to render 30-seconds because it wanted to buffer the AVI file in memory and ran out of RAM (2GB) after a several-hour rendering. An example of the second, a simple home-brew compositor that used the Windows multimedia API to write the AVI to disk -- the same machine and the same set of images required about 45 minutes to render the entire clip.
So instead of saying:
I need more than 4GB RAM (3.5 if I want it stable) for video editing and 3D rendering.
I would suggest you say "I need to buy tools that are properly designed and implemented for my class of computer."
Just be careful about the definition of "derived works" vs. works that coexist, or works that link against system-integral libraries. Non-GPL works can coexist with GPL works, and non-GPL works can link with GPL libraries under certain circumstances; similarly, GPL works can link with non-GPL libraries under the same and similar circumstances (such as a GPL program linking with the Standard C library of the compiler).
If people get the information without using a browser, therefore never seeing the ads, the advertisers won't want to spend any money on the site.
It was a problem with text browsers, so many companies explicitly dropped the ALT tags. Now they fight ad-blockers.
Wouldn't it be cool if I could write my own mapping application ( or download a pre-made one from the site ) and have it connect to xml.mapquest.com, give my username and password, and retrieve the data I requested.
I know I will be in the minority here, but if you don't like the credit check, why are you still fighting for the job?
I don't think you're in the minority on that.
Just like with any NDA, post-employment non-competition agreement, or other employment terms, if you don't like the way they treat you BEFORE they hire you, you should tell them that, and look elsewhere.
Re:Oldest working code...
on
Immortal Code
·
· Score: 5, Insightful
I'm always curious as to what may be some of the oldest "working" code that's publicly available. Code that was written ages ago, but still used today.
Many ISP's and low-budget group have self-signed certs. They're easy to make. (well, easy for someone who is setting up a secure web site). I have quite often seen sites with a self-signed cert and another page giving the fingerprint of the cert. Most vendors allow these, but they aren't "trusted".
The only reason the big companies charge so much (their claim, not mine) is the insurance they provide, and the fact that they are "trusted" by the various vendors.
Any new group wanting to be a trusted CA will face the liability issue -- if one of your customers sues you, even if you try to disclaim all liability up front, you will still face massive court fees. Even if you won in court, you would lose financially if not insured.
There is no technical or logistical problem with setting up a Free (and free) common-geek's CA, the problems are entirely legal ones. I know because I looked into it right after SSL came out. It looks like a good business plan, right up until someone takes you to court.
Several sections have been challenged, but none successfully. Whenever the EFF and other groups get 'good' cases, those that the high courts would use to turn over the law, the media giants ask the court for a settlement.
You miss the point. They made a request without following the traditional legal routes (subpoena). This means that (if it doesn't go through appeal) they can demand any ISP for the name of any subscriber for alleged privacy violations.
Let me give an example. I could send a letter to your ISP, and say 'We believe that a user at 92.43.23.134 is electronically distributing our copyrighted documents. We demand that you turn over their name and contact information, according to the terms of the DMCA.'
Or they could say "several people at all these addresses and all these times are suspected of..."
This essentially means there will be no legal check. See the fourth ammendment to the US Constitution: "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. "
It has been fairly well established that obtaining records of that type are subject to 4th ammendment restrictions.
The crowbar example is badly flawed. I can think of no similar analogy.
The whole issue bothers me. You don't need a program like DeCSS to copy a DVD, you need a program like Nero Burning Rom, which makes copies of DVD's quite easily, and is not surrounded by any contraversy.
I believe that a DVD needs the CSS entact for use -- all the pirated DVD's are (or should be) bit-for-bit copies of the originals. You can run DeCSS to extract the video mpeg streams, which could then be viewed on an mpeg viewer, but if you run DeCSS, unless your DVD player also plays raw mpegs, it won't work.
Just like the ElcomSoft case, I believe that a through search of pirated DVD's will yield no or nearly no instances of piracy using that tool. That's mainly because the tool is impractical as a piracy device.
I remember one guy saying that he had to test every single play in a football game
Just because it's a console game doesn't mean you don't need good testing standards. You can't just skip regression tests and coverage tests, or if you do, you'll regret it. But you need more than just the ability to play games. Actions that require good timing to do certain things, the testers need to repeat them over, and over, and over, and over again, making sure that it is difficult, but not too difficult. Unfortunately with games, good testing means introducing human error to the test process, and that can't be automated.
You should see 'test sheets' at some places, detailing the scene and goal of the scene, and listing all the different posibilities, and a checklist that the tester has done all of them. It feels like this:
Load saved game
Get to scene
Do 17 jump-kicks and a 'hi-yah'
Watch for glitches, screen errors, or problems
Put down a check mark or write down problems
* reset *
Load saved game
Get to scene
Do 12 jump-kicks and four 'hi-yah's
Watch for glitches, screen errors, or problems
Put down a check mark or write down problems
* reset *
Load saved game
Get to scene
Find item A
Do 13 jump-kicks, a 'hi-yah', and use the item
Watch for glitches, screen errors, or problems
Put down a check mark or write down problems
* reset *
Load saved game
Get to scene
Find item A
Get killed by monster Z
Watch for glitches, screen errors, or problems
Put down a check mark or write down problems
* reset *
Repeat for 10-12 hours each day.
Game testing has about zero appeal. Most people think "that would be fun" because they are ignorant. They see the final product and think it's easy. That just means the creators did good work.
Game programming is similar. The hours are crazy, the pay is low, expectations are high, deadlines are tight, specs keep changing, and the stress is insane. Sure there are a few (as in not very many, as in you won't ever get one) game jobs that don't have the problems, but it isn't the common case.
I would LOVE to see everyone who wants to program games actually be forced into the game market for one year. After the year, there would be enough decrease in demand that salaries might go up to a reasonable level with a corresponding drop in stresses.
Can any honest, unbiased and Slashdot/Register editor/user please post the rebuttal from Microsoft for the same case? You know to get a balanced view, or All thing considered(TM)
I'll try it, and standard/. disclaimers apply...
I've seen other corporate contracts before, the 'if one party fails, the other gets the rights' is a common thing. In this case, Sendo was not worried about MS failing, so they let the clause slip. That's not a big thing.
MS had invested in sendo by buying shares in the company, followed by other agreements. While the agreements may have been a good business decision and run by one set of managers, the financial managers may have seen the shares in the company as a bad investment (after all, they aren't putting out the product on time...) and decided to order a buy-back on the investment.
After READING THE ARTICLE the suggestion that using DRM or encryption doesn't make sense. They are modifying the image by running various filters and kernels over it, trying to enhance and draw out information. Additional protections of the file does nothing to protect the image integrety. What they are having a problem with is using the enhanced versions of the prints.
The only thing the DRM or encryption would do is provide yet another means of tracking the files -- but it sounds like they are already using safeguards there. All versions, the user, and the duration of use are tracked. Those are the same, or in some cases better, than protections of physical evidence.
They don't need DRM cameras or higher cost encryption schemes. They need the same arguments that first allowed for fingerprints, DNA testing, and other new technologies in the courts.
They can at least reduce the chance a lot with redundency.
I had an undergrad Computer Security class several years ago. It was taught by a SysAdmin at the IRS processing center. (it handles all the Business IRS submissions for the western US). Even more amazing, the professor was a SHE.
She discussed this exact situation and several others, and how much redundancy is needed to avoid it. In one story, told a story where the top 4 sysadmins went to lunch together. Their car was hit in traffic and all 4 died. Because the govenrmnet requires lots of redundency and documentation, there were many other people at that building and at the Eastern processing center who knew and could access every password, and could fill in every aspect of the jobs of the deceased. Sure, it initially took 8 people to do the job of the 4, but there was no interruption and no major economical damage done.
If you want a secure system, you should be able to have over half of your administrators, programmers, and other key employees suddenly die or quit, and still be able to operate normally with little or no interruption. This is even more important if you have multiple key sites -- If everyone died at one site from some plague, you should still be able to recover all of your data.
One of my sys-admins has a poster on the inside of his door, which he usually keeps under his jacket. It has a picture of a boss and something like "Are the machines for the new people ready?" and a translation of "I guess I should tell you I'm going to hire some people."
It's amazing to me how many PHB's keep their SA's out of the loop. It's also amazing to me that PHB's will say "I want this put together by $DATE" where $DATE is just barely enough time if everything else is delayed. The SA gets it done at a huge cost to other projects, and then the PBH doesn't use it until several weeks after the date.
I mentioned both NTSC and PAL to cover both bases.
NTSC uses the YIQ color space, and PAL uses YUV or YPbPr. The computers that the movie was developed on used RGB. To move from RGB to either YIQ or YUV requires some lossy transformations.
Red being 'hot', red or blue shifts, and color saturation (2 of the 3 are reported problems with the DVD) are symptoms of not doing the transformations properly.
This is an old problem in the industry, and probably doesn't even deserve much mention in on/.
From the article:
"Sen to Chihiro no Kamikakushi (Spirited Away)" is a digitally-animated movie produced by Studio Ghilbli, and its full-digital frames were designed and produced on computers. The coloration of the master for the DVD and VHS was strictly supervised/approved by Studio Ghibli's color designers and DP/Cinematographer.
and quote two:
Studio Ghbli said that they did not use the data that was used in theatrical releasing prints of the film, but they used the newly mastered DVD/Video digital data in consideration with the fact that the DVD should be played on Liquid Crystal TV or Plasma TV, so should be no problem for its quality.
Now if you have worked with computer monitors, TVs, and broadcast standards at all, you should have heard about RGB, NTSC, and PAL.
RGB is the way that computer signals are sent. It is a pure encoding of the percentage of Red, Green, and Blue to display at some location (based on the current beam position and timing).
NTSC (used in the US) encodes the information in YIQ color space. When color TVs were invented, they decided to keep backwards compatibilty with B/W tv's. Thanks to a bit of math that is beyond the scope of a/. post, the red waveform was distorted and other colors are clipped, so that red becomes more intense, and pure yellow, cyan, red, and blue are all impossible to get. Red becomes more intense than the RGB display, and blue is muted.
PAL (used everywhere else) encodes the information in YUV color space, or YPbPr. In this case, where again, scaling and TV hardware result in different color than the RGB that computer monitors display.
So when the distributors say "the DVD should be played on Liquid Crystal TV or Plasma TV, so should be no problem for its quality" what they mean is We didn't convert RGB to the YUV or YIQ color space either because they forgot (what customers say) or because they meant it to be viewed on an RGB display (what the studio is saying).
Is that a real problem? Most people who have to deal with broadcasts say 'no' because your TV is supposed to have a tint and hue knob that you can frobnicate until you get the desired colors.
How much better would Windows be if we shot a programmer for every BSOD?
Actually Windows itself is pretty stable. The Windows core has been around the block, has had billions of installations, and doesn't crash. The BSOD is usually a kernel check or a STOP -- a condition where Windows says that something really bad was prevented. Just like a kernel panic, it's actually a good thing, compared to the alternative.
Most of the BSOD's in Windows come from shoddy software. The BSOD or kernel panic allows developers to find the device drivers, libraries, or other 'insider' code that is messed up.
I've done a *LOT* of debugging, including wading through the kernel and drivers to find strange bugs (these comments are about graphics drivers specifically). I have seen device drivers with int 3's (debug interrupts) scattered through them. I have seen device drivers that obviously were using the 'minimal rebuild' options, resulting in slower and more-corrupt code. I have seen drivers that try to run (and usually crash) Pentium 3, Pentium 4, and Athalon instructions even though the CPU doesn't support those instructions. In short, drivers and applications, not the Windows kernel or API's, are generally at fault.
When I do have the misfortune of having to do driver-level debugging, I have never, not once, seen a crash with the Windows NT/98/2000/ME/XP kernels. Inefficient, unoptimized and seemingly poor design decisions are in there, as are occasional functional errors and side effects, but as for crashes in the kernel, I have never seen one.
If the same logic were applied to all software (If it crashes, you die) not even Donald Knuth would be left alive. And that would be a sorry state.
Slashdot Mirror
Sorry while I rant, but you just stomped on one of my nerves. (Unless your comment about neededing that much RAM was a complaint about Adobe or their direct *cough* compeitors -- sucks to be you.)
<Old Geezer Mode> In one case, not long ago, a fellow lab-rat Eric Mortenson had sold his research and tools to Adobe, but part of the poorly-written agreement said that he couldn't upgrade his work station. So he finished his Ph.D on a 386 with 32-MB of RAM, while the rest of us in the lab were using Pentium 3's, DEC Alpha's, and various SGI boxs. Eric's algorithms ran great on the newer PC's even though he couldn't develop them on the new boxes. Other with Adobe (NOT on that web site interestingly enough) needed the DEC Alphas (64-bit machines) with scads of memory and much more running time to do a similar implementation of Eric's algorithms. </Old Geezer Mode>
3D rendering doesn't take that much RAM. As a 3D graphics researcher and developer, I have worked with models where individual objects were multi-gigabytes (meshes+textures and volumes) but even then, having 1GB of RAM was more than enough for us to reach 20-30 FPS realtime on a box with NT4 and first- and second-generation 3D cards. Software rendering with very realistic detail was a little slower (3-5 fps) but was fine for writing movies. Progressive geometry & texture transmission, continuously calculated view-dependant detail levels, and other current and not-so-current research would solve the memory problems in 3D. Don't believe me? Go to Visualization 2003 and see if the leading researchers are finding RAM as their primary bottleneck. It is a bottleneck of course, but processing speed, caches, and the system BUS limitations are far more troubling.
As for video editing, you only need enough memory for the tools, a few frames, and whatever operations you are performing. In every case that I've had to do video editing, I've seen two classes of tools -- those that take gobs of memory and try to copy the entire video clip into RAM and end up thrashing for memory -- and those that intellegently figure out what is needed and use only the memory needed for the app.
An example of the first, an Adobe AfterEffects rendering a simple math function over time was only able to render 30-seconds because it wanted to buffer the AVI file in memory and ran out of RAM (2GB) after a several-hour rendering. An example of the second, a simple home-brew compositor that used the Windows multimedia API to write the AVI to disk -- the same machine and the same set of images required about 45 minutes to render the entire clip.
So instead of saying:
I would suggest you say " I need to buy tools that are properly designed and implemented for my class of computer. "
Frob.
The only thing the entertainment industry has any skill at is entertaining people. And even then, I find them questionable.
frob
Just be careful about the definition of "derived works" vs. works that coexist, or works that link against system-integral libraries. Non-GPL works can coexist with GPL works, and non-GPL works can link with GPL libraries under certain circumstances; similarly, GPL works can link with non-GPL libraries under the same and similar circumstances (such as a GPL program linking with the Standard C library of the compiler).
Frob.
Just like with any NDA, post-employment non-competition agreement, or other employment terms, if you don't like the way they treat you BEFORE they hire you, you should tell them that, and look elsewhere.
So... by announcing which ones have been running that long, they are announcing which ones are vulnerable to known attacks.
I guess they won't be on the list for long.... :)
frob
Yuck. The citizens should run in terror!
Frob.
The only reason the big companies charge so much (their claim, not mine) is the insurance they provide, and the fact that they are "trusted" by the various vendors.
Any new group wanting to be a trusted CA will face the liability issue -- if one of your customers sues you, even if you try to disclaim all liability up front, you will still face massive court fees. Even if you won in court, you would lose financially if not insured.
There is no technical or logistical problem with setting up a Free (and free) common-geek's CA, the problems are entirely legal ones. I know because I looked into it right after SSL came out. It looks like a good business plan, right up until someone takes you to court.
frob.
Let me give an example. I could send a letter to your ISP, and say 'We believe that a user at 92.43.23.134 is electronically distributing our copyrighted documents. We demand that you turn over their name and contact information, according to the terms of the DMCA.'
Or they could say "several people at all these addresses and all these times are suspected of..."
This essentially means there will be no legal check. See the fourth ammendment to the US Constitution: "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. "
It has been fairly well established that obtaining records of that type are subject to 4th ammendment restrictions.
frob.
The crowbar example is badly flawed. I can think of no similar analogy.
The whole issue bothers me. You don't need a program like DeCSS to copy a DVD, you need a program like Nero Burning Rom, which makes copies of DVD's quite easily, and is not surrounded by any contraversy.
I believe that a DVD needs the CSS entact for use -- all the pirated DVD's are (or should be) bit-for-bit copies of the originals. You can run DeCSS to extract the video mpeg streams, which could then be viewed on an mpeg viewer, but if you run DeCSS, unless your DVD player also plays raw mpegs, it won't work.
Just like the ElcomSoft case, I believe that a through search of pirated DVD's will yield no or nearly no instances of piracy using that tool. That's mainly because the tool is impractical as a piracy device.
frob.
You should see 'test sheets' at some places, detailing the scene and goal of the scene, and listing all the different posibilities, and a checklist that the tester has done all of them. It feels like this:
Game testing has about zero appeal. Most people think "that would be fun" because they are ignorant. They see the final product and think it's easy. That just means the creators did good work.
Game programming is similar. The hours are crazy, the pay is low, expectations are high, deadlines are tight, specs keep changing, and the stress is insane. Sure there are a few (as in not very many, as in you won't ever get one) game jobs that don't have the problems, but it isn't the common case.
I would LOVE to see everyone who wants to program games actually be forced into the game market for one year. After the year, there would be enough decrease in demand that salaries might go up to a reasonable level with a corresponding drop in stresses.
I'll try it, and standard /. disclaimers apply...
I've seen other corporate contracts before, the 'if one party fails, the other gets the rights' is a common thing. In this case, Sendo was not worried about MS failing, so they let the clause slip. That's not a big thing.
MS had invested in sendo by buying shares in the company, followed by other agreements. While the agreements may have been a good business decision and run by one set of managers, the financial managers may have seen the shares in the company as a bad investment (after all, they aren't putting out the product on time...) and decided to order a buy-back on the investment.
Other than that, though, I can't come up with a pro-MS view for it. The articles and MS's own Press Pass area show a lack-luster support for their "partner" (Initial press release with Sendo, This should have been the pre-launch party with Sendo, The MS Technology is hyped, their partner is... mentioned., and what would have been the press release at the same time as Stinger was to be released is the press release "Microsoft Launches Windows Powered Smartphone Software", so they keep the target date and product, just changed people.)
:-)
frob.
The only thing the DRM or encryption would do is provide yet another means of tracking the files -- but it sounds like they are already using safeguards there. All versions, the user, and the duration of use are tracked. Those are the same, or in some cases better, than protections of physical evidence.
They don't need DRM cameras or higher cost encryption schemes. They need the same arguments that first allowed for fingerprints, DNA testing, and other new technologies in the courts.
frob.
She discussed this exact situation and several others, and how much redundancy is needed to avoid it. In one story, told a story where the top 4 sysadmins went to lunch together. Their car was hit in traffic and all 4 died. Because the govenrmnet requires lots of redundency and documentation, there were many other people at that building and at the Eastern processing center who knew and could access every password, and could fill in every aspect of the jobs of the deceased. Sure, it initially took 8 people to do the job of the 4, but there was no interruption and no major economical damage done.
If you want a secure system, you should be able to have over half of your administrators, programmers, and other key employees suddenly die or quit, and still be able to operate normally with little or no interruption. This is even more important if you have multiple key sites -- If everyone died at one site from some plague, you should still be able to recover all of your data.
If you can't do that, your system is not secure.
frob.
It's amazing to me how many PHB's keep their SA's out of the loop. It's also amazing to me that PHB's will say "I want this put together by $DATE" where $DATE is just barely enough time if everything else is delayed. The SA gets it done at a huge cost to other projects, and then the PBH doesn't use it until several weeks after the date.
An unhappy sysadmin is a big security hole.
frob.
NTSC uses the YIQ color space, and PAL uses YUV or YPbPr. The computers that the movie was developed on used RGB. To move from RGB to either YIQ or YUV requires some lossy transformations.
Red being 'hot', red or blue shifts, and color saturation (2 of the 3 are reported problems with the DVD) are symptoms of not doing the transformations properly.
frob.
Or maybe they intended everyone to watch it on RGB/Digital screens instead of regular CRT TV's.
From the article:
and quote two:
Now if you have worked with computer monitors, TVs, and broadcast standards at all, you should have heard about RGB, NTSC, and PAL.
RGB is the way that computer signals are sent. It is a pure encoding of the percentage of Red, Green, and Blue to display at some location (based on the current beam position and timing).
NTSC (used in the US) encodes the information in YIQ color space. When color TVs were invented, they decided to keep backwards compatibilty with B/W tv's. Thanks to a bit of math that is beyond the scope of a /. post, the red waveform was distorted and other colors are clipped, so that red becomes more intense, and pure yellow, cyan, red, and blue are all impossible to get. Red becomes more intense than the RGB display, and blue is muted.
PAL (used everywhere else) encodes the information in YUV color space, or YPbPr. In this case, where again, scaling and TV hardware result in different color than the RGB that computer monitors display.
So when the distributors say "the DVD should be played on Liquid Crystal TV or Plasma TV, so should be no problem for its quality" what they mean is We didn't convert RGB to the YUV or YIQ color space either because they forgot (what customers say) or because they meant it to be viewed on an RGB display (what the studio is saying).
Is that a real problem? Most people who have to deal with broadcasts say 'no' because your TV is supposed to have a tint and hue knob that you can frobnicate until you get the desired colors.
frob.
Most of the BSOD's in Windows come from shoddy software. The BSOD or kernel panic allows developers to find the device drivers, libraries, or other 'insider' code that is messed up.
I've done a *LOT* of debugging, including wading through the kernel and drivers to find strange bugs (these comments are about graphics drivers specifically). I have seen device drivers with int 3's (debug interrupts) scattered through them. I have seen device drivers that obviously were using the 'minimal rebuild' options, resulting in slower and more-corrupt code. I have seen drivers that try to run (and usually crash) Pentium 3, Pentium 4, and Athalon instructions even though the CPU doesn't support those instructions. In short, drivers and applications, not the Windows kernel or API's, are generally at fault.
When I do have the misfortune of having to do driver-level debugging, I have never, not once, seen a crash with the Windows NT/98/2000/ME/XP kernels. Inefficient, unoptimized and seemingly poor design decisions are in there, as are occasional functional errors and side effects, but as for crashes in the kernel, I have never seen one.
If the same logic were applied to all software (If it crashes, you die) not even Donald Knuth would be left alive. And that would be a sorry state.
frob.