Mandrake held its number-one position in total downloads (measured in MB) from Tucows in March. Even though it's down a couple of points from its January high, it still accounts for over a third of the downloads total. Red Hat held even with 15% at #2. Corel slipped a point to 12% in the #3 spot. Phat Linux dropped three points, but still held the #4 position at 10%. Debian and SuSE follow with 5% apiece. The rest are between 3% and 1%.
What were Linux people talking about in March and early April? Below is a sampling of some of the hotter news stories over the past few weeks, as reported in “The Rookery”, Linux Journal's on-line source for news, notes and reports from the field (updated daily and found at our web site http://www.linuxjournal.com/):
Federal court ruling that Microsoft violated anti-trust law, and the ensuing class-action suits filed against Microsoft. Also, discussed quite elegantly in Bryan Pfaffenberger's article “Guilty! What's Next for Linux?” (http://www.linuxjournal.com/articles/currents/018.html).
Sixth Circuit Court's finding that source code is a form of expressive, as well as functional, speech.
IBM's dumping of Red Hat stock. What's that about?
Caldera's IPO, disappointing or realistic, seems to be a matter of who you talk to.
W. R. Hambreck & Co. giving a “buy” ranking to VA Linux.
InterVideo's claim to have the “first legal DVD software solution for the Linux OS.”
The coming showdown between Linux and Windows in the embedded systems market.
Hello, and welcome yet again to another episode of Stupid Programming Tricks! Last month, which I hope you didn't miss, we got a wee bit complicated, making a sine scroller by plugging sine functions into each other. The process involved lots of variables and functions, and really taxed the processor. This month, it's time to relax a bit from complicated things, but nevertheless we'll do something cool, and it will involve sines.
Former demo-sceners may have noticed a trend in this column: that much of what we do is passed down from a certain tradition. Where is the 3-D <\#224> la Quake? Where are the filled vector graphics? Where are the trippy acid effects? Alas, your amiable author missed the PC scene for a short-lived adventure in, well, something else, before discovering Linux, so we still believe a demo should have a scrolltext and that 2-D is okay. Now, we've done more with scrolltexts than most people can stand; however, there is a tradition just as ubiquitous as the scrolltext, and probably even easier: the raster bar.
A raster graphic is basically a bitmapped graphic (as opposed to a vector graphic), thus a raster bar is a bitmapped graphic of a bar. Usually we draw these bars with cool, shaded colors, so that they look like horizontal pipes or laser beams, and we make them bounce up and down on the screen, which looks rather cool. What is the point of such bars? There is none! Well, actually, sometimes it's to show off the computer's colors; sometimes to delineate different areas of the screen; sometimes it's just to add something interesting and technological to look at. When the palette is properly set up, the bars can look like shiny metallic pipes or perhaps glorious rainbows. You can even scroll the colors inside of raster bars for all kinds of funky effects. You could sync the color scrolling to the vertical position of the bar, as though the passing raster bar uncovered hidden colors in the screen. You could cycle the colors in numerous ways inside the bar (turning blue pipes to purple, red, orange, yellow, green and back to blue), or you could pass colors between several raster bars on the screen.
Another clever trick is to include a scrolltext inside of a raster bar. This has numerous advantages; for one thing, you don't have to worry about making sure the background shows up properly in the black space underneath the letters, since you're filling the whole thing up with raster color. You don't need to clean up areas before writing with raster bars, because the bars overwrite whatever's there initially. And, the colors of the raster bar can highlight the text like a high-energy laser beam.
One influential demo for me on the Amiga was Hot Copper by Acro of Rigor Mortis. It used several large raster bars of different colors scrolling up the screen and then falling down again in order to display several different scrolltexts of varying speeds with different text. In the days before the Net as we know it, words were rare and meant much more; scrolltexts were like messages in bottles found at the beach, greetings from faraway shores, by people you actually knew! How did the text travel so far? Who passed what disk to whom at what party, how many boards did it go through, how long until it got to you? If only Amiga emulation weren't so harassed by copyright zealots, we'd have a more open time enjoying these (the Amiga ROMs are still copyrighted, but at least the demos aren't). Alas, I degenerate.
We're going to make six bars, each 320 pixels wide by 17 pixels high. Each bar will get to use nine colors, running from darkest at the top to lightest in the middle and dark again at the bottom (that's eight colors which get used twice in each bar, with one bright color right in the middle). This makes the shiny, pipe-looking effect for our bars. In honor of Roy G. Biv, we'll have red, orange, yellow, green, blue and purple bars, even though logically we should use red, yellow, green, cyan, blue and purple. Of course, cool Commodore coders made rainbow bars, but they're too cool for us. Still, we are fairly daring in our own right; after all, we're using “runs-as-root-can-really-destroy-your-system” SVGAlib. Let's look at our algorithm.
Step one is to draw the bars. We'll make six arrays to store our six different bars: redbar, orangebar, yellowbar, greenbar, bluebar and purplebar. We could dynamically allocate the memory, but why bother, since we already know the size of our graphics? Well, it's in case we change graphic size, but let's be lazy this time around. First, we have to set the palette properly, so we'll do nine shades of red, nine shades of orange, nine shades of green, nine shades of blue and nine shades of purple. A simple loop fixes this, rendering 54 colors total, starting at palette color #192, because it's nice to save the earlier palette colors in the event we add something else. Once we've set the palette, we draw the red bar in red color, store it in the redbar array, then loop through and do the same for the other colors. When we're finished, we'll have six bars in memory, ready to be blitted wherever we like!
Step two is to draw the bars on the screen in our never-ending loop of joy. We'll set a loop that increments a variable called X, needed because the vertical positions of our bars will be based on a sine function of X, shifting the phase a bit for each bar so that we get a wave-like effect (instead of having every single bar on top of the other). We'll draw the bars, starting with purple and working toward red, hold the screen still for a vertical refresh (usually 1/60th of a second), then clear the screen and repeat the loop until someone exits.
Raster bars, alas, have little practical value; in fact, they're an epitomic cliché, but I sincerely hope we can continue this cliché into the 21st century and beyond. Perhaps we should put raster bars in rocket ships and send them out into the galaxy as evidence of our civilization...
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)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
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