Linux 2.2 and the Frame-Buffer Console
One of the largest downsides of the new kernel driver system, and the one that has been getting the most attention, is the question of stability. Will these new frame buffers impact the outstanding uptimes of modern Linux? The answer is simply no. One of the glorious things about Linux is that you are generally never forced to do things you don't want and disabling the frame buffer is as easy as a recompile (if the distributions even ship with it by default—something I highly doubt).
It is my opinion that Linux developers reach a higher standard than some other software developers do. (This might explain why I've never gotten anything more than teeny bits into the kernel myself.) Even in a worst-case scenario, a rampant kernel module is only somewhat more dangerous than a rampant “setuid root” X server. People accept that risk daily.
The new driver system has less supported hardware than its legacy counterpart. Additionally, the supported hardware is generally in a sub-optimal or non-accelerated position. In contrast to XFree and to a lesser extent SVGAlib, that is an order of magnitude less support. The video subsystem today is a lot like the sound subsystem was yesterday, i.e., it supports very few cards. With time and patience, developers will no doubt make this new system as robust as possible.
Also, the frame buffer is not meant to be a generic base for an acceleration architecture. While it is likely that better acceleration will be provided in the future, we may have to wait until that becomes generally available. Alternately, it is quite likely that the GGI project (General Graphics Interface at http://www.ggi-project.org/) or some organization will propose and implement a workaround to this situation. Once again, due to the newness of the system, not all answers are immediate.
Red Hat 5.2 (which I use at home and at work) already includes support for the frame-buffer X server, FBDev. If you are experimenting with this feature of Linux 2.2 and have Red Hat, this will save you a download/compile cycle. Unfortunately, at this time there is no easy way to configure this device; I recommend consulting the documentation. Red Hat 6.0 may include this feature or make it easier to use.
To those who want to jump right into the frame-buffer console, an option exists that works with nearly all VGA-compatible video cards: the VesaFB driver. It does require a VESA 2.0-compatible BIOS. This driver is not a good example of what the new features of Linux 2.2 can do, but it does allow one to get her feet wet. In particular, it lacks support for resizing the screen resolution and it requires the mode to be changed at boot time. In reality, this driver is meant only as an example driver and your mileage may vary getting it into production work. Users of Linux on other platforms may have a better idea of how things should be in the end.
Joseph Pranevich (email@example.com) is an avid Linux geek and, while not working for Lycos, enjoys writing (all kinds) and working with a number of open-source projects.
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!
- SourceClear Open
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- Parsing an RSS News Feed with a Bash Script
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Managing Linux Using Puppet
- 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