UpFront

Sasha Levin wrote a new hash table implementation for the kernel. Typically in a big, decentralized software project, developers aren't necessarily aware of the cool stuff being implemented in the various nooks and crannies of the code, and there's a tendency for lots of alternative implementations to crop up everywhere. Hash tables are a good candidate for that. Sasha's patch was intended to provide a generic hash table that all kernel developers can use.

Something like this can never find users unless it's really fast. Sasha's implementation uses a variety of speed-enhancing optimizations, including doing as much as possible at compile time via macros. But, macros have their own little syntactic idiosyncrasies that can require a little extra care during use. Mathieu Desnoyers and Tejun Heo pointed out some improvements and bugs to Sasha's code, addressing some of those problems.

Darrick J. Wong took the trouble to create a nearly three-hour gource animation of Linux kernel development history, going all the way back to the beginning: www.youtube.com/watch?v=pOSqctHH9vY.

It's lovely to watch. It's also interesting because gource relies on having a computer-readable log of a project's development history, while the early history of Linux is more or less a mystery. Linus Torvalds accepted vast numbers of patches in the 1990s, but he just used the UNIX diff and patch commands to apply them. The only real records of the patches were e-mail logs and Usenet logs, but these don't give clear indications of which patches actually were accepted into the kernel, and when. It was only with the arrival of BitKeeper, and later of git, that a detailed record of Linux's history began to be compiled.

There have been some efforts to re-create some of that early history into its own git tree, but this is nowhere near as detailed as the kind of historical records being created these days. The beginning of Darrick's video, therefore, just shows Linus doing everything for a while and then being joined by other developers, presumably once the historical record became more accurate.

After six and a half years of maintaining the KVM code (the Kernel Virtual Machine), Avi Kivity has stepped down. His co-maintainer Marcelo Tosatti, formerly also the Linux 2.4 maintainer, was left briefly as the sole KVM maintainer, until Gleb Natapov came in to replace Avi.

Everyone should use KVM. It's an easy, secure way to boot up a new computer without having to go buy one. You can play around with the /etc directory and other strange internals in ways you might have been afraid to before. You can try out different Linux distributions, or maybe create your own, and you also can experiment with creating clusters of many interoperating systems. If anything goes wrong, just turn off the VM and start fresh. It's very cool.

Most people are familiar with Instapaper and Read It Later. Those types of services are great for tagging Web articles for later reading, and in the case of Read It Later (now called “Pocket”), they do a wonderful job of copying articles off-line for reading when the Internet isn't available.

Using Pocket's Chrome extension, as I browse the Web during the day and find articles I'd like to read later, I add them to my Pocket queue with a single click. This works perfectly for me, because although I find lots of things to read during the work day, I don't have time to read them. Now, I simply can open the Pocket app on my Nexus 7 and catch up on my reading as if it were an e-book. As you can see, articles are formatted for easy reading, and because they sync off-line, reading doesn't require Internet access.

Pocket is a great system, a really nice Android app and provides an effective way of staying out of trouble at work! Check it out at the Google Play store, or visit the Web site: getpocket.com.

I'm the sort of person who doesn't like to install Java. I actually don't like to install Flash either, but it's still tough to survive browsing the Internet without Flash installed. There is one program that makes me break my own rules, however, and that's Crashplan.

For years, I've been singing the praises of BackupPC, and for servers, I still think it's the best thing going. The problem with BackupPC, however, is in order for it to work reliably, your workstations need to be on all the time. This is especially difficult with laptops.

Crashplan is an incredibly powerful backup utility that allows local or offsite backup, and the company offers cloud-based storage for reasonable rates. Normally, I wouldn't be so excited by a paid service and a non-open-source software package, even if it does offer a Linux-native client. The folks at Code 42, however, have given away the ability to swap storage with friends as an alternative to their paid-cloud-based service. If you have a computer at work, and a computer at home, you can back them up over the Internet to each other completely free!

As I already mentioned, I normally don't like Java-based programs like Crashplan, but its functionality is so great, I don't mind breaking my own rules. More than that, I give a lot of credit to Code 42 for not only making a native Linux client, but also for giving away incredible functionality for free. If you're not backing up your data, be sure to consider Crashplan at www.crashplan.com. Its price, feature set and generous non-paid features make it this month's Editors' Choice!

We asked some Drupal community members and leaders from all over the world about the current state of Drupal and what they are most looking forward to in Drupal 8. We got a variety of opinions from everyone from core developers to end users. Here's what they had to say.

Ryan Szrama:

The current state of Drupal is frenzied. Everyone has a lot of irons in the fire (as always), and core devs are working madly to get awesome new features into Drupal 8. I think everyone feels not just the challenge but the opportunity to make Drupal better, the ecosystem larger and their businesses more successful.

