Fedora 64-bit Browsing and Media

Work-in-Progress: 2006 December - 2006 January

For those running any Linux/x86-64 distribution, you've undoubtably run into the "Long Mode" memory model, or more specifically, the fact that libraries, plug-ins and programs with 48-bit addressing can't use those of 32-bit and vice-versa. I previously covered the hows and whys of this model, and how most other OSes attempt to address it (or avoid it altogether). Fortunately for most users of Fedora Core or Suse Linux x86-64, this is fairly well mitigated, especially after the first few versions. Unfortunately, it hasn't been addressed well when it comes to Internet browsing and multimedia. There are no x86-64 versions of Acrobat, Flash and the x86-64 version of Java lacks a plug-in.

Although I've run every x86-64 release of Fedora Core since version 3, I have basically "hacked" i386 RPMs in as needed. This has been a general PITA when it came to updates, and always required manual intervention. After purchasing a new HP Pavilion dv9000z notebook, I decide to install Fedora Core 6 x86-64 and strictly install only the absolute minimum i386 RPMs required for browser and multimedia compatibility in the hope that no special commands are required outside of YUM to update.

I'm happy to report I was able to accomplish this, and have updated over a dozen times over the last month via YUM without issue. I have broken this article into four (4) parts.

Overview:

1. Livna x86_64 Multimedia
2. Extras/Livna/3rd-Party i386 Multimedia/Plugins
3. 3rd-Party i386 Firefox 2.0
4. Future, Automated YUM Updates
   

1. Livna x86_64 Multimedia

Ideally, we want to only install i386 when absolutely necessary. For the most part, this is only when we need browser plug-in functionality. For nominal desktop usage, including DVD and common multimedia playing, the x86-64 components are just fine. For obvious legal and "clean redistribution" reasons, Fedora leaves out several components. Although Livna provides them, I do not recommend you blindly tap the Livna repository without considering possible indemnification issues, especially if you are installing them at a commercial entity.

Procedure:

• Remove Totem
• Setup Livna key and repo
  
• Install various DVD support, Xine and Totem-Xine
• Install additional multimedia
  

For DVD and other multimedia playback, including CSS encrypted DVDs, we want install Xine and, for GNOME (possibly KDE users as well), replace the /totem package with totem-xine. For MP3 playback, I like included XMMS and will merely add the MP3 support along with the Grip digital ripping and Lame MP3 encoding package. I can honestly say I only grip my own CDs and DVDs, period, and strongly believe in respecting the IP of others regardless of what I think of them (as I expect them to do the same of my works).

Remove Totem

# yum remove totem

=============================================================================
Package                 Arch       Version          Repository        Size
=============================================================================
Removing:
totem                   i386       2.16.1-1.fc6     installed         4.9 M
totem                   x86_64     2.16.1-1.fc6     installed         4.9 M
Removing for dependencies:
rhythmbox               x86_64     0.9.5-4.fc6      installed         6.4 M
totem-mozplugin         x86_64     2.16.1-1.fc6     installed         300 k

Install Livna public key and repo

# rpm --import http://rpm.livna.org/RPM-LIVNA-GPG-KEY
# rpm -ivh http://rpm.livna.org/livna-release-6.rpm

Install various DVD support, Xine and Xine-Totem

NOTE: xine-lib-extras-nonfree, from Livna.ORG, now seems to be required for CSS encrypted DVD playback as xine-lib is in Fedora Extras. Also note the Xine versions between packages may not match up in the example below.

# yum install libdvdcss libdvdnav libdvdplay libdvdread rhythmbox totem-mozplugin totem-xine xine-lib xine-lib-extras-nonfree

=============================================================================
Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
libdvdcss               x86_64     1.2.9-4.lvn6     livna              31 k
libdvdnav               x86_64     0.1.10-2.lvn6    livna              88 k
libdvdplay              x86_64     1.0.1-4.lvn6     livna              34 k
libdvdread              x86_64     0.9.7-1.lvn6     livna              66 k
rhythmbox               x86_64     0.9.5-4.fc6      core              3.1 M
totem-mozplugin         x86_64     2.16.1-1.fc6     core              129 k
totem-xine              x86_64     2.16.2-2.lvn6    livna             1.9 M
xine-lib-extras-nonfree  x86_64     1.1.4-1.lvn6     livna             522 k
Installing for dependencies:
aalib                   x86_64     1.4.0-0.11.rc5.fc6  extras             75 k
libmodplug              x86_64     1:0.8-3.fc6      extras            114 k
lirc                    x86_64     0.8.1-0.2.pre2.fc6  extras            248 k
xine-lib                x86_64     1.1.2-17.fc6     extras            2.1 

Install additional multimedia

This is definitely left to individual taste.
# yum install grip lame lame-libs xmms-mp3

2. Extras/Livna/3rd Party i386 Firefox/Multimedia

