Yes we are using them for rendering output a lot. The renderers will correctly calculate brightness well outside the 0-1 range and this allows us to recover that information in compositing.
Biggest problem with renderers is that they refuse to treat incoming texture maps as anything other than linear. It would help a lot if they assummed 8-bit files were sRGB brightness levels. In some cases this can be fixed in shaders but that is rather tedious. Also often GUI input of colors is wrong, since it assumes the 8-bit color displayed by the GUI is linear.
We have been using an in-house format we call RGBA. This is simply SGI's format with the "exponent" of the largest of RGB put in the alpha channel, and the top 8 bits (with a leading 1) of the mantissa of RGB put into the RGB channels. This is an old trick from Graphics Gems. We have not really used Debevec's HDR format, RGBA was much easier to get into our software as it all already read/wrote SGI's format. But EXR is much better and we expect to use it extensively.
The greater dynamic range matters a lot less than getting the numbers to represent *linear* intensity levels.
Most existing software works with 8 bits where the 255 levels are assigned to intensities by the definition "this number means the intensity you get when it is put on the screen". This is NOT linear (it is approximatley a 2.5 power function, and is also standardized as the sRGB curve).
Most of the algorithims used by the software does assumme linear levels though (like assumming that two pixels with 10 in them will be as bright as one pixel with 20 in it). This assumption is incorrect and is why a lot of renders and manipulations that you think are obeying the laws of physics produce bad computer-generated appearing images.
The problem is that you cannot use 8 bits for linear, as the steps at the black end are way too far apart (and lots of uselessly close steps are up at the white end). Fixing this requires a lot of rewriting of the software, and typically means replacing everything with floating point.
Tiles were invented back when image processing meant running PhotoShop on a Mac with 1Mbyte of memory.
In fact tiles are a complete hinderance to modern programs that want to access arbitrary rectangles of the image and not obey some predefined cutting into tiles. For these programs, "tiles" like in tiff files require reading the entire image into memory before any of it can be returned, completely inverting the entire purpose of tiles. In the software I am writing our tiff reader refuses any tiled tiffs (ie it only accepts files that are one big tile) and we have yet to encounter any tiff that is not just one big tile.
Many modern programs "tile" the image by cutting it into scan lines or groups of scan lines, which you could consider long narrow tiles. But this requires no special support by the file other than storing the pixels in horizontal order.
This serves a different purpose. This is a well-defined lossless storage for floating-point intensity data. It is going to be at least twice as big as PNG (probably more as the compression is not going to be as good). For images that are not being manipulated, but just shown to the user, there is no need for more than 8 bits. For photographic images (which this is likely to be used for) neither it nor png are good for the net, use lossy compression like jpeg and it will be 10 times smaller.
Rendering into HDR images is really useful if you want to process the color later using a 2D program. Post process blurs, lens flare, and motion blur are far, far better when done to an HDR image. Also since no data is lost the 3D person does not have to waste lots of time adjusting the lights to get the render into range.
Just to clarify, there is a seperate floating-point intensity for each color (rgb). The above description implies there is a seperate color and intensity.
Though this is practical if you use a linear space like XYZ so little software uses this that it is probably much more useful to store rgb. Don't even think about trying to store "hue" or store non-linear values like CIE xyz or any of that color-management stuff, non of it is defined well enough for cgi.
Actually what causes lines to come out different widths is that hinting requires the characters to start at integer positions. If you print a bunch of n's and you want them all to look identical, it should be easy to see that they must each be placed an integer distance away from the previous one. And if you want it too look even, they must all be placed the *same* distance apart, or there will be obvious irregularity in the letter spacing.
So if in fact the n is 4.6 pixels wide, there will be.4 width added for every n in the line.
This can play havoc with the poor secretary trying to get wysiwyg. MicroSoft has done some nasty stuff like space the letters on the printer on integer screen pixels to make it match. But they had to abandon this as other software started producing obviously better output on the same devices. So I believe they have been forced to give up on hinting in order to get nice-looking display that is also WYSIWYG. Apple seems to have decided to do the same thing. And due to Apple's patents it looks like Linux is doing the same thing from the start.
Post Script Type 1 versions of zapfdingbats and lucida sans are easily available (I seem to have them on my disk) though I'm not sure if it is legal. The newer Xft/FreeType renders Post Script Type 1 just as nicely (some claim better) than True Type.
I suppose your joking, but the big deal is that until now most of the fonts that could legally be distributed with Linux looked like the fonts you are creating. That's pretty bad.
Mac OS X/Cocoa also has the concept of sheets, which are basically modal dialogs attached to one certain document window in an application. There's no similar concept in e.g. Gnome,
Actually both X (or X Window Managers) and Windows support the idea of "child" windows that belong to a certain parent window. In fact this is about the only way to keep one window atop another. On both systems hiding the parent window makes the child window disappear, and showing it again makes the child window reappear. Also (for Windows and most X window managers) the child windows have no iconize buttons of their own and cannot be iconized seperately. Sheets match pretty cleanly onto this.
The answer is #1 on all platforms. Low level calls are used.
Except it is possible the Aqua look on OS/X uses #2 a bit, such as to request images from the OS for what a button should look like, that it then draws just like an image supplied by the program.
Personally I don't think it is possible to write a working and truly portable toolkit by any other method. WxWindows despite all the claims here is obviously not used for any open-source software or anything complex like a drawing or word processing program, but mostly for commercial fill-out-the-forms stuff. At the current bad level of the technology and toolkit design this is just impossible. If toolkit 1 needs you to do "A" before "B" and toolkit 2 needs you to do "B" before "A" (typical example is A=create a window, B=figure out what you will draw in it) then no portable toolkit can do anything other than combine A & B together, no matter how illogical or complicated it is. This severly limits the ability to make an easy-to-program and nice design.
I expect someday a low-level design will be made that will cleanly provide widgets without being obscenly complex and will be obvious enough that all systems will use it. But we are nowhere near this. This is similar to the discovery in about 1970 that powerful file systems could be managed with just read/write/seek and not "record management" and that discovery led us to the enormous and fast disks, varied filesystems, and the networks we use today. GUI is obviously harder but perhaps some genius out there will figure it out.
A "trusted" OS would not run unless that hash is correct. This prevents you from modifying how that "trusted" OS is loaded so that you could, for instance, debug it or reverse-engineer it.
In fact in the newer versions of fltk there is an Fl::signal() function that does just that. On Unix it uses a pipe to signal the main thread, on Windows it uses some Windows thread thing, so it is portable.
You probably want to do Fl::add_fd() to add a callback to be called when your file descriptor is ready. This uses select() internally.
The add_timeout() callback should be done as well. However you have to put your code in the timeout. You can't rely on it making wait() return, wait() will not return while the modal file chooser is up.
I think there will be only one key (or probably a fixed *set* of keys). At least at some level.
I doubt they will give the private keys to anybody. Instead you must send your binary to a "signing service" that will do it. So the vendors will not have access to these keys. However I see a lot of problems. Any software developer will have to sign dozens of test versions a day, so this system will have to be automated. It would not be too hard for a trusted developer to get anything signed they wanted. Alternatively the software developer could be given a "broken" Windows that runs anything with full trust, but this system itself would be incredibly valuable. In either case I don't see how a Hong Kong pirate or Osama bin Laden, with a lot of money and other methods of coercion at their disposal, would have little trouble cracking this.
I also wonder if Public key encryption can be broken if you have the ability to select arbitrary messages you want encrypted.
Of course the whole point of this is to lock down private machines so the individual can't fast-forward through ads (even on their pirate copy), and make it impossible to do things (like play even a pirate copy) without running Windows. It has nothing to do with stopping piracy or with security, so these holes are irrelevant to their plans.
No, the "POSIX subsystem" is absolutely useless. It cannot read/write files that the Win32 system could read/write, and it cannot make any Win32 calls. It is strictly there to fullfill a checkmark on government requirement forms and is purposely designed so that it is impossible to write useful software under it.
I still say they were stupid. There would be no Linux today if they had just based NT on Unix. It could have been even as bad a copy as Xenix. They realized their mistake and that is why the now say "embrace and extend" is the way to go.
The VMS guys saw all the Vaxen sold to education instutions wiped and replaced with BSD Unix and felt quite defeated by this. It did not matter what banks left on the Vaxes, for the average new student is CS a VAX ran BSD Unix. The students were also exposed to a great deal of FUD that VMS sucked and Unix was a win. I think they had a lot of hatred of Unix.
This is obviously some crazy old speech or document, with whatever they are attacking replaced by "Microsoft". Can anybody figure out what the original was?
The VMS guys from Dec HATED Unix, because BSD had completely wiped out their beloved VMS. The expensive new hires had enough clout to either fire or bury all the Unix supporters at MicroSoft. Their hatred is the real reason NT is so hostile to Unix.
If MicroSoft had any business sense they would have made NT very Unix-like so that porting software to it was a no-brainer. If they had done that there would probably not be any Linux or any other Unix variant today and EVERYTHING would run NT. But emotions were stronger than sense...
Wrongo! Every program that calls open() uses the BSD system. Mach message passing is only used for ipc between NextStep applications.
You seem to be confusing the user-level tools with the kernel. The tools are easy to add (take a look at cygwin for Windows) but they don't mean the result is Unix.
False. It is pretty clear the TPM chip contains a PUBLIC key. You can read it. But you cannot encrypt anything in a way that will be decrypted by the public key. However large companies are able to sign contracts that give them access to the private key, or a service that encrypts their information with it.
Therefore there is something your own software cannot do with the encryption system: it cannot create data that can be decrypted by it. Others can. Thus by definition you cannot use the encryption key system in any way you like.
You have no idea what you are talking about. Every one of your examples can be done by software and virtual memory hardware that exists today. The TCP/IP driver can peek at the VPN passwords because the programmer was too stupid to put the things in different memory spaces. If you think having a different form of protection in TCPA is going to suddenly make the programmer smart enough to not do this mistake, you are seriously deluded. However I think you are trying to make excuses.
TCPA means there is a public crypto key in the hardware. THERE IS NO PRIVATE KEY. This means that the owner of the computer CANNOT SIGN CODE!!! (by owner I mean the same thing you mean, the IT department, not the dumb secretary who is at the desk). The fact that the owner cannot sign code is the ONLY difference between TCPA and all the well-established security schemes in existence.
The entire purpose of TCPA is to make sure that people cannot program their own computers. It is not a magic thing that is going to suddenly make software have no bugs!! It is going to sign those bugs and say they are "trusted".
Closed source and commercial software changes the defaults a lot more, and usually without telling anybody.
In fact one of the big problems with Linux is the extreme fear of changing the defaults on the chance that it will be incompatable. This is why tcsh still does not do the full editing and tab completion by default, why "find" is a pain to use for simple searches, and why programs like make are such horrors to program.
Probably the criticism you wanted was that Open Source often puts *no* checkmark in the control panel. You are supposed to figure out that you can change things by setting an environment variable and you can only figure that out by reading the source.
One each, apparently. Though if you want a Democratic skew you could say that 50% of the Democrat appoitees voted against it but only 14% of the Republican appointees voted against it.
Slashdot Mirror
Yes we are using them for rendering output a lot. The renderers will correctly calculate brightness well outside the 0-1 range and this allows us to recover that information in compositing.
Biggest problem with renderers is that they refuse to treat incoming texture maps as anything other than linear. It would help a lot if they assummed 8-bit files were sRGB brightness levels. In some cases this can be fixed in shaders but that is rather tedious. Also often GUI input of colors is wrong, since it assumes the 8-bit color displayed by the GUI is linear.
We have been using an in-house format we call RGBA. This is simply SGI's format with the "exponent" of the largest of RGB put in the alpha channel, and the top 8 bits (with a leading 1) of the mantissa of RGB put into the RGB channels. This is an old trick from Graphics Gems. We have not really used Debevec's HDR format, RGBA was much easier to get into our software as it all already read/wrote SGI's format. But EXR is much better and we expect to use it extensively.
Most existing software works with 8 bits where the 255 levels are assigned to intensities by the definition "this number means the intensity you get when it is put on the screen". This is NOT linear (it is approximatley a 2.5 power function, and is also standardized as the sRGB curve).
Most of the algorithims used by the software does assumme linear levels though (like assumming that two pixels with 10 in them will be as bright as one pixel with 20 in it). This assumption is incorrect and is why a lot of renders and manipulations that you think are obeying the laws of physics produce bad computer-generated appearing images.
The problem is that you cannot use 8 bits for linear, as the steps at the black end are way too far apart (and lots of uselessly close steps are up at the white end). Fixing this requires a lot of rewriting of the software, and typically means replacing everything with floating point.
In fact tiles are a complete hinderance to modern programs that want to access arbitrary rectangles of the image and not obey some predefined cutting into tiles. For these programs, "tiles" like in tiff files require reading the entire image into memory before any of it can be returned, completely inverting the entire purpose of tiles. In the software I am writing our tiff reader refuses any tiled tiffs (ie it only accepts files that are one big tile) and we have yet to encounter any tiff that is not just one big tile.
Many modern programs "tile" the image by cutting it into scan lines or groups of scan lines, which you could consider long narrow tiles. But this requires no special support by the file other than storing the pixels in horizontal order.
This serves a different purpose. This is a well-defined lossless storage for floating-point intensity data. It is going to be at least twice as big as PNG (probably more as the compression is not going to be as good). For images that are not being manipulated, but just shown to the user, there is no need for more than 8 bits. For photographic images (which this is likely to be used for) neither it nor png are good for the net, use lossy compression like jpeg and it will be 10 times smaller.
Rendering into HDR images is really useful if you want to process the color later using a 2D program. Post process blurs, lens flare, and motion blur are far, far better when done to an HDR image. Also since no data is lost the 3D person does not have to waste lots of time adjusting the lights to get the render into range.
Just to clarify, there is a seperate floating-point intensity for each color (rgb). The above description implies there is a seperate color and intensity.
Though this is practical if you use a linear space like XYZ so little software uses this that it is probably much more useful to store rgb. Don't even think about trying to store "hue" or store non-linear values like CIE xyz or any of that color-management stuff, non of it is defined well enough for cgi.
So if in fact the n is 4.6 pixels wide, there will be .4 width added for every n in the line.
This can play havoc with the poor secretary trying to get wysiwyg. MicroSoft has done some nasty stuff like space the letters on the printer on integer screen pixels to make it match. But they had to abandon this as other software started producing obviously better output on the same devices. So I believe they have been forced to give up on hinting in order to get nice-looking display that is also WYSIWYG. Apple seems to have decided to do the same thing. And due to Apple's patents it looks like Linux is doing the same thing from the start.
Post Script Type 1 versions of zapfdingbats and lucida sans are easily available (I seem to have them on my disk) though I'm not sure if it is legal. The newer Xft/FreeType renders Post Script Type 1 just as nicely (some claim better) than True Type.
I suppose your joking, but the big deal is that until now most of the fonts that could legally be distributed with Linux looked like the fonts you are creating. That's pretty bad.
Actually both X (or X Window Managers) and Windows support the idea of "child" windows that belong to a certain parent window. In fact this is about the only way to keep one window atop another. On both systems hiding the parent window makes the child window disappear, and showing it again makes the child window reappear. Also (for Windows and most X window managers) the child windows have no iconize buttons of their own and cannot be iconized seperately. Sheets match pretty cleanly onto this.
Except it is possible the Aqua look on OS/X uses #2 a bit, such as to request images from the OS for what a button should look like, that it then draws just like an image supplied by the program.
Personally I don't think it is possible to write a working and truly portable toolkit by any other method. WxWindows despite all the claims here is obviously not used for any open-source software or anything complex like a drawing or word processing program, but mostly for commercial fill-out-the-forms stuff. At the current bad level of the technology and toolkit design this is just impossible. If toolkit 1 needs you to do "A" before "B" and toolkit 2 needs you to do "B" before "A" (typical example is A=create a window, B=figure out what you will draw in it) then no portable toolkit can do anything other than combine A & B together, no matter how illogical or complicated it is. This severly limits the ability to make an easy-to-program and nice design.
I expect someday a low-level design will be made that will cleanly provide widgets without being obscenly complex and will be obvious enough that all systems will use it. But we are nowhere near this. This is similar to the discovery in about 1970 that powerful file systems could be managed with just read/write/seek and not "record management" and that discovery led us to the enormous and fast disks, varied filesystems, and the networks we use today. GUI is obviously harder but perhaps some genius out there will figure it out.
A "trusted" OS would not run unless that hash is correct. This prevents you from modifying how that "trusted" OS is loaded so that you could, for instance, debug it or reverse-engineer it.
In fact in the newer versions of fltk there is an Fl::signal() function that does just that. On Unix it uses a pipe to signal the main thread, on Windows it uses some Windows thread thing, so it is portable.
The add_timeout() callback should be done as well. However you have to put your code in the timeout. You can't rely on it making wait() return, wait() will not return while the modal file chooser is up.
I doubt they will give the private keys to anybody. Instead you must send your binary to a "signing service" that will do it. So the vendors will not have access to these keys. However I see a lot of problems. Any software developer will have to sign dozens of test versions a day, so this system will have to be automated. It would not be too hard for a trusted developer to get anything signed they wanted. Alternatively the software developer could be given a "broken" Windows that runs anything with full trust, but this system itself would be incredibly valuable. In either case I don't see how a Hong Kong pirate or Osama bin Laden, with a lot of money and other methods of coercion at their disposal, would have little trouble cracking this.
I also wonder if Public key encryption can be broken if you have the ability to select arbitrary messages you want encrypted.
Of course the whole point of this is to lock down private machines so the individual can't fast-forward through ads (even on their pirate copy), and make it impossible to do things (like play even a pirate copy) without running Windows. It has nothing to do with stopping piracy or with security, so these holes are irrelevant to their plans.
I still say they were stupid. There would be no Linux today if they had just based NT on Unix. It could have been even as bad a copy as Xenix. They realized their mistake and that is why the now say "embrace and extend" is the way to go.
The VMS guys saw all the Vaxen sold to education instutions wiped and replaced with BSD Unix and felt quite defeated by this. It did not matter what banks left on the Vaxes, for the average new student is CS a VAX ran BSD Unix. The students were also exposed to a great deal of FUD that VMS sucked and Unix was a win. I think they had a lot of hatred of Unix.
This is obviously some crazy old speech or document, with whatever they are attacking replaced by "Microsoft". Can anybody figure out what the original was?
The VMS guys from Dec HATED Unix, because BSD had completely wiped out their beloved VMS. The expensive new hires had enough clout to either fire or bury all the Unix supporters at MicroSoft. Their hatred is the real reason NT is so hostile to Unix.
If MicroSoft had any business sense they would have made NT very Unix-like so that porting software to it was a no-brainer. If they had done that there would probably not be any Linux or any other Unix variant today and EVERYTHING would run NT. But emotions were stronger than sense...
You seem to be confusing the user-level tools with the kernel. The tools are easy to add (take a look at cygwin for Windows) but they don't mean the result is Unix.
I also agree this would be a good idea, though they would probably go with Direct X rather than OpenGL, which would be bad.
In any case other toolkits can be made to work with Xlib emulation, much like X is done on Win32 right now.
Therefore there is something your own software cannot do with the encryption system: it cannot create data that can be decrypted by it. Others can. Thus by definition you cannot use the encryption key system in any way you like.
TCPA means there is a public crypto key in the hardware. THERE IS NO PRIVATE KEY. This means that the owner of the computer CANNOT SIGN CODE!!! (by owner I mean the same thing you mean, the IT department, not the dumb secretary who is at the desk). The fact that the owner cannot sign code is the ONLY difference between TCPA and all the well-established security schemes in existence.
The entire purpose of TCPA is to make sure that people cannot program their own computers. It is not a magic thing that is going to suddenly make software have no bugs!! It is going to sign those bugs and say they are "trusted".
In fact one of the big problems with Linux is the extreme fear of changing the defaults on the chance that it will be incompatable. This is why tcsh still does not do the full editing and tab completion by default, why "find" is a pain to use for simple searches, and why programs like make are such horrors to program.
Probably the criticism you wanted was that Open Source often puts *no* checkmark in the control panel. You are supposed to figure out that you can change things by setting an environment variable and you can only figure that out by reading the source.
One each, apparently. Though if you want a Democratic skew you could say that 50% of the Democrat appoitees voted against it but only 14% of the Republican appointees voted against it.
Too bad you can't find any good friends.