If you are worried about tampering, just use a secure hash. e.g. create a web site or phone number people can call to verify md5sums of important documents.
If you really want to prevent copying (as in copyright infringement), then you'll have to wait for Palladium. ("Ctrl-C" - "I'm sorry Dave, I can't let you do that...")
I see... Honestly if that's what you are trying to do (make a portable / descrambled copy of a DVD), I'd switch to DVD-R. The burners and disks are pretty cheap now. And you can just use MPEG-2, which is a solid, widely-supported standard.
One of the things I liked about 4dwm was the ability to "iconize" a window (minimize it to a little icon you could drag around). I found this preferable to today's taskbars, because you could organize/group the icons.
I have been looking for an open source window manager with this feature, but so far have not found any.
DiVX is just fucked for having so many incompatible versions. I used to think they were the future of online video, now I use Sorenson. At least with Quicktime, as long as someone has version 5, you KNOW they will be able to play your video.
This is a bad idea because it breaks the package database. Next time dpkg wants to upgrade Perl, it will overwrite your link.
Just say no to messing with/usr on a Debian system. Wait until the Perl features you need are available from Debian, or make your own deb. (it's not hard - many free software packages already come with the debian/ files)
Many posters have commented that the pricing is rather absurd, the DRM restrictions are very confining, and hardly any big-name/popular movies are going to be released this way. I have a feeling this offering might be designed to fail - after it bombs, the MPAA can say "look, we tried to offer movies online, but nobody bought them, everyone just pirates movies, etc... So we need mandatory DRM a la SSSCA or CBDTPA!"
If my theory is correct, I predict that whatever encryption they are using will be easy to crack. This would make the MPAA's argument for mandatory DRM even stronger. ("See? They hacked it! Waaaah we need Palladium!")
What's sad is that very little actual code is released by the US government itself. Although a lot of programming/media creation goes on in government bureaus like NASA, the Defense Department, etc, little or no code is released because of security/ITAR issues.
The less-sensitive material is mostly produced by contractors, who are free to do anything with it that fits their contract - including copyright or patent it. (incidentally, the US government is allowed to infringe on any US patent. I'm not sure if there is a similar immunity for copyright)
e.g. I created a 7-minute CG video for NASA illustrating the upcoming Mars Rover missions in 2003. To my knowledge 100% of the funding originally came from US taxpayers - but the video is copyrighted by Cornell University (the contractor in this case) and there are pretty strict controls on its use and distribution. It is anything but public domain.
The only places I remember seeing a specific disclaimer of copyright are on NASA's photo archives. e.g. Hubble Space Telescope photos are explicitly put in the public domain.
There are tons of really great photos on www.af.mil. I haven't seen any notice of whether they are copyrighted or not. (which is a dangerous situation, since copyright is *automatically* granted even if there is no (C) on the material)
My guess is, the XML format will make it much easier to manipulate Office documents from scripts, but it will still be very difficult to construct an actual WYSIWYG editor for them.
e.g. Say that there is a tag with extremely complex, undocumented, formatting and display rules. It might be easy to add or remove things from tags, but only Office would actually know how to *display* a table correctly.
This would allow MS to say "we have an open file format" without really endangering their core business, GUI document editing tools.
I may be mistaken but I think there is an information theory problem here. How can you add X bits of new information to a Y-bit image without loss (or enlarging the image)?
Obviously a human viewer isn't going to notice if you just tweak the least significant bits of each pixel, but the article seems to claim that the technique is completely lossless.
Some people have said "why not just use a separate digital signature?" I think the advantage of this technique is that you could save the image in any lossless format (e.g. BMP or TIFF) and still retain the watermark.
One aspect of poorly-written code (volumes of which I produce myself) is that it does not extract as much redundancy from the problem as it could. e.g. big if() or switch() statements instead of a table of results or function pointers. I find that the best program is almost always the shortest. (within reason; removing all the newlines doesn't count =)
Non-orthogonal, inconsistent APIs are another big source of trouble. (stdio comes to mind... quick, which of the arguments to fread() is the FILE* pointer? What's the difference between fputs(foo, stdout) and puts(foo)?)
I also have Array<T> (vector), Map<T>, etc. These work almost exactly like STL containers, except most of the code is out of line so compiles are MUCH faster and binaries are MUCH smaller.
My containers have the added advantage that you can embed ListElements in a structure or class to avoid allocating extra memory when inserting into a list or hashtable.
Are you using STL? You may want to try STLport, or even write your own template containers.
On my project I switched from the GNU STL to STLport, and compile time went down by half. Then I wrote my own containers and compilation speed went down by a factor of FIVE!
(my containers are templates to be typesafe like STL, but I have very carefully moved most of the code out-of-line instead of stuffing it all in the headers)
C++ templates are a real double-edged sword. They give the compiler tons of room for optimization, but they do it by presenting it with basically ALL your code at once.
Thanks for the example. Yes, it looks like templates can be used to implement accessors in C++ easily...
However I don't think you fully understand my "IMPLIES" concept. It declares a relationship between two things. The runtime should be smart enough to decide what action to take when one thing changes.
I want to write:
class Foo {
Toolbar m_toolbar;
bool m_toolbar_visible;
m_toolbar_visible IMPLIES "m_toolbar is visible" };
I want the same results as if I had written:
class Foo {
Toolbar m_toolbar;
bool m_toolbar_visible;
I much prefer the first code example, since it simply states the relationship between the boolean and the visibility of the toolbar. The second code example, which is what we are all accustomed to writing, is less direct and more verbose and error-prone.
Hmm, perhaps this could also be accomplished with template magic =)....
Oh yes, I see your point. Accessor methods can definitely improve the syntax of MVC systems.
I really wish I could just make a statement like: "mToolbarVisible IMPLIES toolbar_window.visible" and then the language runtime would figure out that writes to mToolbarVisible should cause the toolbar to show or hide itself.
Inklings of this idea are present in GTK's widget classes - you can declaratively specify position/size constraints for each widget (e.g. "this widget must be aligned to the right side of the window and half as tall as the enclosing window"). GTK takes care of handling resize events automatically. You don't need to write any "onResize" handlers; the widgets automatically configure themselves to satisfy your constraints.
There is also the issue of interfacing with libraries that weren't written with GUIs in mind. The Toolbar example implies that whatever object contains mToolbarVisible also must contain a list of views that want to be notified of toolbar events. It may be difficult to set this up if the Toolbar container is implemented in a library that you can't control (or don't even have the source to!).
A clean API between the graphical front-end and the back-end is a good start, but there are some deeper issues that need to be dealt with. A database or web application is fairly easy because the data flow is only one-way - the GUI either commands the database to give it some information, or sends new information to be entered.
However many kinds of programs need back-and-forth behavior - e.g. say you're editing a spreadsheet that is embedded in a word-processing document, and you've got two views open - one on the spreadsheet alone, and another showing a "print preview" of the whole document. You change an entry in the spreadsheet. Now what? The application must figure out that it needs to pull the updated spreadsheet into the other window.
Notice the key difference here - the back-end code , meaning the internal data structures where the spreadsheet is stored, MUST be made aware of changes so that it can inform the various front ends. I suppose you could wrap the entire back-end in a single MVC setup, but what if the back-end is the only code that knows the scope of the change? You don't want every view to be completely thrown out and refreshed for every trivial change to the spreadsheet.
The only working solution I have found is to add interactivity features to the back-end. (e.g. each spreadsheet cell needs to contain a list of views to notify after a change). This is less than ideal because it pollutes the back-end code with MVC notifiers and dependency information - things that the interface needs, but are totally unrelated to the actual functionality of the back-end code. The MVC stuff just gets in the way of implementing a nice clean spreadsheet library.
I have a feeling that a better solution would be an advanced language runtime that automatically tracks the data/interface dependencies for you. Are there any out there?
My experience definitely agrees... I've found that constructing an interactive (not necessarily graphical) interface to non-interactive code takes 2-10 times longer than writing the non-interactive code itself.
I attribute this to the huge difference between batch processing and running an event loop. Programming languages are very well suited to "do this, then do that" style batch programs. But it is much more difficult to handle interactivity ("on click, do this, on keypress, do that") since you have to keep track of dependencies between internal data structures and the external interface.
e.g. say you have a rule that when MyApp::toolbar_visible == true then the toolbar must be shown. But most programming languages don't allow this kind of declarative specification. Instead, you have to track down every line of code that modifies MyApp::toolbar_visible, and tack on extra code to hide/show the toolbar depending on its new value... Or, if you have a slider control that is supposed to reflect the value of some variable. You again have to track down every point where that variable can be modified, and insert code to update the scrollbar.
MVC helps here, but it's still annyoing - instead of the simple "MyApp::toolbar_visible = true;" you end up writing something like "MyApp::toolbar_visible = true; MyApp::notify_toolbar_change();" Ideally you should only need the "= true" part, and the language runtime should figure out that the toolbar needs to be shown.
I've seen some attempts to use declarative specifications for interface elements, like NeXT's interface builder and TCL's "watched" variables. But none of these are really mainstream. (I don't have much Visual Basic experience - is that declarative?)
Theoretically the price for a SACD could be less than a CD, since it is more difficult to pirate a SACD, so fewer sales will be lost. I doubt this will actually happen though =).
What I'd really like to know is, what would be the best API for porting a large existing program to Mac OSX?
Say I have a medium-to-large C or C++ program. Currently it has a Windows GUI (using MFC or straight Win32) and an X GUI (using Gtk or Qt). Now I want to port it to OSX, taking as much advantage of existing code as possible. What API do I use?
(e.g. I am excited about all the possibilities of Cocoa, but is it really that easy if the core program is NOT OSX-only?)
It's a terrible shame the laws are like that... Given the low price of storage these days, it wouldn't be too hard for the Library of Congress to escrow digital versions of all registered copyrighted works. When each copyright expires the work could be made available to anyone via the internet.
I really hope Lessig succeeds in the Supreme Court and Boucher succeeds in Congress. If not, most of our cultural works from the 20th century onward will be unrecoverable by future historians. The last copies of out-of-print books will have crumbled to dust, along with the last celluloid prints of our films, leaving only scrambled encrypted disks and DVDs, the hardware for reading which will be long gone.
Slashdot Mirror
I know it's DoD SOP to coin TLAs for everything, but FOSS is just lame. Reminds me of dental FOSS.
Guess they couldn't use OSS, cause that's another government agency, right? What about DFSG...
If you are worried about tampering, just use a secure hash. e.g. create a web site or phone number people can call to verify md5sums of important documents.
If you really want to prevent copying (as in copyright infringement), then you'll have to wait for Palladium. ("Ctrl-C" - "I'm sorry Dave, I can't let you do that...")
I see... Honestly if that's what you are trying to do (make a portable / descrambled copy of a DVD), I'd switch to DVD-R. The burners and disks are pretty cheap now. And you can just use MPEG-2, which is a solid, widely-supported standard.
Thanks, I forgot about fvwm! I ignored it earlier because there were no themes that I liked, but I see things have improved a lot.
Right now I'm using icewm - it's easy to configure and there is an excellent 4Dwm theme available for it - that's all I really ask =).
One of the things I liked about 4dwm was the ability to "iconize" a window (minimize it to a little icon you could drag around). I found this preferable to today's taskbars, because you could organize/group the icons.
I have been looking for an open source window manager with this feature, but so far have not found any.
DiVX is just fucked for having so many incompatible versions. I used to think they were the future of online video, now I use Sorenson. At least with Quicktime, as long as someone has version 5, you KNOW they will be able to play your video.
This is a bad idea because it breaks the package database. Next time dpkg wants to upgrade Perl, it will overwrite your link.
/usr on a Debian system. Wait until the Perl features you need are available from Debian, or make your own deb. (it's not hard - many free software packages already come with the debian/ files)
Just say no to messing with
If my theory is correct, I predict that whatever encryption they are using will be easy to crack. This would make the MPAA's argument for mandatory DRM even stronger. ("See? They hacked it! Waaaah we need Palladium!")
What's sad is that very little actual code is released by the US government itself. Although a lot of programming/media creation goes on in government bureaus like NASA, the Defense Department, etc, little or no code is released because of security/ITAR issues.
The less-sensitive material is mostly produced by contractors, who are free to do anything with it that fits their contract - including copyright or patent it. (incidentally, the US government is allowed to infringe on any US patent. I'm not sure if there is a similar immunity for copyright)
e.g. I created a 7-minute CG video for NASA illustrating the upcoming Mars Rover missions in 2003. To my knowledge 100% of the funding originally came from US taxpayers - but the video is copyrighted by Cornell University (the contractor in this case) and there are pretty strict controls on its use and distribution. It is anything but public domain.
The only places I remember seeing a specific disclaimer of copyright are on NASA's photo archives. e.g. Hubble Space Telescope photos are explicitly put in the public domain.
There are tons of really great photos on www.af.mil. I haven't seen any notice of whether they are copyrighted or not. (which is a dangerous situation, since copyright is *automatically* granted even if there is no (C) on the material)
My guess is, the XML format will make it much easier to manipulate Office documents from scripts, but it will still be very difficult to construct an actual WYSIWYG editor for them.
e.g. Say that there is a tag with extremely complex, undocumented, formatting and display rules. It might be easy to add or remove things from tags, but only Office would actually know how to *display* a table correctly.
This would allow MS to say "we have an open file format" without really endangering their core business, GUI document editing tools.
I see. You could take advantage of redundancy in the source image. Thanks...
I may be mistaken but I think there is an information theory problem here. How can you add X bits of new information to a Y-bit image without loss (or enlarging the image)?
Obviously a human viewer isn't going to notice if you just tweak the least significant bits of each pixel, but the article seems to claim that the technique is completely lossless.
Some people have said "why not just use a separate digital signature?" I think the advantage of this technique is that you could save the image in any lossless format (e.g. BMP or TIFF) and still retain the watermark.
Could the payload problems be solved by resurrecting the Saturn V, or building another large rocket?
One aspect of poorly-written code (volumes of which I produce myself) is that it does not extract as much redundancy from the problem as it could. e.g. big if() or switch() statements instead of a table of results or function pointers. I find that the best program is almost always the shortest. (within reason; removing all the newlines doesn't count =)
Non-orthogonal, inconsistent APIs are another big source of trouble. (stdio comes to mind... quick, which of the arguments to fread() is the FILE* pointer? What's the difference between fputs(foo, stdout) and puts(foo)?)
Maybe Adobe would prefer that authors buy Acrobat and use it to publish documents rather than LaTeX... =)
I thought URLs were supposed to be permanently stable! Shutting down a TLD does not exactly help this out...
I admit I've broken a couple minor links on my own sites, but I do try very very hard to keep old URLs working...
No. The containers consist of an unsafe "core" part that works with void* pointers, wrapped in a typesafe template.
// note: append() is implemented out-of-line
The idea is roughly like this:
struct CoreListElement {
struct CoreListElement *next;
};
class CoreList {
void append(struct CoreListElement *elemnt);
};
template < typename T >
class List {
struct ListElement : public CoreListElement {
T value;
};
CoreList core;
void append(const T& t) {
core.append((CoreListElement*) new ListElement(t));
}
};
I also have Array<T> (vector), Map<T>, etc. These work almost exactly like STL containers, except most of the code is out of line so compiles are MUCH faster and binaries are MUCH smaller.
My containers have the added advantage that you can embed ListElements in a structure or class to avoid allocating extra memory when inserting into a list or hashtable.
Are you using STL? You may want to try STLport, or even write your own template containers.
On my project I switched from the GNU STL to STLport, and compile time went down by half. Then I wrote my own containers and compilation speed went down by a factor of FIVE!
(my containers are templates to be typesafe like STL, but I have very carefully moved most of the code out-of-line instead of stuffing it all in the headers)
C++ templates are a real double-edged sword. They give the compiler tons of room for optimization, but they do it by presenting it with basically ALL your code at once.
Thanks for the example. Yes, it looks like templates can be used to implement accessors in C++ easily...
However I don't think you fully understand my "IMPLIES" concept. It declares a relationship between two things. The runtime should be smart enough to decide what action to take when one thing changes.
I want to write:
class Foo {
Toolbar m_toolbar;
bool m_toolbar_visible;
m_toolbar_visible IMPLIES "m_toolbar is visible"
};
I want the same results as if I had written:
class Foo {
Toolbar m_toolbar;
bool m_toolbar_visible;
void set_toolbar_visible(bool new_value) {
if(new_value == true)
m_toolbar.show();
else
m_toolbar.hide();
m_toolbar_visible = new_value;
}
};
I much prefer the first code example, since it simply states the relationship between the boolean and the visibility of the toolbar. The second code example, which is what we are all accustomed to writing, is less direct and more verbose and error-prone.
Hmm, perhaps this could also be accomplished with template magic =)....
Oh yes, I see your point. Accessor methods can definitely improve the syntax of MVC systems.
I really wish I could just make a statement like:
"mToolbarVisible IMPLIES toolbar_window.visible"
and then the language runtime would figure out that writes to mToolbarVisible should cause the toolbar to show or hide itself.
Inklings of this idea are present in GTK's widget classes - you can declaratively specify position/size constraints for each widget (e.g. "this widget must be aligned to the right side of the window and half as tall as the enclosing window"). GTK takes care of handling resize events automatically. You don't need to write any "onResize" handlers; the widgets automatically configure themselves to satisfy your constraints.
There is also the issue of interfacing with libraries that weren't written with GUIs in mind. The Toolbar example implies that whatever object contains mToolbarVisible also must contain a list of views that want to be notified of toolbar events. It may be difficult to set this up if the Toolbar container is implemented in a library that you can't control (or don't even have the source to!).
A clean API between the graphical front-end and the back-end is a good start, but there are some deeper issues that need to be dealt with. A database or web application is fairly easy because the data flow is only one-way - the GUI either commands the database to give it some information, or sends new information to be entered.
However many kinds of programs need back-and-forth behavior - e.g. say you're editing a spreadsheet that is embedded in a word-processing document, and you've got two views open - one on the spreadsheet alone, and another showing a "print preview" of the whole document. You change an entry in the spreadsheet. Now what? The application must figure out that it needs to pull the updated spreadsheet into the other window.
Notice the key difference here - the back-end code , meaning the internal data structures where the spreadsheet is stored, MUST be made aware of changes so that it can inform the various front ends. I suppose you could wrap the entire back-end in a single MVC setup, but what if the back-end is the only code that knows the scope of the change? You don't want every view to be completely thrown out and refreshed for every trivial change to the spreadsheet.
The only working solution I have found is to add interactivity features to the back-end. (e.g. each spreadsheet cell needs to contain a list of views to notify after a change). This is less than ideal because it pollutes the back-end code with MVC notifiers and dependency information - things that the interface needs, but are totally unrelated to the actual functionality of the back-end code. The MVC stuff just gets in the way of implementing a nice clean spreadsheet library.
I have a feeling that a better solution would be an advanced language runtime that automatically tracks the data/interface dependencies for you. Are there any out there?
My experience definitely agrees... I've found that constructing an interactive (not necessarily graphical) interface to non-interactive code takes 2-10 times longer than writing the non-interactive code itself.
I attribute this to the huge difference between batch processing and running an event loop. Programming languages are very well suited to "do this, then do that" style batch programs. But it is much more difficult to handle interactivity ("on click, do this, on keypress, do that") since you have to keep track of dependencies between internal data structures and the external interface.
e.g. say you have a rule that when MyApp::toolbar_visible == true then the toolbar must be shown. But most programming languages don't allow this kind of declarative specification. Instead, you have to track down every line of code that modifies MyApp::toolbar_visible, and tack on extra code to hide/show the toolbar depending on its new value... Or, if you have a slider control that is supposed to reflect the value of some variable. You again have to track down every point where that variable can be modified, and insert code to update the scrollbar.
MVC helps here, but it's still annyoing - instead of the simple "MyApp::toolbar_visible = true;" you end up writing something like "MyApp::toolbar_visible = true; MyApp::notify_toolbar_change();" Ideally you should only need the "= true" part, and the language runtime should figure out that the toolbar needs to be shown.
I've seen some attempts to use declarative specifications for interface elements, like NeXT's interface builder and TCL's "watched" variables. But none of these are really mainstream. (I don't have much Visual Basic experience - is that declarative?)
Theoretically the price for a SACD could be less than a CD, since it is more difficult to pirate a SACD, so fewer sales will be lost. I doubt this will actually happen though =).
What I'd really like to know is, what would be the best API for porting a large existing program to Mac OSX?
Say I have a medium-to-large C or C++ program. Currently it has a Windows GUI (using MFC or straight Win32) and an X GUI (using Gtk or Qt). Now I want to port it to OSX, taking as much advantage of existing code as possible. What API do I use?
(e.g. I am excited about all the possibilities of Cocoa, but is it really that easy if the core program is NOT OSX-only?)
It's a terrible shame the laws are like that... Given the low price of storage these days, it wouldn't be too hard for the Library of Congress to escrow digital versions of all registered copyrighted works. When each copyright expires the work could be made available to anyone via the internet.
I really hope Lessig succeeds in the Supreme Court and Boucher succeeds in Congress. If not, most of our cultural works from the 20th century onward will be unrecoverable by future historians. The last copies of out-of-print books will have crumbled to dust, along with the last celluloid prints of our films, leaving only scrambled encrypted disks and DVDs, the hardware for reading which will be long gone.