Now the fun begins. First off, Fedora Core 6 x86-64 comes with both i386 (32-bit) and x86-64 (48-bit) versions of Firefox, but favors the latter by default. You want to leave the latter installed for desktop support, but we want to favor the former when you run Firefox. So we'll need to change the startup script (I should make a RPM that does this, and re-applies anytime a new version is installed). Then we'll mix in some 3rd party RPMs, namely Acrobat Reader, Flash v9 and the JDK (I prefer having the full JDK over just the JRE). Lastly, we'll do what everyone says you shouldn't, but it works just fine. We'll drop in two (2) YUM Repo files that are disabled by default, then run one (1) command enabling them temporarily to give you just what you need -- namely DVD, MP3 and codec support along with MEncoder/MPlayer and plug-ins for i386.

Procedure:

• Verify both Firefox i386 and x86-64 are installed
  
• Edit Firefox launch script to favor i386
• Setup jpackage key and repo
  
• Download 3rd party i386 RPMs
• Install and enable 3rd-party i386 software
• Setup 3rd-party i386 plug-ins
• Setup Extras-i386/Livna-i386 repos (disabled)
  
• Install Extras/Livna i386 RPMs

Verify both Firefox i386 and x86-64 are installed

It's important to note that with Fedora 6, each entire tree for Firefox is installed in /usr/lib[64] for i386 and x86-64 respectively. You should ensure both are installed, i386 for what you're going to use, but also x86-64 for desktop and other, native x86-64 support. You should at least have x86-64 and have to only install i386 in the worst case. Don't be tempted to uninstall x86-64, as various dependencies (especially GNOME) will come up. Yes, the Firefox launch script will launch i386 by default if it cannot find x86-64, but not having the x86-64 version installed can cause some dependency headaches.

# yum list firefox
...
Installed Packages
firefox.x86_64 1.5.0.8-1.fc6 installed
firefox.i386 1.5.0.8-1.fc6 installed

Edit Firefox launch script to favor i386

Now we will edit /usr/bin/firefox to favor the i386 version. I highly recommend you use RCS to maintain changes of any files, especially stock files. That way, you can easily do differences or [re-]patch changes whenever scripts are updated. I will include the few, paltry commands to revision files below.

# cd /usr/bin
# mkdir RCS
# ci -l firefox
type in something like "Firefox launch script"
# gvim firefox
or whatever your favorite editor is

Comment out the following lines ...
#if [ -x "/usr/lib64/firefox-1.5.0.8/firefox-bin" ]
#then
###MOZ_LIB_DIR="/usr/lib64"
#fi

And let's save our changes so we can identify them later ...
# ci -l firefox
type in something like "Removing detection of lib64 version"

Now the 32-bit version will launch when you execute Firefox.

Setup jpackage key and repo

The JPackage Project maintains a most excellent Sun Java compatibility RPM that properly configures the Alternatives system for Sun's Java, allowing it to co-exist with GCJ as well as offer additional capabilities.

# rpm --import http://www.jpackage.org/jpackage.asc
# cd /etc/yum.repos.d
# curl http://www.jpackage.org/jpackage.repo
# gvim jpackage.repo
or whatever your favorite editor is -- enable (enable=1) the non-free repository

Download 3rd-party RPMs

Install and enable 3rd party RPMs

Setup 3rd-party i386 plug-ins

Setup Extras-i386/Livna-i386 repos (disabled)

Install Extras/Livna i386 RPMs

# yum --enablerepo=extras-i386 --enablerepo=livna-i386 install a52dec.i386 libdvdcss.i386 libdvdnav.i386 libdvdplay.i386 libdvdread.i386 mencoder.i386 mplayer.i386 mplayer-fonts.noarch mplayer-gui.i386 mplayerplug-in.i386

