Google's Mike Waychison has posted some patches to organize Google-specific firmware used in its servers. These patches were met with approval by Alan Cox and Greg Kroah-Hartman, although Google's servers remain unavailable for purchase by the public. Perhaps that will change soon.
Chris Wright officially is no longer on the stable kernel team, and he has not been involved in that project for some time. Greg Kroah-Hartman will continue his effort to release several short-term stable versions of each kernel, during the intervals between official releases from Linus Torvalds. Long-term stable trees in the 2.6 series are maintained by Andi Kleen, Willy Tarreau, Paul Gortmaker and others.
The ancient versioning system, CVS, still is being used by some kernel developers in spite of the advent of git, and Sebastian Andrzej Siewior recently posted a patch supporting those developers. His patch took out all the stale CVS $Id$ tags sprinkled throughout the kernel that were confusing CVS. Apparently, some developers are syncing the kernel sources from git and then feeding the whole tree into a CVS repository before working on it—bizarre. But, it's a great testament to the hardiness of CVS after so many years and so many attempts to find something better.
A recent bug in SysFS allowed regular users to overwrite NVRAM. Vasiliy Kulikov's patch to close the security hole had taken more than a month to be incorporated into the kernel. In light of that, he's posted a patch to give the system administrator the power to mount the SysFS directory as read-only. This blanket protection would not be in effect at all times, but it would give administrators the ability to lock down that part of the system in the event that a similar bug were discovered. The problem, as Greg Kroah-Hartman points out, is that locking down SysFS may produce other unanticipated problems, and he feels the right approach simply would be to fix SysFS bugs as they occur, rather than add a blanket layer of security over it. The debate is unresolved at the moment and could play out either way.
Huang Ying recently posted some code to cause unknown non-masking interrupts (NMIs) to crash the kernel and produce a panic report. But, part of the problem is that a wide array of systems produce unknown NMIs for no reason at all. Huang's solution was to create a whitelist of systems that were known not to do this, and his patch would work only on that whitelisted set of systems. But, Ingo Molnar suggested using active event filters to allow unknown NMIs to go through a localized policy decision-making process first, so the decision to panic the system could be made on a per-system basis.
Active event filters, as Ingo pointed out, would allow a certain portion of the decision-making process to occur while still in kernel space, without having to return to userland. This is key, because when the system is crashing, it often is not feasible to pass control over to a user-space program. But in the case where the active event filters determined that a crash probably was not occurring, they could hand control to a user-space dæmon that would make additional decisions about how to handle the unknown NMI.
Active event filters apparently are tremendously powerful and soon may be seen in use throughout the kernel as a way of standardizing a number of disparate behaviors that currently are handled in an ad hoc manner.
Engineers are some of the heaviest number-crunchers around. If you are a grad student, post doc or undergrad, you usually get whatever is lying around as your work machine. Also, depending on how inflexible your local IT department is, you may be forced to use one of the commercial operating systems around these days. What are lowly students to do when they need to do heavy computational work? You may be interested in looking at CAELinux (Computer Assisted Engineering, www.caelinux.com). This project provides a live CD that gives you all the open-source tools you might need for your engineering work. And, because it is a live CD, you can use it without touching the local drive of the machine you are using.
Like all live CDs, it has all the standard Linux desktop tools you should be familiar with, including Firefox for Web browsing, Evolution for e-mail, and OpenOffice.org for word processing, spreadsheets and presentations. Along with these applications, there are dozens of others to help with all your number-crunching work. The most recent versions are based on Ubuntu, so it should be a fairly comfortable environment for most people. Be aware, however, that you can't use the usual software update mechanism in Ubuntu. Many of the packages in CAELinux are compiled from source and optimized, so you don't want them being overwritten accidentally by any packages provided by Ubuntu.
A really well written introduction to CAELinux is available right on the desktop, called “Getting Started”. You should start here if this is your first step into the world of CAELinux.
Last month, I looked at OpenFOAM in this space. CAELinux includes a full install of OpenFOAM. It also includes another fluid dynamics program called SALOME. This program provides a full graphical interface that takes you from forming your problem, to modeling, to calculation and through to analyzing your results. This might be a good choice for those who are more comfortable with a GUI. A series of examples on the desktop are available that provide a walk-through of the program, showing each of the steps as you go through.
As you can see, the tutorials walk through several common simulations, like modeling flow through a pipe. These can provide great starting points for many people.
If your work leans more toward data analysis, several popular packages are available. For all of you Matlab addicts, there is Scilab. Scilab provides the same types of functions in an environment familiar to Matlab users. There also is Maxima, which provides tools more from a mathematical background (for example, analyzing functions and doing calculus), as compared to Scilab's approach of working from a matrix background (such as looking at data analysis). Maxima has several front ends available. The default one in CAELinux is wxMaxima. If you are doing really heavy statistical analysis, there is R. The real power of R is the CRAN repository, and a fair amount is available out of the box. R also has several graphical front ends. CAELinux provides two: R Commander and RKWard. If you are doing work more along the lines of pure mathematical analysis, there also is Octave. The default GUI available within CAELinux is QtOctave. In all of these cases, text-based interfaces also are available, if you are an old-style computer user who prefers that kind of thing.
Several software packages exist for applications other than CFD or statistics. If you need to do finite element analysis, there's elmer. It provides both a text-based and GUI interface. There also is JavaFoil, available for doing analysis on airfoils and wings. If you are designing electrical circuits, two packages are available. Electric is a CAD program that helps you lay out a circuit. And, once it is all laid out, you can use PCB Designer to get it set up so you can etch a board to make it real.
This is all fine and good if you can use a standard toolset in your work. But, what if you need computing power for really cutting-edge research? CAELinux provides the entire GNU toolset. This means you have everything you need to go ahead and start developing your own code. All of the most common scientific and engineering libraries, like gsl and LAPACK, are available. If you are working on really large problems, MPI and openMP also are available. This way, you can develop a parallel programming solution if that is what your problem needs.
Once you have finished all your calculations, an important part of data analysis is graphical analysis. There is something visceral and instinctive about actually seeing your data represented. To this end, CAELinux provides several packages. If you simply want to plot your data, you can use programs like grace and LabPlot. If you want to do more complicated data analysis, you have programs like G3Data and OpenDX Data Explorer. These programs have lots of functionality that can be used to look at your data graphically. If you are doing CFD work, several programs for visualizing your meshes are available. So, you have your choice based on what features you need.
The last option to look at this month is using CAELinux in “the cloud”. Cloud computing is one of those sexy terms that gets used a lot in marketing, but it sometimes doesn't really give you anything useful. In this case, there really is something substantial being offered. CAELinux now can be run as an application under Amazon Elastic Cloud Computing. You can now run, on demand, as many nodes as you like, each having eight cores and 64GB of RAM. For people who don't have the resources to run their own clusters, but need more than what a desktop can handle, this can be a very attractive choice. It definitely is worth looking into as a possible option. You can find more information about EC2 at aws.amazon.com/ec2, and the CAELinux Web site has a very good set of instructions to get you up and running.
As you can see, CAELinux provides a lot of power and functionality for doing computational science. Because it is a live CD, you can run it on essentially any 64-bit machine without touching the hard drive. But, you also have the option of installing it on the machine if you are allowed. Download an ISO and start playing with it to see just how much work you can do with it.
Digital music and, more recently, digital video and digital books, have changed the way we consume media. Comic books are no different, and with the advent of tablet computers, digital comics are becoming more and more popular. If you don't have a tablet computer, however, viewing CBR (or their compressed version, CBZ) files is as simple as installing a CBR reader and downloading your favorite comic.
Many comic book readers are available for Linux. A quick Google search will turn up programs like Comix, ComicMaster and Comical, all of which display digital comics quite well. Another search likely will turn up some free comic resources, like the one shown here: Cory Doctorow's Futuristic Takes of the Here and Now. If you miss the comic books of your youth, or if you still enjoy them on a regular basis, you owe it to yourself to check out CBR/CBZ files.
No, I'm not talking browncoats and spaceships. Unfortunately, that ship has sailed. If you're the musical type, however, installing a Firefly Media Server is fairly simple. It was renamed from mt-daapd, so your distribution still might call it that. After a quick install, visit the Web configuration, usually at http://localhost:3689 with the default login mt-daapd and password mt-daapd. You can configure your music location, smart playlists and just about every other aspect of the media server. Then comes the cool part.
On any software or hardware on your network that supports daap (often known as the iTunes protocol), you should be able to play your music remotely. Firefly does a decent job of scanning your music collection and updating the clients on the network. You can add m3u playlists, and Firefly will serve up playlists as well.
I find the best way to listen to music on XBMC is via daap. It makes configuring playlists and adding media simple. It's also cross-platform, so those folks using actual iTunes can listen to their tunes as well.
Sometimes, you just want a simple word processor. Yes, there are many options for word processing, from the awesome OpenOffice.org to the awesome-for-other-reasons vi. If you're looking for a happy medium, however, it's hard to do better than AbiWord. When you add the free on-line component, AbiCollab.net, you even can collaborate with other AbiWord users on documents.
AbiWord is available for Linux, Windows and even OS X. You need version 2.8 or higher to use AbiCollab.net, but most distributions include at least version 2.8. Check out the Web site at www.abisource.com.
Did you learn all your Linux console skills from books or from forums? Or, did you peek over someone's shoulder to see the real action? Once in a while, we stumble upon new projects that deserve some attention, like Playterm (www.playterm.org). What's the reason for this command-line “peep show”? To spread GNU Linux command-line knowledge.
You will see a fair amount of on-line terminal recordings when you enter this site. The recordings cover several topics performed in the shell: tricks, one-liners, guided tutorials and handy utilities.
Personally, I found them quite entertaining to watch, and it brought me back to the BBS days. It can be educational, and also quite hilarious to see people making typos and mistakes.
Another interesting Playterm feature is the embed facility. You can upload terminal recordings on this site, which you then can embed and play on your blog or Web site. Optionally, you can allow commenting on your recordings, which, of course, will provide interesting hints and tips and other improvements.
The Coder of Salvation (Leon van Kammen) created Playterm because he was just too curious about what people were doing in their terminals. He used to work for a company where he did extreme programming sessions with his colleagues through the GNU screen -x utility. In his experience, it is extremely educational when you work together in one terminal (and also entertaining). In his opinion, console-related books and articles are great, but sometimes it can be more helpful to see gurus at work. If it were up to him, more command-line projects should feature a terminal player on their sites: “Why not? Why have only a tar archive on a site? Developers should make more demos to show the world how cool their utilities are! It hurts me to see so many great utilities being overseen by the masses.” Obviously, these are the words of a true terminal evangelist.
Before the big Internet boom, people used BBSes a lot (en.wikipedia.org/wiki/Bulletin_board_system). People called to other people's BBSes via their phone line. The cool thing about running your own BBS was that you could create a console “intervention”. By doing this, you could “take over” the terminal session of a given user. In those days, a lot of teaching and cooperation was done this way.
Of course, the Playterm Web site would not be possible without the GNU and Open Source movement. Thanks also to the developers of ttyrec (0xcc.net/ttyrec) and jsttyplay (encryptio.com).
Playterm is still beta, but it's already fully functional. Currently, we are curious about how many users we can serve, but in terms of global Linux knowledge, we are very excited. At this point, Playterm.org is a nonprofit project to serve the community and spread GNU Linux knowledge. Hopefully, it will inspire youngsters to use the shell more often.
I may not be Steven Spielberg, but every time I see a rerun of Gumby, I'm convinced I could be a famous producer. With Linux, I don't even have to get a fancy movie set. I can make my own science-fiction adventure film with nothing more than a Webcam and a streak of bizarre creativity.
Stopmotion is a Linux program designed for creating stop-motion films. It's available for most distributions and easily compilable for the rest. Stopmotion is simple in its design, and it allows you either to import a series of pre-taken photos or take live stop-action with a Webcam. I find the latter to be slightly easier, as you can see a ghost image of the last shot you took, making the slight changes you need easy to spot.
Recording stop-motion films is tedious work, but the end result can be pretty cool. Check out the homepage, short-linked here: is.gd/stopmotion. If you create an interesting video, send a link to info@linuxjournal.com. If we get enough, we'll post them on our Web site.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
—E. W. Dijkstra
One thing a computer can do that most humans can't is be sealed up in a cardboard box and sit in a warehouse.
—Jack Handey (from “Deep Thoughts”, Saturday Night Live)
If you have any trouble sounding condescending, find a UNIX user to show you how it's done.
—Scott Adams
Isn't it interesting that the same people who laugh at science fiction listen to weather forecasts and economists?
—Kelvin Throop III
Computer Science is no more about computers than astronomy is about telescopes.
—E. W. Dijkstra
Even he, to whom most things that most people would think were pretty smart were pretty dumb, thought it was pretty smart.
—Douglas Adams
It is bad luck to be superstitious.
—Andrew W. Mathis
The problem with quotes on the Internet is that it is often difficult to verify their authenticity.
—Abraham Lincoln
One of our favorite things to do over at LinuxJournal.com is to check the pulse of the Linux community and our readership. We do this fairly regularly with simple polls on our site. These give us valuable insight into your interests, and they give us a fun way to get feedback on a specific question. Sometimes a simple question generates a tremendous amount of discussion, and even a little controversy. We recently asked readers to choose their favorite programming language, and we received a lot of great answers. Check it out at www.linuxjournal.com/content/whats-your-favorite-programming-language.
We know that for some of you, your favorite programming language is such an important part of your existence that you are understandably quite opinionated on the subject. So, as you might expect, there were clear leaders and underdogs, as well as passionate supporters of each.
Python tends to be the favorite among our readers, and it has won more than one Readers' Choice Award for favorite programming language. Indeed, Python has staying power, as it once again was the leading choice among LinuxJournal.com readers with 24% of the votes. Not surprisingly, there were many skeptics among the commenters, but Python fans did their best to set everyone straight about Python's virtues, and one reader offered this sage advice:
In my opinion, a large Python system is well organized (like any language), sticks to standards, has docs (particularly module docs) and has tests. Consistent, well-written Python code makes it fairly obvious what objects/types functions accept and return, and having useful standard types (lists, dics, sets, etc.) encourages people not to make exotic variations often. Having module docs that document what your function does and its inputs and outputs clarify any questions.
In a close second and third place were C and C++, respectively. Both had enthusiastic support in the comments section, and we can infer from some comments that “all of the above” (in the case of C, C++ and Python) might have been a popular answer as well. Many indicated a preference for different languages for different tasks, and we applaud their versatility and open-mindedness!
Java trailed C++ in fourth place, and it was cited more than once as a preferred learning and teaching language. It probably also is safe to bet that some of Java's popularity is due to the increasing demand for Android applications written in Java. One anonymous commenter gave us a detailed breakdown of how Java fits the bill versus other languages:
For fun: Forth.
For teaching (elementary): Logo.
For teaching (secondary+): Java.
For desktop applications: C++ (with Qt).
For Web services: Java (SE or SE + Servlet only).
For enterprise internal: Java (EE with or without Spring).
For enterprise external: Java (SE or SE + Servlet and JSP, no Spring).
For cloud: C++, Java, Scala and Python together.
For mobile: Java (Android) C++ and Qt (native).
For embedded systems: C++ or Java (real time).
For device drivers: C++ or C.
For deep embedded (no MMU): C, Forth or Assembly, as needed.
Although these may not suit everyone, I have to give credit for such a detailed response.
Getting a little less love were Perl, C# and Ruby. Although these all have devoted followings, their fans were largely outnumbered in this poll. I was a little surprised to see Ruby score only 4% of the votes, as I personally know so many enthusiastic Ruby coders.
Haskell and OCaml each got 1% of the vote, while the catchall “other” made up the remaining 8%. Most interesting were the comments describing the variety of languages our readers use regularly as well as dabble in.
PHP always has a few fans, and although we can argue that PHP belongs in a separate “scripting languages” poll, its fans still showed support. The same can be said for JavaScript and Bash, both of which got a little love from our readers. Perhaps we'll do a favorite scripting language poll soon, but in the meantime, since PHP, JavaScript and Bash tend to be part of my daily life, it is nice to see I am not alone.
There were quite a few mentions of Scala, LISP and Erlang, as well as oldies but goodies, FORTRAN and Cobol. The latter occasionally were mentioned in the context of “getting old”, but frankly, do the classics ever go out of style?
It is always fun to read the nostalgia posts that inevitably appear on these sorts of comment threads. When programmers share their stories, there is usually a mention of the language they started with, and when our readers share stories of the language they were using in 1976 or even 1968, it gives us all a glimpse at where we've been, and how we all got to where we are today. Whether you started as a mainframe pioneer or a geeky kid typing out rudimentary BASIC on your TI-99/4A (What? Bill Cosby said it was cool!), you've likely had a somewhat meandering journey made up of more than a few languages to get to the code you write today. In my humble opinion, sharing these stories is one of the best parts of LinuxJournal.com. I hope you'll all join in the fun and check out the current poll next time you visit LinuxJournal.com. Don't be shy! Tell us your stories and opinions in the comments. You never know who you may inspire. I suspect it might be me!