In the From the Editor in the December 2003 issue, Mr
Marti mentions the courts decided in favor of “banning our
technology journalism colleagues at 2600 from even linking to one
DVD-descrambling program, DeCSS.”
I cannot help but wonder if this censorship would go so far as to
be enforced against paper publications. In other words, would they
press this law against a newspaper or magazine (like yourselves)
who might decide to print the URL of such a link?
It would be interesting if they would push the DMCA to such an
extreme as to be clearly contrary to the freedom of the literal
press, as opposed to the Web-based “virtual” press.
Maybe if some magazine published the URL www-2.cs.cmu.edu/~dst/DeCSS/Gallery/dvd-hoy-reply.htm, you would find out. —Ed.
In the December 2003 issue of LJ, page 40, Glenn Stone raises the point that the “Big 3” graphics core logic vendors are standing firmly on the side of releasing binary-only drivers for their products. I wanted to mention that ATI provides programming information for most of their RADEON line under NDA to interested developers. Some XFree86 and DRI developers already have access to this documentation, and an open-source RADEON driver is underway.
ATI also provides code samples and support for their products; a Mach64 DRI driver recently was developed from scratch due to their involvement. Neither NVIDIA nor Matrox will provide any programming information, even under NDA, to developers wishing to write open-source drivers for their recent products. ATI, therefore, can be regarded as the one mainstream company that, while understandably not running to open source the drivers it has developed in-house, is nevertheless a friendly force to open-source developers as well as all users that prefer open source.
I also have another approach to consider. Given that 3-D graphics is still a cutting-edge technology upon which new ground is broken on a daily basis, the OEMs consider it crucial to their business model that their proprietary secrets remain guarded. An all-or-nothing approach is counterproductive. I say that we firmly and reasonably draw a line beyond which further source code or documentation revelation would be of diminishing return, and ask that of the companies involved, instead of asking for everything including their crown jewels.
Stone also calls for debate on this topic. I see very little to debate, besides to buy products only from the company that gives you the level of support you desire, whether it be binary-only drivers that work “most of the time”, open-source drivers developed and supported in-house or simply the availability of programming documentation for their hardware. Also, consider the value of whether you wish to participate in a self-supporting user community, or whether you really don't mind being dependent on a single source of support for the product and its associated software.
Furthermore, it is imperative that when you make a buying decision that
you contact the sales departments of both the company from which you bought the
product, to tell it how its enthusiasm for open source caused you to
buy its product, and the company's main competitors, to let them
know what your criteria were and why you did not choose their product.
Only by making informed buying decisions and providing feedback to the
companies involved can we ever expect our preferences to have an impact
on the market as a whole. Be active if you want to see change.
Because Monarch Computer Systems supported the Ultimate Linux Box Project [LJ, December 2003], I have been considering them when purchasing a new system. Recently, I had a problem with a system that required me to make a contingency plan in case I could not get it fixed. It turned out that I did fix the system, which had a strange power supply problem. However, Monarch was so helpful to me that I thought the least I could do was commend them on their service. I wrote to Monarch:
Thank you very much for your help. I borrowed a PS from a friend yesterday and that resurrected my A7V system. So I will not be needing a system right now. This is good for me because our little company isn't doing so well and my salary has been cut by one-third. However, when I get more work or get my salary back, I want to get another system as an upgrade and to make this A7V system a backup. When that time comes, I will be coming to Monarch first! Chris has been super-helpful for me in preparing a low-budget new system. This is even more impressive because he knew from the start that this was not going to be a high-margin sale!
I give Monarch my highest recommendation.
Those of you who know me well also know that I collect automated musical instruments and have a fondness for organ music. Nick Walker found this link (www.eetimes.com/sys/news/OEG20031203S0032) and sent it to me about an Aeolian-Skinner organ at Trinity Church in NYC that was destroyed by the dust and dirt caused by the World Trade Center collapsing on 9/11. From there I read several articles, including the one at this address: www.organpower.com/DoubleOpen5401.pdf. On page 6 of the PDF it has the words:
The decision was made to develop the organ's control and tone generation systems in a Linux environment. Linux, a highly stable operating system, is considered by many to be the finest environment in which to run this type of standalone application on either standard or embedded controller PCs.
The passage is from an article entitled “Epiphany on Wall
Street”, Open: A Publication of the New York City
Chapter of the American Guild of Organists.
Jon “maddog” Hall
In the December 2003 issue, an article by Rick Moen on the use of USB Flash storage devices (“Floppies for the New Millennium”) includes the following: “...no matter what you do, the Flash disk always mounts read-only....Exactly why /bin/mount insists that the Flash disk is write-protected and must be mounted read-only is a genuine mystery.”
I am the author and maintainer of the driver that talks to this entire class of devices. To me, it's not a mystery. USB mass storage devices are handled by a virtual HBA in the SCSI subsystem. For direct-access type devices (disks, Flash, etc.), sd.c checks the write-protect status with a MODE_SENSE command. The problem is, MODE_SENSE isn't used by Microsoft Windows. Thus, the firmware to recognize, process and respond to that command properly often is lacking from USB devices, especially those that are under extreme price pressure, such as the keychain-type Flash devices discussed in the article. Sometimes, they simply respond with incorrect data.
This problem is widespread. I've even seen quite a few devices that crash their internal firmware when they see certain MODE_SENSE or MODE_SENSE_10 commands. This is basically a matter of poorly implemented devices—the device is tested with a popular OS and not fully coverage-tested for compliance to the open and published specifications.
Up to a certain 2.4.x kernel version, a failure of the check for
write-protect would default to write-protected status. Often this
is accompanied by a message from the kernel (sd.c: test WP failed,
assuming write protected). Later, a patch was merged that made
the assumption write-enabled.
The 2.5/6 kernels introduced a new problem—sd.c wants to check for
mode page 8, which causes more devices to die.
Currently, those of us involved with USB storage development are
trying to identify what MODE_SENSE/MODE_SENSE_10 commands are used
by Microsoft Windows to speak to these devices—the theory is
that if we can identify these commands, then they must be safe
for Linux to use.
Author/Maintainer, Linux USB Mass Storage Driver
As a newbie in Linux development, I was delighted to read the
article “Controlling Hardware with ioctls” by Lisa Corsetti
[January 2004]. So I downloaded the
source code and discovered that the ioctl calls used
work only if you are running as a privileged user, which I was
totally unaware of. In the context of the article, this worked great,
but it would be nice if a similar piece of code had been shown to
get the same information for an ordinary user.
When you need ordinary users to do a task that's reserved for root, use sudo: www.courtesan.com/sudo. —Ed.
I recently asked the Computer History Museum (www.computerhistory.org) if they would like my back copies of Linux Journal. Museums always are reluctant to take items, as it is hard to raise money to take care of the things. So, it was great to hear they were excited to add LJ to their collection. I thought you might like to see Linux Journal becoming a part of history; here is museum curator Sharon Brunzel holding LJ #1. Note that she is wearing curator's gloves, required when handling all historical objects.
I've been subscribing to Linux Journal for three years now. Great
magazine, but I noticed you don't have a classified section. Many
readers can benefit from small, low-cost classifieds. I advertise
my group in a local computer paper's classified section and was
disappointed to see LJ doesn't have any classifieds. A section
for user groups might be a good addition or simply “help wanted” and
“education and training”. Linux thrives on user group participation.
President, Toronto Area Novell User Group
Jason Ellison's article “Controlling Devices with Relays” in the December 2003 issue was a refreshing complement to the other articles on kernel scalability. I have been using Linux for almost ten years, but I still consider myself to be both a novice administrator and programmer. Jason's article was perfect for all of us who don't spend our days tweaking operating system internals, but who know just enough about our computers to be dangerous.
In upcoming issues, I would enjoy seeing more articles that take this cookbook approach to describing the diversity of Linux solutions—defining a short problem, reviewing the options available and discussing the solution with enough detail that a sufficiently motivated novice can ring a bell or two at home if they desire.
I work as a mechanical engineer. As part of my
job, there are countless opportunities to implement solutions
similar to the warning bell system that Jason created. Combining
computer control with mechanical hardware can save tremendous
amounts of money.
The ability to make use of inexpensive components, existing computer
equipment and validated Linux software, as opposed to purchasing
an overpriced supervisory control and data acquisition (SCADA)
package should be applauded.
The Jodrell Bank Observatory appears to be using Red Hat Linux
in connection with looking for a signal from the European Space
Agency's Mars Lander, Beagle-2. Look in the lower-right corner for a
“waterfall display” (time vs. frequency) plot of the spectrum around
Beagle-2's center frequency. The desktop is clearly GNOME on Red Hat.
The signal of interest is 5 watts from about 98 million miles away (www.jb.man.ac.uk/public/Thursday3.jpg).
Installing slashcode, the content management software that
runs the popular Internet site Slashdot (www.slashdot.org),
always has been a difficult and arduous task for even the
hardened administrator. In response to this, in June of
2002, I created the “Install Slash For Dummies” document,
very much like Linux Journal's own slash installation
However, the document did not provide a comment system nor did
it provide a community-based forum. In response to this, I have
created www.installslash.org. This is a new community
site, and its goal is to make it as easy as possible to install slash, and at
the same time provide support and valuable information on modifying
slash to your liking, no matter at what skill level you reside.
Something that I have yet to see handled in the Open Source community
is the difficulty that federal employees have in contributing to
open-source/free software. I'd love to contribute more and help
out with projects that I use at my (federal) workplace, but I understand
that the law prohibits that.
Federal employees cannot hold or give copyright in any code
created by them, but the code must be public domain. This makes
contributing difficult at the very least. I believe that some GPL
or other license projects have significant federal-employee written
code, but I do not understand how they can place it under the GPL.
I'd love to see a treatment/explanation of this. I have not yet
seen any. If something does exist, please point me to it.
Any project, under any license, can accept public domain code. The public domain is not a license; see /article/6225. —Ed.