TLDP is short for The Linux Documentation Project, an organization of volunteers authoring, reviewing and managing documents about the Linux operating system. Documents basically come in two formats based upon their length. The shorter ones generally are called HOWTOs (or mini-HOWTOs, if they are really short), the longer documents, called guides, deal in-depth with a Linux feature.
The number of topics discussed in these HOWTOs and guides is practically unlimited, ranging from installing the Linux system to managing all kinds of devices, services and environments, to creating your own system from scratch. Name any topic, there's something about it in TLDP, mainly thanks to volunteers who share their experiences.
All the documentation is freely available in several formats suitable for printing and on-line browsing. The main submission language is English, but several translation efforts, including French, German and Chinese, try to make this immense amount of information available to a wider public.
Linux environments tend to change at a rather high speed, so do the docs. Sooner rather than later, submissions about new protocols and applications reach TLDP, outdating older documents. The main problem here is TLDP maintainers usually are rather soft-hearted, so partly out of melancholy, partly out of respect and sometimes partly because of the lack of volunteers for upgrading a document, they tend to archive everything.
Given this information, it might thus be best to stick to the following golden rules when searching the LDP collection:
1. Check the revision date on a document. If it's older than a year, don't depend on it too much.
2. Check that a document is being updated regularly; this is an extra sign that it is being maintained seriously.
Most documents contain revision history information in the preface.
As Matt Welsh, one of the co-founders, puts it: "The history of the LDP is a pretty murky memory these days." It started in 1992, before the World Wide Web existed. It's hard to imagine how we did without HTML, but in those days almost everything was FTP and Usenet and dial-in to a BBS was most likely. In the beginning, most of the documentation was in one big file, split into sections, called the Linux FAQ.
Later, Matt got together with Lars Wirzenius and Michael K. Johnson, who had the idea of producing printed Linux documentation. Michael initially started on a kernel hackers guide, Lars did the system administrator guide and Matt wrote the first installation guide. Everything was done in LaTeX, so the only way to read these docs in a reasonably comfortable way was either by printing them out or using a PostScript viewer.
But as Linux capabilities grew, it was no longer possible for one person to maintain everything. Pretty soon, not even several people could manage the job. Thus, the HOWTOs were born, each describing a part of the original big chunk of information. This created an easily extendible system that allows for many authors to contribute to their areas of specialization.
That effort lead to the use of SGML, which enabled the fast generation of all sorts of output formats, including HTML, from one source file or set of files. The first tests were conducted at Sunsite (a famous server machine at the University of North Carolina), which was the first Web site offering information about Linux. Also, when you wanted to download Linux software, Sunsite.unc.edu was the place to go. It still contains some kernel archives--probably by accident, there also are a lot of empty directories these days.
Before the crash (May 2003) I was able to find, via FTP, a document referring to two maintainers of the LDP as it was run by the end of 1994 at UNC. It pointed to Jon Magid and a mysterious Erik with no last name, who was still at Sunsite in 1996.
After extended research in the dungeon server rooms of Google, we can state with almost certainty that the mysterious Erik does have a last name after all. Most likely, we are dealing here with the Erik Troan, who supported possibly half of the Linux users in the 1993-1996 period and later on became the Senior Director of Engineering at Red Hat.
Further research revealed that sometime in 1996, Greg Hankins became supervisor of the LDP project. He was the original author of the Serial HOWTO, which he began maintaining in 1993; he also was one of the main contributors to the SGML-tools development project.
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
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- 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