Stampede Linux was created because of our dissatisfaction with other distributions. We found that while other distributions had many useful features, none of them had everything we wanted. While the development team recognizes perfection is an unachievable goal, the driving force behind the development of Stampede Linux is to create a perfect distribution.
The Stampede Linux Project was founded by Matt Wood, who heads the development team and is the backbone of everything relating to Stampede. His original intention for Stampede was for it to be a Pentium-compiled rebuild of Slackware—a private distribution for use by himself and a couple of friends. However, Stampede has grown to be much more; it dropped its Slackware ties early in the development process.
Perhaps the most frequent question we're asked during this development period is: “Why another distribution?” Several reasons provide the answer:
None of the current distributions are optimized for newer machines. We don't believe Pentium/Pentium Pro/Pentium II/K6 machines should be running code written and optimized for 386 or 486 machines. All of Stampede's binaries and packages are compiled using the Pentium GCC Compiler.
There isn't a distribution centered mainly around up-to-date and current packages, as well as security. We believe that having a secure system (in conjunction with updated packages) is the only way a distribution should be created. Rather than giving the user the option to install packages to increase security, Stampede will be as secure as possible, and give the user the option to install packages to decrease security.
Although most distributions are fairly easy to install, we find that for the new user they aren't easy enough. If the Linux revolution is going to take place, simpler and more intuitive installation and configuration programs must be developed.
These reasons have led to the implementation of several key features. First off, all packages are compiled with the Pentium GCC Compiler, a variation of the GCC Compiler with optimizations for Pentium class chips. This is important because PGCC increases performance of a Pentium-compatible system and usually results in a 10-30% faster system. The Pentium GCC compiler is also fully compatible with i386+ processors and clones. (Information on PGCC can be found at http://www.goof.com/pcg/).
All Stampede stable binaries are also compiled without debugging (-g) information, delivering a smaller, faster binary. We are considering the release of a separate package which includes debugging information, for those who want it.
Stampede Linux also uses gnulibc2 (libc6), a much faster version of the standard C libraries. This version includes a more stable interface, thread-safe functions, an improved math library, new functions from POSIX and XPG4.2, and is 64-bit clean. However, it is still under development and is available only for GNU-based (both Hurd and Linux) systems. More information on GNU libc can be found at http://www.gnu.org/software/libc/libc.html.
The Stampede Linux Package (SLP) Management system is also progressing quite nicely. Unlike some other distributions, using this package is totally optional. If you wish, you can stick with gzipped tar (or bz2) files and not use the SLP files. However, we believe that most users will want to use the package format because of its portability. The development team plans to have automatic upgrading of packages implemented by version 1.0 of Stampede.
Stampede plans on using BSD-like init scripts to configure all of the system run-level maintenance, but developing these scripts does not yet have a high priority. Even though these scripts are easy to configure, we still plan to create a set of configuration tools which allow a simple, straightforward way of setting up and changing the init scripts.
Another feature worth mentioning is the boot/root disks. With Slackware, finding and downloading the correct boot disk seemed to annoy almost everyone on the development team. So, we have decided to create a third disk, a modules disk. Anything that can be compiled as a module instead of being built into the kernel will go onto the module disk. This will include CD-ROM, Ethernet and hard disk drivers. Doing this should make it easier for newcomers to Linux to find the right boot disk.
The setup program is also notable. We have designed it in such a manner that it auto-detects the packages on the source media, and then asks you which ones to install. This method makes it much easier for us to add and update packages and package sets, as well as for the user to create or install their own. There will also be an option to select from a number of different automated installs. This will be a big plus for those who are new to Linux, and also to those who prefer not to answer questions during the install.
The development process of Stampede is quite unique. The Stampede Linux development team consists of people in different areas of the world who collaborate their efforts over the Internet by e-mail and IRC. While it does happen that tasks are assigned to certain individuals, most of the time one of us comes up with an idea, or gets one from a user or mailing list, and then works on it. If it gets the official okay from Matt, it goes into the distribution. Personal preference is a factor in determining which tools and programs we choose to include in the distribution, but we try to create and include programs which are easy for the new user, yet powerful enough for the more advanced.
During this development stage, we try to maintain a good balance between functionality and stability. We feel that as long as a program isn't too buggy or awkward to the user, it is worth including. We don't stick with software just because it's in other distributions. We realize that by using programs such as gnulibc2 and PGCC, and our new package format, we are taking a potential risk that users who have become accustomed to the older software may run into trouble at this time. However, we believe the advantages greatly outweigh the disadvantages. We also have confidence in our method because of our plans for SLP. With the automatic package updating mentioned earlier, there should be no problems.
Like other computer programming projects, we have obstacles we are trying to overcome. One of the main obstacles we face in our development is that all testing must be done on our own personal computers. Since at this point we have no money to buy equipment, it is hard for us to test Stampede on different computers. We need testers with different equipment. However, we still plan to become a non-profit organization, dependent on user efforts and donations to help us further development.
Odd bugs seem to be giving us a lot of trouble at this time. Since we can't always tell whether something is going wrong because we placed it in the incorrect place, compiled it wrong or coded it badly, it is hard for us to find bugs in the actual software. Thankfully, this seems to be less and less of a problem as development progresses and the system becomes more stable as a whole.
Any and all ideas given to us are taken into consideration. If it is worthwhile to the user to have in the distribution, it is worthwhile for us to include. It's hard to say what we have planned for future versions, because any new idea we have, we try to squeeze into version 1.0.
However, here are some things we hope to see in Stampede's future:
Ports to different architectures: we recently found someone to help port to SPARC, and we also have members of the development team who plan to start on a Power PC port.
A central system configuration utility: this will most likely be for the X Window System, written in GTK (which all our X utilities use). It will include sections to add/remove users and groups, configure the init scripts and much more.
A more automated package update process: as mentioned earlier, automation is something we strive for, as we believe this will not only help new users, but will also give experienced users less worry. We are beginning development of the Stampede Linux Package Daemon (slpd), which will optionally query a central server at given periods of time and check for package updates, then download and install them.
Development of Stampede Linux is moving ahead at an incredibly fast pace. We have a very talented team of developers, and all are devoted to making Stampede Linux the best distribution available. The creation of Stampede is only 50% coding, because putting it all together and making sure it all runs smoothly has proven to be an equally big task. However, we take things one day at a time and deal with each obstacle as it comes. We aren't in this for the money or to outdo anyone. We are fully supportive of the Open Source cause. We simply want what you want—a distribution that is fast, stable, secure and robust. It is our goal to prove that there is always room for improvement.
David Haraburda (firstname.lastname@example.org) is a Linux fanatic who currently resides in Fort Worth, Texas. Information on him and the other developers can be found at http://www.stampede.org/people.html
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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