Ouch, sorry for you... Here is what to do: spawn a separate thread to handle the networking. Create a pipe between this thread and the main thread. The main thread, which is the only one to interact with FLTK, should use add_fd() to wait on the pipe. Whenever the networking thread needs the GUI to do something, it should write a message to the pipe. The main thread should read the message and then perform the appropriate action.
It will be interesting to see whether they use the same key pair for all machines, or whether each machine will have a different key.
One key pair for everybody would be cheaper and simpler, but there is a big chance the key would get compromised. (MS went this route with Xbox and seem to have done a good job keeping the key secret, however the Xbox software vendors form a much smaller group than the general software development and media communities...)
One key per device would give better security, but all your software and media would have to be custom-encrypted for your machine, which would impose pretty substantial costs on vendors. I'm not sure a typical company would want to maintain a farm of machines running 24/7 just to encrypt their products for each new customer.
Even in a one-key-per-device system, there is still the danger that one key pair could be recovered (or forged) - and then whoever has that pair could decrypt and offer plaintext versions of anything to the world... If such a system is adopted, expect hardware vendors to maintain a "master list" of the public keys for every unit sold; before encrypting a product the media vendor would check your key against the list to prevent you from providing a forged public key (whose private key you know).
The burden of administering this list would be heavy, and I'd expect it to become the target of many attacks... e.g. one of the large overseas piracy outfits could set up a rogue hardware manufacturer just to get access to the key list. It might not even take that much - a "social engineering" attack at a hardware vendor might score some key pairs. There would be a race between key attackers and the "master list" maintainers, who would strike compromised keys off the list as they are discovered.
Yes, STL implementations vary greatly in overhead - the GNU STL seems to add about 10x and STLport, which I like better, adds only 2x-4x. (this is compared to my own little out-of-line collections library).
I have an inline List class that takes less than one page of code, compiles instantly, and does everything I need (including proper management of Lists of objects with constructors and destructors). It is better than the STL list because you can embed the list pointers in a class or struct if you want, to avoid the overhead of allocating a new list node for each item.
Practically any string implementation is going to be less heavy than STL's string:). I think the approach of having string be a generic template is the wrong path - the only use I can think of is strings of u16s or u32s for Unicode - but in that case you are probably just as well off using UTF-8. Practically all C++ programs need some kind of self-allocating string, and it's stupid to penalize them all just to handle one rare corner case.
Ah yes, the true power of the STL - the ability to make your binaries ten times bigger and compile times ten times longer without warning:):)
Yes, for really tough problems (multimap of lists of strings to sets of ints...) STL is the only way to go. But for everyday stuff like lists, arrays, and strings, you are much better off with a simpler solution.
This is more of an IDE thing than a debugger thing, but I'd really like to have an automated way of finding all the call sites that access a particular class or struct member.
e.g. if I have struct foo { int count;... };
I want to see all lines of code that access the 'count' member of struct foo. (WITHOUT showing all other occurrences of the string 'count' like a simple grep would).
Bonus points if the feature can track pointer aliasing - e.g. in the example above, *((int*)&foo) should also count as a hit... Or if I have an array 'int arr[]' and I want to see all access to arr[3], including *(arr+3) and arr[i] where i could equal 3.
Yeah, the early ones like "CGA", "EGA", and "VGA" had very specific meanings (certain combinations of horizontal/vertical resolution and color palette). "SVGA" was a quasi-standard for a variety of video modes from 320x240x8bits up to 1600x1200x32bits and beyond. "XGA" was an IBM proprietary standard that never became popular, and everything since has just been pure marketing buzzwords. ("It has QXGA instead of SXGA so it must be better...")
It's interesting that Apple, one of the most marketing-driven of computer vendors, still tells you the exact pixel resolution.
And don't get me started on the digital camera industry for deciding to multiply it out and tell you they've got "X megapixels"...
Dontcha wish they'd stop using those stupid XGA/SXGA/QXGA/whatever acronyms and just tell you how many damn *pixels* the thing does horizontally and vertically...
You point out an interesting "negative externality" problem - when someone decides to copy content without paying they are gaining a lot for themselves (a free copy with little chance of being caught), but losing a little for everybody (more ammunition for pro-DMCA arguments). Everyone is making the decision that benefits himself most, but when you add it all up it's going to be a huge net loss for everybody...
You actually bring up a serious point. One question that often gets overlooked in the DRM debate is, "who owns the keys?" Most DRM systems only allow major studios to encrypt their works; there is no "home edition" of the cypher algorithm for independent artists to protect their own projects. (or if the algorithm is public, there is no way to get the keys needed for encryption).
Thus the protection afforded by DRM is very asymmetrical, as opposed to copyright, which applies to all authors. (unless you crack the algorithm and distribute ReCSS...)
Thanks for the info. Of course there is very little chance Morrison would actually get in trouble for collecting old film, but it's still no less an infringement than, say, distributing MP3s made from a newly-discovered tape of some music group you've never heard of. And here he's charging money for it!
(I dislike strong copyright as much as anyone else, I just think so much of the conduct the RIAA/MPAA/FCC are pounding on is just as harmless as gathering these old film clips...)
I'm sure if movie studios had thought of selling rights to post-decay film prints, they would all have gone to the highest bidder already:)...
The copyright extensions were retroactive - that's why "Steamboat Willie" still hasn't become public domain... Only films released before 1923 are public domain; there aren't too many of those left...
I was shocked that the New York Times Mangzine article about this film neglected to mention any of the copyright issues. Very few (no?) motion pictures have yet entered the public domain. Therefore, Mr. Morrison is likely in blatant violation of the copyrights on various pieces of his film.
I find it offensive how casual industry "insiders" tend to be about copyright violations, while they simultaneously condemn audience members for time- or space-shifting their own works.
Hopefully reality will catch up to them soon enough - the only available subject for the next "Decasia" will be the white noise of encrypted video streams, their keys long lost in obsolete trusted playback hardware...
Wow, this is very scary - Linux with a professionally-designed interface on top:)... (although XFree is still betrayed by the horrendous-looking fonts in the menu bar of their Task Manager...)
I hope they also take care to double-buffer most of the UI graphics like Windows - it's not good enough if the screenshots match, the interactiveness has to match also...
I can give a good recommendation for FLTK. It is a solid, mature toolkit, and yet remains simple to understand and use. FLTK widgets are written in native 2D code (X11/GDI/etc) for speed, but it is very easy to add OpenGL where necessary. FLTK is good for graphics apps because it understands the special needs of programs where a GUI update is not computationally cheap. (unlike other toolkits, it gives you very detailed control over the event loop if you want it...)
Although FLTK's default widget appearance looks dated, it resembles the SGI inteface that people have come to associate with high-end graphics programs. (virtually no high-end graphics software uses the native widgets on any platform, perhaps because native widgets tend not to offer the kinds of things you need - like good color pickers, configurable slider bars, etc)
Just about the only drawback to FLTK is that the API is C++-only, and it's tied strongly into a C++ "one owner" memory management model, which makes it difficult to use from any other language. (however FLTK is simple and well-designed C++, not like the haphazard hodgepodge of classes and poor event systems in many lesser C++ APIs)...
Presumably NTFS is off by default because the code is a work in progress and writing to it may corrupt your filesystem. Also NVIDIA doesn't allow redistribution of its binary drivers. The other points are reasonable...
I dunno about Junkyard wars... The more I watch it the more I think the hosts/interviewers are just patronizing the contestants. ("What a bunch of pencilheads! Let's all get together and give them swirlies after the show!")
Re:Cable is fundamentally better
on
DSL Rising
·
· Score: 2
I like your point about "shared bandwidth." So many ISPs are capping up/down speeds that theoretical maximum bandwidth is meaningless. You should only be concerned with how much of that bandwidth the cap gives you.
e.g. my cable modem is capable of uploading at over 100KB/sec, which it used to do years ago. Now the upload speed is capped to 30KB/sec. I'd be happier with a connection that maxes out at 50KB/sec, half the cable modem, if only I were allowed to use all of it:).
When they say Firewire I/O they don't necessarily mean that it won't be encrypted. Yes there is equipment that sends MPEG-2 over Firewire without encryption (some HDTV cable boxes can be modified to do this), but there is also a CSS-like encryption standard for Firewire.
Also there is the possibility that the FCC will mandate a "broadcast flag" (a bit that says "no copying") in the Firewire stream; any hardware or software that doesn't respect that flag would be outlawed in the US. (much like Macrovision-free VHS and DVD players...)
As an interesting side note, the TV Firewire standard is just plain old MPEG-2, which means that once Firewire PVRs are available, they would also be able to record video straight off a DVD without any loss of image quality. (assuming you had a DVD player with Firewire output, which I expect will start to appear soon)...
You are right, there is a distinct lack of recordable consumer-level HDTV interconnects right now. You've got analog component, but nobody seems interested in recording it (plus the MPAA et al probably want it to go away ASAP since it's not encrypted).
The two digital standards are FireWire (IEC 61883-4) and DVI. In the next few years I expect most HDTV tuners and TVs will sprout at least one of these, and analog component will fade away. I have a JVC D-VHS deck with FireWire I/O, and I've successfully captured and played back 1080i ATSC video using a custom Linux utility. This proves it is possible to construct a HDTV PVR...
The big sticking point of course is the copy-prevention business. Currently ATSC broadcasts are not encrypted, and some HDTV tuners can be modified to output the unencrypted signal via FireWire. However, it is likely that all transmission of HDTV video over FireWire will be encrypted in the near future (or there will be a "don't copy" bit embedded in the video, backed by DMCA enforcement). DVI has been scrambled from its beginning as an HDTV transport format. (AFAIK DVI sends uncompressed video, so it's not clear you'd be able to record it even without any encryption)
I've heard rumors that the encryption developers have not learned their lesson and are still using cryptographically weak algorithms. So we might very well a DeCSS-like utility for decrypting HDTV FireWire streams.
Another reason could be that syscall overhead is much lower in Linux (since you are calling glibc which calls the kernel directly, whereas on Win32 you are calling user32.dll which calls ntdll.dll which calls the kernel; and the kernel entry/exit code on Linux is much more optimized). Also process and thread context switches are several times faster than on Windows. And finally, Linux until recently gave much longer timeslices to CPU-bound processes (which can be a bad thing on the desktop:).
I am running a functional render farm of 4 Linux machines with LWSN 5.5 and 7.5. I don't use many plugins but the ones I have work OK.
Sometimes it runs faster than Windows. (I think it could be that the Linux malloc and VM implementations are better, or the Win32 console subsystem is just really slow).
The hard parts were finding a stable version of Wine and getting suitable X and filesystem environments set up. I'll let you figure those out:)
I do wish Newtek would just release the Linux build of lwsn. My guess is they are terrified of the support issues.
Incidentally, the Layout and Modeler GUIs are pretty close to usable in Wine, except for some annoying mouse/keyboard input bugs.
You do have a good point. For most people, probably the safest economical way to back up text documents is by printing them on high quality paper, and storing multiple copies in different locations. If the need arises to retrieve any data, scan the paper and use OCR software to convert it into whatever format is currently popular.
For archiving images, printing on high-quality paper with a good printer would work, although not so cheaply.
Sound and video are even more difficult, because you're pretty much confined to some sort of magnetic or optical format, which may not be readable on any machine in the future. (good old optical film with an optical soundtrack might work, at horrific expense...)
I think the group you are talking about was more advocating Lightwave and other off-the-shelf software (vs the traditional heavily customized Alias/Softimage/RenderMan pipeline), rather than NT (vs UNIX). By the time they formed Station X, they were producing results just about as good as the traditional pipeline, but much more quickly and cheaply. (although I attribute this just as much to their artistic talents as choice of software). Station X failed for stupid legal reasons; I was told they were actually quite profitable.
(disclaimer: I worked as an intern at SXS one summer - it was one of the most exciting jobs I've had!)
Slashdot Mirror
Ouch, sorry for you... Here is what to do: spawn a separate thread to handle the networking. Create a pipe between this thread and the main thread. The main thread, which is the only one to interact with FLTK, should use add_fd() to wait on the pipe. Whenever the networking thread needs the GUI to do something, it should write a message to the pipe. The main thread should read the message and then perform the appropriate action.
It will be interesting to see whether they use the same key pair for all machines, or whether each machine will have a different key.
One key pair for everybody would be cheaper and simpler, but there is a big chance the key would get compromised. (MS went this route with Xbox and seem to have done a good job keeping the key secret, however the Xbox software vendors form a much smaller group than the general software development and media communities...)
One key per device would give better security, but all your software and media would have to be custom-encrypted for your machine, which would impose pretty substantial costs on vendors. I'm not sure a typical company would want to maintain a farm of machines running 24/7 just to encrypt their products for each new customer.
Even in a one-key-per-device system, there is still the danger that one key pair could be recovered (or forged) - and then whoever has that pair could decrypt and offer plaintext versions of anything to the world... If such a system is adopted, expect hardware vendors to maintain a "master list" of the public keys for every unit sold; before encrypting a product the media vendor would check your key against the list to prevent you from providing a forged public key (whose private key you know).
The burden of administering this list would be heavy, and I'd expect it to become the target of many attacks... e.g. one of the large overseas piracy outfits could set up a rogue hardware manufacturer just to get access to the key list. It might not even take that much - a "social engineering" attack at a hardware vendor might score some key pairs. There would be a race between key attackers and the "master list" maintainers, who would strike compromised keys off the list as they are discovered.
Yes, STL implementations vary greatly in overhead - the GNU STL seems to add about 10x and STLport, which I like better, adds only 2x-4x. (this is compared to my own little out-of-line collections library).
:). I think the approach of having string be a generic template is the wrong path - the only use I can think of is strings of u16s or u32s for Unicode - but in that case you are probably just as well off using UTF-8. Practically all C++ programs need some kind of self-allocating string, and it's stupid to penalize them all just to handle one rare corner case.
I have an inline List class that takes less than one page of code, compiles instantly, and does everything I need (including proper management of Lists of objects with constructors and destructors). It is better than the STL list because you can embed the list pointers in a class or struct if you want, to avoid the overhead of allocating a new list node for each item.
Practically any string implementation is going to be less heavy than STL's string
Ah yes, the true power of the STL - the ability to make your binaries ten times bigger and compile times ten times longer without warning :) :)
Yes, for really tough problems (multimap of lists of strings to sets of ints...) STL is the only way to go. But for everyday stuff like lists, arrays, and strings, you are much better off with a simpler solution.
This is more of an IDE thing than a debugger thing, but I'd really like to have an automated way of finding all the call sites that access a particular class or struct member.
... };
e.g. if I have
struct foo { int count;
I want to see all lines of code that access the 'count' member of struct foo. (WITHOUT showing all other occurrences of the string 'count' like a simple grep would).
Bonus points if the feature can track pointer aliasing - e.g. in the example above, *((int*)&foo) should also count as a hit... Or if I have an array 'int arr[]' and I want to see all access to arr[3], including *(arr+3) and arr[i] where i could equal 3.
Yeah, the early ones like "CGA", "EGA", and "VGA" had very specific meanings (certain combinations of horizontal/vertical resolution and color palette). "SVGA" was a quasi-standard for a variety of video modes from 320x240x8bits up to 1600x1200x32bits and beyond. "XGA" was an IBM proprietary standard that never became popular, and everything since has just been pure marketing buzzwords. ("It has QXGA instead of SXGA so it must be better...")
It's interesting that Apple, one of the most marketing-driven of computer vendors, still tells you the exact pixel resolution.
And don't get me started on the digital camera industry for deciding to multiply it out and tell you they've got "X megapixels"...
Dontcha wish they'd stop using those stupid XGA/SXGA/QXGA/whatever acronyms and just tell you how many damn *pixels* the thing does horizontally and vertically...
You point out an interesting "negative externality" problem - when someone decides to copy content without paying they are gaining a lot for themselves (a free copy with little chance of being caught), but losing a little for everybody (more ammunition for pro-DMCA arguments). Everyone is making the decision that benefits himself most, but when you add it all up it's going to be a huge net loss for everybody...
You actually bring up a serious point. One question that often gets overlooked in the DRM debate is, "who owns the keys?" Most DRM systems only allow major studios to encrypt their works; there is no "home edition" of the cypher algorithm for independent artists to protect their own projects. (or if the algorithm is public, there is no way to get the keys needed for encryption).
Thus the protection afforded by DRM is very asymmetrical, as opposed to copyright, which applies to all authors. (unless you crack the algorithm and distribute ReCSS...)
Thanks for the info. Of course there is very little chance Morrison would actually get in trouble for collecting old film, but it's still no less an infringement than, say, distributing MP3s made from a newly-discovered tape of some music group you've never heard of. And here he's charging money for it!
:)...
(I dislike strong copyright as much as anyone else, I just think so much of the conduct the RIAA/MPAA/FCC are pounding on is just as harmless as gathering these old film clips...)
I'm sure if movie studios had thought of selling rights to post-decay film prints, they would all have gone to the highest bidder already
The copyright extensions were retroactive - that's why "Steamboat Willie" still hasn't become public domain... Only films released before 1923 are public domain; there aren't too many of those left...
I was shocked that the New York Times Mangzine article about this film neglected to mention any of the copyright issues. Very few (no?) motion pictures have yet entered the public domain. Therefore, Mr. Morrison is likely in blatant violation of the copyrights on various pieces of his film.
I find it offensive how casual industry "insiders" tend to be about copyright violations, while they simultaneously condemn audience members for time- or space-shifting their own works.
Hopefully reality will catch up to them soon enough - the only available subject for the next "Decasia" will be the white noise of encrypted video streams, their keys long lost in obsolete trusted playback hardware...
I had to completely restore Windows installations for one family member and one friend who both got hit by Klez...
Wow, this is very scary - Linux with a professionally-designed interface on top :)... (although XFree is still betrayed by the horrendous-looking fonts in the menu bar of their Task Manager...)
I hope they also take care to double-buffer most of the UI graphics like Windows - it's not good enough if the screenshots match, the interactiveness has to match also...
I can give a good recommendation for FLTK. It is a solid, mature toolkit, and yet remains simple to understand and use. FLTK widgets are written in native 2D code (X11/GDI/etc) for speed, but it is very easy to add OpenGL where necessary. FLTK is good for graphics apps because it understands the special needs of programs where a GUI update is not computationally cheap. (unlike other toolkits, it gives you very detailed control over the event loop if you want it...)
Although FLTK's default widget appearance looks dated, it resembles the SGI inteface that people have come to associate with high-end graphics programs. (virtually no high-end graphics software uses the native widgets on any platform, perhaps because native widgets tend not to offer the kinds of things you need - like good color pickers, configurable slider bars, etc)
Just about the only drawback to FLTK is that the API is C++-only, and it's tied strongly into a C++ "one owner" memory management model, which makes it difficult to use from any other language. (however FLTK is simple and well-designed C++, not like the haphazard hodgepodge of classes and poor event systems in many lesser C++ APIs)...
Presumably NTFS is off by default because the code is a work in progress and writing to it may corrupt your filesystem. Also NVIDIA doesn't allow redistribution of its binary drivers. The other points are reasonable...
I dunno about Junkyard wars... The more I watch it the more I think the hosts/interviewers are just patronizing the contestants. ("What a bunch of pencilheads! Let's all get together and give them swirlies after the show!")
I like your point about "shared bandwidth." So many ISPs are capping up/down speeds that theoretical maximum bandwidth is meaningless. You should only be concerned with how much of that bandwidth the cap gives you.
:).
e.g. my cable modem is capable of uploading at over 100KB/sec, which it used to do years ago. Now the upload speed is capped to 30KB/sec. I'd be happier with a connection that maxes out at 50KB/sec, half the cable modem, if only I were allowed to use all of it
When they say Firewire I/O they don't necessarily mean that it won't be encrypted. Yes there is equipment that sends MPEG-2 over Firewire without encryption (some HDTV cable boxes can be modified to do this), but there is also a CSS-like encryption standard for Firewire.
Also there is the possibility that the FCC will mandate a "broadcast flag" (a bit that says "no copying") in the Firewire stream; any hardware or software that doesn't respect that flag would be outlawed in the US. (much like Macrovision-free VHS and DVD players...)
As an interesting side note, the TV Firewire standard is just plain old MPEG-2, which means that once Firewire PVRs are available, they would also be able to record video straight off a DVD without any loss of image quality. (assuming you had a DVD player with Firewire output, which I expect will start to appear soon)...
You are right, there is a distinct lack of recordable consumer-level HDTV interconnects right now. You've got analog component, but nobody seems interested in recording it (plus the MPAA et al probably want it to go away ASAP since it's not encrypted).
The two digital standards are FireWire (IEC 61883-4) and DVI. In the next few years I expect most HDTV tuners and TVs will sprout at least one of these, and analog component will fade away. I have a JVC D-VHS deck with FireWire I/O, and I've successfully captured and played back 1080i ATSC video using a custom Linux utility. This proves it is possible to construct a HDTV PVR...
The big sticking point of course is the copy-prevention business. Currently ATSC broadcasts are not encrypted, and some HDTV tuners can be modified to output the unencrypted signal via FireWire. However, it is likely that all transmission of HDTV video over FireWire will be encrypted in the near future (or there will be a "don't copy" bit embedded in the video, backed by DMCA enforcement). DVI has been scrambled from its beginning as an HDTV transport format. (AFAIK DVI sends uncompressed video, so it's not clear you'd be able to record it even without any encryption)
I've heard rumors that the encryption developers have not learned their lesson and are still using cryptographically weak algorithms. So we might very well a DeCSS-like utility for decrypting HDTV FireWire streams.
Another reason could be that syscall overhead is much lower in Linux (since you are calling glibc which calls the kernel directly, whereas on Win32 you are calling user32.dll which calls ntdll.dll which calls the kernel; and the kernel entry/exit code on Linux is much more optimized). Also process and thread context switches are several times faster than on Windows. And finally, Linux until recently gave much longer timeslices to CPU-bound processes (which can be a bad thing on the desktop :).
I am running a functional render farm of 4 Linux machines with LWSN 5.5 and 7.5. I don't use many plugins but the ones I have work OK.
:)
Sometimes it runs faster than Windows. (I think it could be that the Linux malloc and VM implementations are better, or the Win32 console subsystem is just really slow).
The hard parts were finding a stable version of Wine and getting suitable X and filesystem environments set up. I'll let you figure those out
I do wish Newtek would just release the Linux build of lwsn. My guess is they are terrified of the support issues.
Incidentally, the Layout and Modeler GUIs are pretty close to usable in Wine, except for some annoying mouse/keyboard input bugs.
You do have a good point. For most people, probably the safest economical way to back up text documents is by printing them on high quality paper, and storing multiple copies in different locations. If the need arises to retrieve any data, scan the paper and use OCR software to convert it into whatever format is currently popular.
For archiving images, printing on high-quality paper with a good printer would work, although not so cheaply.
Sound and video are even more difficult, because you're pretty much confined to some sort of magnetic or optical format, which may not be readable on any machine in the future. (good old optical film with an optical soundtrack might work, at horrific expense...)
I think the group you are talking about was more advocating Lightwave and other off-the-shelf software (vs the traditional heavily customized Alias/Softimage/RenderMan pipeline), rather than NT (vs UNIX). By the time they formed Station X, they were producing results just about as good as the traditional pipeline, but much more quickly and cheaply. (although I attribute this just as much to their artistic talents as choice of software). Station X failed for stupid legal reasons; I was told they were actually quite profitable.
(disclaimer: I worked as an intern at SXS one summer - it was one of the most exciting jobs I've had!)
LWSN.EXE runs quite well under Wine, you know ;-)