Flash cards have always been a good way to go through questions. You get the question, provide a response and see if it's correct. That's the theory behind this little application. You can classify the question as difficult or easy, put as many as you'd like in the data file and quiz yourself. The application provides a way to keep track of the number of correct and incorrect responses, total number of questions, a button to randomize the next question and more. Requires: Perl, Perl module Gtk.
—David A. Bandel
This is a simple, lightweight web checker. If you run it with the --match option and match your domain name, it will not wander off on all the sites you might be linked to. You can have it mail the results or simply watch it traverse your site picking up the URLs. No more broken links, no matter how complex the site—at least none you don't know about. Requires: Perl, Perl modules File::Basename and LWP.
—David A. Bandel
If you're running a large mail server with thousands of users, Dbmail may be helpful. Users and mail are all stored in an SQL database; system users do not need to be created. The Dbmail program comes not only with dbmail-smtp, a receive-only SMTP dæmon (you'll still need sendmail or another MTA for outgoing mail), but also with dbmail-pop3d, a pop3 server, and dbmail-imapd, an IMAP dæmon. Instructions for setup are sketchy, so you'll need to figure it out for yourself. Fortunately, that's not too hard to do. Configuration includes things like POP or IMAP before SMTP. Requires: PostgreSQL or MySQL, libssl, libcrypto, glibc.
—David A. Bandel
In spite of the October 31, 2002 feature-freeze, developers continue to hack on their favorite projects. December saw a number of such developments, some weirder than others. In the POSIX realm, Krzysztof Benedyczak and others did some work on implementing POSIX message queues to allow processes to communicate more directly with each other. Linux always has maintained a love/hate relationship with POSIX (and other official standards), sticking to the principle that bad ideas should be avoided whether they have an official seal or not. Message queues have not been particularly controversial in the Linux arena, but the UNIX world at large has not always agreed on the proper public interfaces for them. So whatever the ultimate Linux message-queue implementation, there will be permanent issues surrounding attempts to port any applications that use the feature.
Drivers for new hardware are churned out constantly, development series or no. December saw several new drivers for Via cards (the 8633 AGP and 8233 onboard sound card) from Nathaniel Russell and a framebuffer driver for the Intel 810 and 815 graphics chips from Antonino Daplas. Overall the framebuffer code did not fare spectacularly well in December, though many patches and advancements were made. Part of the problem is the basic framebuffer design makes assumptions that simply are not true for certain hardware, and the design issues are hard to correct because a lot of user-space code relies on the existing implementation. But James Simmons has been quite active in addressing the issues that can be addressed, and a lot of work by him and others will be in the 2.6 framebuffer code, including some fancy new APIs.
A whole new architecture saw the light of day in December. After a month's intense labor, Andrey Panin ported Linux to the SGI Visual Workstation. Some might say, as Alan Cox did when Andrey announced his work, that such an effort belonged truly in the land of dementia. After all, the VISWS was apparently a flash in the pan, appearing briefly a few years ago and then dropping off the map. But Alan still applied the patch.
Intel's sysenter and sysexit instructions, introduced way back with the Pentium II, finally are starting to find support under Linux. Theoretically, they provide a quick way to perform system calls, but in practice it proves difficult to find an implementation that doesn't sacrifice too much of the speed the instructions are intended to save. A lot of progress was made in December, but this is all quite invasive work, and as Alan Cox has said, Linus Torvalds appears to be “doing the slow slide into a second round of development work again”, as was the case with all other development series.
Speaking of invasive work, it looks as though Andre Hedrick's new IDE subsystem will be dropped en masse into the 2.4 kernel. Normally such an invasive change would be attempted only during a development cycle, but apparently the old IDE code is too nightmarish to live. News of the new IDE code's imminent acceptance into 2.4 was greeted with shouts of jubilation from all sectors. Quite a different reaction from Linus' decision to drop a new virtual memory subsystem into an earlier 2.4 kernel.
In the final months of 2002, some folks decided to set up a Bugzilla database to help bring 2.5 to a successful, stable conclusion as soon as possible. Not all developers feel that Bugzilla is the best tool for the job, however. Since the bug database was first set up, it has proven difficult to use in certain ways. Bugs go unclaimed, and developers have trouble finding references to bugs in their areas of interest. In light of this, John Bradford decided to start from scratch and implement an entirely new bug-tracking system, designed specifically for the Linux kernel. He chose to focus on automating much of the search facility and enhancing the organization and presentation of bugs to streamline the ability to find bug reports in any particular area of interest. That said, the existing Bugzilla database has its adherents, and as of the end of December 2002, John still had not put together a fully usable replacement.
This is an extremely difficult game but includes its own tips, hints and tricks manual. You can download this game or play it right on the Internet. It can be invoked as a jar file for a standalone game or called from any Java-enabled browser. If you're like me, you'll have tiles all over the place and be no closer to a solution than when you started. Requires: Java.
—David A. Bandel
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
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
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