![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/letters.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Letters All in one big page See also: last week's Letters page. |
Letters to the editorLetters to the editor should be sent to letters@lwn.net. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them. |
April 4, 2002 |
From: Oliver Neukum <oliver@neukum.org> To: letters@lwn.net Subject: close() and the kernel Date: Thu, 28 Mar 2002 12:45:38 +0100 Hi, the subject is not as clear cut as you indicate. close() does not directly map to release(). close() maps to flush(), which does return error values just fine. release() is really just internal kernel operation which tells a filesystem/driver that an object is no longer in use. While it is bad in principle to discard error messages, the errors from release() cannot be reliably delivered to the right process. Suppose that you flush buffers on release() and get an error. You'd report that error to the last process happening to close the device, not necessarily the process which wrote the data. The device in question happened to be a device that can only be exclusively opened by one process. In encouraging such practices in the kernel we get device drivers which fail to work in a multithreaded enviroment. This is the reason Alan Cox introduced flush() in late 2.1.x in the first place. Regards Oliver | ||
From: Tom Wu <tom@arcot.com> To: letters@lwn.net Subject: iSCSI and SRP Date: Mon, 01 Apr 2002 18:12:07 -0800 In the March 28th article entitled "iSCSI and patented technologies", LWN made a few points that require clarification. The article discussed the IETF IP Storage working group's efforts to standardize a password authentication mechanism. SRP was chosen because it belongs to a class of cryptographic technologies known as "strong password protocols", which protect even easily-guessed passwords from password-guessing attacks carried out over the network. As the inventor of SRP and the author of RFC 2945, one of the reasons I decided to make the technology royalty-free was the growing importance of OSS/Free Software. Without an unencumbered royalty-free strong password technology, OSS implementations would at a disadvantage compared to commercial implementors, who could afford to license such technology if it were incorporated into any standards. Strong password technology is too important to be left exclusively in commercial hands. LWN's article says that SRP "appears to be covered" by three separate patents, which is not entirely correct. Stanford has a pending patent on the technology, which is licensed on a royalty-free basis as described in the article. The other patents, held by competitors in the space, need to be examined a bit more closely. Lucent has not actually asserted any claim that any of their patents are relevant; although one might hope for an explicit disclaimer, it might be more realistic to assume that no statement will be made one way or another, and act accordingly. Phoenix claims that its patent "may" apply to SRP, but as with any claim, it is up to the individual to examine the patent and the circumstances surrounding it in order to determine exactly how valid and supportable the claim is. For anyone interested in using (or just learning about) strong password technology, regardless of whether their implementation is commercial, OSS, GPL, etc., the SRP distribution is available from: http://srp.stanford.edu/ The distribution is available under a BSD-style Open Source license. -- Tom Wu Principal Software Engineer Arcot Systems | ||
From: jimd@starshine.org (Jim Dennis) To: letters@lwn.net Subject: "The Way Out" Date: Mon, 1 Apr 2002 12:38:39 -0800 (PST) Hi, Regarding the amusing Unisys/Microsoft joint venture in to marketing stupidity I have this response: (Posted as "comments" to an otherwise vacuous "registration" form on their site). Jim Jones had "the way out." The Heaven's Gate cult offered "the way out." I see that someone in your marketing department drank the Kool-Aid(TM) and managed to blow away tens of millions of dollars to declare that Microsoft and Unisys can offer sysadmins a roughly similar "way out." At least this isn't another "Astroturf(TM)" campaign, or another case of Mindcraft "bench-marketing." Ahh! The acrid smell of FUD on a Monday morn. Welcome to IT in the new millennium. | ||
From: Duncan Simpson <dps@io.stargate.co.uk> To: letters@lwn.net Subject: Programming and security... Date: Thu, 28 Mar 2002 23:48:54 +0000 Cc: "jacob navia" <jacob.navia@wanadoo.fr> Jacob Navia suggests the right fix would be making calling free with the same memory twice safe. Indeed there are some implementations of malloc(3) that have this property and one of them might be used by MS windows (subject to unknown dependencies on the exact versions of an unknown set of dlls). Calling free with the same memory twice, or memory not obtained via malloc, is a BUG. If your application dumps core as a result, or causes a herd of flying pigs to emerge from your nose, that this within the documented behaviour. There are other goals in software design in addition to robustness in the face of bugs elsewhere, including scalability and performance. Every test for voilation of the assumptions a function makes, for example that a pointer is not NULL, wastes cycles protecting many applications against bugs which do not exist. Some "facts" are very expensive to test. Often when such tests are implemented they are not included in production binaries for performance and code size reasons. The malloc implementation in glibc 2.x, which dies when free is abused, is designed to be fast and scalable. Very few implementations of malloc which tolerate double free could claim to be scalable, and some are relatively slow. Also note that 99% of the code uses shared zlib and a single update fixes all of that 99%. P.S. Security standards have significnatly improved. Most programs how include very few buffer overrun bugs, which were endemic in older programs. M$ software is a dishonourable exception :-( -- Duncan (-: "software industry, the: unique industry where selling substandard goods is legal and you can charge extra for fixing the problems." | ||
From: jimd@starshine.org (Jim Dennis) To: linux-kernel@vger.kernel.org Subject: Nominations: Date: Mon, 1 Apr 2002 13:22:28 -0800 (PST) Cc: letters@lwn.net, editors@linuxtoday.com Hi Linus, I must commend you on the timing of your decision to step down as "Benevolent Dictator(TM)." However I'm extremely disappointed by your nominations for your successor. I think the time for *benevolence* is over. If we are to usher in a new era of Linux kernel development we must consider a broader, darker range of candidates. I'd like to nominate Senator Hollings! He's the obvious choice since he clearly intends to usurp the role of Grand Software Source Code Dictator for *all* software and firmware (open or closed). Indeed, regardless of whether you select him and even if he declines the title I think that we should all immediately add him to our MUAs for automatic copies of all source code submissions, patches and related discussions (for his legislative approval, of course). (Of course we should also appoint a special "technical advisor" to assist the Respected Mr. Hollings, William Gates III should be considered; surely chairman Bill could see "the way out" of any conundrum offered by the development community). -- Sincerly, Jim Dennis, "The Linux Gazette Answer Jester" | ||
From: Thomas Hood <jdthood@mail.com> To: letters@lwn.net Subject: Re: The SSSCA under any other name Date: 02 Apr 2002 12:11:43 -0500 One way to make the SSSCA issue comprehensible to the general American public might be to draw an automotive analogy, as follows. "Passing the SSSCA is like putting a regulator on every car preventing it from breaking traffic regulartions. Pull up to a stop sign and it slams on the brakes. Pull onto the highway and the accelerator pedal blocks at 55 mph. The proponents argue: Only a criminal wouldn't want such a device built into his car! The regulator also controls the radio, making sure that you listen to commercials. The proponents say: Only a pirate would listen to the radio without listening to what the advertisers, who paid for the programming, have to say! The proponents say: This doesn't restrict your freedom at all---you can always choose not to drive your car on public highways!" Etc. | ||
From: David Neto <DNeto@altera.com> To: "'letters@lwn.net'" <letters@lwn.net> Subject: CBDTPA: definition of a digital media device Date: Thu, 28 Mar 2002 06:46:37 -0800 Regarding the CBDTPA and its definition of a digital media device. Digitial components don't distinguish between copyrighted works or any other set of bits. That's the beauty of the universality of digital machines. So am I to understand that an ethernet cable is a "digital media device"? How about a 128MB DIMM memory bank? How about just 1024 bits of SRAM? 1 SRAM bit? Sure, that's a debate about definitions. I'd expect that the government might be willing to let the courts interpret the law on this one. Whether the intent of the law is good or bad is an entirely different matter. For that fight you've got to do you politicking. Best of luck from a Canadian, David (These are my views, not my employer's....) | ||
From: Don Carter <don.carter@rogers.com> To: letters@lwn.net Subject: Consumer Broadband and Digital Television Promotion Act Date: Sun, 31 Mar 2002 22:09:40 -0500 Regarding the Consumer Broadband and Digital Television Promotion Act, you say: "So how can free software function in this legal environment? ... A source-available system, where users can remove the corporate big brother code at will, can never be "reliable" or "resistant to attack" in the eyes of CBDTPA supporters. If that interpretation holds, Linux systems become illegal whether or not they include the security code." A source-available system can implement the CBDTPA if and only if the CBDTPA is implemented purely in hardware. Removing the "corporate big brother code" (which would simply access the api exposed by the underlying hardware) would then merely make the protected content unavailable. This does not mean that computers need to be neutered completely (the 'don't turn my computer into a settop box' argument). Protected content can be handled specially by the hardware, while all other content is treated exactly as it is today. If Microsoft gets its way, protected content will be delivered through proprietary protocols implemented in Microsoft operating systems -- protocols that would be protected from reverse-engineering by the DMCA and protected from clean-room implementations by patent. As much as I dislike the MPAA and the RIAA, they do have a legitimate concern here. Likewise, consumers and Open/Free Source advocates have legitimate concerns (backups for personal use, being able to time- and space-shift content the user has legal rights to, making protected content available in an unprotected format once copyright has expired). We can work with them and find a solution that addresses everyone's concerns, or we can fight against them. But if we choose the latter, we strengthen Microsoft's hand. If content-providers decide to go with Microsoft's "digital rights management", then we will have successfully locked Linux out of any part of the network that transports protected content. Not only will Linux forever concede the desktop market, it will eventually lose the server market as well. Don | ||
From: tom poe <tompoe@renonevada.net> To: letters@lwn.net Subject: Commentary by Alex Salkever Date: Sun, 31 Mar 2002 15:05:25 -0800 Cc: "DMCA" <dmca_discuss@lists.microshaft.org> Hi: Your posting about Guard Copyrights, Don't Jail Innovation, by Alex Salkever highlights some interesting support for NOT passing the DBDTPA law: http://www.businessweek.com/bwdaily/dnflash/mar2002/nf20020327_2364.htm There is a growing school of thought that recognizes the significance of Lawrence Lessig's Creative Commons Project [see: http://cyber.law.harvard.edu/cc/ ] as providing a key ingredient to change within the Music Industry. Here's just a taste of what this marvelous project does for consumers. The Internet empowers all of us, as we have the ability to communicate instantly across the country, and around the world. This empowerment translates into marketing strategies and audience development for artists and musicians that heretofore had to rely on managers, producers, "in-between" agents to do that for them. The stumbling block with the Internet approach resides primarily in the legal profession. Licensing issues, and related issues to distribution, and control of one's works is missing. Without such guidance and assistance, many artists and musicians remain "trapped" in the present Music Industry's grip. The Creative Commons Project unleashes them, frees them to pursue alternative strategies that will, in fact, bring them the fame and fortune the Music Industry refuses. For starters, there is a push to broaden the base of Public Domain works available to the world community. A model for such a mission can be seen in its earliest formation here: http://www.studioforrecording.org/ the main site http://www.ibiblio.org/studioforrecording/ the Repository Page The community-based recording studios provide FREE recording services in return for the artist or musician to place their works in the Public Domain. Related services will assist these individuals and groups to develop and follow marketing strategies that will lead to successful careers, without reliance on the Music Industry. One of the premises for this model lies with recognizing that tours, concerts, and a blending of Public Domain and Copyrighted works is where the "money is". This gives hope to those managers, producers, agents, that they will still have a role to play, but the terms may be slightly different. <grin> I can't wait to see the day this all happens, and we are able to watch ASCAP and BMI "eat their 40 copyright-protected 'arrangements' of "Row, Row, Row Your Boat". Thanks, Tom | ||
From: Leon Brooks <leon@cyberknights.com.au> To: Linux Weekly News <letters@lwn.net> Subject: Disney hates baseball, film at 11? Date: Fri, 29 Mar 2002 13:14:23 +0800 Cc: Jerry <wa6cvl@sbcglobal.net> Jerry used the analogy of crime-proof cars to show the clumsy stupidity of the CBDTPA. Perhaps a more accurate analogy for Michael D Eisner's statements would lie in that all-American favourite, the sandlot baseball game (Aussies might relate better to backyard cricket matches). What Michael is in essence proposing in analogy is that because he wants to be able to sell admission to Disney's baseball grounds, the US government should legislate that all open spaces possibly useable as baseball grounds must have security fencing, sight screens, a ticket office and so on, or be illegal to own or use. The first analogical problem that would confront him in places like Australia (and some US states) is that there are so very *many* of these, and lots of them are crown land or reserves. But the real flies in the ointment would be sandlot baseball, public parks, and undeveloped land. Oh, yes, and what would happen when the lawyers finished with all of these? Anyone carrying a baseball glove across a vacant lot (or their own backyard) would be liable for prosecution. Actually getting together for a baseball game would be really asking to be jailed as criminals. Councils could be prosecuted for making potential baseball diamonds (in the form of parks and gardens) available without properly licenced baseball fittings. Right-Of-Way laws and baseball control laws would clash. The ultimate irony would be watching the Disney corporate Christmas party being rounded up and herded into paddy-wagons after some of the staff carelessly broke out bats and balls. Carrying the analogy back to real life, Disney's overt goal is control over the viewing of their own media. In order to gain this control, they are apparently willing to enforce control over every medium, and every viewing device, regardless of purpose, location, ownership, cost or anything else. The kindest thing that could be said about that is `it is very irresponsible'. It does not appear to have dawned on Disney that many viewing devices exist through which Disney footage has never passed and will never pass. Their proposal would make these devices every bit as illegal as the ones deliberately and carefully used by pirates to clone (for sale) copyrighted, commercial DVDs by the thousands. Cheers; Leon | ||
From: "Charles Hethcoat" <Charles Hethcoat <clhiii@attglobal.net>>
To: letters@lwn.net
Subject:
Date: Thu, 28 Mar 2002 21:15:27 -0600
Dear Editor:
Of all the self-serving balderdash floating about in Congress and
Hollywood, Michael Eisner's article in The Financial Times is just
about the worst I've seen. Thanks for alerting us to it.
Eisner shamelessly quotes Abraham Lincoln's words while using them to
repress the very rights that Lincoln was talking about:
"...The patent system changed this; secured to the inventor, FOR
A LIMITED TIME, the exclusive use of his invention; ..."
The key phrase in this quotation, completely ignored by Mr. Eisner,
was "for a limited time." This is the important fact about patents
and copyrights that is being destroyed by the media moguls. The
public interest is only served by (1) a /limited/ period of
government-protected monopoly (allowing for profit by the copyright
owner), followed by (2) an /unlimited/ period in the public domain.
The facts in the next paragraph come from the excellent article by
Neil Weinstock Netanel that appeared in 106 Yale Law Journal 283
(1996). This article is MUST READING for you, me, Mr. Eisner, all of
Hollywood, and the U. S. Congress:
http://www.utexas.edu/law/faculty/nnetanel/yljarticle.htm
The Constitution demands that copyrights be limited in term. Congress
originally (in an Act dated May 31, 1790) limited copyright to one
14-year term, renewable at most one time. Since then, reacting to
commercial pressures, Congress, acting against longer-term public
interest, lengthened the term repeatedly (in 1831, again in 1909,
again in 1976). The 1976 Act gave exclusive rights to the copyright's
owner for the life of the author plus 50 years. According to the
article, another piece of legislation pending would extend this even
further, to life plus 70 years. (I am not sure if it passed.)
Where will it end? Apparently never, for, the Constitution
notwithstanding, the idea of a copyright has now been replaced by an
irritatingly wrongheaded notion of "intellectual property"---an idea
that basically makes a copyright into real property for perpetuity,
and gives the owner the right to shoot to kill, figuratively speaking.
(I am from Texas, where trespassers may be shot on sight.) How bad
has it gotten? Now the idea even has an acronym: IP. I have even
seen help wanted ads for something called an "IP Manager."
If I could, I would ask Mr. Eisner a question: How much longer does
he expect to continue getting richer and richer off of Mickey Mouse?
He (Mickey) should have gone into the public domain /years/ ago, if
Congress were doing its job. And if Mr. Eisner were doing his job,
Disney would just have moved on to something else even newer, cuter
and more irresistible with which to lure us into movie houses and make
us buy DVDs. Today, it should be perfectly legal for underpaid
watermelon farmers to eke out a living by making plywood Mickey
likenesses and hawk them from the back of a pickup truck on the
roadside. But it isn't, of course; that is "theft of intellectual
property" and will be stopped immediately under the protection to
Disney afforded by Congress.
Eisner, the MPAA, and their storm troopers are the real thieves. They
are stealing our money and stealing our way of government, and trying
to tell us that Abe would approve. A pox on all their houses.
Charles Hethcoat
| ||
From: JP S-C <jp_sc@yahoo.com> To: letters@lwn.net Subject: 2nd Linux Accessibility Conference Date: Thu, 28 Mar 2002 20:51:21 -0800 (PST)
| ||
| ||
Copyright © 2002
Eklektix, Inc., all rights reserved