I'm most excited to have fago's Entity API updated and included in Drupal core. A robust entity system will make building and maintaining contributed modules like Drupal Commerce much easier than it's been on Drupal 7, and we have both the will and code in place now to make this shine in Drupal 8. Great work all around.

Pol Dell'Aiera:

Drupal 8 will be the bomb.

Bert Boerland:

Web services/WSCCI is by far the best thing happening to Drupal and even the Web. Web services first!

Larry Garfield:

Current state: the sands are still very shifty. Drupal 8 still has a strong potential to be revolutionary and kick so much ass it's not even funny. The trick is if we can close the deal and not leave ourselves in a fugly transitional state. That is still a real risk that keeps me up at night.

Most excited about? There's too much to limit myself. Mostly I think the formalization of APIs that's happening in many places. The detangling of hook_menu, EntityNG, the conversion of more and more systems to cleanly injected (and therefore swappable) systems, etc. The architectural quality of Drupal 8 is steadily increasing, and once we wrap our heads around that transition it should be so much more powerful.

Look at the distinction between a Content Management System, a Content Management Framework and a Web Publishing Tool. Really, really think about it. Then listen to Karen McGrane talk.

Drupal is so close to something so awesome and I don't think we even realize it. Stay tuned.

Diana Montalion Dupuis:

In general, I am concerned about the schism between the needs/desires of the development community and the needs/desires of people who pay us to solve their business problems with Drupal. I'm excited about many aspects, and as always, beyond grateful to the dedicated geniuses of the community. I also fear that we are doing something (from the “What problem do I solve?” perspective) different enough from previous versions/visions that we are taking a sharp left turn and actually making something else.

I feel the enthusiasm, Larry's especially. I agree that transition management is a make or break challenge. A steady stream of information that connects our current marketshares' investment in Drupal, and the Drupal shops' investment in team skills, with the changes coming will ease that transition. “Drupal will now be widely applicable to XYZ and thus, extend our Web presence into ABC functional areas. So, train your team!” (In layman's terms.)

Karoly Negyesi:

Disclaimer: I am paid to work on some aspects of Drupal 8 core. Regardless, this my opinion.

Current state: the core developers are often screaming. Sometimes from joy, sometimes from frustration.

The new APIs are superbly powerful. At the same time, it'll take some effort to learn them. Parallel to this, there are concerns about the developer experience, but they were raised before the code freeze even—this is good. Previously, similar concerns only occurred much later in the cycle, and so they couldn't be addressed. No matter how much will we enhance the DX of the new APIs, the “surface” between the old and new APIs will be rough. See Larry's worries above about a transitional state. I consider that inevitable—just the degree is the question.

I love what is happening to the UI. However, I always did. I am just a PHP guy.

Jason Smith:

I'm very interested in seeing where the services/WSCCI and configuration management stuff goes. Those are killer features.

I'm a little concerned about the barrier to entry being raised high enough due to architecture to discourage new folks. Drupal's pulling toward enterprise, which is a good thing. But, my concern is that it may neglect that roadmap to mastery that makes Drupal a fantastic platform for open-source devs. 

Barrett Smith:

I'm most excited for the configuration management changes slated for D8. Improving the way settings are managed will go a long way toward securing Drupal's place in enterprise-class, multi-tier environments.

Bronius Motekaitis:

I love that the Drupal community has grown so large, that Drupal-powered projects keep increasing in size and complexity, and that core and the community are working diligently to keep up. I also like that user experience and accessibility continue to receive a lot of attention. While this is very exciting, it is disconcerting, because sweeping changes necessitate climbing up that steep, personal learning curve. By Drupal 8, I believe we in the community will have gotten much better about documenting core and contrib, migrations and upgrades, and build recipes.

As code developers and application builders already marinated in Drupal, we love the increases in power and flexibility, but it is important to retain the community of “simple, one-off builders” and continue to pique the interest of prospects: spending time on documentation, UX/design and appearance are all important in these regards.

David Stagg:

The biggest issue with Drupal 7 (and as a consequence, Drupal 8) is that it's coming too quickly. While the core is being developed at such a rapid pace (that's good!), a lot of modules and other libraries that worked exceptionally well in Drupal 6 aren't being ported over quickly enough to Drupal 7 or 8 (that's bad!).

Events are a perfect example. Drupal 6 has a robust set of modules and features that allows us to make an intensive event-based site; in Drupal 7, almost none of these are available. For those of us intently focused on the front end without the capabilities to create the modules ourselves, this can be tough. The best part of open source is the community, but when the development moves too fast, the dust that settles oftentimes forfeits a complete package. And after all, Drupal isn't complete without the community.