=============================================================================
Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
a52dec                  i386       0.7.4-10.lvn6    livna-i386         49 k
libdvdcss               i386       1.2.9-4.lvn6     livna-i386         31 k
libdvdnav               i386       0.1.10-2.lvn6    livna-i386         89 k
libdvdplay              i386       1.0.1-4.lvn6     livna-i386         34 k
libdvdread              i386       0.9.7-1.lvn6     livna-i386         66 k
mencoder                i386       1.0-0.66.rc1.lvn6  livna-i386        1.3 M
mplayer                 i386       1.0-0.66.rc1.lvn6  livna-i386        2.6 M
mplayer-fonts           noarch     1.1-4.lvn6       livna             1.0 M
mplayer-gui             i386       1.0-0.66.rc1.lvn6  livna-i386        237 k
mplayerplug-in          i386       3.31-2.lvn6      livna-i386        482 k
Installing for dependencies:
aalib                   i386       1.4.0-0.11.rc5.fc6  extras-i386        74 k
enca                    i386       1.9-3.fc6        extras-i386       118 k
faac                    i386       1.24-6.lvn6      livna-i386         79 k
faad2                   i386       2.0-19.20050131.lvn6  livna-i386        209 k
ffmpeg                  i386       0.4.9-0.25.20061030.lvn6  livna-i386        1.7 M
fribidi                 i386       0.10.7-5.1       core               53 k
gsm                     i386       1.0.10-12.lvn6   livna-i386         41 k
imlib2                  i386       1.3.0-3.fc6      extras-i386       576 k
lame-libs               i386       3.97-3.lvn6      livna-i386        331 k
libdv                   i386       0.104-4.fc6.1    core               80 k
libid3tag               i386       0.15.1b-3.fc6    extras-i386        44 k
libmad                  i386       0.15.1b-4.lvn6   livna-i386         82 k
libmp4v2                i386       1.5.0.1-2.lvn6   livna-i386        264 k
libmpcdec               i386       1.2.2-4.fc6      extras-i386        30 k
lirc                    i386       0.8.1-0.2.pre2.fc6  extras-i386       238 k
lzo                     i386       2.02-2.fc6       extras-i386        63 k
speex                   i386       1.2-0.1.beta1.fc6  updates           475 k
x264                    i386       0-0.8.20061028.lvn6  livna-i386        241 k
xvidcore                i386       1.1.0-4.lvn6     livna-i386        242 k

3. 3rd-Party i386 Firefox 2.0

Procedure:

• A

4. Future, Automated YUM Updates

Procedure:

• B
  

Smaller Footprint x86 Embedded

Work-in-Progress: 2006 December - 2006 January

Most of the embedded systems development work I've done during my career has focused largely on non-x86 compatible systems. Specialized, custom, low-power, low-thermal, small systems with 68k, ARM, MIPS, Power[PC] and XScale in more recent years, and even some more eccentric before that. But when it comes to lower-volume, commodity-off-the-shelf solutions, there are many options available to developers.

Overview:

• Commodity x86 Embedded Form Factors
• Commodity x86 Embedded Processor Sockets
• Commodity x86 Embedded Interfaces and Peripherals
• What x86 Embedded Should and Shouldn't Do
• Solid State Boot Options and Issues
• Sample of Today's Commodity Products

Commodity x86 Embedded Form Factors

[ need to add drawing of MicroATX v. Mini-ITX v. 5.25" SBC v. 3.5" SBC against standard-size ATX in enclosure ]

I'm not going to even attempt to cover all of the available form-factors that x86 products are available in. That would take many, many blog articles. Intel's Embedded Computing Small Form Factors, is a great starting point for looking up any form factors I cover here, plus many other, often smaller, options.

