Linus Torvalds is planning to put out Linux version 4.0 in a year or so, and he mentioned it by way of explaining why he wanted to do it and what he hoped would happen when he did.
Apparently, his main reason to go from 3.x to 4.x is to avoid the 3.x minor numbers going up above the teens. He said, “I'm ok with 3.<low teens>, but I don't want us to get to the kinds of crazy numbers we had in the 2.x series.” That's no joke. The 2.1.y series got up to 2.1.132, and there were complaints.
So, why announce it now, if 4.0 is a year or two away? Linus said he hoped the 4.0 kernel could be a “stabilization” release, where everyone contributed bug-fixes only. By announcing it early, he hoped everyone gradually would get used to the idea, and that perhaps there would be at least a very slim chance of success. He said, “I may be pessimistic, but I'd expect many developers would go 'Let's hunt bugs....Wait. Oooh, shiny' and go off doing some new feature after all instead. Or just take that release off. But I do wonder...maybe it would be possible.”
Clearly his thinking has come a long way from the old 2.x days, when long periods of stabilization were official policy—and the source of much developer angst.
Even now, most responses were opposed to making 4.0 a “stabilization” release. But, that could have less to do with a general dislike of bug-fixing and more with the fact that a large culture of stabilization has emerged in the wake of the 2.6 tree's abandonment of stabilization efforts nearly altogether.
Originally Linus was supposed to hand off the 2.6 tree to Andrew Morton, who would maintain it as a stable tree while Linus forked off a 2.7 development series. Instead, Linus stayed in control of 2.6, never forked a development tree, and just started taking development patches in 2.6 instead. Thus endeth the x.even/x.odd development paradigm for stable and development kernels.
In place of this, in those long-ago days, Linus said that really the Linux distribution folks were the natural ones to handle stabilization. They typically heavily patched the Linux kernel anyway, so they had a process in place and the motivation to keep their users from hitting bugs.
But that didn't really seem like enough, so Andrew converted his beloved and popular -mm tree into what is now called the linux-next tree. Before the switch, the -mm tree was simply the collection of patches Andrew intended to feed up to Linus. But he was so prolific, and collected so many patches from other developers, that the -mm tree already had started to become a natural staging area for many patches that were on their way to the official tree. And, a lot of people ran the -mm kernel on their home systems because they liked it better. Renaming it linux-next simply formalized that identity and gave code a place to live, and more important, it allowed it to be tested by a large number of users before heading up to Linus.
Greg Kroah-Hartman and some others also started their own stabilization effort, in which they would fork off each official release and put out a few more official versions of that release consisting of bug-fixes only. For example, after Linus put out 2.6.39, Greg and his fellows put out 2.6.39.1 through 2.6.39.4, all with stabilization fixes and security patches. When Greg started this work, Linus' nickname for it was the “sucker's tree” because of the unfathomable amount of work required.
Both Andrew's linux-next and Greg's stable tree persisted into the 3.0 time frame and continue to be a primary means of stabilizing the official kernel tree. Any patches going into Greg's stable tree, for example, must be accepted into Linus' tree first. That may sound odd, but it actually prevents the same bug from cropping up again and again in new official releases. Even with the patches going into Linus' tree, Greg's stable series is still valuable, because it has the fixes, the whole fixes and nothing but the fixes, which means Greg's tree becomes more and more stable while Linus' continues to gallivant off in development-land.
Greg also occasionally designates one of his forks as “long-term stable”, which means he intends to put out more than just a few stabilization releases, but will continue to maintain it for maybe a year or longer. The choice of which official release will become “long-term stable” is a source of much ongoing speculation, because distributions like to organize their ongoing work around a particular kernel as early as possible—in fact, earlier than Greg typically picks out a new “long-term stable” candidate.
But, that is another story. The point is, stabilization efforts have risen up to fill the gaps left by Linus' decision to abandon stabilization efforts in the main kernel tree. And as a result, his concept of 4.0 as a “stabilization” release doesn't seem to strike anyone as very important.
Actually, Linus didn't completely abandon stabilization as a goal. Each release cycle includes a final release-candidate process that focuses on stabilization for a couple weeks before the official release comes out.
But, this brief stabilization window was exactly why certain people didn't like his 4.0 stabilization idea. Olof Johansson, for example, said that instead of dedicating a whole release to stabilization, why not just extend the stabilization window of the previous release?
There were other objections. Ingo Molnar and Greg both felt that the release before 4.0, “would also probably be a super-stressful release to maintainers, as everyone would try to cram their feature in there”. And Greg remarked, “I see it today when people are trying to guess as to what the next long-term-stable kernel is going to be, and they throw things in that are half-baked just because they know they can 'fix it up' later.”
Ingo also said that a better way to make the official kernel more stable would be for maintainers to put more pressure on developers to submit fixes to known bugs before sending in patches implementing new features.
Ingo pointed out that Linus rarely got patches directly from the developer who created them, and that these patches typically went through at least a maintainer and possibly another person above them, before reaching Linus. So Ingo didn't feel that Linus could have much direct influence over the stabilization process anyway. He concluded, “why not just do what worked so well for v3.0 and afterward? Keep the existing process in place.”
And Greg pointed out that his stabilization forks were actually very successful. He pointed out that 4,000 bug-fixes went into the 3.0.x stable releases, which he felt indicated that developers in general already took stabilization very seriously. He suggested that trying to focus on stabilization for a single 4.0 kernel release would not be as useful as evangelizing good practices for submitting code to Greg's stable trees.
The discussion continued for a bit, but for the moment, Linus had nothing to add. It seems as though he does want to improve the stabilization process for the official kernel in some way. Maybe he'll do it with a push for stability in 4.0, and maybe he'll try something else that runs more along the lines of supporting existing stability efforts.
Many of us grew up with LOGO, the kid-friendly programming language that guided a little turtle around a screen. Yes, it was simplistic. Yes, it taught only the very basics of programming concepts, but it also inspired an entire generation of programmers. The applications you run every day were written by people who steered a digital turtle around a screen in third grade.
Alice is a project from Carnegie Mellon University that allows new programmers to use a drag-and-drop interface to create 3-D scenes and perform programmatic results without typing any code. The Alice Project has evolved through the years, and it's currently on version 3. The code is freely downloadable and is available for Linux, Mac and Windows.
(Image from www.alice.org)
Although the LOGO programming language allowed for some lengthy instructions for the turtle, it was limited. Alice, on the other hand, uses the animation environment to teach amazingly complex programming concepts. By utilizing an environment where syntax is dragged as opposed to typed, it takes “typos” out of the equation. It's hard to describe just how complex the programming can be with Alice, so I urge you to download it or at least visit the Alice Project at www.alice.org.
For doing its part in producing the next generation of programmers, while (at least in my mind) continuing the legacy of a small digital turtle from my youth, Alice gets this month's Editors' Choice Award.
Whether you're a fan of the shambling brain-munchers or you prefer your undead to sprint from victim to victim, zombies are amazingly popular. In an ironic twist, the most unhealthy members of humanity, or former members, can help you become the healthiest!
“Zombies, Run!” is an application for your Android phone that uses GPS and your music collection to help motivate you to exercise. A slim waist and a great beach body might be enough to get you running, but how about the sounds of an approaching zombie horde? It's a twisted motivator, but it really works!
The application isn't free, but at $7.99 (or less if you find it on sale), it costs about as much as an extra-large frozen mocha latte. Both investments will affect your health, but in this case, the zombies are far better for you. Check it out at https://www.zombiesrungame.com.
I'll be honest, the first thing that drew me to Wampserver was the name. Although it's just a continuation of the LAMP acronym for Linux, Apache, MySQL and PHP, there's something about that name that makes me smile. Anyway, Wampserver is an application for Windows that provides Apache, PHP and MySQL in a single manageable package.
Wampserver includes a single installer for all the components and an interface for controlling them (Figure 1). Although it certainly makes sense to use Linux for hosting an Apache-based Web server, if you're in a situation that requires you use Windows, Wampserver is a perfect way to install what is normally a fairly complex set of applications.
Figure 1. Wampserver Interface
Wampserver installs all open-source software on your Windows machine, and is itself open-source software as well. It's available from SourceForge or directly from the Wampserver Web site: www.wampserver.com.
Kyle Rankin demonstrated the advantage of splitting terminal windows in previous issues. If you'd like a simple, graphical way to split your terminal window, look no further than Terminator (gnometerminator.blogspot.com). Split screens and keybindings can be saved for quick setups, and it's simple to create a grid of terminal windows or a combination of large and small screens.
If you've ever opened multiple terminal windows and tried to arrange them so you could see them all, Terminator will make your life a lot easier. Even if you've never tried a split-window setup, the ease and simplicity Terminator offers might make you a believer. It did for me!
Mapping is ordinarily a complex task—just consider all the available software to help maintain and generate maps. And, that's only for mapping in two dimensions. Maintaining and generating maps of caves bumps this complexity up a notch. Caves exist in all three dimensions. So any mapping software needs to keep track of volumes rather than areas. There are not very many options that can handle this task. Luckily, one available package can do this job very well: Therion (therion.speleo.sk/index.php). Therion is an open-source program, released under the GPL and available for Windows, Mac OS X and Linux.
Most distributions should have a package available, or you always can download the source and build it from scratch. In Debian-based distributions, you can grab it with the command:
sudo apt-get install therion
Once it is installed, you can find it in your desktop environment's menu system, or run xtherion from a terminal window.
When you first start up Therion, you essentially get a blank canvas. You can open an existing file or create a new one to begin working. Let's start by creating a new project. You can click the File→New menu entry or press Alt-N. Therion then asks you to enter a name for your new project. This name should end with .th.
You end up with two black panes as the main part of the interface. On the far right, there are a number of sub-panes, with the settings pane opened. Here you can set the working directory for your current project and the related configuration file. You also can set command-line options, and there is a compile button, which I'll discuss shortly.
The main interface is actually composed of three separate windows. You start in the first one, the “Text Editor”. There is also a “Map Editor” window and a “Compiler” window. They are accessible two ways. The first is by using the menu. The window entries are located under the main menu entry Window. There also are keyboard shortcuts for each of them. You can bring up the text editor with F1, the map editor with F2 and the compiler with F3.
Figure 1. The main window that comes up when you first start Therion.
Let's start with the text editor. The first step is to define the survey for this project. Since this is just a quick tutorial, let's just use the name “example1”. In the text editor window (press F1 to bring it up), enter the following text:
survey example1 endsurvey
Between these two lines is where you need to enter your survey data. You could enter this data manually, but usually, it would have been collected using some other system. One example of this is using PocketTopo to go and collect the survey data directly in the field.
If you don't have any data available, you can get some on-line. There is a very good tutorial at the Cave Surveying Group (cp.cavesurveying.org.uk/index.php/articles/3-therion-tutorial). It also includes some example data you can use while you are learning to use Therion. Let's use the example file bpwth.txt.
In the text editor window, add an extra blank line between the two lines you already entered, and place the cursor on this new blank line. Now you can click on the menu entry File→Import and select the file bpwth.txt. This will import the data you are going to plot.
Figure 2. The survey data is simply a list of data points.
Once you have all of your data imported, you need to save it to a file. Because the project's name is example1, name the text file example1.th.
The next step is to run the compile stage to process all of this data. Press F3 to switch to the compile window. You need to give the compiler some options so that it knows what to do, so open a new configuration file by either clicking the menu item File→New or pressing Alt-N. The default filename that comes up is thconfig. To keep things clean, name the file thconfig.thc, and save it in the same location as the text file you created earlier. Click in the top pane to set the focus there, and enter the following text:
source example1.th export model -fmt survex -o example1.3d
The first line tells Therion where the data is to compile. The second line tells Therion what file format to use to save the compiled model. In this particular case, the model is being saved in Survex 3D format. Therion supports several different file formats.
With this information in the system, you now can go ahead and compile your model. You can press F9 or click the menu entry File→Compile. Therion will process your model and write out details in a log, which is displayed in the lower pane.
Figure 3. The log of results from the compile shows up in the lower pane of the main window.
So, what does this look like? Luckily, Therion includes a viewer called Loch that can handle Survex 3D files. You should have an entry for it in the menu system for your desktop environment. You also can start it up from a terminal window with the command loch. It uses OpenGL to draw the three-dimensional model of your cave data. There is also another program called Aven that you can use to visualize the cave data.
Figure 4. Loch is one of the viewers for 3-D files available from Therion.
Figure 5. You also can use Aven to view 3-D files generated from Therion.
The last window to look at here is the map editor. For this example, let's switch to the map editor by pressing F2. Add a new file by clicking the menu item File→New and save it with the filename example1.th2. The file ending .th2 is the default for mapping files in Therion.
You can add images from several different file formats to your map, but in this case, let's add data from the PocketTopo export data. Click the menu entry Edit→Insert Image, and change the file type to “PocketTopo therion export”. Select the same sample data file as before, bpwth.txt. You will end up with a very nice layout of the cave that was surveyed with PocketTopo. You then can edit this map, adding points, lines and areas.
Figure 6. You can import map data from PocketTopo into Therion.
Hopefully, you now will be able to plan safe and rewarding trips into your local caves with Therion. With more and more publicly accessible caves using Therion, you will have a growing set of information available before you ever leave home. Don't forget to check out the other tutorials available on-line to learn all of the other great things you can do with Therion.
We would spend many hours taking turns trying to rescue the princess and overthrow Bowser. We bonded over 8-bit technology and room temperature fizzy drink.
—B. T. Hogan
Nothing of me is original. I am the combined effort of everybody I've ever known.
—Chuck Palahniuk
Wanting to be someone you're not is a waste of the person you are.
—Kurt Cobain
No one can be right all of the time, but it helps to be right most of the time.
—Robert Half
[Television is] the triumph of machine over people.
—Fred Allen