I just noticed that Unix Review fell off the face of the planet. After consulting the great Internet Oracle I found that Unix Review ceased publication in 2007. Their website now redirects to Dr. Dobb's, where I was unable to find the two articles that I wrote for Unix Review in 2001.
I have posted both articles to my site for vanity historical reasons. I haven't changed or updated the articles in anyway, so they should be amusingly out of date at this point.
Enjoy the history.
I finally had an opportunity to reload the Inspiron 600m with Fedora Core 2. I am pleasantly surprised by what many people said was a horrible release, but it seems that this is a case of a few bad features spoiling the distribution. Yes, I actually like the new Nautilus. So far.
ACPI works out of the box on Core 2. It even has this nice new daemon, cpuspeed, which will manage the throttling of the processor. So far this seems to really help battery life. Wireless did not work from the initial install, but then I didn't really expect it to. Installing the ipw2100 module was simple once I had the kernel source installed. Installing the kernel source was a pain, though, because the mirrors were out of sync. The ipw2100 driver does work for this laptop, and now I don't have to use my Lucent PCMCIA card.
Now that all of the features of this laptop work, I think it's time to start looking for a new one...
This morning Slashdot broke the news that Intel has a driver out for their Centrino wireless cards. Having spent a bit of time reading this over it looks good, it just needs a bit of fleshing out. The initial version doesn't support WEP, which makes this useless for me at the moment. However, I do plan on keeping a close eye on this.
Read all about the progress at ipw2100.sourceforge.net.
This laptop has been retired in favor of my new Dell Inspiron 600m. I probably won't have much more to say about this laptop.
I will still be happy to answer questions, but the last time I installed this laptop with Fedora Core 1 everything just worked.
This information is provided to let you know how I configured my laptop to work with Linux; it is provided with no warranty at all under any circumstances. If you break your laptop trying anything listed below don't whine at me about it.
I have replaced Redhat 9 with Fedora Core 1 on this laptop. To my great pleasure everything works with the exception of the internal wireless card. The only modification that was needed was to add "acpi=on" to the gurb configuration. Unless you have some insatiable desire to hurt, this is likely a better solution.
I have installed Redat 9 on this laptop. This of course means I will be assuming a Redhat 9 installation here and will mention the portions I had to manipulate to get the laptop functioning.
Almost everything on this laptop has "just worked" by default in Redhat 9. The notable exceptions include the internal wireless card, detailed below, as well as power management. I did have to recompile the kernel to gain acpi power management. So far I am very pleased with this laptop.
The following is the listing of the parts of the 600m that I purchased. Yours of course may be different.
XFree86 version 4.3.0 is set up correctly during the install. I have included the configuration file I am using. It is important to note that I don't use XFS so if you are this file will have to be adjusted a bit.
DRI seems to work with the stock Redhat kernel, unfortunately this must be rebuilt to get acpi working correctly.
Current XF86Config configuration file.
lspci reports the sound card as Intel Corp. 82801DB AC'97 Audio (rev 01). The i810_audio module works flawlessly, so far.
In order to get ACPI working the kernel needed to be recompiled. I got the latest stable kernel ( 2.4.21 ) and the corresponding ACPI patch from acpi.sf.net. Here is the config file I arrived at after many attempts.
I am currently working on changing the DSDT the kernel uses, none of the attempts thus far have resulted in the batteries listing their information correctly. They show 47950 mW vs 48000 mW.
PCMCIA works without any changes using "yenta_socket".
Since rebuilding the kernel ACPI handles power management quite well. I do not have hibernate set up yet and will likely use the software suspend kernel path.
The ethernet device is detected correctly using the "tg3" module. The following line was added on install to the modules.conf file.
alias eth0 tg3
This is an Intel Pro 2100 mini-pci card. This unfortunately contains the Broadcom chipset. It is not currently supported. I am using a pcmcia wireless card until this device is supported.
USB just works by default. The following lines were added to the modules.conf on install.
alias usb-controller ehci-hcd alias usb-controller1 usb-uhci
I purchased the 30 GB drive as I didn't need the extra space or particularly care about the disk performance, it is a laptop after all. The following is the hdparm information from the drive.
Currently I am using the following hdparm line, this is not the best performance this drive has seen. When running the Redhat kernels the drive performed slightly better, this is due to the patch for some new ID's that the original kernel had vs 2.4.21. It's not enough for me to track this patch down currently.
/sbin/hdparm -X udma5 -S 240 -d1 -u1 -m16 -c3 /dev/hda
This information is provided to let you know how I configured my laptop to work with Linux; it is provided with no warranty at all under any circumstances. If you break your laptop trying anything listed below don't whine at me about it.
That said, if you have anything constructive to contribute to this information let me know at nicholas@photodwarf.org.
This is the hardware that my Inspiron 4100 has inside of it. Yours, of course, could be configured differently.
Overall I am very pleased with this laptop. Under Redhat 9 everything works correctly out of the box, unlike previous versions of redhat. Of course good things come to those who wait. ;)
No hassle with this, automatically detected correctly.
PCMCIA=yes PCIC=yenta_socket PCIC_OPTS= CORE_OPTS=
Got around to getting suspend to disk working. All that was needed was following the instructions on dell's support site ( Dell Support Page this link may not work, the title of the document is "How do I recreate the Suspend to Disk (S2D), or Save-to-Disk, file or partition on a Dell? Inspiron? portable computer?" this is part of the "Knowledge Base" ). They type of partition is "OS/2 hidden C: drive" and run the s2d utility from dell. Pretty easy and it mostly works. Sometimes it does not resume or locks completely on resume and I believe this to be a problem with apm and the kernel and not in the hardware itself.
Update: The seemingly random problems with resume were nothing wrong with linux, the kernel or apm, and I strongly suspect the same thing happens with other operating systems as well. The crux of the matter is the button on the front of the laptop triggers an unsuspend. Couple this with a laptop bag that allows this button to be hit while in transit and you have a laptop that suspends and unsuspends several times while it is in the bag, which makes things mildly unhappy. Yea, it took me a while to figure this one out ;) The solution is to get a bag that does not do this ...
Redhat 9's X setup on install correctly identifies both the chipset and the panel. It just works. Including GL and DRI.
The rest of this section is for historic purposes.
Good news, XFree86 4.2.0 is out and supports this chipset. Also of note RedHat has released new XFree86 rpms, version 4.1.0-15, they appear to have back ported the fixes for the radeon support so that works as well now. Here is the config file. The 3d stuff doesn't work in Redhat's release and I haven't tried 4.2.0 yet.
This configuration allows the screen to run at 1400x1050, not bad running at a Depth of 24.
Some related information if this doesn't work for you can be found on the XFree86.org's Xpert list, particularly in November 2001. Or possibly in the message from Micheal Clark that contained the tar ball and the XF86Config that I was using.
Sound is correctly identified and works flawlessly under Redhat 9, the rest of this section is left for historic purposes.
Under the 2.4.9-12 ( Redhat 8 ) kernel rpm the sound seems to work, sort of. sndconfig seems to work with the newer kernel and assigns the sound card as such in modules.conf.
alias sound-slot-0 i810_audio post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc \ -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc \ -S >/dev/null 2>&1 || :
There does seem to be some playback problem though. Some applications do not play sound correctly, through this module. I got around most of this problem by running esd and sending the sound that way. The only real noticeable application that I haven't found a fix for is flash, everyone sounds like Alvin and the Chipmunks. This is due to a bug in the i810 driver in this version of the kernel. It is fixed in 2.4.9-21 from redhat but it has a nasty problem of hard-locking the machine if you stop the audio stream from a wav or from flash.
The internal ethernet (10/100) comes across as eth0 and will run using the 3c59x driver from a stock kernel. Nothing special required, it uses eth0.
Note: Save yourself some time and use the GUI tool provided by Redhat.
The internal wireless card is actually run off of the pcmcia slots. Therefore, just set up your network in /etc/pcmcia/wireless.opts, define the network configuration in /etc/syscongfig/network-scripts/ifcfp-eth1 and off you go. The first couple of octects from the cards mac, this may be different for you, is 00:02:2D. Oh yea, in case you missed the not obvious reference it uses eth1.
I am almost positive that this is a WinModem, but have not investigated because I don't currently have dialup access anywhere. Broadband for me all the time ( woot ! ).
I have recieved some information that there are drivers for the modem, haven't had an account to test it out on but here's the link.
USB works flawlessly, I finally got a USB based printer to test against.
hdparm is your friend to the end, it makes laptops happy. Here are the options that I put in /etc/rc.d/rc.local, it makes the drive speed along. The second lines seems to make the drive even happier, but as I just found it I am keeping the old line around. Just in case.
/sbin/hdparm -d 1 -c 3 -m 16 /dev/hda
/sbin/hdparm -X udma5 -S 240 -d1 -u1 -m16 -c3 /dev/hda
That little E button is keycode 129. You can map this with xmodmap by putting "keycode 129 = F22" into .Xmodmap and then restarting X. If you are on a Redhat System, like I am, this will be read automagicly. You can use your window manager to map the key at this point. And viola, you now have a mapped E button.
The "Open Source" label has become so common that users rarely consider all the implications of the term. In fact, there is no universal definition of "Open Source." If you are working at home on a personal workstation with standard product distributions, you may never need to explore the subtle differences between Open Source variants. But if you write your own software, or if you dabble in the distribution of software, you'll need a clear understanding of the various license options.
In this article, I will discuss some of the prominent interpretations of the term "Open Source." For the terminology-minded, I will use the term "open source" when referring to free software and "Open Source" when referring to the abstract concept. There has been, and will be for the foreseeable future, debate over the correct use of each wording.
The first important task when evaluating Open Source licenses is to define them. Two of the standards organizations overseeing the open source world are the Open Source Initiative (OSI), a non-profit corporation that stemmed from the same roots as Debian, and the Free Software Foundation (FSF). Both OSI and FSF have established guidelines for what they consider "Open Source."
OSI lists nine guidelines for determining whether a license can be declared Open Source. The OSI guidelines are slightly at odds with the Free Software Foundation's definition of what constitutes Open Source. The FSF takes a more holistic view of the license, specifying four freedoms that should be considered, along with the the spirit of the license itself, when deciding whether a license is truly Open Source. Regardless of the differences between OSI and FSF's methods, the results are remarkably similar.
The FSF four freedoms are described at the FSF Web site: http://www.fsf.org/philosophy/free-sw.html. The following is a synopsis of the four freedoms (which are numbered zero through three):
The FSF also compares other licenses' compatibility with the GPL. The FSF tends to review every license they can find to see if it is compatible with other Open Source licenses, and keeps related notes on their Web site.
The OSI requires that licenses apply for the OSI Certification Mark (http://www.opensource.org/docs/certification_mark.html). They also do not keep a list of licenses that have failed the Certification Mark, or are not completely Open Source. Neither one is the end-all in deciding what is or is not Open Source; they simply supply the baseline in a constantly changing environment.
There are hundreds of software licenses, from the fully closed-source Microsoft EULA to the opposite extreme, the GPL. Between these lie a multitude of others; I will focus on the licenses most similar to the GPL. Since there is some discrepancy in what makes a license Open Source, only the ones that both OSI and the FSF regard as Open Source are listed here.
The GNU General Public License (http://www.fsf.org/copyleft/gpl.html) is the Open Source license du jour for the FSF and most of the Open Source License. It gives software developers and users all of the rights outlined by both the FSF and OSI. The GPL works by putting a copyright on the software, which the original developers retain, and by specifically lining out who can copy, distribute or modify the software. This includes everyone who wants to follow the rules outlined in the GPL. Running the software is not covered in the GPL, neither is the output of the program. The output is only covered if it happens to be a work based on the original software, such as a program that creates other programs. The GPL also makes mention of software patents, which are currently rampant in the software industry. If a patented program is placed under the GPL it should be licensed free for everyone's use, though the FSF would prefer no patent at all.
Copying, distributing, and modifying the software are all allowed if the changes and the original software are all available to the public. The GPL does not allow non-open source software to be linked against it in any form, which is the reason for the LGPL. The GPL grants you every one of the freedoms from the FSF and meets all of the requirements of the OSI mark; this helps to make it the core of the open source movement in licenses.
The problems people tend to have with the GPL are the license's viral nature and RMS's extreme evangelism. The viral nature of the GPL becomes an issue when GPL software is combined with software of another license. The GPL "infects" the other software so that it must be released under the GPL as well. Although this is not necessarily a bad thing, it will certainly affect the decision to use it in a combined environment. The solution offered in this case is the GNU Lesser General Public.
To help the GPL gain usage in even more areas, the GNU Lesser General Public License (http://www.fsf.org/copyleft/lesser.html) was introduced. The LGPL was originally the GNU Library General Public License, but the name was changed to promote use of the GPL. The big difference between the GPL and the LGPL is that the LGPL allows non-Open-Source software to link to the libraries with impunity, without suffering the viral effects of the GPL. However, this is the reason that the FSF recommends using the GPL over the LGPL. The greatest benefit of the LGPL is the ability to link it with non-Open-Source software; because of this, LGPL libraries and software can slowly replace the non-Open-Source libraries the software may be using.
The BSD license (http://www.xfree86.org/3.3.6/COPYRIGHT2.html#5) is a short, concise license which allows redistribution of the source under the same license. The BSD license is almost identical to the GPL now in its action, if not wording, since the removal of the advertising clause. This license does not restrict what software can be linked to it or what anyone can do with the software after the fact. Almost all of the tcp/ip software on the internet today started under this license, or was based on such software. This license recently underwent a small change, which removed the advertising clause from the original license. That clause forced people to state that "This product includes software developed by the University of California, Berkeley and its contributors." Although this isn't crippling to the Open Source nature of the license itself, it was seen as a major hassle for people who marketed the software. The new versions of this license do not have this restriction. The BSD license is not viral like the GPL, and is approved by the OSI.
The Artistic license (http://www.perl.com/language/misc/Artistic.html) takes most of its fame from being the co-license of Perl. The core of Perl is released under both the Artistic License and the GPL; users get to pick which license to use for their situation. The Artistic license is much like the GPL, though it also allows negotiation with the copyright holder in order to change the way the license applies in specific circumstances. This license allows the software to be embedded in non-open source applications as long the original software is completely hidden. It also allows executable only distributions as long as one of 4 conditions are met: you must tell the user where to get the standard version, accompany the executables with the source code, give the new executables new names and document these changes in the manual, or make some other arrangements with the original Copyright holder. These differences are what causes the FSF foundation to recommend against utilizing this license, though these differences are what makes it attractive to people who want the software to be used regardless of location. Perl is embedded in many commercial applications because of these features in the Artistic License. The OSI defines the Artistic License as an Open Source License, but the FSF suggest that people avoid it because the vagueness of the license might fail to protect your rights.
IBM's Public License (http://oss.software.ibm.com/developerworks/opensource/license10.html) meets all of the OSI's approval criteria. The FSF lists the license as free software, yet notes that it is incompatible with the GPL because some of the requirements are not part of the GPL. These requirements center around the patent licenses that are required by the IBM license but not by the GPL. The IBM license is also subject to the laws of New York and the United States, as stated in the license itself, which could pose problems for developers outside of the United States.
The X11 License (http://www.x.org/terms.htm) is used by the The Open Group for the X Window System. It does not have OSI's certification as an Open Source license. Because OSI does not list licenses that have not passed the approval, or have tried, it is not plainly obvious why this license is not OSI approved. The FSF does recognize it as compatible with the GPL. The license itself reads very much like the BSD license.
The MPL (http://www.mozilla.org/MPL/MPL-1.1.html) is OSI-approved as an Open Source license, yet the FSF has some reservations about version 1.0. The 1.0 version of the MPL does not allow GPL'ed software and MPL'ed software to be linked together because of some of the restrictions in the MPL. This restriction could also cause problems in linking the MPL to software that is covered under any other license, hence the 1.1 revision of the license. The 1.1 version of the license resolves this issue by offering portions of the code to be under multiple licenses. The MPL also cleans up some problems that were present in the Netscape Public License, specifically problems in the NPL that allowed code to be taken into closed-source projects by Netscape Corporation. The FSF urges people not to use the MPL because of the linking problems inherent in the 1.0 version.
Choosing the right license for your software is much like finding the right way to create it in the first place. If the software was developed for your place of employment you will have different requirements than if you write it in your spare time. Some of the requirements to keep in mind are:
There tend to be two camps of thought on this issue. First, there is the FSF foundation, which wants all software to be covered under the GPL, and therefore free for everyone to update and use. Second is the OSI, which just wants more people to use Open Source compatible software. Both camps are looking for the same goal: get the source and the ability to use the software to the largest possible audience.
If the social and philosophical issues of Open Source software don't concern you, then choose any one of these licenses, as they all accomplish the same feat: software is distributable to everyone, users can modify the software, and you retain the copyright on your work. However, if the philosophical issues are a consideration for you, choosing the right license will require a great deal of thought about how you view closed-source applications and their use of your software. (The GPL, for instance, doesn't allow closed-source software to use the product, while most of the other licenses do not have this restriction.)
Open Source licenses are growing in number every year, and corporations are adding their own, as well. Some, like IBM, have met the criteria for being an Open Source license. Others, like Netscape's, have not fared so well. If you can't find a license that suits all of your needs, chances are either you are not looking hard enough, or your requirements cannot be met by an Open Source software license. Start with the OSI and FSF guidelines and determine if you are willing to operate within these restrictions. If so, check the OSI and FSF Web sites to look for leads on a license that may be right for you.
Originally published in Unix Review, March 2001.
It's not a Burgundy, it's not a Bordeaux, and it's not an emulator. It's WINE, an implementation of the Microsoft Windows API for Unix variants. Alexandre Julliard and the WINE development team have been getting a lot of press as they approach their 1.0 release. WINE could propel Linux into the desktop market and lower the barrier for small businesses to switch operating systems. It can even help those of us whose only tie to Windows is games. And yes, it even runs Solitaire.
In a nutshell, WINE is a program that allows you to use Windows applications in a more stable environment. One of the benefits of WINE not being an emulator is that it cages Windows applications into a "safe" area, more so than Windows itself, leaving you with a useable operating system even after your application crashes. WINE is an implementation of the Windows API, which allows it to run unmodified Windows 3.1/95/98/NT binaries under Linux, FreeBSD, and Solaris. It does not require Windows to be installed, but can use the native Windows DLLs to supplement its own functionality. WINE currently implements 90% of the popular API calls, and new features are being added to each release. It also includes a development tool kit and multilingual support. WINE is not distributed under the GNU Public License, but under one similar to X11.
In 1993, Bob Amstadt began developing a program to bring the Windows 3.1 API to Unix. Shortly after development started, Alexandre Julliard took over as project coordinator. Development has continued under his leadership during the past eight years. Recently, several companies have taken an interest in helping further the development of WINE. Among them are Corel and CodeWeavers. There are now over 300 developers working to get WINE past the developer-only phase. The complete Change Logs for WINE, starting in 1993, can be retrieved from the WINEHQ online source tree.
Just as the acronym states, WINE is not an emulator. Instead, it is an alternate implementation of the Windows API. This makes WINE more like GTK than VMWare or Plex86, which makes the jobs of the developers a little harder. WINE has been developed through study of the spartan Microsoft documentation of its own APIs, and through a lot of reverse engineering. This gives WINE the ability to match Windows bug for bug. Being a bug-for-bug match enables the user to see all of the error messages that would have been missed if they were running Windows (though they do seem slightly out of place in the Unix environment). An example would be the message received while trying to install Microsoft Explorer 5.5 on a Microsoft free installation:
"A previous program installation was never completed. You need to restart your computer to complete that installation before running Internet Explorer Setup. Setup will now close. [OK]"
Because WINE implements the API—just the DLLs and not the VXDs—it does have some limitations: it cannot use devices that the base operating system does not know how to handle. Of course there are exceptions to this rule; some parallel devices that do not have Linux drivers are known to work. Applications also run slightly slower under WINE than they do in Windows at this time, mainly due to the debugging code in the current source. Once the debugging is removed, however, applications are expected to match their native Windows speeds.
Generally, older Windows 3.1 applications have a better chance at running under WINE than newer ones, though some of the newer applications like Internet Explorer 5.0 and parts of the Microsoft Office Suite run just as well. At WINE Headquarters there is an Application Database (http://www.WINEhq.com/Apps) that lists all of the applications that people have successfully operated under WINE. Linux Games (http://www.linuxgames.com/WINE) has a section for Windows Games that run under WINE, notably StarCraft, Myth, and Heretic II. WINE will also run the Windows 95 tour, which never looked as good as it does under Linux.
WINE is currently moving toward its 1.0 release. Snapshots are made of the development tree every three to four weeks. If the absolute latest source is needed, the developers also provide access to their most recent CVS tree. New features and fixes are being made weekly. The current priorities are to get to 1.0 as soon as possible, make the installation easier for the average user, and finish implementing the API.
CodeWeavers, Inc. (http://WINE.codeweavers.com) is currently making WINE easier for the average desktop user to install and use. Jim Graham, the project coordinator at CodeWeavers, and his team have released a 1.0 preview of WINE. The preview contains a TK-based configuration wizard and a program launcher, as well as tighter integration with Gnome and KDE. You can find the preview release at their site along with an overview of the usability they have added. The preview version doesn't have all of the functionality that the newer bi-weekly releases have, though the configuration tool takes a lot of the work out of getting WINE set up.
TransGaming Technologies (http://www.transgaming.com) recently released patches for WINE, helping to complete the support for Direct X. Their first patch was released on December 27, 2000. TransGaming is operating under a version of the Street Performer Protocol. Users who subscribe to their service get to vote on which games they will work on first. Once one game is completed, they move to the next. TransGaming plans to release all of their code under the same license as WINE when they reach 20,000 subscribers.
With its first non-developers-only release, WINE may become the new killer application that brings Linux to the forefront of the desktop market. Even now, WINE is useful for many applications and can help you waste just as much time as your Windows friends by playing games from the Entertainment Pack.
Originally published in Unix Review, January 2001.