Donna Benjamin:

More than one core developer has admitted they've not actually built sites with D7. Our commitment to the future means we abandon the past, and sometimes it seems the upgrade path is an afterthought.

But I'm optimistic about the future—I think D8 has extraordinary potential. The work that's been done on HTML5, Multilingual, Mobile, Config Management, Web Services and Authoring Experience is really quite phenomenal. It will be a game-changer.

I just hope it's still the kind of system that provides the kinds of solutions my clients and communities require. But I can't deny I am worried its enterprise target puts it out of reach for small sites for small orgs with small budgets, and volunteer teams. Many people learn Drupal in those environments. At the moment, we don't have an alternative formal training and certification pathway to replace that pipeline.

As for the community itself, keep an eye on AsiaPac: India, China, South East Asia and Australasia. We're just not on the radar for most EuroMericans. 

For some reason, single-site Web applications like the kind created with Prism seem to have fallen out of style. I've always been particularly fond of Chrome-based applications, and yet, there doesn't seem to be a way to create a single-site Web application properly on OS X using Chrome. Thankfully, even with modern releases of Chrome, it's certainly possible and still very useful.

Two different scripts are available and freely downloadable for creating single-site Chrome apps on OS X. The first is an AppleScript file created by Mait Vilbiks, available at snar.co/chromeapp1. The other is a Bash script that does the same identical thing, but it works on the command line. It's available at snar.co/chromeapp2. (Note: both files are public domain and can be modified if desired.)

Figure 1. The AppleScript version walks you through the process.

If you have ever wished Google Calendar was a standalone application, or if you just want to have dock icons for your various Web activities, either of these scripts work wonders. Even better, if you want to delete the application, simply drag it to the trash. Chrome apps work great as standalone applications in OS X, and now you can try them yourself!

We polled our on-line readers about their Web development preferences and got some surprising and not-so-surprising results. Perhaps the biggest surprise is that Drupal just slightly edged out WordPress. WordPress traditionally has been the most popular of the two among our readers, with Joomla a close third to Drupal's second place. This time, Drupal beat out WordPress by a hair with Joomla a distant third. Chrome's popularity over Firefox was a surprise, but as someone who tests in everything but prefers Chrome, I can't say I'm shocked. Our readers' love of vim and JQuery is not a surprise, nor is the popularity of Python and PHP.

Thanks, as always, for participating in our on-line polls. The full results follow.

1) What is your favorite browser for testing?

2) What is your favorite Web programming language?

3) What is the best CMS to develop for?

4) What is your favorite editor?

5) What is your preferred development framework?

6) Which JavaScript libraries do you use most frequently (multiple answers permitted)?

7) What is your favorite hosting company?

8) Which do you prefer to use?

9) What is your preferred revision control system?

10) Do you currently practice continuous integration?

11) Which SQL database do you work with most frequently?

12) Which NoSQL database do you work with most frequently?

A lot of the software packages I've covered in recent articles have been focused strictly on doing computations on your machine, separate from the real world. So in this article, I explore how to use your computer to design something you can build and use in the real world: your own model rocket. Let's take a look at the OpenRocket utility and see how it can help you design your own rockets. OpenRocket even can run simulations on your designs to show how they should behave in flight.

Most distributions should include a package for OpenRocket. For example, in Ubuntu, you would install it with apt-get install openrocket. It is actually a Java program, so you always can download the jar file directly from the Web site (openrocket.sourceforge.net). To run it, you need to have a reasonably up-to-date Java VM installed as well.

When you first start it up, you are presented with an empty screen, ready to begin designing your first rocket. A project window pops up, allowing you to enter details like the design name, your name and design notes. You can build your rocket from a series of components. You probably will want to start with the nose cone by clicking on it from the “Add new component” window. It then will appear in the bottom section, beginning your design.

You will notice that OpenRocket already begins to make calculations based on your design. You will see a small blue circle that denotes the center of gravity of your rocket. The center of gravity is the point through which all of the mass acts. There also is a small red dot that marks the center of pressure. This is the point through which all of the atmospheric forces act. OpenRocket calculates these values as you make changes to your design.

You can edit almost all of the parameters for each component. There are two ways to edit these component parameters. You can double-click on the component of interest in the design window to access the edit window. There also is a list of the component layers in the top half. You can highlight the component of interest here and then click on the Edit button.

What you can change will depend on which component you are trying to edit. The first component to design probably is the nose cone. You can select what kind of profile your nose cone should have, such as conical or ellipsoid. You can set the length and base diameter, as well as the wall thickness. But, OpenRocket goes even further. You can select the kind of material from which your nose cone should be made. The different types of materials have different densities, which changes the weight of your component.

