UpFront

Kernel configuration has become more and more complex through the years with the proliferation of new drivers, new hardware and specific behaviors that might be needed for particular uses. It has reached about 3,000 config options, and that number will only increase.

Jean Delvare recently pointed out that a lot of those config options were relevant only to particular hardware, and yet the config system presented them to users who didn't have that hardware. This seemed like a bug to him, and he suggested that maintainers begin requiring proper hardware dependencies for all config options.

He acknowledged this would be a big task—especially for existing drivers. But creating the requirement for new drivers would at least get the ball rolling, and older drivers could follow along more gradually.

Josh Boyer agreed with all this. From his work on the Fedora project, he had to deal with the config system intensively, and he found it difficult. He said, “I've gotten to the point where I can somewhat guess based on the driver name which arch it's for (lately the majority are for ARM), but that isn't really a great way to handle things.”

There was some resistance to the idea. Greg Kroah-Hartman, in particular, suggested that there were existing alternatives. For example, he said users simply could compile everything as modules. Then, they'd be loaded into the system only as needed.

But, neither Jean nor Josh liked that suggestion. Jean said that in the old days it was fine to build everything as a module, but nowadays there were just too many modules, and that “Saying 'm' to everything increases build times beyond reason. You also hit build failures you shouldn't have to care about, depmod takes forever, updates are slow as hell. This is the problem I am trying to solve.”

Greg didn't see how build times could be a problem. Building the kernel on his laptop, he said, took about 20 minutes—with all 3,000 modules compiled in. If that wasn't good enough, he suggested upgrading the hardware to get a faster build time.

But, Jean said this wasn't a practical solution for some cases. He said, “We have 34 kernel flavors for openSUSE 13.1, for example. And, every commit potentially triggers a rebuild of the whole set, to catch regressions as fast as possible. So every module we build, for no good reason, gets built a hundred times each day.” He added that it would cost a lot of money to upgrade the hardware underneath that build system.

Greg said he understood the issue, but that fixing the config system was just a hard problem to solve. It boiled down to enforcing better habits on everyone producing patches. He said, “If you see new drivers show up that you don't know where they work on, ask the developers and make up patches.” He added, “Perhaps a few developers could be auditing the new Kconfig items of every kernel around -rc3 time frame to ensure that they don't do stuff like this.”

Jean said that -rc3 would be too late, because “all kernel developers and distributions have already moved to the new kernel so they have already answered the n/m/y question for all new entries.” He added, “It's the reviewer's job to refuse new drivers with bad Kconfig descriptions in the first place. This must happen as early as possible in the chain.”

No clear decision came out of the discussion, but it does seem as though there's a vast mountain of configuration options that are becoming more and more difficult to deal with. Eventually, I think some form of clean hardware dependencies will end up being implemented, along the lines of Jean's suggestion.

With all the new devices coming out on the market, there's a big desire to get Linux running properly on all of them. Things like Intel's Quark system use only a few MB of RAM and have other tight hardware requirements. Shrinking Linux down to the right size poses a challenge.

Andi Kleen recently pointed out, “One problem on these small systems is the size of the network stack. Currently enabling IPv4 costs about 400k.” He wanted to give users the option to prune down the Linux networking stack to only the bare essentials and get it down to 100K per application—competitive with Adam Dunkel's LwIP (Lightweight IP) project.

Andi posted some patches to create three available options for the networking stack: a full system with all current features, a partial system that supported regular users but not servers or a minimal networking system for the special userland on deeply embedded systems. The minimal system, he said, would “remove rtnetlink (ioctl only), remove ethtool, raw sockets”.

This seemed extreme to Richard Weinberger, who said that on such a minimal system, even the ps command wouldn't work. Tom Zanussi on the other hand, said that the microYocto Linux distribution ran okay with Andi's patches and had decent workarounds to keep ps working properly. But, he added that microYocto was “very much a work-in-progress with a lot of rough edges, but it is a fully functional system on real hardware”.

Alexei Starovoitov felt that trying to support such a minimal system would only create config options that led to a hacky, work-in-progress, rough-edged system. He said that if the goal was to create a half-functional system that was just very very small, the same thing could be accomplished with linker hacks. Simply “compile kernel as-is. Most functions have a stub for mcount() already. Use it to track whether the kernel function was called or not. Collect this data in userspace (as perf already does), add a few more functions that had a 'notrace' attribute on them, and feed this into a special linker that unpacks existing vmlinux, throws away cold functions, relocates the rest and here you have tiny vmlinux without recompilation.”

But, Andi pointed out that for networking code, this wouldn't really work. He objected, “How would you know you exercised all the corner cases in the TCP stack? And you wouldn't want a remotely exploitable system because some important error handler is missing.”

The discussion ended inconclusively. But, it does seem as though real patches, and not linker hacks, will be used to support all new hardware—even the tiny hardware that's been coming out lately.

Controlling a remote computer is something you're all familiar with. Whether that means RDP to your corporate Windows Server (we don't judge), Apple Remote Desktop (which is really VNC) to your OS X machine or VNC/X11/etc. into your GUI Linux machine, it's always a pain in the rear.

The folks at Google are trying to make it a little easier with Chrome Remote Desktop. It's a combination of Chrome browser app and native binary that runs on your client machines. Once the dæmon is installed, you can access the computer remotely from anywhere, including a really cool Android app. The combination of available platforms is pretty impressive too:

Server platform (what can be controlled):

Client platforms (what can be used to control the systems above):

Permissions on the dæmon can be customized for controlling your own computer remotely (no local permission required) or for allowing other people in to assist you. The latter is preferred to avoid anyone barging in on your work session. The dæmon is available for Windows and OS X, and recently they released a beta version of the dæmon for Ubuntu/Debian Linux! Thanks to its wonderful cross-platform approach and smooth functionality in our testing, Chrome Remote Desktop earns this month's Editors' Choice award! Check it out today at https://chrome.google.com/remotedesktop.

Sometimes, when the clock hits 3:00am, and you've been in the server room since 9 o'clock the previous day, you start to get a little batty. That's the only explanation I have for programs like cowsay in Linux. Still, I'm glad they're there, because life wouldn't be nearly as fun without them. Here's a quick list of silly Linux programs off the top of my head. I'd love to hear about more, so please, send me your crazy Linux Easter eggs, and I'll follow up on the Web site showing off the best ones.

Most of these silly things have been around for years and years, but every so often, I learn of one I never knew about before. Send me your favorites, and I'll be sure you get credit for slacking off at work—er, I mean for discovering awesomeness! E-mail info@linuxjournal.com (put something like “FUN” in the subject line so I know what it's about).

In the September 2014 issue, I mentioned my new router, and I got a lot of e-mail messages asking about how well it works. I can say without hesitation it's the nicest router I've ever owned. And, it was less than $100!

The EdgeRouter Lite is a business-class router based on the open-source Vyatta system. It has been forked, and as it matures, it will become less and less like the original Vyatta code, but for the present, it works much the same. I purchased the EdgeRouter because my old ATOM-based ClearOS router/firewall couldn't keep up with the traffic from my home network. My favorite features include:

I'll admit, setting up the EdgeRouter Lite was a pain in the rear end. The basics can be done via the Web interface, but if you want any QOS for your connection, it will be a learning experience trying to figure out the Vyatta command and code (and concepts!) for doing so. It took me three or four hours to get the setup that I'm happy with, and since then, I haven't touched it—at all. It works so fast, I never notice it, and it's been rock-solid since day one. If you're looking for an advanced router, but don't want to break the bank, the EdgeRouter Lite might be exactly what you're need. Be warned, however, its setup is not for the faint of heart.

I was chatting with a Windows-using friend recently, and he wanted to try Linux on one of his older computers. I always like those sorts of conversations, and so I kept chatting, walking him through setting up Unetbootin to create a USB installer and so on and so on. Unfortunately, he wasn't able to get the USB drive to boot. Since we were half a country apart, I couldn't troubleshoot locally, so we moved on to burning a CD/DVD.

My first instinct was to have him download the incredible InfraRecorder. Unfortunately, there seems to be a malware-infected version of InfraRecorder going around, and of course, that's the download link he found. So, be sure to send folks directly to infrarecorder.org to download it.

Image courtesy of www.visualpharm.com.

Alternatively, I'm a big fan of the free-but-not-free program ImgBurn as well. It's not open source, but it is freeware, and it has a very simple interface. Either way you go, be sure to warn potential Linux converts about the malware masquerading as open-source software. Remember to send people directly to the Web site rather than having them “google” for it. The open-source InfraRecorder is at infrarecorder.org, and the freeware ImgBurn is at www.imgburn.com. Once they switch to Linux, everything they need will be an apt-get or yum away!

In the past, I've covered various astronomy packages that help you explore the universe of deep space. But, space starts a lot closer to home. It actually begins a few hundred miles above your head. There are lots of things in orbit right above you. In this article, I look at one of the tools available to help you track the satellites that are whizzing around the Earth: Gpredict (gpredict.oz9aec.net/index.php).

