I knew that the US federal government had odd relationships with its technology contractors, but I didn't know that an entire program exists apparently to force the taxpayer to subsidize technology that it should therefore own---but it turns into a private tech monopoly, which (as with the company in the article) makes its money mostly from selling the resultant patented technology back to... the US Federal Government, which pays for it with... more taxpayer money.
I don't know enough about the situation either. But now investigators can subpoena the documents whose numbers were given in the email. The purpose in detaching the DTN's from the loans they referred to, would be to prevent finding those documents even though they could (according to the email exchange) not be entirely deleted. They say in the email that the document will now only show up if you search for it by DTN, not by the loan.
Another question: Can it be empirically determined (i.e. with a real decision procedure) that a video file was at some point encoded in something H.264? Would it be possible to remove such a "watermark" from a video mechanically?
Can anyone answer this: what is the legal theory behind this "downstream liability" where someone who creates a video, transcodes it to something other than H.264, and then releases the video under a creative commons BY-SA license, and then someone else comes along and becomes liable for patent royalties because of a previous person in the remix chain having used H.264?
After parsing this lawyer's output, I'm never using H.264 again if I can avoid it, despite the criticisms of WebM (no real spec, dog-slow encoding.) More importantly I would like to see how much of my existing video work can be done without any use of 264---in particular I will be checking my hardware devices to see if I'm entrapped at the outset.
Emphasis seems odd here. Keybindings are just about the most trivially (and commonly) customized part of Emacs, and things like CUA-mode and customized Mac builds of Emacs are common ways of dealing with the issue. Whereas the major benefit of Emacs for Lisp development---having your development environment written in Lisp, by Lispers, who have collectively spent 30 years or so improving its Lisp editing/development capabilities both in included and in third-party elisp libraries---is not mentioned.
I think the poster implicitly points out something interesting---that Java and Common Lisp are both large languages that require sophisticated tools to use effectively. I'm not talking about Emacs versus Eclipse here, I mean the toolset in your brain. Money quote:
"IntelliJ makes Java programming as easy as it can possibly be. It more or less compiles your code as you type it, points out most bugs as they occur, intelligently suggests code completion to finish your words for you. I generates all the annoying repetitive code, like getters and setters and equals() methods for you. Without it, Java would be much more laborious to program in..."
So to Java users, writing annoying repetitive code is a life-saving feature of the IDE, whereas for Common Lisp it would simply be bad style.
Hi, I made this video. I don't show it in the video but this is a Touchsmart TM2. The screen flips up and swivels 180 degrees to reveal a conventional laptop form factor with keyboard, so I mainly use emacs that way. However, gestures are still available above the keyboard when the screen is in that mode, and also emacs code reviews that i talk about could be interesting... I have a lot of other stuff planned, see http://lispgamesdev.blogspot.com/ for more.
Hello folks, I've updated the compo site and wiki page to reflect that the contest is indeed open to any dialect of Lisp. Best of wishes to all participants!
I am the author of the Xiomacs page. The project is indeed abandoned, however I never really throw away code, and some of the ideas have turned up in another project. I will keep you posted.