Recently there was some discussion about ways to ease the tired backs of kernel maintainers. Apparently the merge windows are times of great labor, and some folks wanted to alert contributors to some preferable code submission habits.
There were a variety of ideas, and Kevin Cernekee summarized them in patch form, but one key idea was that none of this advice really could be treated as etched into stone. Linus Torvalds and Theodore Ts'o, in particular, pointed out that maintainers all have their own ways of doing things, and that no general rules could be relied on universally to produce repeatable results.
In general though, as Kevin posted, the merge window is not a great time to submit new patches. The merge window is the time after a new kernel version comes out and before the first -rc release. Developers either should avoid submitting patches at that time, or as was also discussed, they at least should not expect a reply to their patches, and they should avoid submitting any patch a second time during that period, if the first one seems to go unaccepted.
Kevin also posted a very rough calculation of when developers might expect to see their code in an official kernel. If they submit code within the first four -rc releases, they could expect to see their code in the next official kernel release. If they submit code within the remaining four -rc releases, they could expect to see it in the second following official release. Alan Cox thought this calculation very valuable, though Linus cautioned that it was really quite a rough estimate and highly dependent on any given maintainer's particular patch acceptance habits.
Richard Weinberger has suggested a security improvement aimed at attackers who target forking servers, such as httpd and sshd. Apparently by creating lots of forks, the attacker could make guesses about code locations in each forked memory allocation. After enough tries, it potentially could find the location of key code and launch a root shell in the parent process. That would be bad.
Richard's idea was to identify if a child process dies due to a fatal error and cause future forks to wait 30 seconds before executing. This would cause the attack to take much more time, but would tend not to inconvenience regular users.
There was some support for this idea and some opposition. Pavel Machek came to believe that Richard's patch was only trying to slow the kernel down in random ways, in the hope that it might help. But Kees Cook and Andy Lutomirski both felt that Richard's patch was highly targeted and would not unduly delay user code.
Richard had gotten his original idea while exploring the intricacies of the offset2lib weakness, which detailed a way for attacking code to identify the location of user libraries in memory. Once this location is known, there are relatively trivial ways to launch a root shell. Any technique by which an attacker could gain knowledge of the location of code in memory, therefore, must be considered a security hole and be fixed immediately. But, it's not always clear exactly how best to prevent that information from being seen.
The Arm and Arm64 projects are experiencing a kind of growing pain—some incompatibilities between the /proc/cpuinfo files on both architectures that are causing some user programs to lose portability.
Part of the problem is that the Arm64 developers need to incorporate all APIs from Arm into their code if they want to maintain portability, although they really want to abandon those APIs in favor of better ones. In the current case, the /proc/cpuinfo files will have to be brought in line with each other, even if there's code out there that depends on their differences.
Russell King had a bit to say about the situation, in the form of a cautionary tale:
As ARM64 wants to be compatible with ARM32 (in that it wants to be able to run ARM32 applications), ARM64 has to offer a compatible user API for everything that is a user API.
That means you have to generate an ARM32 compatible /proc/cpuinfo, ARM32 compatible hwcap information, ARM32 compatible signal structures, ARM32 compatible everything else. Which means you basically need to have a copy of the ARM32 core code in ARM64, even if you want a different native ARM64 user API.
This is exactly the reason why architectures like X86 decided it was silly having separated 32- and 64-bit, and why they went through a process of merging the two together. A lot of the code was identical, and a lot of the 32-bit-specific code was needed for 64-bit to provide the 32-bit API.
Right now, you're finding out this the hard way, and hitting these API problems in the process, and going “oh fsck” when you hit them—quite simply because you've backed yourselves into a corner over this. You have established a different ARM64 API because you didn't want the ARM32 legacy, but then you've found that you do need the ARM32 legacy. Now you're in the position of having to change the ARM64 API, possibly breaking ARM64 applications in the process.
Ever since my “tiny $20 tablet” project (see my Open-Source Classroom column in the March 2015 issue), I've been looking for more and more cool things to do with cheap Android devices. Although the few obvious ones like XBMC or Plex remotes work well, I've recently found that having Android devices around the house means I can gain back an old-school ability that went out of style in the late 1980s—namely, an intercom system.
If you remember the big white boxes screwed to the wall in the garage and basement so you could talk to the person in the kitchen about making sandwiches, you know exactly what I mean. With multiple Android devices around the house, it means I can send an audible message quickly without the need to call or text.
There are several great intercom apps in the Google Play store, like “Intercom for Android”, “Intercom for Android” (yes, more than one!), “Tikl” and so on. Each has its own set of advantages and disadvantages. Some work well over great distance by using the Internet, and some work with an ad hoc Wi-Fi connection between rooms. Whatever your instant communication needs, the intercom idea is one worth exploring, especially if you have multiple Android devices around your house. Download a few apps today, and let me know when that sandwich is done!
I love Bitcoin. It's not a secret; I've written about Bitcoin mining and cryptocurrency in the past. I'm the first to admit, however, that we're at the very beginning of the cryptocurrency age. Although it's becoming easier and easier to use Bitcoin (see www.coinbase.com, for example), the limited use cases combined with the wild volatility of price make Bitcoin the wild wild west of the financial world.
There are a few awesome ideas, however, that are brilliant in their simplicity. Certainly things like the Humble Bundle folks integrating Bitcoin purchasing and Overstock.com allowing Bitcoin purchases are great first steps. Those are really just re-inventing the wheel, however, because we already can buy things using existing forms of currency.
Enter ChangeTip.
Sending someone a tip or donation on the Internet generally has been done with something like PayPal. That's all well and good, but it's fairly cumbersome. The folks at www.changetip.com have made sending money over the Internet extremely simple, and fun!
With its integration into Twitter, Facebook, GitHub, Google+, YouTube, Reddit and more, ChangeTip makes sending money as simple as sending a Tweet. Thanks to the world of OAUTH, you don't even need to create an account on ChangeTip.com to claim or send funds. If you send money to people who don't have accounts, they simply sign in to ChangeTip via the social-media account from which you sent it to them, and the money will be there waiting for them. Oh, and the money? It's Bitcoin!
With its seamless integration to Coinbase, ChangeTip makes actual financial transactions secure, simple, and did I mention simple? Check it out today at changetip.com, or visit my personal page at shawnp0wers.tip.me. And, if you want incentive to try it out, I originally planned to include a bunch of “one-time links” in this article that could be claimed for $1 each. It turns out that the one-time links expire after a week. So although it might have been a great April Fool's joke, I really want to give everyone a chance to claim some tips, so keep reading!
On April 1st, 2015, watch my personal Twitter account (@shawnp0wers), and I'll tweet out some ChangeTip URLs worth actual money. Be the first to click the link, and you will be the proud owner of $1 from yours truly. I'll try to spread out the tweets throughout the day, so don't worry if you're reading this after work. It probably won't be too late!
Due to its awesome use of cryptocurrency and social media, along with the ease of use and ability to give money to folks who read my article, this month's Editors' Choice award goes to ChangeTip. Let's change the world!
(Note: I'm not asking for tips! I know many of you are really kind and generous, so I want to make it perfectly clear that posting the link to my ChangeTip page isn't my way of asking for tips. It's just so you can see how simple ChangeTip is to use!)
Elon Musk is known to be particularly apprehensive about artificial intelligence (https://twitter.com/elonmusk/status/495759307346952192). Although many of us are both excited and worried about the potential future of AI, most don't need to fear computers taking over in the creative realms of society.
Or do we?
Heading over to computoser.com both delights and concerns me. Using nothing more than algorithms and preloaded data, the Web site will generate completely unique and oddly pleasant electronic music. I expected the results to feel bland and single-dimensional, but honestly, some of the songs are incredible and seem to relay emotion that obviously was never there to begin with.
Although it might be the downfall of civilization and might mean the unemployability of creative folks like myself, you can taste the computer's creativity yourself. There's also an app in the Google Play store if you want some Skynet music in your pocket: play.google.com/store/apps/details?id=com.computoser.
No, really! While on a normal day, the word “Microsoft” can be used as an antonym for “Open”, the world of .NET seems to be going legitimately open source. I have to confess that my limited development knowledge doesn't give me a full appreciation of the significance of .NET and ASP.NET things being released into the open-source world the end of last year, but seeing actual GitHub repositories of the core technologies is encouraging.
Are you a Linux developer interested in branching into .NET programming now that it's open source? Are you a .NET developer who wants to develop for non-Microsoft platforms now that it's officially supported? Do you think Microsoft has done too little too late? Whatever your take, the .NET Foundation seems to be doing more than just releasing source code; the GitHub repositories are a significant step toward a real community. Check out the wide selection of Git repositories at https://microsoft.github.io.
If writers stopped writing about what happened to them, then there would be a lot of empty pages.
—Elaine Liner
The time to repair the roof is when the sun is shining.
—John F. Kennedy
The customer doesn't expect everything will go right all the time; the big test is what you do when things go wrong.
—Sir Colin Marshall
If the universe is bigger and stranger than I can imagine, it's best to meet it with an empty bladder.
—John Scalzi
Courage is the price that Life exacts for granting peace.
—Amelia Earhart
For any object moving through a fluid, forces are applied to the object as the fluid moves around it. A fluid can be something like water, or even something like the air around us. When the object is specifically designed to maximize the forces that the fluid can apply, you can designate these designs as airfoils. A more common name that most people would use is a wing. The shape of a wing, or airfoil, determines the forces that are applied to it when it moves through a fluid or the air. These forces also depend on the speed of motion through the fluid and the direction of flow around the airfoil.
With all of these parameters, how can you design airfoils? How do you optimize airfoils for a particular use? You need some way of analyzing all of this information—specifically, you need software that can run the numbers and do the calculations. There are very complex pieces of software that can analyze hydrodynamic problems in the abstract. But, with airfoils, you can limit the problem to such a degree that the equations are greatly simplified.
One of the software packages available to do these kinds of calculations is XFLR5 (www.xflr5.com/xflr5.htm). XFLR5 started as a fork of the much older xfoils program, but it has been extended with extra functionality.
Installation on Debian-based distributions can be done with the command:
sudo apt-get install xflr5
That command should install the XFLR5 documentation package as well.
When you start XFLR5 the first time, it is not very flashy. In fact, on my system, I end up with a plain black window.
Although you can design your own airfoil from scratch, doing so can be fairly tedious. It is much easier to take a previously designed airfoil as a starting point and make alterations. A good database of airfoil designs is located at the UIUC Airfoil Coordinates Database, containing nearly 1,600 airfoils (m-selig.ae.illinois.edu/ads/coord_database.html). The database contains DAT files, which contain the information you need to use in XFLR5. They also have GIF files, allowing you to see what the airfoil looks like before downloading the DAT file. Once you choose one, download the related DAT file and open it in XFLR5 by clicking on the menu item File→Open.
You can change the view to the OpPoint View by clicking the menu item View→OpPoint View or by pressing the F5 key.
At the bottom of the window, you can see airfoil characteristics, such as the thickness. Let's say that the first design change you need to make is to generate a thinner airfoil. You can do this by clicking the menu item Design→Scale camber and thickness or pressing the F9 key. This pops up a new window where you can change those characteristics.
When you make your changes and click OK, XFLR5 will ask you if you want to overwrite the current airfoil or if you want to create a new one. If you choose to create a new one, you will be able to switch between the various loaded airfoils using the drop-down at the top of the window.
Now, let's generate the polars to do some analysis on this new airfoil that you created. The easiest way to do this is to click the menu item Analysis→Batch Analysis. If you have a multi-core or multi-CPU machine, you can select the Multi-threaded Batch Analysis menu item instead to get it done more quickly. This pops up a new window where you can select the range of Reynolds numbers to do the analysis over, and the step size for each Reynolds number to use.
You also can select whether to do this for only the current foil, or you can do the analysis for a list of foils. Once you have all of the parameters set, you can click on the Analyze button at the bottom of the window. For each step, you will see an output message in the top right-hand pane telling you how many iterations were needed for convergence, and in the bottom left-hand pane, you will see the actual plotted values for each iteration of each step. Once it finishes, you can close this analysis window and go back to the main window. The polar view will be opened automatically, showing you all of the polar plots. You can select a single polar plot of interest by clicking on the menu item Polars→Polar Graphs, and then selecting the graph you want to see.
Now that you have a foil and its polars calculated, you can move on to three-dimensional analysis and look at a full wing design. Clicking on the menu item File→Wing and Plane Design will pop up a new view where you can design a new full wing. Within this new view, you will need to click on the menu item Wing-Plane→Define a New Wing to open up a new window to create your new wing.
You can give it a name and description, and set all kinds of characteristics. You also can select sections of your wing and use the airfoils that you designed in the earlier step to provide the cross-sections of the wing along its length. Once you are happy, you can click on the Save and Close button and see your new wing displayed in the main window.
You now need to test your wing and analyze how it will behave when it starts moving through the air. Clicking on the menu item Analysis→Analysis Definition will bring up a parameter window where you can set up the details of your analysis.
Once everything is set, click on the OK button to get back to the main window. Depending on what you are trying to do, you may need to set some advanced settings by clicking the menu item Analysis→Advanced Settings. Here, you can change items like the maximum number of iterations, the relaxation factor or the panel boundary conditions.
The final step is to set the number of sequential steps in the right-hand pane, under the analysis settings section. Clicking the Analyze button in the right-hand pane starts off the whole process.
You also can design an entire plane, which is made up of one or more wings as well as a tail and fins. You can do this by clicking on the menu item Wing-Plane→Define a New Plane. In this part of XFLR5, you can define your entire plane and see how it behaves as a complete object.
With XFLR5, you now can design your very own aircraft wings. This tool should be helpful for anyone, but especially for hobbyists who are designing their own RC aircraft. Cost is no longer a barrier for letting your creativity run wild. You might come up with a totally new, awesome wing design.
You can find more documentation at the main XFLR5 Web site, which can help you do more complex analysis. Some of it was written based on older versions, however, so the location of certain functions within XFLR5 has moved, and you may need to do some investigative work to figure out how to do similar tasks. But, it is definitely worth the minor amount of work involved.