Several different material presets are available, but you also can go ahead and define your own custom material type. This custom material either can be used just for one design, or you can add it permanently to your materials database if it is something you will be using over and over again. You even can set the type of finish your rocket will have. This finish can be different for each component, or you can apply a common finish to your entire rocket.

When first starting OpenRocket, you get a new project dialog where you can enter details of your rocket.

You can edit many details of the different components by double-clicking the component of interest.

The rocket engine database has lots of information on many different brands.

The next part of your rocket is the actual body tube. If your rocket is going to have a single stage, you will need only a single body tube. For multiple stages, you will need a separate body tube for each stage. Opening the edit window for the body tube allows you to change the tube length, diameter and wall thickness. You also can change the material from which the body tube is made.

Because body tubes usually contain a rocket motor, you can set the motor that you want to use as well. To do so, open the edit window and click on the motor tab. You can click the Select Motor button and choose from a large selection of commercially available motors. This list of motors includes technical information, such as the thrust curve and the run times, as well as physical characteristics like the length, diameter and weight.

As with the other sections of the application, you can define your own custom entries. This means even full-on DIY model-rocket enthusiasts who build their own motors can use OpenRocket to design their rockets.

The component list includes other items like parachutes, shock cords, connectors and blocks, so you can design your rocket as a complete model.

The final stage is to add tail fins to your rocket. As with the other components, there are well designed presets available that will satisfy most design needs. You can edit some parameters to customize the fins to some degree. If that's not enough, there is a freehand option where you can design your fins from scratch.

OpenRocket is not only a design program. You also can take your model rocket and run an analysis on it to see how it will behave in flight. The analysis section looks at individual components and shows how they affect the stability, drag and roll characteristics of your rocket. You can set parameters like wind direction, angle of attack and speed, and calculate how it will behave in flight. This is great functionality, but OpenRocket goes even further. It can take your original design and try to optimize it for the best flight characteristics. You can optimize based on altitude, velocity or some other combination of characteristics.

Once you have a final design, you can run it through simulations. The simulator can apply different conditions on your rocket, like applying crosswinds or taking Coriolis effects into account, and it shows how your model rocket should behave. OpenRocket uses JFreeChart to plot your rocket's behavior based on the simulation results.

You even can add your own code to the simulation to add extra effects. One way to do this is using Python and jPype to use Python code in the simulations. Additionally, you have the ability to write and use your own expressions in the simulator. This allows you to customize the simulator to a great degree without having to add external code. Then, you can see the limits of what your model should be able to handle and how high it will go under different conditions. This is really great in helping you decide when the weather is going to be too rough for your design.

You can run an analysis on the different components of your rocket.

You can optimize your rocket to maximize certain parameters.

You can run full simulations to see how your rocket will behave in different conditions.

I have covered only the features available in the most minimal way. If you are into building and flying model rockets, your time definitely will be well spent poking around all of OpenRocket's available features. The Rocketry Forum hosts a forum where you can ask for further help. And once you have gained some experience, you can give back by helping other new rocket enthusiasts. Go ahead and design your fleet, and get yourself out into the wild frontier of space!

Many of the cool things in Linux Journal require the use of the command line. For us Linux users, that's generally not a big deal, because we have a terminal window readily available. Some of the time, however, it's helpful to have a shell account on an Internet host somewhere.

If your Web-hosting service provides shell access, you might be able to use it for rudimentary command-line procedures. (In fact, Dreamhost in particular allows SSH tunneling through its servers for clients.) If you want to use particular programs like screen or irssi though, it will require something a little more robust.

Some free shell services are available (like www.geekshells.org), but they often are very restrictive, and it can be challenging to get an account with them. Thankfully, if you don't mind spending a few dollars a month, shell accounts are fairly common and relatively inexpensive. The Eggdrop folks have compiled a great list here: www.egghelp.org/shells.htm.

Figure 1. Sometimes, you just need a shell.

Of course, if you want to have a full-blown server on the Internet, it's hard to beat a colocated Raspberry Pi server like the one Kyle Rankin talked about last month. However you manage it, it's hard to be a geek without access to a terminal!

If this is coffee, please bring me some tea; but if this is tea, please bring me some coffee.

—Abraham Lincoln

Almost all my middle-aged and elderly acquaintances, including me, feel about 25, unless we haven't had our coffee, in which case we feel 107.

—Martha Beck

Do Lipton employees take coffee breaks?

—Steven Wright

I have measured out my life with coffee spoons.

—T. S. Eliot

To me, the smell of fresh-made coffee is one of the greatest inventions.

—Hugh Jackman

I never drink coffee at lunch. I find it keeps me awake for the afternoon.

—Ronald Reagan