I've been deeply involved with MPEG for several months now, so your article on MPEG-1 playback programs caught my eye (LJ May 2001). I found several factual errors about MPEG in the article.
First, MPEG-2 video does not necessarily have better video quality than MPEG-1: the differences between the video portions of the MPEG-1 and MPEG-2 standards are fairly minor. An MPEG-1 file with a 720 x 480 frame size, compressed to 6 Mbit/s is legal, and will be very similar in appearance to a 720 x 480 6 Mbit/s MPEG-2 movie.
Second, the author states that “not all MPEG-1 files are entirely `compliant”'. The MPEG standards define what a compliant decoder is expected to be able to handle, but not how a compliant encoder works. In other words, a compliant decoder is not one that is “tolerant”, but is instead one that adheres closely to the letter of the ISO 13818 standard, so as not to be surprised by the output of a novel (but legal!) encoder. Unfortunately for free software authors, these documents are expensive: the basic set of MPEG-2 PDFs (ISO 13818-1 through -3) costs $424, and the complete set is $1,390 (from http://webstore.ansi.org/). It's little wonder that commercial MPEG products far outstrip free ones' capabilities, in nearly all cases.
Third, the author states that an “MPEG-1 audio stream...is an MP3 file”. This is not always true, and is not even likely. MPEG-1 defines three different audio encodings (or “layers”). Layer I audio is the most basic, but it isn't used very often. Layer II is the most common: video CDs and MPEG files you download from the Internet almost always use Layer II audio. Layer III (aka MP3) is optional, so most MPEG decoders don't include support for it. Since few decoders support Layer III audio, most encoder creators also don't bother including support for it.
Just a note to let you know that the certified sword cuts both directions (Editorial focus, LJ May 2001). As CIO of a multimillion dollar corporation it is my job to not only run the IS department but to hire and fire employees. One of the first questions I ask is if the prospective employee has any certifications, if so I politely tell them “I'll let you know if we can use you” and promptly throw their application into the garbage can.
Before you ask, no I am not certified. I have however taught pre-MCSE classes at Unisoft Institute of Technology in Houston and was horrified to learn that I had to teach the way the test worked, and the way the real world worked (pre-MCSE in this case really meant A+ and Networking certification). This effectively meant that I held two classes in one, which to say the least was difficult. Additionally, long ago before computers were my profession I was an ASE-certified mechanic. Since I have passed 10 ASE certifications I can tell you that they are just as much a joke as computer certifications. I quickly realized that even holding all the certifications I did, and after graduating from a top automotive technical school with a 4.0 GPA and Alpha Beta Kappa National Honor Society, that I was not a very good mechanic.
To me, being certified means that the person does not have enough knowledge or experience to get the job on their own merits and hopes that this piece of paper will help them, and it does not. In my experience the only time certifications help you is when you are applying to a business where the person responsible for creating hiring policies is not a real computer technician.
I am forced to deal with MIS and IS degrees from recent college graduates as well as a plethora of certifications on a regular basis. Unfortunately, I have found that the people who have neither a degree nor a certification but who have been working with computers for ten years are much better equipped to handle the job. At least if they are inexperienced I can teach them the way things really work instead of attempting to retrain them after they have their degree or certification.
I very much enjoyed the April 2001 Linux Journal article “Linux on Carrier Grade Web Servers”. You did a nice job of describing the software choice, hardware environment and test results. I look forward to future articles discussing the other LVS implementations (direct routing and IP tunneling) and comparing their stability and performance with that of the NAT implementation.
I enjoyed your articles on Linux Certification (LJ May 2001). I thought the “real-life” experience was very telling, although perhaps toned-down a bit to protect the vendors.
Here's my thoughts on what I read:
We can earn an extra $10K per year by becoming certified? Really? Who can? New grads? Having worked on, supported and/or maintained SVR4, AIX, HP-UX and Solaris for twenty years, I can't imagine getting another $10K just because I had some Linux certificate.
I looked at some of the questions from Red Hat's and Sair's study guides and tests. What a crock! “What's the fdisk type code for a Linux swap partition?” Who cares?! Look it up by typing l to list the types. Forgot that command? Type ? to list them all. Better yet were the impossible to understand questions and answers on Sair's test. Their “correct” answer for wc -l * is that it returns the total number of lines in the files. Gee, my experience is that it shows the line count for each file, followed by the total, but that answer isn't available. Yes, they want the entire Linux community to help improve the tests, but if they can't get the simple things right, I'd hate to see how they do with the hard topics.
Finally, the exam companies could learn a good lesson from the FCC and ARRL. The amateur radio exams are also multiple choice, but they are composed of a certain number of sub-elements. Each sub-element has a number or required topics. Each topic has a number of published questions and answers, with references to the rules and regulations. The effect is, the actual exam might have only 25 questions, but those questions are pulled from a pool of several hundred, and each critical element is covered.
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
- Returning Values from Bash Functions
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- 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