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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide