April 2009 Archives

Here's an SSH security tip. Nothing groundbreaking, but something that a few of us non-sys-admin types are likely to overlook: It is possible to prevent certain specific users and groups from having ssh access to a Linux ssh server.

This can be handy if you want ssh access available on a computer, but only want a certain user to be able to login remotely. This might be the case, for example, if you gave your kid or your gaming buddy an account on one of your PCs, but you know that he or she does not need remote SSH access. If you configure the sshd to not allow that user ssh access, then you have taken away one possible route that a cracker could use to try to break into your machine remotely.

The instructions are simple: http://www.cyberciti.biz/tips/openssh-deny-or-restrict-access-to-users-and-groups.html

http://xkcd.com/571/

I found a really cool WWII submarine simulator called Danger From the Deep. Here are their screen shots:

http://dangerdeep.sourceforge.net/gallery.html

DftD is FOSS, with installers for Windows and for 32- and 64-bit Linux. The game is a German sub sim, with a particular focus on realism. Not just realism in the sense of good 3D graphics, but authenticity: the game makes available a view of each important control room for each different kind of submarine, and all the labeling on the instruments are in German! You direct many of the mechanical details of the sub, with controls as finely grained as, for example, deciding to what temperature you want to warm up your torpedo before you launch it!

One of the greatest things about the game is that authentic 1940s feel, which is enhanced not only by working all the gauges and knobs in the simulation and looking around on the bridge of your German U-Boat, but even by the music tracks, which start with a scratchy recording of "I'm in the Mood for Love" the moment you hit the title.

Anyway, the project is still fairly young (0.3.0) but nevertheless quite playable and enjoyable. Oh, and one tip: If you check it out and decide you want to learn to play, don't try to figure it out on your own - the online manual is very helpful.

First of all, let us discuss open manuals. Computer users, of course, have been doing free online documentation pretty much since the beginning of the Internet. The most renowned collection, I imagine, is Wikipedia. An open manual, however, has a more formal structure, with numerous chapters put together into a book-like form, in order to guide the user extensively in a single technical activity. Also, an open manual is clearly placed under an open license, unlike, say, a blog post which contains technical information but reserves all copyright privileges.

My flagship example is flossmanuals.net. The site provides free online manuals for a variety of open source software, such as streaming software, office software, and networking utilities. If a user wishes to contribute to a manual, he navigates to the "write" section of the site and selects the appropriate manual. He either selects a chapter to edit, or enters the name of a new chapter to create. The contributor is also provided with a set of writing guidelines, both for the specific manual, and for manuals in general. If the user wishes to create a new manual, he must e-mail a request to a site maintainer, who reviews the request and starts the project.

In FOSS tradition, the content of the manuals are open for review and for modification. However, the structure of the interface and procedures are a little more formal than many open content environments, maintaining an overall higher level of quality.

I believe open manuals like this will continue to gain popularity over traditional technical manuals. Traditional manuals, often in printed format, tend to be expensive, and not readily available to the interested learner. But the open manual is readily available for reading and distribution. The traditional technical manual can only be modified at the author's discretion (who, of course, is at his liberty to retire from writing whenever he wishes) but the open manual can be modified as soon as it becomes inaccurate.

I will also briefly discuss open textbooks. The idea is roughly the same as the open manual, except that the open textbook is targeted at the scholastic community, and covers scholastic subjects. Wired.com posted an article last year entitled Open Source Textbooks Challenge a Paradigm which discussed flatworldknowledge.com and its novel approach to textbook marketing. The textbooks are produced under an open license, and can be read online for free. The site makes money through related services, such as selling attractively formatted printed versions of the manuals to those who want them in book form.

The advantage to the student is obvious, as it avoids the oh-so-familiar pain of having to buy a book if you are not sure you are going to need it. And teachers benefit as well, because they are able to modify a section of a textbook if they feel it is inaccurate. Currently there seems to materials available for around sixty different classes.

I am not aware of a writer who has specifically criticized the idea of an open manual or an open textbook. One would probably, though, use the same arguments used against any open content system. For example, one article pointed out a number of the disadvantages of Wikipedia, such as edit wars, vandalism, and the insertion of opinion and inaccuracies by non-experts. But I think people will see that open manuals and open textbooks are less prone to this problem, for one because of the more formal nature of their construction, but also because they are, by nature of their content, going to spend a lot more time under the scrutiny of the experts. And for classes or large projects, the teacher or project leader can always download a copy and make any necessary modifications before distribution.