ATX Compatible: MicroATX (9.6x9.6")

MicroATX is clearly not an embedded form-factor, but it is commonly used in x86 embedded prototyping and provides as good "basis" where to start as most PC technicians are at least familiar with ATX (12" wide x 9.6-13" deep) and its 6" wide face-plate for external, user-accessible ports.

MicroATX has traditional ATX faceplace compatibility, the first 6", with another 3.6" for up to 4 vertically standing slots, a total of 9.6 wide. In a nutshell, it is 12" wide ATX with "3 slots chopped off." MicroATX should not exceed 9.6" in depth, making it no more long than it is wide (9.6x9.6" square), although it is commonly only 8.0" deep. Prototype MicroATX boards often have just about every interconnect on-board, in addition to traditional slots of most (if not all, many gone from newer PC systems) types. See the next section on those. MicroATX prototyping boards are often used as a base-board for ETX (see below or the aforementioned Intel page).

For completeness (in case you run into it), FlexATX is a variant of MicroATX that is only 7.5" wide (sometimes 7.5x7.5" square, although commonly the same depth as MicroATX, a resulting 7.5x 9.6"), with up to 2 vertical slots. It was a lesson common, but popular "low-cost" desktop option that has been replaced by Intel in the last 2 years by the slightly wider (10.5") and changed-orientation (when sitting vertically in a tower for thermal considerations in the expansion and CPU areas, long story) PicoBTX. And despite Intel's main, new value form-factor for OEMs being 10.5x10.5" MicroBTX, MicroATX is still far more popular. Neither FlexATX nor any of the newer BTX options are are popular for prototyping embedded today, and especially not for embedded given the next ATX compatible option.

ATX Compatible: Mini-ITX (6.7x6.7" / 170x170mm)

Mini-ITX has become quite popular over the last 3-4 years as the smallest ATX face-place compatible solution, and is virtually always 6.7" square. Unlike MicroATX or similar, desktop-centric form-factors, Mini-ITX was designed for the smallest footprint/entry-level embedded size PC. The width is the standard 6" for the ATX face-place, with just enough width left for a single, traditional, vertical expansion slot.

Using no or a low-profile card in its slow, the form-factor fits in as small as a 7x7" enclosure less than 2" high -- essentially not much more than ATX faceplate dimensions. Indeed the size difference between a 9"x11"x14" MicroATX cube and a 7"x7"x2.7", of which (the added 0.7" height above the ATX face-place) allows for an internal 2.5" notebook hard drive and a slimline DVD-RW optical drive, is quite massive as a previous blog article of mine last year contrasts quite effectively in just a few snapshots.

[Embedded] Single Board Computer ([E]SBC): 5.25" (6"x8")

The designation of the 5.25" SBC (aka ESB[C]) comes from its size relative to the dimensions of the common PC 5.25" disk drive, 6" wide by 8" deep. Although much of this designation owes itself to storage solutions, it is a common form-factor for countless embedded platforms where no traditional, external face-plate is used. Indeed, in most cases, a limited set of ports are physically connected, and most ports (sometimes quite extensively) are optional pin-outs with included or optional cabling. On-board ports are usually on the edge of long side, so even when connected, the 5.25" SBC will fit in a complete 8x8" enclosure, such as a NEMA 4X enclosure (rated for outside usage), with only those few ports needing cut-outs with air/water-tight gaskets.

Another note on SBC versus most Mini-ITX is power input. Most Mini-ITX requires standard and varying +3.3/5/12V 20-pin ATX 1.0 power input (although some do not), whereas most SBC systems vary widely. Some take a single +12V, others a dual +5/12V, yet others may even take variable voltage and yet others might take as high as +48V.

[Embedded] Single Board Computer ([E]SBC): 3.5" (4x6" / 102x145mm)

The next, obvious and popular SBC form-factor is the 3.5" SBC. Designed to fit in the typical 4x6" PC 3.5" disk drive bay, it is probably the smallest, massed produced form-factor for x86 for embedded applications without getting into vendor-centric form-factors. The 3.5" SBC is smaller than Mini-ITX, has limited ports like its bigger brother, but is still big enough to offer countless pin-out headers, a good helping of various interconnects (such as ETX, PC/104, etc...) and interface options.

Common Interconnect Form-Factors Used on Other Form-Factors

One note I want to make on form-factors is that some form-factors that are built around commonly known interconnects (some stackable, some not), but are also and quite commonly available as options on larger form-factors. E.g., even though PC/104 (including PC/104 Plus) is a known, embedded form-factor (90x96mm), it is also an interface you can find on 3.5" SBC, among others.

Other form-factors are not completely usable units on their own, and require additional support. E.g., the Embedded Technology eXtended (ETX) is a "brains" board that uses up to four (4) 100-pin connectors (one set in each corner) to connect to its "base board," commonly a 3.5" SBC or larger, with pin-outs and additional peripherals. In fact, ETX is a great prototyping and even limited production option where you are evaluating different "core logic" options (Eden v. C3 v. Geode LX v. Geode NX v. ULV-Celeron v. Yonah, etc...), but you have found a "base-board" that supports your peripheral/interface needs (which can get eccentric). Furthermore, it's not uncommon to see a 3.5" SBC model and find out it's a baseboard plus ETX module atop, which several manufacturers do to minimize costs/maximize reusability across multiple processors/chipsets as well as different peripheral options (e.g., optional CardBus/PCMCIA and/or CompactFlash, extra serial ports versus other options, etc...) even though they don't separately sell the 3.5" SBC "baseboard" from the ETX module.

Again, start with the aforementioned Intel link for more on PC/104, ETX and other common interconnects with their own form-factors as well as when used as an interconnect atop of other form-factors.

Commodity x86 Embedded Processor Sockets

While some PC technicians are familiar with older and newer PC desktop and, to a lesser extent, server sockets, commodity processor sockets for Embedded PCs are typically different.

Socket-370 for Intel ULV Celeron/Pentium and ViA Eden/C3

Socket-370 is a rarity in the Embedded PC world now, but it needs to be addressed. For the most part, the legacy GTL+ bus with SDR (single data rate) SDRAM used by both Intel Ultra Low Voltage ([U]LV) Celeron and Pentium processors (based on Pentium II/III generation) and ViA Eden/C3 products are rarely offered in a Socket-370 PPGA or FC-PGA flavor. Most of the time both Intel and ViA release these processors ball grid array (BGA) packages directly solidered on the mainboard itself.

ViA's GTL+ bus solutions offer DDR SDRAM support, even though the "front-side bus" to the processor may only be SDR SDRAM. This is because the chipset integrated graphics processor unit (GPU) may utilize main memroy as well.

Socket-462 (A) for AMD Athlon XP-M and Geode NX

About the only "cross-over" product from the desktop to the embedded world is AMD's Geode NX. Not to be confused with the Cyrix-National Semiconductor lineage, including AMD's own Geode LX and earlier products, the Geode NX is a Thoroughbred-Barton generation, 9-issue, but ultra-low voltage (ULV) Athlon core. Although one has to take care when it comes to the Geode NX, as its voltage requirements and jumpers do not match those of standard Socket-462 processors, but those of the Athlon XP-M[obile].

Reference this most excellent article for more information on the voltage/keying-jumper differences between desktop Socket-462 and mobile/embedded Socket-462.

Socket-S1 (638) for Sempron Mobile, Turion 64 and Turion x2

AMD has moved away from its value desktop and mobile Socket-754 with DDR SDRAM support to its new, dedicated Socket-S1 with 638-pins and DDR2 SDRAM support for portable and embedded PC solutions. Socket-S1 could be considered the "sister" of Socket-AM2 (940-pins), which is AMD's new, unified (both value and performance) desktop DDR2 SDRAM platform. Sempron Mobile, Turion 64, Turion x2 and virtually all future AMD mobile and embedded (you can safely assume a future Geode product) will be featured on the Socket-S1 platform with DDR2 support and a single, HyperTransport tunnel for I/O, graphics and access to additional CPUs.

Socket-479 (Yonah/Merom) for Pentium-M, Core and Core 2

The "rebirth" of the Intel 7-issue Pentium Pro architecture into the "Core" platform in the aftermath of the NetBurst/Pentium 4 performance/thermal issues begins with the Pentium-M[obile], the original Socket-479 platform. The Socket-479 platform, with upgraded DDR2 support over Socket-370, adapted the last, Pentium III design (7-issue + 1-SSE pipe) into the Pentium-M design for portable and embedded solutions. The original, Intel Yonah series of products, better known as Core, was introduced on the same platform. The newest generation, Merom series -- better known as Core 2 -- is yet the latest implementation of the Socket-479 platform.

When it comes to Socket-479, it is important to note exactly what Socket-479 implementation is in use. Although most older Socket-479 platforms support the Pentium-M, fewer support Yonah/Core and even far fewer the latest Merom/Core 2 products. This is not unlike the issues on the desktop with various processor support for LGA-775, where most existing LGA-775 implementations do not support Core 2 -- although Core was never release for LGA-775 (which simplifies things a little bit).

Commodity x86 Embedded Interfaces and Peripherals

When dealing with embedded form-factors, minimizing the size of any expansion options and add-in peripherals is essential. As such, here are several interface options to be aware of on various ATX-based and SBC boards. When I mention size, this is the width of the connector, and not necessary any limit on the overall size.

PC/104 and PC/104 Plus

Although now very rare, it is not too infrequent to see an embedded platform offering PC/104 connections. The PC/104 portion of an embedded board, such as a 3.5" or 5.25" SBC, will fit in 90x96mm (typically near one end of the board). The original specification called for 104-pins for 8-bit ISA, extended to 146-pins for 16-bit ISA -- all 100mils spacing (0.1"). PC/104-Plus adds 120-pins of 50mils spacing (?) for PCI. Although an even newer PCI-only specification removes the ISA pins to regain real-estate, it is rarely seen in embedded. Most systems now favor Mini-PCI connectors to add a few, necessary

Mini-PCI (60mm)

Mini-PCI almost looks like a SO-DIMM memory socket, but it's not. It's a commonly a 32-bit, 33MHz PCI slot (although other width/speed options exist, but are very are) on a shared PCI bus (133MBps), but saves a great amount of mechanical room. A major driver of Mini-PCI was the need for interchangeable communication devices (modem, network, wireless, etc...) on portables, such as notebook computers. The same holds true for embedded.

One thing to note is that while 32-bit CardBus and 32-bit PCI share some similarities, CardBus is not a PCI bus, even though CardBus it is commonly bridged from PCI. CardBus was designed to be mechanically compatible with PCMCIA (designed for ISA-generation systems) and offer backward compatibility.

CardBus (and PCMCIA)


PCI Express Mini CEM (30mm)

The PCI Express Mini Card Electromechanical (CEM) design, aka Mini PCI Express (or Mini PCIe), is almost a PCIe (a dedicated, 3GHz, bi-directional per x1 bit ~ 250MBps per x1 bit at 8/10 data encoding serialized interface) slot turned on its side with a more SO-DIMM like connector (NOTE: the PCIe CEM specification has a reservation of many pins, including for a second channel, so it's capable of PCIe x2 or ~500MBps). Quite perfect for PC portables, the Mini PCIe interface allows two 30mm wide expansion modules in the same width as one 60mm wide Mini PCI device. And unlike Mini PCI with CardBus, the latter maintaining backward compatibility with PCMCIA (and ISA electrical/voltage) which had to be bridged to PCI, Mini PCIe has a direct relationship with not only PCIe slot, but the ExpressCard standard for external add-on cards (a good contrast in the design difference is illustrated here). An external ExpressCard/34 (34mm wide) device is basically the same as an internal Mini PCIe card.

LVDS Flat Panel Interface


Parallel AT Attachment (ATA)


CompactFlash


Other Options


What x86 Embedded Should and Shouldn't Do


Solid State Boot Options and Issues


Sample of Today's Commodity Products

LPI Reiterates and Updates Certification Policies

The Linux Professional Institute (LPI) has recently reiterated its exam retake policies and recommendations as well updated its recertification policy with the recertification requirements to maintain an ACTIVE status. I will attempt to cut through the rhetoric with the facts, the tracks, newer developments and, finally, my professional opinions.

Overview:

- Who is LPI? How are they different?
- Just the Facts of the New LPI Recertification Policy
- The LPI Certified Level 3 (LPIC-3) and New Specialization Developments
- Opinions from a LPI "Outsider"
- Democracy v. Meritocracy+Executive

Who is LPI? How are they different?

Before I answer that, let's step back and look at other companies (and their motives) in the certification industry. There are three (3) types of certification companies, from most to least recognized, at least typically ...

1. For-Profit Product Vendor
2. For-Profit Training or For-Profit/Non-Profit Industry Associations
3. Non-Profit or Government-Related Professional Organizations

And before I being to address those, let's look at where each obtains their revenue, in order of most profitable to least profitable ...

1. Product and support sales with possibly some training-related revenue
2. Training, training materials and other training-related revenue
3. Certification and other, exam-centric fees with extensive volunteering by industry

By far, the most recognizable certifications are those of, by and for a vendor and its products. They are driven by the sheer economies of scale of the hardware and software products sold, and the training of professionals on and for the product ensures the product sells because it is supported. Some demonize this as "pushing product," and some do little to actually put "value" into an otherwise worthless, computered-administered examination with a lot of high profit-margin training (or training partnerships) built around them. But some vendors do take the time and effort to care about the quality of their certifications. Cisco and Red Hat deliver lab-based certification to ensure many of its qualified professionals actually have "hands-on" with the product. The programs aren't perfect (and Cisco is guilty of some of its lesser certifications being computer-administered "cakewalks" like others), but they are a solid attempt by the vendors to present individuals as adequately competent with the product in common usage.

The second type is commonplace among many, alleged "vendor-neutral" certification organizations. Most of these organizations, although their certifications are branded differently, are actually for-profit training organizations. They sell their own training materials, training programs or certified training licenses to select partners and trainers. In a nutshell, training is the revenue, and it can be a very profitable one. If the demonizing is "pushing product" for the former, it's definitely "selling training" in this case. I have personally balked at some of the "test of a test" type questions that I assume formal training would answer on some exams in one of these "vendor-neutral" programs, and reverse my logic when I retook the exam (the only one I ever failed) and got a perfect 100% on the section I had previously failed (even though I had made an 85% overall, I got a 69% -- 1% under the section minimum).

Lastly, but not leastly, are non-profit organizations or government agencies charged with certification and licensure. Although some fees are collected from actual examination, certification and licensure, most of their "resources" come directly from volunteers in the industry. Rules, statues and objectives, consideration for locale titles and relevance of knowledge, practices and principles are the foundation of their focus, content and the resulting professional who is entitled their designation. These organizations thrive on community involvement, but that community involvement must be a "put up or shut up" involvement, with actual donation of time towards not only developments, but the openness to consider both ideas from peer-professionals as well as, and just as much, what commercial organizations in the industry consider "important" for a professional to know and respect.

The not-for-profit Linux Professional Institute (LPI) is the last type, earning no money from vendor alignment or partnerships and no money from training or sale of materials or any related training partnerships. And despite early, multi-vendor funding, LPI has been self-sufficient for almost a half-decade now. It survives on the limited funding it receives from direct examination and the countless volunteers who help develop and analyze the objectives and exams themselves.

LPI has certified more Linux professionals world-wide than any other Linux program.

Just the Facts of the New LPI Recertification Policy

There is countless comments, complaints and even some rhetoric and FUD flying about regarding LPI's new Recertification Policy (see Section 6). I hope to cut through these comments and get to the facts.

1. Perpetual Certification: LPI Certifications are perpetual -- i.e., LPI Alumni who obtain LPI Certified (LPIC) status at any level will always be in the LPI database as a professional who has obtained LPIC status.

2. Linux Knowledge is Perpetual: LPI has, since Day 1, always stated that they value all Alumni who obtain their certifications and believe that Linux technical knowledge, unlike most vendor hardware/software products that change significantly with every version (many times, often purposely for marketing/forced upgrades/recertification) is perpetual.

3. Certification Date Is Relevant: LPI has also, since Day 1, stated that both Alumni and employers should take into consideration the date of the certification, and whether concepts from the examination version and period are relevant to today's new Linux capabilities that were not tested prior.

4. Minimum and Recommended Retake: LPI has always had the policy that no Alumni may retake any certification exams until they are revised, although it recommends Alumni retake certification exams whenever the objectives are revised. NOTE: This has been roughly every two (2) years, at least in the case of LPIC-1 (exams 101 and 102), which is the highest level approximately 90% of LPI Alumni have obtained.

Even with this new policy, these terms have not changed since Day 1. Several people have even gone as far as demonizing and proliferating rhetoric using item #4 (which is an abuse of such a Democratic process or any organization that listens to its providers and consumers), saying that LPI requires you to retake the exams every 2 years. This is not the case at all -- never has been, never will be! The recommendation, to retake the exams on every objective revision, has not changed since Day 1.

Since then, the policy has been augmented as follows.

A. ACTIVE v. INACTIVE Status: In 2004, LPI decided to introduce an ACTIVE and INACTIVE status for LPI Alumni. Alumni who have an ACTIVE status must recertify before their ACTIVE period expires. Alumni who have an INACTIVE certification (did not recertify before the date their ACTIVE period expired) must pass all lower and current exams again to regain an ACTIVE status at the same level.

B. Five Year ACTIVE Status: In 2006, LPI has instigated the following requirements for maintaining ACTIVE status:

- Certified prior to 2003 September 01: Must recertify by 2008 September 01 or lose ACTIVE status in database.
- Certified after 2003 September 01: Must recertify within a 5 year period after their certification.

Recertify: The recertification terms are clearly open right now, but will be better defined in the near future (see the next section on LPIC-3 and specialty developments). At this time, it means passing all of the exams at your current level, namely exams 101 and 102 if LPIC-1 and exam 201 and 202 (but not 101 and 102 again) if LPIC-2. In the near future (i.e., 2007), a new LPI Certified Level 3 (LPIC-3) and specializations beyond LPIC-2 will be available.

All of these new developments will be released well before any existing LPI certification becomes INACTIVE (the first date any would become INACTIVE being 2008 Sep 01).

The LPI Certified Level 3 (LPIC-3) and Specialization Developments

For more on the LPI Certified Level 1 and 2 (LPIC-1 and LPIC-2) tracks, see my 3 year-old blog entry on Linux Certification: CompTIA, LPI and Red Hat (from 2003 May). Unlike prior LPI certification levels, LPIC-3 is going to offer a set of options.

Although LPIC-3 has not yet been finalized, it is clearly the "Mastery" level. As such, broad, general exams used at levels 1 (Junior Administrator, equivalent to 18 months of full-time employment in an enterprise LAN/WAN/Internet environment) and 2 (Seasoned Administrator of 36 months) are not are easily applicable. LPIC-3 exams are going to be specific to technologies, more towards a Mastery-level.

Now not every administrator is going to have Master-level knowledge of every, major Linux technology and implementation. As such, LPIC-3 will be a set of elective exams. The first two (2) level 3 exams currently in development are Samba (and network filesystem-related services) and LDAP (and network directory-related services). At least four (4) other LPIC-3 exams are also being developed, but will be released later. Industry input is driving these two (2) exam choices for the initial LPIC-3 release.

So like prior levels, only two (2) level 3 exams will need to be passed to obtain LPIC-3 certification. For the initially available LPIC-3 track, only Samba and LDAP will be available. For subsequent exam releases, more options and combinations will become available. There is open speculation regarding whether a higher level title, such as Master LPIC-3 or LPI Certified Level 4 (LPIC-4), will be achievable upon release of all six (6) exams currently under development. First things are first, as LPIC-3 must become available.

But more realistically is the flexibility of the LPI program when level 3 exams become available. Specializations and other titles are options for those at LPIC-2. These specializations also become a draw in value for those approximately 90% of LPI Alumni who only obtained LPIC-1 and stopped, and reason to obtain LPIC-2. And given the recertification requirements to maintain ACTIVE status every five (5) years, just taking one (1) LPI level 3 exam, and earning a new specialization, becomes a direct way to recertify.

In fact, one could argue this is the best "continuing education requirement" offered yet in an IT certification program. Most professions require completion of "continuing education" every 5 years to maintain a certification or license, and most of these are under the direct ethic to force individuals to "learn something new." Taking a new LPI level 3 exam, and earning a new specialization in the process (let alone LPIC-3 after two level 3 specialization exams), is a great way not to just have people "take the same old exam!"

A program must continue to maintain a sense of "current value" to its certified individuals. LPI has always and will always recognize every Alumni who achieves any LPIC status. As LPI offers the LPIC-3 with its master-level of specializations, it opens up the opportunity to enforce real "continuing education requirements." And LPI has chosen to do so on a 5-year cycle, which is an accepted, "real world," non-profit/government certification/licensing practice.

Opinions from a LPI "Outsider"

I am a traditionally degreed engineer. Although I keep putting off my Professional Engineering (PE) license, one of these days** I'll bite-the-bullet and obtain it. And when I do, the "continuing education requirement" every 5 years or so becomes a reality.

[ **NOTE: I largely waiting for the National Society of Professional Engineers (NSPE) and various state Board of Professional Engineers (BoPE) to not only recognize software engineering as a legitimate, licensed engineering practice, but actually offer a true Practices and Principles exam for it. Until then, all I can take is the general, Electrical Engineering examination with 4 specialization options for the second half. Both the non-profit IEEE and the non-profit NCEES have had the course ware, examination materials and, most importantly, the attitude -- saying "it's time" for Software Engineering for the last 10 years, especially from a "safety" and an "in public interest" standpoint -- but the "bridge builders" must not listen well as they control much of the process (don't get me started). ]

In the IT certification world, which I largely loathe, the recertification process is largely a joke. After going several bouts with Cisco after taking all 5 exams of the dual-CCDP/CCNP track (not including the 2-exams for the pre-requisite CCDA/CCNA), Cisco informed me one of my exams was "too old," even though I only took it 3 months earlier. And if I want to recertify my RHCE, I have to take the full day, 6-hour lab exam all over again at full price ($750 in 2003). And if you think that's bad, I can't wait to see what Red Hat requires for recertification on the RHCA -- a 5-exam set of 3-6 hour lab exams!

Now those are the sets of exams from two (2) of the, maybe, three (3), "best" vendor programs out there (Novell being the only other vendor that offers lab or simulator-based exams). When you start talking other vendor exams, they are even worse. And that's before we even look at CompTIA, which only tests at an over-simplified "6-months of experience" level, let alone is heavily influenced by industry and training vendors.

There has been a lot of rhetoric flying about, even the word "proprietary," on this new recertification requirement to maintain the ACTIVE status. Many have started to question LPI's organizational decisions as of late. Now everyone should understand that the LPI leaderhsip and organization has changed over the past year or two. While I have nothing but good things to say about those who "got the process rolling" in the first 5-6 years -- from the founders and original leaders like Evan to the Pritchards to countless other volunteers, it was inevitable that LPI would gain enough "business mindshare" that industry factors would reshape it. This is required to keep the LPI organization moving forward, especially with all the additional and expedited developments that were always going to occur.

But the community is large enough that we can't always do everything in a "Democracy," and it's turning into more of a combination of "Meritocracy" combined with "Executive Leadership." Democracies are great, but they aren't always efficient -- and sometimes can be defeating. "Meritocracies" are definitely "put up or shut up" and you can be certain that with individuals like Matt running the exam development, he's definitely a "put up" type of guy. At the same time, you have to have "Executive Leadership" that finally "makes a decision" or otherwise things don't move forward -- and can (and often does) drop into a mode of "tit4tat" style rhetoric and political arguments. As long as that "Executive Leadership" consults the community, it works (and I'll let others argue whether or not this happened).

With that all said, I haven't really "put up" anything (really haven't had any time due to consulting work since the April committees in Boston), so I tend to "shut up" other than to point out these simple realities. I still owe Matt countless hours I offered, but haven't fulfilled.

Democracy v. Meritocracy+Executive

This is not the first time such an "organization" has been debated. The Debian Project clearly uses a huge Democracy of maintainers, with some Meritocracy, and even some Executive (but it's largely removed and has virtually no power in decisions). Most of Debian's "commercial decision making" base begins with the original Progeny corporation started by its founder, and is now the separate DCC Alliance (of which Progeny participates in).

I could not count on my hands how many times the LPI Discuss list has going through clearly "heated commentary" on MTAs (among countless other things). Why sendmail? Why this? Why not that? At some point, you have to pick what you can support, for whatever reasons. E.g., optional sectioning costs real money from Prometric/Vue for their computer-administered testing formats, and at some point, there has to be a decision on what 1 or 2 MTAs to support.

One of the beautiful things about Debian is the flexibility in kernel, GCC and GLibC -- essential the base ABI/API (Application Binary Interface, Application Programming Interface) in each release. It's also one of the major issues with Debian for industry. The DCC Alliance is standardizing the ABI/API for industry. Many have balked about this, but it's the type of "Executive Decision" I'm talking about.

Not to throw "Linux branding" into the mix, but with another, purely community-developed distro -- The Fedora Project -- Red Hat forces the base ABI/API (among other) aspects. There will always be one (1), fixed, base ABI/API per release. It gets specific to "get things done." It's not perfect, it's less flexible, and many people don't like the limitations. But for most of the community and all of the industry, it works and allows consistent releases in a timely manner that are well integration-tested.

There's nothing wrong with such things being done in the Debian world, and I hope we see more moves like the DCC Alliance is making on Debian. After all, Debian can continue to address the community better than a single vendor like Red Hat, at the same time, multiple vendors in the DCC Alliance can tie-down and make the Executive Decisions required to push things through to support industry. In the same regard, as long as LPI's Executive listens to its members and always adheres to the advice of its Meritocracy, built on the Democracy of its Alumni, it can serve both the community and its industry well.