One of the difficulties with “live patching” a running kernel is the desire to remove the older version of a patched module, once the patch has been applied. Even if all new invocations of patched functions are sent to the new code, how can you be sure that some piece of code in that older version isn't still running because it was called before the live patch occurred?
Miroslav Benes recently posted some patches to resolve this issue. His code essentially implemented a reference counter, which would mark existing users of a given module as “safe” if they were running on the new patched code. Any code running in that module that was not yet marked “safe” would be running on the old version. Once all users were marked “safe”, the older version of that module would have no more users and could be removed from the running kernel safely.
Josh Poimboeuf had also worked on this code and offered some technical criticisms of Miroslav's patch. In particular, he pointed out that users could mess with the reference count for a given module, simply by disabling and re-enabling it in rapid succession within the kernel. Miroslav replied, “That is unfortunately true. I don't have a solution in my pocket that would be 100% reliable. At the same time I don't see a practical problem. Yes, refcount could overflow, but that shouldn't be a problem, should it? Anyway, I'll note it in the changelog.”
Apparently it's one of those bugs that occurs only under pathological circumstances, and so it doesn't really need a solid fix.
Other issues required further debate, and Jiri Kosina, who had the responsibility to accept the patch once it was ready and feed it up to Linus Torvalds, joined the discussion. There were various sequences of user actions that potentially could crash the system, and the code had to be able to deal with each of them before it could be accepted into the kernel. Also, the code had to avoid too many time-consuming checks along the way; it had to just work. So, for example, as Jiri put it at one point:
My understanding is that the concern here is that walking through the complete linked list every time sysfs node is accessed, just to figure out whether we're able to find a klp_patch entry that points back to the particular kobject that's being passed to the sysfs callback, isn't really super-efficient. I personally wouldn't worry that much about that particular aspect (sysfs operations are hardly considered time critical anyway), but I'd have to think a bit more whether this is really safe wrt Deadlocks between kernfs locks and klp_mutex; but so far it seems to me that klp_mutex always nests below kernfs, so it should be OK.
In a related post, Jessica Yu pointed out
If any of the sysfs functions get called, we would have to take care to ensure that the klp_patch struct corresponding to the kobject in question actually still exists. In this case, all sysfs functions would require an extra check to make sure the matching klp_patch is still on the patches list and return an error if it isn't found.
She said this would be simple to implement, but complex to conceptualize, and she suggested other alternatives as well.
Ultimately, there don't seem to be any major roadblocks standing in the way of this code, but there do seem to be a number of finicky nuances that everyone involved will need to consider very carefully. But, the code does seem on track to getting into the kernel.
Sometimes legacy features are brought back to life when hardware manufacturers begin to depend on them once again—in this case, ISA (Industry Standard Architecture), the 16-bit bus used on IBM systems in the 1980s. Recently, William Gray posted some patches to deal with modern hardware, such as PC/104 cards, which are modular, embeddable systems that run on the ISA bus. William's code enabled ISA support on a per-driver basis. As William put it:
This patch introduces the ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now build conditionally on the ISA_BUS_API Kconfig option, which defaults to the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the ISA_BUS_API Kconfig option to be selected on architectures which do not enable ISA (e.g. X86_64).
The ISA_BUS Kconfig option is currently only implemented for X86 architectures. Other architectures may have their own ISA_BUS Kconfig options added as required.
Linus Torvalds responded to William's post with a criticism of the way the dependencies were structured. He felt that the ISA symbol was defined for non-x86 architectures, and so the behavior of William's code on those architectures should be the same as on x86 systems. That is, Linus said that ISA_BUS_API should exist on all other architectures that depend on ISA, if that's the behavior we'd expect under x86.
After a few more versions of his patch, William posted one that was intended to be accepted into the kernel. This time, Linus replied, “This version seems fine and safe. I didn't see the other patches in the series (not cc'd to me), but at least this one would seem to do the right thing and expose part of the ISA code without causing other architectures to possibly lose it.”
In my “Non-Linux FOSS” piece in this issue, I talk about the newly open-sourced Simplenote application from the folks at Automattic. One of the other fairly new additions to their cross-platform note-syncing platform is that an Android app is available for free in the Google Play Store.
The Android app does pretty much all the same things the desktop or web-based app does, and it syncs between devices automatically. With many “syncing” apps, I find it frustrating that the syncing isn't reliable or consistent. I have to admit, this one seems pretty solid. Perhaps it's because it does text and only text—I'm not sure.
To be completely honest, Simplenote doesn't do nearly as many things as Evernote does; however, that seems to be by design. It is a “simple note” program, and it handles simple notes extremely well. Along with syncing to other devices, it also allows you to publish notes publicly on the web so others can see them (for example, simp.ly/publish/L75FXz). On top of that, it allows you to share notes between a group of users simply by tagging the note with their email addresses.
Simplenote may not be as robust as Evernote, but what it does with text is amazing. From my limited experience with it, it's also fairly reliable. If you're not using Simplenote for taking simple notes, you should give it a try. Just search for Simplenote in the Google Play Store. It's from the folks at Automattic, the same company responsible for WordPress.
I'm a big Evernote user. It's a powerful commercial program that allows you to sync text, photos and documents across multiple devices. Sadly, there's no native Linux client. Also, it's a proprietary software package, and that bums me out.
Simplenote has been an alternative to Evernote for quite some time now. It's created by Automattic, the folks behind WordPress. It's designed to sync only text-based notes, but that's usually all I want anyway. Recently, the developers at Automattic decided to release Simplenote as open source! They also compiled binaries for just about every platform out there, including Linux!
The data is synced into their cloud, so if you're not keen on someone else keeping a copy of your data, Simplenote might not be for you. The convenience of multi-platform synchronization is worth it for me. Since the software itself is open source, a person could look and see exactly what they do with your data as well.
Thanks mainly to its cross-platform capabilities, including multiple apps for mobile devices, I'm giving the new open-source Simplenote this month's Editors' Choice award. Grab a copy today from simplenote.com, or head over to its GitHub page and snag the source code: https://github.com/Automattic/simplenote-electron.
(For a look at the Android-specific version of Simplenote, check out my Android Candy piece also in the UpFront section of this issue.)
I've covered several different programs that are useful when doing electrical engineering in the past. In this article, I want to look at a program called linsmith (jcoppens.com/soft/linsmith/index.en.php) that helps you do calculations or see how different parameters behave.
Linsmith allows you to generate Smith charts for problems in electrical engineering, especially RF (radio frequency) circuits. Smith charts are a graphical way of representing the rather complex interactions that can happen when dealing with multiple nonlinear electrical components. You can use them to see how they interact and what happens if you vary some of the parameters.
Now, let's look at how to use linsmith to try to make this task a little easier. Throughout this article, I am assuming that you know enough about electrical circuits that I won't need to explain too many of the terms I'm using. If you want to learn more, a good place to start is the Wikipedia page for Smith charts: https://en.wikipedia.org/wiki/Smith_chart.
First, you will want to install it on your system. It should be in the package management system for your preferred distribution. For example, you can install it on Debian-based distributions with the command:
sudo apt-get install linsmith
Once it's installed, you can start it either by finding it within the menu system for your desktop environment or by running the linsmith command within a terminal window.
This program is strictly a graphical one, so you need to be running X11 in order to use it.
When it first starts, you will see a blank Smith chart, ready for use. On the right-hand side of the main window is a set of tabbed panels where you can enter the details of the electrical problem you are working on. This section is broken into loads that you can apply to the system, a circuit tab where you can define discrete circuit elements that are part of the problem, and a results tab where you can find a running log of the calculations being made.
Figure 1. When you first start linsmith, you will see a blank Smith chart, ready for you to use.
Now, let's look at what you can do in terms of applying loads to the system using the Loads tab. This section is actually broken down further into three more sub-tabs. The first one is labeled “R + jX”. This tab allows you to enter a load characterized by a frequency, given in mega-Hertz, and an impedance, given as a complex-valued number of Ohms. For example, you could enter a load of 140MHz, with an impedance of (25+j40) Ohms, by entering these values in the appropriate boxes and then clicking the button labeled New directly below them. This will place a new load value in the table of load impedances, and it will display a new yellow dot representing this load on the Smith chart.
Figure 2. Adding a new load adds a yellow point to the Smith chart.
Now that you have a load, you can alter it by adding in extra components. You can do this by clicking on the tab labeled Circuit. In the Component section, you can select from elements, such as capacitors, inductors or even transformers. For each of those components, there is a different set of parameters that you can use to define your new component.
As an example, you could add a capacitor of 40pF by clicking on the capacitor button and entering the value in the “Capacitor value:” text box. If you don't recognize the different component symbols, you can simply hover over them to see a text box appear.
Once you have the values all set, you can click on the New button just below the component section to add this element to your Smith chart. This will add a red line and a red end point on the Smith chart.
Figure 3. You can add components, such as capacitors.
In all cases, you can select an element that already exists to edit its values. When you select an item, you can edit its parameters in the appropriate boxes in the top of the pane. Once you're done, you need to click on the Update button to apply the changes to your Smith chart. These elements can be added either in series or in parallel. This option is in the section of the right-hand side panel labeled Connection.
Clicking on the Edit→Preferences menu item will open a new window where you can set several preferences for how linsmith can work. Several tabs covering several sections of options are available. The first tab, General, sets the most basic of parameters. The screen tab lets you set the image used as the background of the Smith chart, along with what colors you want to use for the various elements. The printing tab lets you set the paper size and margins, along with the colors to use for each of the parts of your Smith chart.
Figure 4. You can set a number of parameters using the preferences window.
In the main display, you should see a number of informational displays for your problem on the bottom bar. This is a Z Smith chart, so the values at the far left-hand side of the bottom bar are coordinates within the chart. On the right-hand side, there is a display of the SWR (Standing Wave Ratio) as well as the Q value for the problem. After this, there is a set of zoom buttons where you can zoom in on sections of the chart to see further details. There also is a button to recalculate the results of the Smith chart based on changes you may have made.
The last two options allow you to change the base values of the Smith chart. You can rotate the chart either to the load or to the generator. You also can change the normalization impedance from the default 50 Ohms to one of 75, 150, 300 or 600.
Once you're done, you can save your work in a few different ways. Under the File menu item, you can select to save either circuit details or load details as a separate file. Each of these sub-menus allows you to save data or load previous data. You also can import data from CSV files and s2p files. To save the final results, you can print the resultant Smith chart either by pressing Ctrl-P or by selecting the File→Print menu item. This way, you can save the chart to a PDF file. Hopefully, linsmith will be a useful tool for electrical engineers to add to their toolboxes.
Okay, that title really isn't fair. NethServer has all the Linux stuff, it's just that you don't have to interact with it in the traditional way in order to reap the benefits. NethServer is a web-based management software package built on top of CentOS. You can download it as a separate distribution, but truly, it's just software on top of CentOS. In fact, the installation methods are either “install the NethServer distro” or “add the NethServer repository to your existing CentOS install”. I really like that.
The concept behind NethServer isn't a new one. Lots of distributions are designed to simplify managing a server. I've written about ClearOS, Untangle and several others in the past. Plus, you always can just install Webmin on your server and get a “roll your own” web-administered system. The thing I like about NethServer is how well it allows you to configure services while not doing anything proprietary underneath. I think the interface is simple and intuitive as well.
Tons of features are available in the free community version of NethServer, but a few of the more advanced features require you to purchase a license. If you'd like to give NethServer a try, you either can download the ISO, install the repository on your existing server, or try the live Docker-based demo! Check it out at www.nethserver.org/demo-running-on-docker.
I feel a little weird sharing to a large audience the best way to get my attention when trying to pitch an idea or project. Still, the amount of ineffective email I get on any given day is overwhelming, so maybe it will be for the best. (See the screenshot, that's from yesterday afternoon.)
Last month, the community manager for Nethserver, Alessio Fattorini, contacted me via email. The message appeared to be written in earnest, so it got much farther than most email I get. Generally, I never make it past the subject line. Anyway, his message was a plea for help in learning how best to reach the media and journalists he wanted to write about his project. No one ever had asked me that before, so I wrote him back. Here's my message:
Alessio,
I've never been on your side of the equation, so I'm not sure how companies get contact info. I can tell you my process for deciding what to look at (the first step in deciding what to write about). I can also tell you what turns me off. This is just off the top of my head, and honestly, since this isn't my main job, I probably don't function like the folks who depend on such information on a daily basis. For me, I have 4–6 items a month that I highlight, so I tend to be picky.
1) I hate standard PR email messages. They tend to sound like they were written by a marketing department (they often are), and I personally don't care about how successful the CEO has been and so on. I want to know why a product announcement would be interesting to my readers, and I want to know early in the email. If your subject is “Blah blah announces new version...”, I generally don't even read it.
2) Keeping in mind the last sentence of the previous point, if you “trick” me into reading an email with a clever, deceptive title, I will not write about your product. I probably will dislike your product on principle and think you're a horrible person. (DirecTV has this new campaign where it sends out envelopes that look like greeting cards and appear to have handwritten addresses. When you open it, it's a cheesy “card” where the CEO or whomever is excited to tell you about the great prices DirecTV offers. I absolutely hate DirecTV now and never, ever will subscribe to its service!)
3) I like to know about new features that make your product unique, or if I don't know your product (assume I don't, it's a big world—for example, I have no idea what NethServer is), I want to know what makes it worth learning about. There's really no magic formula for this, because if there were, it already would be overused and wouldn't work anymore. But don't start your subject with “RE:”, as if we've been having a conversation about it, because that's starting to be a little too much like DirecTV.
4) This may be the most important: remember what your audience (press, in this case) is looking for. We want to entertain and inform our readers; we don't want to sell your product. I think of my readers as my friends (seriously, I'd totally buy you a cup of coffee if you were in the area), and I want to tell my friends about things that are interesting, useful and fun to talk about. I would never say to my friends, “Hey, there's a highly successful CEO that has pioneered a new product that will revolutionize the way we create virtual machines!” If I did, that friend should punch me in the face. I'd rather say something like, “Dude! Have you ever heard of NethServer? It's like Webmin, but it doesn't suck!” (I'm basing that on your email information, I have no idea if that's really what your product is like.)
The truth is, if you're excited and passionate about your product, don't hide it. Make sure I know you're excited about it and tell me why. At the end of the day, I'm just a guy with a lot of nerdy friends, and I love to tell them about cool stuff. If you have cool stuff, tell me about the stuff, not the company or the CEO or last quarter's earnings.
The response describes honestly how I go about picking subjects to share. If you have a project you'd like to share with the Linux Journal community, drop us an email at info@linuxjournal.com and tell us about it. But if I see “Dear $NAME” in the subject line, I might send sign you up for a Christmas card from DirecTV.
Nothing ever goes away.
—Barry Commoner
Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.
—George S. Patton
Nothing is particularly hard if you divide it into small jobs.
—Henry Ford
Another belief of mine: that everyone else my age is an adult, whereas I am merely in disguise.
—Margaret Atwood
Act as if it were impossible to fail.
—Dorothea Brande