The stable kernel efforts once again have gotten out of control. In the old days, Linus Torvalds had a cute x.even and x.odd version-numbering scheme, where even releases were part of a stable series that would last six months or a year or thereabouts, and odd releases were part of a development series that would last roughly the same amount of time. During the stable series, only bug fixes would be accepted; during the development series, new features also could be added. Over time, that made various folks wish they were dead, because the long duration of the stable series meant that tons of people had to sit around and wait for the development series to open up again.
With the 2.6 kernel, Linus abandoned the concept of a stable series, and this too led to some serious uncertainty among people who no longer had any kernel release they really could rely on. After some vicissitudes, Greg Kroah-Hartman and others started forking off various 2.6 releases that they would maintain as their own “stable series”, simultaneously with Linus' ongoing 2.6 release schedule. The world stopped its desperate careening, and everyone took an easy breath.
Greg and his cohorts chose which 2.6 kernels to fork into a new stable series, largely based on what would work best for them. From the outside, it seemed to be a fairly arbitrary and unpredictable process, which gradually led to pain and suffering among a very specific subset of users—the distribution maintainers. Anyone maintaining a Linux distribution, or developing a Linux-based phone or other embedded device, really wanted to know which kernels were going to have their own stable series, so they could base all their hard work on that kernel. But because there was no way to predict it, those folks were running into problems organizing their work, making market predictions and so forth. They began begging and pleading with Greg to start a new stable series for the particular kernel versions on which they each depended—or at least to make it more predictable which kernels would get a stable series.
Greg and the other stable series folks couldn't accommodate this without putting in a metric ton of additional work, so recently, Greg essentially decided to ditch the whole project.
From now on, he announced, he will no longer maintain long-term stable kernel trees. Instead, what he'll do is put out a few stable releases for each kernel, just until Linus releases the next development kernel version, at which point Greg will start putting out stable releases for that version and so on. This way, Greg says, people will be less likely to fixate on kernels that are super old and out of date and concentrate on the more-recent, better, faster, stronger and more-beautiful kernel of the moment.
The existing stable trees, particularly 2.6.27, 2.6.34 and 2.6.35, will not be going away. Instead, he's handed them off to other folks, who will maintain them as they see fit. Presumably other maintainers may be found to continue the stable patch series of future kernels as well.
Willy Tarreau will be taking over the 2.6.27 kernel, and he says he plans to make it the new “ultra-stable” replacement for 2.4 kernels. His intention is to give the remaining 2.4 users an incentive finally to upgrade to 2.6 kernels.
Paul Gortmaker will be taking over the 2.6.34 tree, essentially for his employer Wind River, who has products that rely on that kernel.
And, Andi Kleen will be taking over the 2.6.35 tree, also essentially for his employer Intel, who plans to release its own distribution based on that series.
So, that's how things stand. It's not clear how future stable series will come into existence, or who will be responsible for them, or how they'll be maintained. But, if the current situation is any indication, distribution maintainers may start assigning their engineers to become stable tree maintainers. Maybe that's the direction things have been going for a long time.
For Linux users, file decompression tools are as close as an apt-get or yum away. For Windows users who want to extract more than ZIP files, it means installing a third-party application. That can mean paying for a program like WinRAR, or it can mean installing a program like 7-Zip.
7-Zip will decompress (and compress!) just about any compressed file you run across on the Internet. Sure, it supports its native .7z file format, but it doesn't force you to use that rather uncommon (but awesome) file format. It integrates nicely into the right-click context menu, and it's basically the only compression program a Windows user will ever need. Download it for free at www.7-zip.org.
We looked at Maxima in the February 2011 issue to do algebra and rearrange some equations. But those aren't the only tricks up Maxima's sleeve. This month, I describe how Maxima can help with differential equations, but I'm going to leave out some of the intermediate results to save some space.
A lot of science involves figuring out how systems change over time and what causes those changes. When you start looking at changes, and especially rates of change, that is essentially calculus. Calculus and rates of change also are linked to slopes of lines on graphs. When you plot data and find an equation that describes it, you can find the slope of the line by taking the derivative of the equation. Let's look at a falling object and see what theory has to say about it.
You should start by looking at how you get a derivative. Let's say you have the equation:
(%i1) f(x):= 2 + x^2;
2
(%o1) f(x) := 2 + x
You would find the first derivative by calling the function diff, giving it the equation to differentiate along with the variable to differentiate by. So, you would write:
(%i2) answer:diff(f(x),x); (%o2) 2x
Maxima can do differentiation of expressions too. If you have a couple equations, you can derive their ratio with:
(%i3) g(x):= x^(1/2);
(%i4) ratio_diff:diff(g(x)/f(x),x);
3/2
1 2 x
(%o4) ----------------- - -----------
2 2 2
2 sqrt(x) (x + 1) (x + 1)
This might be a bit messy to work with, so you might want to refactor it to a more concise form:
(%i5) factor(ratio_diff);
2
3 x - 1
(%o5) - ------------------
2 2
2 sqrt(x) (x + 1)
Maxima also can handle trigonometric functions, but there are lots of identities you can use to help simplify equations with trig functions in them. By default, Maxima does not try to apply these unless you specifically say so, using special functions. As an example, let's say you have the following equation:
(%i6) diff(sin(x)/(1 + cos(x)),x);
2
sin (x) cos(x)
(%o6) ------------- + ----------
2 cos(x) + 1
(cos(x) + 1)
(%i7) factor(%);
2 2
sin (x) + cos (x) + cos(x)
(%o7) --------------------------
2
(cos(x) + 1)
That's still not very simple. If you then apply the function trigsimp, you can force Maxima to apply trigonometric simplification rules to the equation and see what you get:
(%i8) trigsimp(%);
1
(%o8) ----------
cos(x) + 1
You should be aware of some important caveats regarding how Maxima treats trig functions. The first is that sin(x)^(-1) is the reciprocal of sine, not arcsine. To get the arcsine, you would use asin(x). The other is another trig simplification function, trigreduce. This function is used to reduce the powers of trig functions by using the multiple angle formulas. For example:
(%i9) trigsimp(cos(x)^2 + 2*sin(x)^2);
2
(%o9) sin (x) + 1
(%i10) trigreduce(cos(x)^2 + 2*sin(x)^2);
cos(2 x) + 1 1 cos(2 x)
(%o10) ------------ + 2 (- - --------)
2 2 2
That may not look simpler than what you would get from trigsimp, but it is an easier form of the equation to use with other functions, like integration.
Maxima can apply the chain rule when doing a derivative. Say you have the equation:
(%i11) f(x):= x^3);
3
(%o11) f(x) := x
(%i12) depends(x,u)$
(%i13) diff(f(x),u);
2 dx
(%o13) 3 x --
du
The line at %i12 uses a new function, depends. This is a way of telling Maxima that x is a function of u, without explicitly defining a function describing this relationship. If you decide later that you want to define an actual equation for this relation, you can use:
(%i14) remove([x,u],dependency);
(%o14) done
(%i15) x:sin(u);
(%o15) sin(u)
(%i16) diff(f(x),u);
2
(%o16) 3 cos(u) sin (u)
Along the same lines, Maxima can handle implicit differentiation. Say you have the equation x^2 + y^2 = 25, and you want to find dy/dx. You need to use the depends function I just mentioned to handle this:
(%i17) eqn := x^2 + y^2 = 25;
2 2
(%o17) y + x = 25
(%i18) depends(y,x);
(%o18) [y(x)]
(%i19) deriv_of_eqn:diff(eqn,x);
dy
(%o19) 2 y -- + 2 x = 0
dx
(%i20) solve(deriv_of_eqn,'diff(y,x));
dy x
(%o20) [-- = - -]
dx y
The other side of calculus is integration. The basic function to do that in Maxima is called integrate. This function can do both definite and indefinite integrals. Indefinite integrals are the symbolic form of integration you likely learned in school. For example:
(%i21) integrate(x^2,x);
3
x
(%o21) -
3
A definite integral actually is evaluated over an interval. This form of an integral can be visualized as the area under the curve defined by the equation you are integrating. To do definite integrals, simply add two arguments giving the start and end points of the interval:
(%i22) integrate(x^2,x,0,1);
1
(%o22) -
3
Putting all these techniques together, you can solve a differential equation for a given variable—for example, solve dy/dx = f(x) for y. You can do this by doing all the required algebra and calculus, but you don't really need to. Maxima has the very powerful function, ode2, which can do it in one step. Start with your equation:
(%i23) eq: 'diff(y,x) = sqrt(1/x^2 - 1/x^3);
dy 1 1
(%o23) -- = sqrt(-- - --)
dx 2 3
x x
(%i24) ode2(eq,y,x);
2
2 2 sqrt(x - x)
(%o24) y = log(2 sqrt(x - x) + 2 x - 1) - ------------- + %c
x
This one function call does the integration and the solve steps and gives you a final answer to the differential equation.
Let's say you're doing an experiment dropping a coin and timing how long it takes to fall. How do you know whether the times you are measuring actually make sense? Let's start with the most basic law: force = mass * acceleration.
The mass of the coin is a constant, so ignore that for now. The force is the force due to gravity, pulling the coin down to the ground, and the acceleration describes the coin's motion due to this force. The force due to gravity is a constant, at least here on Earth, and it depends linearly on the mass, so you can define the force as:
(%i1) force: mass * g; (%o1) g mass
The acceleration also is a constant, because both the mass and the force are constants. Acceleration is simply the rate of change of the velocity, and the velocity is the rate of change of the position, so you can set that up as:
(%i2) depends(y,t);
(%o2) [y(t)]
(%i3) acceleration: 'diff('diff(y,t),t);
2
d y
(%o3) ---
2
dt
Putting it all together, you get:
(%i4) eq_of_motion: force = mass * acceleration;
2
d y
(%o4) g mass = mass ---
2
dt
(%i5) solve(eq_of_motion, y);
2
d y
(%o5) [--- = g]
2
dt
You can see right away that how fast an object falls doesn't depend on the mass at all. Galileo was right! The next step is to do some integrating and see what you end up with:
(%i6) integrate(%,t);
dy
(%o6) [-- = g t + %c1]
dt
At this step, you would be able to find out the velocity (dy/dt) at time t. The additional term %c1 is a constant of integration. In this case, you can see that it represents the initial velocity of your penny. One more round of integration gives this:
(%i7) integrate(%,t);
/ 2
[ dy g t
(%o7) [I -- dt = ---- + %c1 t + %c2]
] dt 2
/
Now you can find the position, y, of your coin at any time, t. Again, a new constant of integration is introduced, %c2. In this case, you can see that this represents the starting height of your coin. But that's not what you were measuring. You were measuring how long it took the coin to drop a given distance. So you need to do a bit of rearranging. Because you are dropping your coin, you know that the start velocity is 0 (that is, %c1=0). You can rewrite things a little to make it a bit clearer:
(%i8) eqn: y = (g * t^2)/2 + y0;
2
g t
(%o8) y = y0 + ----
2
(%i9) solve(eqn,t);
y y0 y y0
(%o9) [t = - sqrt(2) sqrt(- - --), t = sqrt(2) sqrt(- - --)]
g g g g
There you go. You now have an equation for the time, given a height that your coin is dropping. With this theoretical relation under your belt, you can check to see whether gravity is working correctly in your local lab. If not, you should contact the Nobel committee straightaway.
This only scratches the surface of Maxima's capabilities in dealing with calculus and differential equations, but hopefully, this article gives you a starting point. Happy integrating.
Package management in Linux is great, but unfortunately, it comes with a few cons. Granted, most distributions keep all your software, not just system software like Apple and Microsoft, updated. The downside is that software packages aren't always the latest versions. Whatever is in the repository is what you get. Another frustration is when the software you want to install isn't in the distribution repositories at all.
Usually, it's possible to add software packages, even if they're not in the repos. For Red Hat-based systems, those are RPM files. For Debian-based, they're DEBs. Unfortunately, installing applications that way doesn't give you upgrades when they're available; you need to keep them updated yourself. Most package management systems also have the ability to add third-party repos, but those don't always have the packages you want.
Canonical has a feature in newer versions of Ubuntu that allow the best of both worlds. They're called PPAs (Personal Package Archives). Instead of distributing .deb files, developers simply can distribute their PPAs. With a PPA, the software is updated automatically along with being installed in the first place. While installing PPAs hopefully will become simpler, in the short term, they're still pretty easy to install. You just need to find the right PPA structure, usually given by the developers that support the idea. For example, to install the Mozilla Daily Build PPA, simply type:
sudo apt-add-repository ppa:ubuntu-mozilla-daily/ppa
Someday, installing a third-party application will be as easy in Linux as it is in Windows and Macintosh. With ideas like PPA repositories, however, your software will stay updated. And, that sounds P-P-Perfect to me.
The folks at Recompute have taken the notion of “Going Green” to a whole new level. They've made computer cases out of recyclable cardboard. We had the pleasure of speaking with Recompute's Brenden Macaluso and took one of their computers for a test-drive. Here's what we found:
The computers living inside the cardboard boxes are actually quite functional. Although they're not super-fast gaming machines, the computer options aren't just a bunch of low-end Atom machines.
The cases feel sturdy. We were leery about using a computer case made of cardboard, but it didn't feel flimsy at all.
Although a cardboard case doesn't make the computer internals any more recyclable, it does actually make it easier to recycle those innards. They literally rip right out.
There are many skeptics when it comes to the Recompute idea. Some see the cardboard case as a gimmick, and some think a computer wrapped in brown craft paper is a fire hazard. If you have questions about the Recompute computer, check out the FAQ on the Web site: www.recomputepc.com. For my full video review, check out our Web site: www.linuxjournal.com/video/review-recompute-pc.
We love Dropbox here at Linux Journal. It's cross-platform, offers a decent free offering and generally “just works”. It has some problems though. Dropbox is proprietary. Dropbox stores a copy of your data in its own data repositories. Dropbox is limited in size, especially with its free accounts.
Enter SparkleShare. SparkleShare is an open-source project that allows you to start a Dropbox-like service on your own. It's a very new project and needs time to mature, but the beta is promising. Also, because you run the server yourself, there are no limits to the amount of data you can store. It's also cross-platform and has some of the same sharing features offered by its proprietary brother.
Check out the early stages of SparkleShare at www.sparkleshare.org, and if you're a programmer, consider contributing. I'm excited for a stable alternative to Dropbox that I can host myself.
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
—Linus Torvalds
I have an ego the size of a small planet.
—Linus Torvalds
Do you pine for the days when men were men and wrote their own device drivers?
—Linus Torvalds and David Diamond
If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
—Linus Torvalds
Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen an angry penguin charging at them in excess of 100 mph. They'd be a lot more careful about what they say if they had.
—Linus Torvalds
This month, Linux Journal focuses on my favorite topic: Web development. We've compiled a fantastic collection of information here in the pages of this issue, and I look forward to learning a thing or two along with you.
With the recent release of Drupal 7, I am excited to focus my attention once again on making significant improvements to LinuxJournal.com, and I hope you'll check in from time to time to see what's new on-line. A new major Drupal release is a great excuse to take a look at things that could use improvement on our site, as well as add new features to improve the overall experience for our readers. With the numerous improvements in Drupal 7 beckoning, I can't wait to get started on what should be the best version of LinuxJournal.com yet.
Web development best practices are constantly evolving, and we all struggle to stay current or even ahead of the curve. Linux Journal and LinuxJournal.com are two important sources of the knowledge necessary to keep up with Web technology trends. Join us on-line at www.linuxjournal.com/tag/web-development to find a wealth of information in one place. See you in the comment queue?