A package should be available in most Linux distributions. In Debian-based ones, you can install Gpredict with:

sudo apt-get install gpredict

This is usually a version or two behind the latest, so if you want to have the newest options, you always can download and build from source.

Once you have it installed, you can start it with the gpredict command. When it opens, you should see the main window, with a sample layout given by the module named “Amateur” (Figure 1).

Figure 1. When Gpredict first starts, you get an initial module called Amateur.

In the rest of this article, I take a look at all the various possible layouts and show just how much information is available to you.

The core concept in Gpredict is that of the module. You can think of modules as documents in a word processor. They are containers you can use to hold a number of other layout objects that display satellite information in a number of different ways.

When you first start Gpredict, you get the default Amateur module, which contains a map view, a polar view and a single satellite view. For some of these views, you may notice a small down-arrow in one of the top corners. Clicking this icon gives you an appropriate drop-down list of options. For example, clicking the down-arrow in the map view gives you a list of items, such as detaching the module or configuring it (Figure 2).

Figure 2. Some views have drop-down lists of options.

The map view offers a map of the Earth, with a series of satellites and their footprints on the Earth. When you hover over one of the satellites, you will see an information box with the satellite's detailed location. The single satellite view provides even more detail about one specific satellite. You can select which satellite is being displayed by clicking on the down-arrow in the view. The polar view provides an overhead look, located at the ground station.

In the Amateur module, you get one ground station called “sample”. You can add more ground stations by clicking the down-arrow and selecting configuration (Figure 3).

Figure 3. You can set the configuration details for the map view here.

You can add another ground station by clicking the plus sign. This will pop up a details window where you can enter a name and the location data for your ground station (Figure 4). For the location, you can enter the latitude and longitude manually, or if you live in a major city, you can select it from a global list of locations.

Figure 4. You can add a ground station with details here.

One other item you will notice when you have the configuration window open is that you can select which satellites are displayed. This list is rather large, but there is nothing stopping you from adding all of them to your module. It might make the display a tad crowded, but it still should work.

I should take a step back at this point and describe some other configuration options available. The first option to look at is the menu item Edit→Update TLE. This option lets you update the Keplerian elements for the satellites. You can update them either from the network or from a local file. The default configuration is set up to remind you when the TLE data is likely out of date. You then can go ahead and update this data. For an update over the network, the default configuration is to download NORAD data from www.celestrak.com. For a tutorial on the format for TLE data, visit www.amsat.org/amsat-new/tools/keps_tutorial.php.

All the other configuration options are available under the menu item Edit→Preferences (Figure 5). Here, you can change options like the number formats used or the geographical coordinates. There also is a tab for ground stations, where you can edit or add ground stations.

Figure 5. The preferences window lets you change all sorts of options.

The modules section lets you change configuration options used in the display of the Gpredict modules. You can change things like the refresh rate for the displays or what map to use as the background for the map view. You also can select what type of layout you want for a particular module. When you select a new layout, you will see a preview of what it will look like in the preferences window. There are nine different pre-generated layouts available, or you can create a custom layout. When you select the custom layout, you define what it will look like by entering the layout code. See the user manual for details on how to define a code to create the layout you want.

Gpredict also has the ability to control radios and rotators. The key to this is the hamlib library. By using this library, Gpredict can handle Doppler tuning of radios and tracking of antenna rotators. When you want to connect hardware to your computer, you should verify that hamlib can talk to it successfully. Once you have made sure everything is working correctly, you can set up Gpredict to talk to your hardware. This is handled in the interfaces section of the preferences window. There are two tabs, one for radios and one for rotators. Since hamlib communicates over network protocols, the radio or rotator doesn't even need to be connected to the same machine. You can define one of these pieces of hardware with a hostname, a port and the communication details. Once you have the hardware configured, you can control it by pulling up the radio control window, which you access by clicking the down-arrow in the map view and selecting Radio Control (Figure 6). You can see the details of the downlink and uplink, as well as information about targets.

Figure 6. You can control radios and antenna rotators that are defined in Gpredict.

Now that you know how to get satellite information for what is moving above your head, you should be able to go outside and do some actual observations and see all of the man-made objects travelling around. It can be inspiring to see how much we already do in space, and how much more we could be doing.

Do not hire a man who does your work for money, but him who does it for love of it.

—Henry David Thoreau

When in doubt, tell the truth.

—Mark Twain

Experience is a good teacher, but she sends in terrific bills.

—Minna Thomas Antrim

Just the knowledge that a good book is awaiting one at the end of a long day makes that day happier.

—Kathleen Norris

Always be a little kinder than necessary.

—James M. Barrie