So I believe open manuals and open textbooks could become very popular as technicians, teachers, and students begin to see that there is an alternative to the limitations and expenses of the traditional model. And these professionals are encouraged to find some area of the new open documentation in which they can be regularly contributor, or can provide knowledgeable peer review for efforts of others.

(You'll forgive me if this post seems a little out of place... I'm not in the habit of making predictions about future IT developments. But it is a required part of a school assignment, so if you'll bear with me...)

I believe that the age of single core processors is coming to an end. Not only in the area of High Performance Computing (HPC) but for the average user as well.

Multiple core processors make for more efficient multi-tasking, because separate activities of the system can be assigned to different cores. Consequently, computer retailers have emphasized this in their marketing. For example, HP's Pavilon Elite is marketed as a standard desktop PC, and with repeated reference to its multi-tasking power. Multi-tasking is a central part of our daily computing experience, and I think vendors want us to understand the prospective benefits of buying hardware with multi-core processing capabilities.

Also, individual programs can become much more efficient running on multi-core processors because separate threads of the program can be dedicated to separate cores. However, for the performance boost to be seen, the program must actually have separate threads, that is, it must be designed or adapted to be a multi-threaded program. And many (most, I think) applications available for the average computer user were not designed this way, thus lessening the immediate necessity of moving away from single core processors.

However, the trend is changing. Even computer games, which have been almost universally single-threaded, are beginning to shift. Valve software received a lot of attention about three years ago for moving their 3D game engine, which was underlying the popular Half-Life 2, over to a multi-threaded model. Evidently, designers even see multi-core systems as a possible benefit in embedded design.

Some writers are more skeptical about the progress toward multi-core processing. For example, it can be argued that multi-threaded programming makes simple programming ideas much more complicated and problematic. However, that is a problem which can remedied, over time, with better libraries and new programming languages.

So what does that mean for upcoming IT professionals? For programmers, of course, that means becoming comfortable with a multi-thread model of programming. For some IT techs and system admins, it means taking multi-core hardware and software more seriously. That is, moving those quad-cores out of the "high-end" lab and making them available to all your staff. And it means becoming familiar with what software has and what software has not been optimized for multi-core processing (more than just the OS) so you can give your users the most powerful applications available.

I can certainly imagine a world where 64-bit dual-core processors are as passe as 32-bit single-core processors are now. Personally, I wouldn't mind trading out my old Pentium D for a 16 core AMD.

The code for MinMenu 0.9.0 is available at http://indicium.us/cgi-bin/pages/get?view=minmenu.

Sorry about the long delay from 0.8.2, but I was switching the program over to a multi-threaded programming model, and I was also implementing nested-menu support and improved color schemes. Multi-threaded programming can be challenging, and really obvious bugs in the running program can be very difficult to find in the code.

The new code implements nested-menu support (support for sub-menus) and consequently a new configuration file syntax. Note that the new syntax is not backwards-compatible. (That is, you will need to redo your configuration file if you have one from 0.8.2).

I was having some trouble in my C application attempting to use the "system" function in a multi-threaded (pthread) environment, mainly related to terminal i/o. The problem and solution are documented in the following forum post, which I thought would be worth referencing here:

http://www.linuxquestions.org/questions/programming-9/c-system-function-in-child-thread-717306/

Linux has made impressive progress in GUI capabilities over the last few years. The downside of this is that most Linux users are not familiar with some of the most powerful terminal commands. And some of these commands are very well documented in the man pages:

http://www.bofh.net/man/bosskill.8.html

I spent about four or five hours trying to figure out an odd problem in my curses app. I wrote some code that was supposed to redraw the screen if the value of COLS or the value of LINES changed (i.e., the screen was resized). Whenever there was activity on the screen (a result of the user sending commands) the code worked fine, but if the program was idle, then the screen would not be redrawn after a screen resize.

The problem, I found, was that during the idle times, the values of COLS and LINES were not being updated, even after a screen resize. I had assumed that the values of COLS and LINES were somehow constantly updated. It would seem, however, that the values of COLS and LINES are set at your first call to initscr, but are not updated again until you make a call to the refresh function.

So, I fixed the problem simply by making sure the code calls refresh once before it checks to see if value of COLS of LINES has changed.

Probably everyone else in the world already knew that, but just in case...