Recently, Rob Landley tried to remove a Perl dependency that has cropped up in the Linux build system...and tried...and tried. But, no one appeared to want his patches. Even Andrew Morton argued against removing the Perl dependency, in spite of the fact that Rob's patches replaced the code with smaller, simpler shell scripts.
It's unclear what the reluctance stems from—my understanding always has been that any chance to remove a dependency from the Linux build system was a chance worth taking. But apparently, the top kernel developers see a value in this particular dependency.
The e-mail thread was a bit of an eye-opener for me personally, because I'd started to consider Perl to be a legacy language, with no forward progress on Perl 6, and the language itself essentially stalled.
Microsoft's “secure boot mode” seems to be pitting kernel developer against kernel developer successfully. David Howells recently posted some patches to allow the kernel to load Microsoft-signed cryptographic keys dynamically, and there was some support for the patch. But, Linus Torvalds wouldn't allow it, and there was some support for his rejection of it.
Linus' approach seems to be that he'll support anything that can provide genuine security to the user. And if some new technology is not designed to provide that security, he'll support it to the extent that it can be torqued into a position that provides genuine security. But, he won't support technologies that claim to add security when all they really do is take control of the system away from the user.
Evidently he feels that, as designed, “secure boot mode” does more to take control away from the user, than it actually does to secure the system. So he's rejected David's patches, as well as apparently any notion of catering to Microsoft as the sole key-signing authority for “secure boot mode” security keys.
According to Thomas Gleixner and others, the Linux kernel's hotplug code had been developing races, undocumented behaviors and other problems. He posted a patch to rip the guts out of the beast and replace it with something that, to the user, would appear as a simple state machine.
Linus Torvalds liked the idea, but he wanted to be sure that the guts really were fully ripped out and replaced. He didn't just want to hide the problems. But as Rusty Russell pointed out, Thomas' patch represented only the first step, in which the horror was hidden from the user. The second step would involve cleaning up the internals themselves.
Rob Landley recently chafed at the increased security on the kernel.org server. Ever since the 2011 security breach, the kernel.org admins have implemented tighter access controls that limit the ways in which developers can contribute their work. Rob in particular missed the ability to rsync his code updates to a kernel.org account. As a result, he hadn't been able to update the 00-INDEX files in the kernel source tree. Paul Gortmaker also had been updating those files, but he posted his patches to the public mailing list instead. That seems to be the standard approach these days, along with creating public git repositories from which Linus and others may pull.
One of the things I dislike about using Irssi in a terminal window on OS X is that I often miss the screen flash when someone mentions my name in IRC. With some fancy SSH tunneling (maybe more on that some other issue) and a really cool pop-up notification tool, if someone mentions my name, I can't miss it.
terminal-notifier is a command-line tool for creating OS X-native user notifications. It doesn't rewrite the concept of pop-ups; instead, it gives us nerds a way to add pop-ups to scripts (Figure 1). Because it uses the native notification system, it's easy to modify what sort of pop-up appears. I prefer the kind that doesn't go away until dismissed, but you can change that in the notification settings in OS X's preferences.
If you like pop-up notifications like libnotify, but find yourself on a Macintosh machine more often than not, terminal-notifier might be as useful for you as it is for me at my day job. Plus, now you know that if you mention my name in IRC during the workday, you'll make a window pop up on my screen! Get it at https://github.com/alloy/terminal-notifier.
The major player in the Windows world for GIS programs is the suite of ESRI products. In Linux, we have the package named GRASS (grass.osgeo.org). GRASS originally was developed by the US Army Construction Engineering Research Laboratories, starting in 1982. It is used by many large groups, including NASA, NOAA and the National Park Service. In September 2006, management of GRASS was taken over by the GRASS Project Steering Committee, and it now is an official project of the Open Source Geospatial Foundation.
GRASS may be too much if you just want to do basic GIS tasks. In that case, you may be better served by a program like QGIS. But, if you need to do some serious GIS analysis, GRASS definitely is worth the learning curve. Most distributions should have a set of packages to simplify installation. If you do want the latest source, or need a version of GRASS for Windows or Mac OS X, you always can go to the main Web site.
When you first start up GRASS, it asks you to set a data directory. The suggestion is ~/grass-dir. Once you select this data directory, you need to set some project information. You can click on the Location Wizard to help set the location information for your project.
Once you set the name and data directory, you need to select the method for creating a new location. Just to get started, you simply can accept the defaults. To learn how to work with GRASS, you will want to have some data to play with. Sample datasets are available to download from the main GRASS site (grass.osgeo.org/download/sample-data). Choose one or more of them, download the files and uncompress them into the data directory you set above. These sample datasets then will show up in the “Welcome to GRASS” window when you first start up GRASS. At this point, select one of these datasets. You also need to select a mapset, most usually PERMANENT.
Once GRASS starts up, two windows appear. The first window is a map display, where all of the layers you select will be rendered. The second window is where you select the map layers that you want to apply to the map display window.
To create your first map, click on the “Add raster map layer” button (the one with a checkerboard and a plus sign), or you can press Ctrl-Shift-R. This will pop up a dialog window where you can select which layer you want to add from the mapset you loaded on startup. In this example, I have loaded the PERMANENT mapset from the spearfish location, and I set the 10m elevation as the first layer of my map.
One of the first things you will want to do is to change the colors used within the map. To do this, right-click on the layer in question, and select “Set color table” from the drop-down menu. You then can change the color table that GRASS will select from in order to render the layer on your map. To change your layer to grayscale, select “Type of color table:” and select “grey”.
When you click on the run button, you are switched to the “Command Output” tab where the results from this command are displayed. If you want to see an idea of the spread of the possible values, you can get a histogram by right-clicking the layer and selecting Histogram. If you need more exact numbers, you actually can calculate univariate statistics on the data in the layer. This is done by right-clicking on the layer and selecting “Univariate raster statistics”.
Adding a second layer allows you to start building up the information being displayed on your map. You need to be careful of which order the layers are in the layer list. They are rendered from the bottom up. This means that layers further up the stack may obscure what is being displayed lower down. You may need to change the opacity of the upper layers to allow information from the lower layers to show through. Right-click on the layer in question and select “Change opacity level”. You then can set it to an appropriate level so everything you want to see actually is rendered.
The other type of layer that you can add to your map is a vector layer. In this case, the data is stored as a set of geometrical objects, where each object has some attribute data assigned. With vector layers, the only portions that are rendered are the actual objects. For example, if you add a road layer, you don't need to worry about opacity, because the roads are small enough not to obstruct anything on the layers below. You can right-click on that layer and edit the attribute data. You then can select which values for each attribute to display. This can be a more complex selection—for example, selecting those values between an upper and lower bound or selecting only those values that match some other criterion.
You can change display properties for the objects by right-clicking and selecting Properties. For the road layer, you can set properties like line width, line color and what symbols to use for point elements.
You can add extra elements that you normally see on maps by selecting the “Add map elements” button on the main map display. This opens a drop-down box where you can select extra elements to add. These include scalebars, North arrows, legends and text areas. You can click and drag these elements and place them where they need to be on your map.
Once you have the layout the way you want, you need to save a final copy so you don't lose all of your work. To do so, click the “Save display to graphic file” button on the main map display. The first step is to choose the output size for the map. Then you can select the filename and the file format.
Hopefully, this article introduces you to enough of GRASS to induce you to try it out. If it's good enough for the US Army, it's good enough for me. It should be powerful enough to handle any GIS task you have.
Although it's difficult for me to look at this piece's title and not think of mutant felines, it doesn't make the statement any less true. If you've ever used the tail command on log files, you'll instantly appreciate multitail. My friend (and LJ reader) Nick Danger introduced me to multitail, and I can't believe how useful it is. multitail will “tail” multiple files, split the screen to display them, notify of log file changes and so on. One of my favorite features is rather than show 100 lines of repeated log, it shows the line only once, and it says, “line repeats 100 times”—simple, but awesome.
multitail has more features than I could list on this page, but chances are if you've ever wished you could do something with log files, multitail does it. Check it out at www.vanheusden.com/multitail.
We recently asked our readers about their Android usage, and as predicted, most of our readers own an Android phone, tablet or other Android device. Also not surprising is that our readers are mostly up to date, with the majority of users running the Jelly Bean release. 86% are loyal to Android and have not jumped ship in favor of another platform. E-books also are popular with our readers, but E Ink vs. a backlit color display is a toss up. Read on to see the full results, and as always, thanks for participating!
Do you own an Android smartphone?
Do you own an Android tablet?
Do you own a non-smartphone/tablet Android device?
Which version of Android is running on the majority of your devices?
Cupcake (1.5): <1%
Donut (1.6): <1%
Eclair (2.0/2.1): 1%
Froyo (2.2): 5%
Gingerbread (2.3): 15%
Honeycomb (3.0/3.1/3.2): 2%
Ice Cream Sandwich (4.0): 22%
Jelly Bean (4.1/4.2): 54%
Did you switch from an iPhone to an Android phone?
Have you switched away from Android to another platform (iOS and so on)?
Have you already or are you planning to buy an Ouya?
Which is worse for developers?
iOS's walled garden: 68%
Android's version fragmentation: 32%
Do you read e-books?
If you read e-books, which do you prefer?
An LCD screen: 49%
E Ink: 50%
Does DRM limit the amount of digital media you purchase?
What do you do most on your Android device?
Consume media (audio/video): 34%
Read/create e-mail: 27%
Social networking (Twitter, Facebook and so on): 16%
Play games: 7%
Talk on the phone: 15%
Video conference: 1%
Does your device's battery last all day?
If I don't use it a lot during the day: 17%
Have you rooted your Android device(s)?
Don't go around saying the world owes you a living. The world owes you nothing. It was here first.
In a networked world, trust is the most important currency.
When you relinquish the desire to control your future, you can have more happiness.
Not a shred of evidence exists in favor of the idea that life is serious.
Genius begins great works; labor alone finishes them.
It may not be fair to call Weechat the little brother of Irssi, but in my short introduction to it, that's what it felt like. If Weechat didn't seem quite as powerful as Irssi to me, I definitely can say that it is better-looking out of the box. So, little brother has one thing going for him!
The other day, I was tweeting with Janne Jokitalo about the sorts of things two nerds tweet about: command-line editors and command-line chat clients. I mentioned Irssi in a screen, and he mentioned Weechat. I'm glad he did! Right out of the box, Weechat does some things I've never been able to get Irssi to do well. First off, it has a list of users docked to the right side of the terminal (Figure 1). I always liked that feature in the GUI client X-Chat, but I couldn't get it to work well in Irssi. I also think the look and feel is far more friendly than that of Irssi. Yes, with the help of Kyle Rankin, I've been able to tweak Irssi into the perfect chatting machine, but Weechat seems to have a more gentle learning curve.
It supports IRC and Jabber right now, but the Web site claims more protocols are coming. Weechat is probably already in your distro's repository, so install it, and give it a whirl. You'll get all the geek creed of Irssi with some fancy interface additions! Due to its focus on usability and its roots in hard-core nerd-dom on the command line, Weechat is this month's Editors' Choice selection. Check it out at www.weechat.org.