LWN Weekly Edition
Leading itemsSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->Multipage format
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 20, 2009Coming soon: KMyMoney 1.0Back in 2005, your editor wrote a review of personal finance tools for Linux, focusing on GnuCash, Grisbi, and KMyMoney. The conclusion at the end of that research was that GnuCash had the strongest feature set, but that KMyMoney looked to surpass it sometime in the near future. Four years later, KMyMoney 0.8 remains the current stable series, but that is about to change; the long-awaited KMyMoney 1.0 release is imminent. So it seems time to revisit this important piece of free software.In 2005, GnuCash appeared to be at a low point. The port to GNOME 2 still wasn't done, distributors were talking about dropping the package, and developer morale seemed low. But when looking at KMyMoney, your editor saw a different picture:
KMyMoney, instead, is on a roll. The development community is
active and happy, features are being added at an impressive pace,
and that 1.0 release appears to be getting closer. At current
rates, it will be a matter of months, at most, before KMyMoney
surpasses GnuCash in every area which matters to most users - and
keeps on going.
Since then, GnuCash has produced a number of well-received releases and appears to (still) be the dominant program for personal finance management. Active development continues, with the long-defunct database storage option poised to make a return in GnuCash 2.4. On the KMyMoney side, instead, the 0.8 release that your editor reviewed is still the current major stable release; the 0.8.9 update came out in March, 2008. For whatever reason, things seemed to stall for a long time; if there were a need for more evidence that your editor's predictions deserve ridicule, this would be it. Behind it all, though, the KMyMoney developers have continued their work. As of this writing, the 1.0 release can be expected almost any time. Your editor pulled a copy from the project's CVS repository to see where things stand; the short answer is that KMyMoney has taken some important steps toward being a full-featured personal finance management program. For many (if not most) users, it should be all they ever need. Building the tool was relatively straightforward, with only a couple of "./configure; install a missing dependency; repeat" cycles required. One interesting surprise was that KMyMoney remains a KDE 3 application. Work is being done to port the code to KDE 4, but the developers are not making any promises about completion dates; getting the 1.0 release out the door seems to have taken priority. Despite being a KDE 3 application, KMyMoney will run fine in KDE 4 environments.
As with previous versions, KMyMoney includes an importer for files in the GnuCash format. It gets the job done, mapping GnuCash entries into the KMyMoney way of doing things without any real trouble. There's no support for the business features of GnuCash - KMyMoney is not looking to be a business bookkeeping application - but most users will never notice. Saving a file in KMyMoney 1.0 brings a nice surprise: the application has been integrated with GPG to encrypt financial files by default. For a user who already has a GPG key, it all works automatically, with no additional configuration work required at all. More advanced users can configure the application to encrypt for multiple keys or (to protect against disaster) for a special backdoor key controlled by the KMyMoney developers. The program also advertises the ability to save a file to an SQL database. According to the documentation, SQLite, MySQL, and PostgreSQL are all supported, but your editor was only offered SQLite as an option - and it didn't work. The database storage feature looks like something that is expected to mature in future releases.
There is a budgeting and forecasting module built into KMyMoney 1.0. The application can put together a provisional budget based on past transactions, then track how the user is doing against that budget in the future. The forecasting code can extrapolate trends into the future, giving the approximate date when the money runs out and foreclosure proceedings begin. The program was, however, unable to forecast when your editor's long-awaited federal bailout would arrive.
Some progress has been made with online banking; European users with banks supporting HBCI or OFX will be in luck. Your editor, lacking such a bank, was unable to test out those features. Importing of downloaded bank and credit card data is also now supported; the only working format, though is QIF. The GnuCash importer provides an intermediate window showing the transactions to be imported and providing an opportunity for the user to change what will be done. KMyMoney, instead, just dumps the transactions into the specified account; the user must then go through a mouse-heavy process to classify transactions that the program does not recognize. All of the needed functionality is there, but it's a bit rough around the edges. In summary, KMyMoney 1.0 is a solid application which now has support for all of the features most personal finance users will need. It appears to be quite stable; your editor was unable to make it misbehave or crash - at least, when not trying to use the database storage feature. The developers behind this tool should feel content as they head toward their 1.0 celebration. Thanks to their work, Linux users have two high-quality personal finance tools to choose from.
Null pointers, one month laterOn July 16, Brad Spengler disclosed an easily-exploitable kernel vulnerability based on getting the kernel to dereference a null pointer. This security hole affected a version of the kernel which had not been widely distributed, so it was a problem for relatively few users, but it highlighted a class of problems which was sure to be seen again. Given that, and given our community's perception of itself as being responsive to security problems, it should be safe to assume that steps were taken to prevent null pointer vulnerabilities from opening up systems in the future. The reality is that some things have truly improved, but that some important vulnerabilities remain.C programmers normally expect that an attempt to dereference a null (zero) pointer will result in a hardware exception which, in turn, causes the program to crash. This happens not because there is anything special about a pointer containing zero, but because the trick of not mapping valid memory at the bottom of the virtual address space has been known and used for decades. If no valid memory is mapped near address zero, the hardware will trap attempts to access memory in that range; that includes attempts to dereference null pointers. It is a useful setup which minimizes the damage caused by misuse of null pointers. The only problem is that, in the kernel environment, there is no guarantee that no valid memory is mapped at the bottom of the address space. The default is to not map anything there, but applications can request, via the mmap() system call, that the lowest addresses be made valid. So the null pointer address can be made to point to real memory, and this can happen entirely under the control of user space. User-space addresses remain valid when running in the kernel, so, if the kernel can be made to dereference a null pointer, it will be accessing user-controlled memory. Should the kernel try to jump to a null pointer, it will be running user-controlled code directly. Needless to say, this sequence of events would not be good for the security of the system. After the July disclosure, it was reasonably evident that more null-pointer vulnerabilities had to exist in the kernel. Such bugs are easy to create; all that is required is a missing initialization. A new function pointer added to a structure will be silently set to null by the compiler in every declaration which does not include an explicit initialization for that pointer. Kernel programmers may be diligent about checking for null pointers, but they are human and will miss an occasional check. At times, these checks have been actively discouraged on the reasoning that dereferencing the pointer would, by virtue of oopsing the kernel, provide the same information as the check. For all of these reasons, one must conclude that there will be other situations in which the kernel can be tricked into dereferencing null pointers. Given that, it would behoove us all to build our systems in ways which are resistant to null-pointer attacks. The /proc/sys/vm/mmap_min_addr parameter was meant to be the first line of defense here; it specifies the lowest address which can be mapped by unprivileged user-space code. Unfortunately, this protection proved porous. Systems with SELinux running, as it turns out, allowed "unconfined" users to map low memory regardless of the mmap_min_addr setting. For many other systems, it was possible to exploit a problem with pulseaudio to run code with the SVR4 personality, which resulted in a mapped zero page. All told, these problems enabled an attacker to bypass the low-memory limits and exploit null-pointer vulnerabilities. On August 13, another null pointer vulnerability turned up; this one resulted from the combination of a missing function pointer initialization and a failure to check the pointer before jumping to it. It was an easily exploited hole; demonstration code was duly posted and there have been reports that attack code is already attempting to use this vulnerability. The kernel itself was patched quickly, even if the commit which closed this vulnerability was less than forthcoming about the problem:
Make sock_sendpage() use kernel_sendpage(). kernel_sendpage() does
the proper default case handling for when the socket doesn't have a
native sendpage implementation.
Linus did mention the problem in the 2.6.31-rc6 announcement, though:
There's the NULL pointer fix that was already talked up on
Slashdot, but quite frankly, assuming we got all the "you can't map
things at zero" issues fixed from the last scare, that one
hopefully wasn't quite as bad as it could have been.
So, do "we" really have all of those issues fixed? We do not, though some important progress has been made in that direction. Take Fedora as an example: the SELinux policy problem which unconditionally allowed "unconfined" users to map low memory has been fixed; as a result, Fedora systems with SELinux running in the enforcing mode are not vulnerable. But the underlying means by which security modules bypass the mmap_min_addr check has not been fixed. So unpatched Fedora systems with SELinux in permissive mode are vulnerable, even though systems with SELinux disabled entirely are not. Updates for Fedora were released on August 15, two days after the disclosure of the vulnerability. Two days may seem slow for a problem of this nature, but, as it happens, only one distributor - Debian - got an update out more quickly. Red Hat has not, as of this writing, issued an update for this vulnerability. That is unfortunate because most RHEL systems are vulnerable as the result of a policy choice made by Red Hat. RHEL systems, by default, allow "unconfined" users to map low addresses addresses. Red Hat's Dan Walsh explains: "We are not planning on changing the default in RHEL5, to maintain backwards compatibility." So, because compatibility trumps security, RHEL systems (and those running distributions based on RHEL) remain vulnerable to a trivial local root problem with exploit code easily available and in use. Not good. As of this writing, no other distributors have fixed this problem (though Mandriva's update showed up just before publication). Given that this vulnerability affects every kernel released since 2001, every distribution will have shipped vulnerable kernels. Even those which do not enable SELinux and which have taken steps to mitigate the other zero-page mapping problems should really be moving quickly to close this hole. Leaving the barn door open may not be a wise course of action, even if one trusts the fence which has been built around the barn. One also should not forget all of those older systems, including embedded systems like DSL routers, which will be exposed to this vulnerability. This hole could be a boon to people trying to liberate the devices they own, but it could also be an easy way to take control of important systems which have long since been forgotten about. 2.4 kernels, too, are affected by this problem; it is easy to imagine that the bulk of these older systems will never be fixed. One month ago we got an undeniable warning that this kind of vulnerability was coming. The security of many of our systems has undoubtedly improved over the course of that month. Even so, the latest null pointer vulnerability would appear to have taken some distributors by surprise; important holes have not been closed and updates have, in some cases, been slow in coming. We can - and should - do better than this.
Devices that phone homeBy some accounts, the Palm Pre is a nice device; it is, of course, based on Linux. Joey Hess recently stirred up a bit of a fuss when he dug into his device and determined that it was reporting a surprising amount of personal information back to Palm. It seems that Palm knows where Pre owners are, as determined by the GPS receiver; the device also reports information on application use, program crashes, and more. All of this activity is covered under Palm's posted privacy policy, but it is sure to come as a surprise to many users.Palm is not alone in this kind of activity. More recent Android phones put up a disconcerting confirmation dialog when asked to calculate location information from the cellular network:
Location consent: Allow Google's location service to collect
anonymous and aggregate location data. Collection will occur
regardless of whether any applications are active.
If the user withholds consent, the location service will not function at all. Android devices also upload a great deal of other personal information - the phone book, for example - to Google's servers. Amazon's Linux-based Kindle uses its built-in cellular modem to send back log files, information about what books are on the device, bookmark locations, notes, and more. There is no way to turn this reporting off short of disabling the wireless connection. One of the key advantages of free software was supposed to be freedom from this kind of surveillance. With control over the software on our systems, we can remove feature which were put there for somebody else's benefit. We don't have to create systems which will report our location, application choices, reading preferences, and more to some remote mothership. When we control our systems, we can ensure that those systems don't sell us out to others. But the three examples listed above are all Linux-based systems. We may be running free software, but we are not getting all of the benefits that freedom is supposed to bring to us. Just because a system is running free software does not mean that it is your friend. Ensuring our freedom to control devices like these is part of the motivation behind the anti-DRM provisions added to version 3 of the GNU General Public License. Devices running GPLv3-licensed software must make it possible for users to rebuild and replace that software; said users can, in the process, omit any misfeatures that they feel they can do without. But it must be said: GPLv3 appears to have failed in this regard, so far; vendors of closed devices have generally just chosen to avoid software with that license. Your editor is unaware of a single device which was left open because GPLv3 required it. In any case, many platforms are sufficiently open to enable other solutions to the worst problems. Joey posted a workaround (delete /usr/bin/contextupload) for Palm devices. Fully-open Android devices are available, and those which are not open by design can generally be liberated after the fact. It also appears to be possible to make significant changes to how Kindle devices work - a subject your editor intends to look into in the near future. There are still benefits to having these systems run Linux, even if they are locked down; we understand well how they work and are well equipped to make changes. That said, the number of users actually making such changes has got to be quite small. It would seem that, as a general rule, we are little concerned about the loss of our privacy. Perhaps views will change after, as seems inevitable, some company is caught badly abusing data collected in this manner. Or, perhaps, life will replicate John Varley's Steel Beach, where Lunar residents restore full power to their Central Computer even after it tried to kill them all because having access to its services is so convenient. It is often the case that having our information available to others is most convenient. Regardless of how things go, we can only hope to make informed choices if we know what our devices are actually doing. And we'll only know that if we can see what those devices are up to. Knowing that they run something based on Linux is far from enough. That's why attempts to use laws like the US DMCA to shut down investigation and liberation of devices are so scary. It's bad enough to be unable to run the software we want on our devices; being unable to see what those devices are doing behind our backs is even worse.
Security Google's Chromium sandboxCreating a sandbox—a safe area in which to run untrusted code—is a difficult problem. The successful sandbox implementations tend to come with completely new languages (e.g. Java) that are specifically designed to support that functionality. Trying to sandbox C code is a much more difficult task, but one that the Google Chrome web browser team has been working on. The basic idea is to restrict the WebKit-based renderer—along with the various image and other format libraries that are linked to it—so that browser-based vulnerabilities are unable to affect the system as a whole. A successful sandbox for the browser would eliminate a whole class of problems that plague Firefox and other browsers that require frequent, critical security updates. Essentially, the browser would protect users from bugs in the rendering of maliciously-crafted web pages, so that they could not lead to system or user data compromise. The Chrome browser, and its free software counterpart, Chromium, is designed around the idea of separate processes for each tab, both for robustness and security. A misbehaving web page can only affect the process controlling that particular tab, so it won't bring the entire browser down if it causes the process to crash. In addition, these processes are considered to be "untrusted", in that they could have been compromised by some web page exploiting a bug in the renderer. The sandbox scheme works by severely restricting the actions that untrusted processes can take directly. At some level, Linux already has a boundary that isolates programs from the underlying system: system calls. A program that does no system calls should not be able to affect anything else, at least permanently. But it is a trivial program indeed that does not need to call on some system services. A largely unknown kernel feature, seccomp, allows processes to call a very small subset of system calls—just read(), write(), sigreturn(), and exit()—aborting a process that attempts to call any other. That is the starting point for the Chromium sandbox. But, there are other system calls that the browser might need to make. For one thing, memory allocation might require the brk() system call. Also, the renderer needs to be able to share memory with the X server for drawing. And so on. Any additional system calls, beyond the four that seccomp allows, have to be handled differently. A proposed change to seccomp that would allow finer-grained control over which system calls were allowed didn't get very far. In any case, that wasn't a near-term solution, so Markus Gutschke of the Chrome team went in another direction. By splitting the renderer process into trusted and untrusted threads, some system calls could be allowed for the untrusted thread by making the equivalent of a remote procedure call (RPC) to the trusted thread. The trusted thread could then verify that the system call, and its arguments, were reasonable and, if so, perform the requested action. Chrome team member Adam Langley describes it this way:
So that's what we do: each untrusted thread has a trusted helper thread
running in the same process. This certainly presents a fairly hostile
environment for the trusted code to run in. For one, it can only trust its
CPU registers - all memory must be assumed to be hostile. Since C code will
spill to the stack when needed and may pass arguments on the stack, all the
code for the trusted thread has to [be] carefully written in assembly.
The trusted thread can receive requests to make system calls from the untrusted thread over a socket pair, validate the system call number and perform them on its behalf. We can stop the untrusted thread from breaking out by only using CPU registers and by refusing to let the untrusted code manipulate the VM in unsafe ways with mmap, mprotect etc. There are still problems with that approach, however. For one thing, the renderer code is large, with many different system calls scattered throughout. Turning each of those into an RPC is possible, but then would have to be maintained by the Chromium developers going forward. The upstream projects (WebKit, et. al.) would not be terribly interested in those changes, so each new revision from upstream would need to be patched and then checked for new system calls. Another approach might be to use LD_PRELOAD trickery to intercept the calls in glibc. That has its own set of problems as Langley points out: "we could try and intercept at dynamic linking time, assuming that all the system calls are via glibc. Even if that were true, glibc's functions make system calls directly, so we would have to patch at the level of functions like printf rather than write." So, a method of finding and patching the system calls at runtime was devised. It uses a disassembler on the executable code, finds each system call and turns it into an RPC to the trusted thread. Correctly parsing x86 machine code is notoriously difficult, but it doesn't have to be perfect. Because the untrusted thread runs in seccomp mode, any system call that is missed will not lead to a security breach, as the kernel will abort the thread if it attempts any but the trusted four system calls. As Langley puts it:
But we don't need a perfect disassembler so long as it works in practice
for the code that we have. It turns out that a simple disassembler does the
job perfectly well, with only a very few corner cases.
The last piece of the puzzle is handling time-of-check-to-time-of-use race conditions. System call arguments that are passed in memory, via pointers or for system calls with too many arguments to fit in registers, can be changed by the, presumably subverted, untrusted thread between the time they are checked for validity and when they are used. To handle that, a trusted process, which is shared between all of the renderers, is created to check system calls that cannot be verified within the address space of the untrusted renderer. The trusted process shares a few pages of memory with each trusted thread, which are read-only to the trusted thread, and read-write for the trusted process. System calls that cannot be handled by the trusted thread, either because some of the arguments live in memory, or because the verification process is too complex to be reasonably done in assembly code, are handed off to the trusted process. The arguments are copied by the trusted process into its address space, so they are immune to changes from the untrusted code. While the current implementation is for x86 and x86-64—though there are still a few issues to be worked out with the V8 Javascript engine on x86-64—there is a clear path for other architectures. Adapting or writing a disassembler and writing the assembly language trusted thread are the two pieces needed to support each additional architecture. According to Langley:
The former is probably
easier on many other architectures because they are likely to be more
RISC like. The latter takes some work, but it's a coding problem only
at this point.
There are some potential pitfalls in this sandbox mechanism. Bugs in the implementation of the trusted pieces—either coding errors or mistakes made in determining which system calls and arguments are "safe"—could certainly lead to problems. Currently, deciding which calls to allow is done on an ad hoc basis, by running the renderer, seeing which calls it makes, and deciding which are reasonable. The outcome of those decisions are then codified in syscall_table.c. One additional, important area that is not covered by the sandbox are plugins like Flash. Restricting what plugins can do does not fit well with what users expect, which makes plugins a major vector for attack. Langley said that the plugin support on Linux is relatively new, but "our experience on Windows is that, in order for Flash to do all the things that various sites expect it to be able to do, the sandbox has to be so full of holes that it's rather useless". He is currently looking at SELinux as a way to potentially restrict plugins, but, for now, they are wide open. This is a rather—some would say overly—complex scheme. It is still in the experimental stage, so changes are likely, but it does show one way to protect browser users from bugs in the HTML renderer that might lead to system or data compromise. It certainly doesn't solve all of the web's security problems, but could, over time, largely eliminate a whole class of attacks. It is definitely a project worth keeping an eye on. [ Many thanks to Adam Langley, whose document was used as a basis for this article, and who patiently answered questions from the author. ]
Brief items Another kernel NULL pointer vulnerabilityTavis Ormandy has disclosed a new, easily-exploited NULL pointer vulnerability in the Linux kernel; this one comes from the networking code when any of a number of relatively obscure protocols are used. A fix has been merged into the mainline, but there's likely to be a lot of exploitable kernels out there.
New vulnerabilities cdf: buffer overflows
Compress::Raw::Bzip2: buffer overflow
curl: null prefix vulnerability
dillo: integer overflow
dokuwiki: input sanitization error
kernel: privilege escalation
pidgin: remote code execution
thunderbird: multiple vulnerabilities
viewvc: multiple vulnerabilities
zope: multiple vulnerabilities
Page editor: Jake Edge Kernel development Brief items Kernel release statusThe current development kernel is 2.6.31-rc6, released on August 14. "There's nothing hugely interesting there, although I'm personally gratified by the fact that I have a few more commits than usual. Even if they are all really small, it makes me feel useful." See the announcement for the short-form changelog and some comments on the latest NULL pointer vulnerability fix.The current stable kernel is 2.6.30.5, released (along with 2.6.27.30) on August 16. Both contain a long list of fixes for a number of significant problems. Note that 2.6.27.30 had a compilation problem; 2.6.27.31 was released shortly thereafter with a fix for that one issue. The current ancient kernel is 2.4.37.5, released on August 13 with a fix for the latest null pointer vulnerability (which affects 2.4 kernels as well as 2.6).
Kernel development news Quotes of the week
And I'm tired of being stupid. So this patch makes me smart and
forward-thinking instead.
-- Linus Torvalds
There is also a feeling from some people in this community (they've
told me themselves in private) that certain mainline folk have been
actively trying to undermine the ARM community - given the recent
"discussions" (more like flames) over things like the device tree,
the HTC stuff, etc.
-- Russell King
So System.map is part of the kernel API too? Sigh.
-- Andrew Morton
In briefLow-memory mapping. The recent set of null-pointer vulnerabilities has not been helped by the confusion around how the mmap_min_addr knob and security modules interact. The 2.6.31-rc7 kernel will see a couple of changes intended to clarify and rationalize this interaction. With these patches, SELinux will no longer bypass the mmap_min_addr check; any process wanting to map memory below that address will require the CAP_SYS_RAWIO capability. However, SELinux will also implement its own low-memory limit, controlled by a separate knob in the SELinux policy. As a result, it will be possible to turn off the mmap_min_addr protection but still only allow specific programs to do low-memory mapping.Module loading security. Another SELinux-related change - not yet merged into the mainline - adds a new hook to request_module(). The idea here is to try to limit the ability of user-space programs to load arbitrary modules into a running kernel. In future versions of the SELinux policy, the ability to trigger module loads is likely to be reduced to a much smaller set of roles. HugeTLB mappings. The "hugetlb" feature allows processes to create pseudo-anonymous memory mappings backed by pages which are larger (perhaps much larger) than the normal system page size. For certain kinds of applications, these mappings can improve performance by reducing pressure on the CPU's translation lookaside buffer (TLB). The kernel code resides within such a mapping for the same reason. Using hugetlb pages in user space is a bit awkward, though; it requires mounting the special hugetlbfs filesystem and mapping files from there. Eric Munson has put together a patch implementing an easier way. With this patch, the mmap() system call understands a new MAP_HUGETLB flag; when that flag is present, the kernel will attempt to create a mapping backed by huge pages. Underneath it all, the mapping is still implemented as a hugetlbfs file, but user space need no longer be aware of that fact. spin_is_locked(). Kernel code can test the current state of a spinlock with spin_is_locked(). But what should this function return on a single-processor system, where spinlocks do not exist at all? Kumar Gala ran into trouble because one uniprocessor spin_is_locked() implementation returned zero. The problem was code in this form:
/* Ensure we have the requisite lock */
BUG_ON(!spin_is_locked(&some_lock));
So Kumar thinks that the return value should always be true. But there are other situations where that is just the wrong thing to do; Linus gave an example where code is waiting for a lock to become free. The real problem is that a predicate like spin_is_locked() simply lacks a well-defined meaning when the spinlock does not exist. So there is no way to always give the "right" answer in such situations. What may happen instead is that, in a future kernel, spin_is_locked() will be deprecated. Instead, there will be new expect_spin_locked() and expect_spin_unlocked() primitives for testing the state of a spinlock. When the code is this explicit about what it is looking for, the default answer can make sense; both would return true on uniprocessor systems. localmodconfig. Many kernel testers want to build a kernel which looks like the kernel shipped with their distribution. But distributor kernels come with a configuration which builds almost everything. So our poor tester ends up waiting for a very long time as the system builds a bunch of modules which will never be used. One could avoid this problem by creating a new configuration from scratch, but that process can be a little daunting as well. There are a lot of configuration options in a contemporary kernel. Steven Rostedt has posted a build system change intended to help with this problem. A user who types:
make localmodconfig
will get a configuration which builds all modules currently loaded into the running system, but no others. That should be a configuration which supports the system's hardware, but which lacks hundreds of useless modules. There is also a localyesconfig option which builds the required drivers directly into the kernel.
Runtime power managementWhile a great deal of power management work has been done on Linux systems in recent years, much of that work has been directed toward the creation of working suspend and hibernation capabilities. But there is more to power management than that; there is real value in being able to minimize the power consumption of a running system. That is as true for large data center machines as it is for laptops; reduced power usage and lower air conditioning requirements have both economic and environmental benefits. Now that the suspend problem is mostly solved, increasing amounts of attention are being paid to the other aspects of power management; some recent patches show how the infrastructure for runtime power management is coming together.The core of the future power management structure appears certain to be Rafael Wysocki's runtime power management patch. This patch set adds structure to the power management code to facilitate the suspending and resuming of individual system components at run time. The dev_pm_ops structure is augmented with three new functions:
int (*runtime_suspend)(struct device *dev);
int (*runtime_resume)(struct device *dev);
int (*runtime_idle)(struct device *dev);
These functions are to be implemented by the core device code for each bus type; they may then be turned into bus-specific driver callbacks. The power management code will call runtime_suspend() to prepare a specific device for a lower-power state. This call does not imply that the device itself must suspend, but the device does need to prepare for a condition where it is no longer able to communicate with the CPU or memory. In other words, even if the device does not suspend, hardware between that device and the rest of the system might suspend. A return value of -EBUSY or -EAGAIN will abort the suspend operation. A call to runtime_resume() should prepare the device to operate again with the rest of the system; the driver should power up the device, restore registers, and do anything else needed to get the device functioning again. The runtime_idle() callback, instead, is called when the core thinks that the device is idle and might be a good candidate for suspending. The callback should decide whether the device can really be suspended (this could include checking the state of any other devices connected to it) and, if all seems well, initiate a suspend operation. Along with these callbacks is, of course, a set of core functions designed to manage suspend and resume activities, deal with mid-course cancellations, allow outside code to make power management changes, and so on. See the associated document file for more information on how this subsystem works. The code described above has been through several review iterations and would appear to be on track for merging in 2.6.32. Rafael's asynchronous suspend and resume patch, instead, is rather newer and may take a little longer. The idea behind this patch is to extend the runtime power management code to allow suspend and resume callbacks to be invoked asynchronously; that, in turn, would allow them to be run in parallel. As long as there are no dependencies between a pair of devices, suspending or resuming them in parallel should make full-system transitions faster. The problem is in the dependencies; running a bunch of power management operations in parallel increases the risk of getting the order wrong. To avoid this outcome, the patch adds a new completion object to each device; when a device is to be suspended, the completions will be used to ensure that any dependent devices are suspended first. At resume time the completions are used in the reverse direction: devices wait for their parent devices to be resumed before resuming themselves. As long as the dependency information is correct, this mechanism should ensure that a set of power management threads can run in parallel without breaking the system. Ensuring that the dependencies are correct was one of the reasons for the creation of the Linux device model years ago. With a properly-constructed tree, the system can know, for example, that it cannot suspend a USB controller until all USB devices plugged into it have been suspended. In turn, the PCI controller to which the USB controller is attached must remain functional until the USB controller is suspended, and so on. The problem is that system dependencies are not always that simple. A PCI device may also require the services of an I2C controller, for example, or devices can be combined on multi-function chips in surprising ways. So the device tree has proved unable to represent all of the power management dependencies in the system. Rafael has addressed this problem in a later version of the patch, which adds a new framework for representing power management dependencies. At the core of it is this structure:
struct pm_link {
struct device *master;
struct list_head master_hook;
struct device *slave;
struct list_head slave_hook;
};
One of these structures exists for each dependency known to the system. It indicates that the "master" device must always be functional whenever the "slave" device is; the master must be suspended after the slave and resumed before it. Many of these links can be created by the power management core itself; others will have to be generated by the relevant drivers. There have been some concerns raised about the memory use of this structure, but a better solution has not yet been proposed. Meanwhile, Matthew Garrett has taken the core power management code one step further with a set of runtime power management patches of his own. He has pushed the new power management calls down into the PCI and USB bus layers and used them to suspend devices opportunistically as the system runs; he reports a power savings of around 0.2 watts as a result. Review comments resulted in these patches being withdrawn for now for repairs, but they show the direction things are heading. With sufficient software support and cooperative hardware, Linux should be able to further reduce the operating power needed for whole classes of systems. That cannot fail to be a good thing.
A new API for kfifo?The kernel FIFO implementation, kfifo, is not that widely used and Stefani Seibold would like to see that change. To that end, she has proposed a new kfifo API that embodies many of the design patterns for data structures that were described by Neil Brown. The new interface is simpler in many ways, so it should be easier to use, which, in turn, could lead to more use throughout the kernel. The basic problems with the current kfifo interface stem from the constraints it places on its users. A spinlock is required, though it is not needed by the majority of current kfifo users. Also, the kfifo structure can only be allocated dynamically, so users cannot put FIFOs inside of other structures—only pointers to FIFOs. Moreover, according to Seibold, the current API is too simple and doesn't provide a number of important features. The new API has 23 separate functions, while the current has 9, but there are quite a few variants that increase the total. Those variants include copying from or to user space, supporting fixed-length records, as well as being able to use spinlocks to synchronize adding or removing data from the FIFO. It supports many different use cases in the style of Brown's "Broad Interfaces" pattern. A kfifo is declared using the DECLARE_KFIFO() macro which can be used inside of a struct or union declaration. FIFOs declared with with DECLARE_KFIFO() must be initialized using INIT_KFIFO(). Alternatively, DEFINE_KFIFO() handles both the declaration and initialization for FIFOs outside of struct/union declarations. The macros take name (to name the variable or struct/union element) and size (in bytes) parameters:
DECLARE_KFIFO(name, size)
INIT_KFIFO(name)
DEFINE_KFIFO(name, size)
There are two functions to support dynamic buffer allocation:
int kfifo_alloc(struct kfifo *fifo, unsigned int size, gfp_t gfp_mask)
which allocates a buffer of size bytes using the gfp_mask
as flags to pass to kmalloc(). Or, a pre-allocated buffer can be
attached to a kfifo using:
void kfifo_init(struct kfifo *fifo, unsigned char *buffer, unsigned int size)
Any buffer allocated by kfifo_alloc() should later be freed by
calling kfifo_free().
To put data into the FIFO, kfifo_in() is used:
unsigned int kfifo_in(struct kfifo *fifo,
unsigned char *from, unsigned int n)
which returns the number of bytes stored. As mentioned above there are
variants for getting the data from user space, as well as for locking:
unsigned int kfifo_from_user(struct kfifo *fifo,
const void __user *from, unsigned int n)
unsigned int kfifo_in_locked(struct kfifo *fifo,
const unsigned char *from, unsigned int n, spinlock_t *lock)
As one might guess, the calls to remove data from the FIFO look similar—if reversed:
unsigned int kfifo_out(struct kfifo *fifo,
unsigned char *to, unsigned int n)
unsigned int kfifo_to_user(struct kfifo *fifo,
void __user *to, unsigned int n)
unsigned int kfifo_out_locked(struct kfifo *fifo,
unsigned char *to, unsigned int n, spinlock_t *lock)
In the common case, with only one reader and one writer, extra locks are not
required to add or remove data from the FIFO, but for more complicated
scenarios, the *_locked() variants allow the caller to use the
appropriate lock.
The expected tests for FIFO full and empty (kfifo_is_full() and kfifo_is_empty()) are present, as are ways to get FIFO size and available space (kfifo_size(), kfifo_len(), and kfifo_avail()). One can also consume some FIFO bytes without returning them using kfifo_skip() or clear the entire FIFO with kfifo_reset(). There is also support for fixed-length records, with either 1- or 2-byte lengths stored with each entry. Each call must pass a recsize parameter that specifies the size of the length field (i.e. 1 or 2, though 0 is supported for no length) stored with each entry:
unsigned int kfifo_in_rec(struct kfifo *fifo,
void *from, unsigned int n, unsigned int recsize)
unsigned int kfifo_from_user_rec(struct kfifo *fifo,
const void __user *from, unsigned int n, unsigned int recsize)
unsigned int kfifo_out_rec(struct kfifo *fifo,
void *to, unsigned int n, unsigned int recsize,
unsigned int *total)
unsigned int kfifo_to_user_rec(struct kfifo *fifo,
void __user *to, unsigned int n, unsigned int recsize,
unsigned int *total)
These functions return the number of bytes not copied, which is a
bit strange. For the functions that remove data from the FIFO,
*total stores the number of bytes actually copied. This part of
the interface seems a little dubious, and may not survive in its present
form, though no comments along those lines have been seen.
Overall, the interface has been fairly well-received. There were a few comments on an earlier version of the API, which Seibold has mostly addressed. The only comments on the most recent version (v0.4) were a disagreement between Alan Cox and Andrew Morton over naming conventions. Cox would rather not see the current kfifo_put() and kfifo_get() calls get removed quite yet, noting "We are about to set fifo loose through all the USB and some other char/serial drivers all of which will use the spinlock facility." The current calls use the spinlock, so the kind of change Seibold is proposing would need to be reflected in the USB and char/serial driver code. But Morton thinks that this is the right time to make those changes, because "kfifo has no business assuming that the caller wants to use spin_lock() locking". The basic problem is that Morton would like to see a convention followed that things like kfifo_put() (or, kfifo_in() as Seibold's API defines it) do not assume locking. He agrees with Seibold's decision to add a separate kfifo_*_locked() variants. Cox points out that the convention is very inconsistently followed, but Morton is adamant:
Plus, as I've said enty en times and keep getting ignored: the current
naming is wrong. The generic kfifo_get() should not be assuming that
the caller wants spinlock-based locking.
After initially NAK-ing part of the patch, Cox seems to have relented, so that particular barrier is gone. It would seem far too late in the 2.6.31 process for this kind of change to go in, but unless some other major issues crop up, it is quite possible that a new kfifo API could show up in 2.6.32.
The trouble with discardTraditionally, storage devices have managed the blocks of data given to them without being concerned about how the system used those blocks. Increasingly, though, there is value in making more information available to storage devices; in particular, there can be advantages to telling the device when specific blocks no longer contain data of interest to the host system. The "discard" concept was added to the kernel one year ago to communicate this information to storage devices. One year later, it seems that the original discard idea will not survive contact with real hardware - especially solid-state storage devices.There are a number of use cases for the discard functionality. Large, "enterprise-class" storage arrays can implement virtual devices with a much larger storage capacity than is actually installed in the cabinet; these arrays can use information about unneeded blocks to reuse the physical storage for other data. The compcache compressed in-memory swapping mechanism needs to know when specific swap slots are no longer needed to be able to free the memory used for those slots. Arguably, the strongest pressure driving the discard concept comes from solid-state storage devices (SSDs). These devices must move data around on the underlying flash storage to implement their wear-leveling algorithms. In the absence of discard-like functionality, an SSD will end up shuffling around data that the host system has long since stopped caring about; telling the device about unneeded blocks should result in better performance. The sad truth of the matter, though, is that this improved performance does not actually happen on SSDs. There are two reasons for this:
One would assume that the second problem will eventually go away as the firmware running in SSDs gets smarter. But the first problem can only be fixed by changing the protocol specification, so any possible fix would be years in the future. It's a fact of life that we will simply have to live with. There are a few proposals out there for how we might live with the performance problems associated with discard operations. Matthew Wilcox has a plan to reimplement the whole discard concept using a cache in the block layer. Rather than sending discard operations directly to the device, the block layer will remember them in its own cache. Any new write operations will then be compared against the discard cache; whenever an operation overwrites a sector marked for discard, the block layer will know that the discard operation is no longer necessary and can, itself, be discarded. That, by itself, would reduce the number of TRIM operations which must be sent to the device. But if the kernel can work to increase locality on block devices, performance should improve even more. One relatively easy-to-implement example would be actively reusing recently-emptied swap slots instead of scattering swapped pages across the swap device. As Matthew puts it: "there's a better way for the drive to find out that the contents of a block no longer matter -- write some new data to it." In Matthew's scheme, the block layer would occasionally flush the discard cache, sending the actual operations to the device. The caching should allow the coalescing of many operations, further improving performance. Greg Freemyer, instead, suggests that flushing the discard cache could be done by a user-space process. Greg says:
Assuming we have a persistent bitmap in place, have a background
scanner that kicks in when the cpu / disk is idle. It just
continuously scans the bitmap looking for contiguous blocks of
unused sectors. Each time it finds one, it sends the largest
possible unmap down the block stack and eventually to the device.
When normal cpu / disk activity kicks in, this process goes to sleep. A variant of this approach was posted by Christoph Hellwig, who has implemented batched discard support in XFS. Christoph's patch adds a new ioctl() which wanders through the filesystem's free-space map and issues large discard operations on each of the free extents. The advantage of doing things at the filesystem level is that the filesystem already knows which blocks are uninteresting; there is no additional accounting required to obtain that information. This approach will also naturally generate large operations; larger discards tend to suit the needs of the hardware better. On the other hand, regularly discarding all of the free space in a filesystem makes it likely that some time will be spent telling the device to discard sectors which it already knows to be free. It is far too soon to hazard a guess as to which of these approaches - if any - will be merged into the mainline. There is a fair amount of coding and benchmarking work to be done still. But it is clear that the code which is in current mainline kernels is not up to the task of getting the best performance out of near-future hardware. Your editor feels the need to point out one possibly-overlooked aspect of this problem. An SSD is not just a dumb storage device; it is, instead, a reasonably powerful computer in its own right, running complex software, and connected via what is, essentially, a high-speed, point-to-point network. Some of the more enterprise-oriented devices are more explicitly organized this way; they are separate boxes which hook into an IP-based local net. Increasingly, the value in these devices is not in the relatively mundane pile of flash storage found inside; it's in the clever firmware which causes the device to look like a traditional disk and, one hopes, causes it to perform well. Competition in this area has brought about some improvements in this firmware, but we should see a modern SSD for what it is: a computer running proprietary software that we put at the core of our systems. It does not have to be that way; Linux does not need to talk to flash storage through a fancy translation layer. We have our own translation layer code (UBI), and a few filesystems which can work with bare flash. It would be most interesting to see what would happen if some manufacturer were to make competitive, bare-flash devices available as separate components. The kernel could then take over the flash management task, and our developers could turn their attention toward solving the problem correctly instead of working around problems in vendor solutions. Kernel developers made an explicit choice to avoid offloading much of the network stack onto interface hardware; it would be nice to have a similar choice regarding the offloading of low-level storage management. In the absence of that choice, we'll have no option but to deal with the translation layers offered by hardware vendors. The results look unlikely to be optimal in the near future, but they should still end up being better than what we have today.
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Filesystems and block I/O
Kernel building
Memory management
Networking
Architecture-specific
Security-related
Virtualization and containers
Miscellaneous
Page editor: Jonathan Corbet Distributions News and Editorials POSSE: Teaching teachers about open sourceA small group of Computer Science (CS) professors gathered at Red Hat's corporate campus in Raleigh, North Carolina from July 19th to 24th for the Professors' Open Source Summer Experience (POSSE) 2009 workshop. The program focused on educating CS professors about open source development, including practical ways to get students involved in open source projects and how to integrate open source methodology into the classroom experience. The participants deemed the event a tremendous success and plan to continue it next year, hopefully expanding to new locations and fields of study. POSSE 2009 was an outgrowth of the TeachingOpenSource.org site, a new, open community of teachers and software developers collaborating on educational issues. TeachingOpenSource.org's other projects include mentoring programs and producing teaching materials, but POSSE was its first attempt to gather educators and open source advocates for face-to-face meetings. Hands-on introduction to open sourcePOSSE facilitator Greg DeKoenigsberg said that Red Hat intentionally kept the pilot event small in order to "do it right." Due to a pair of last-minute cancellations, five professors were able attend the week-long workshop, joined by a small contingent of Red Hat employees and by David Humphrey and Chris Tyler from Seneca College, two CS professors with firsthand experience teaching open source in the classroom. The program for the week started by covering the basics of open source software itself, but devoted most of its time to concrete examinations of how open source projects function, from coordinating geographically dispersed teams with online communication tools to build tools and source code management, to packaging, debugging, and testing tools. All sessions were designed to be cumulative, not a la carte; the participants were given overnight assignments based on each day's events and the topics built in complexity over the course of the week. The final sessions dealt with integrating open source software into classroom situations, including finding projects in which students can participate, setting expectations, assessing and grading student participation, and interacting with the broader open source community while running a classroom project. At the Friday wrap-up discussion, the professors presented course outlines, discussed what they had taken away from the week, and how to get faculty colleagues involved. Attendee Matthew Jadud from Allegheny College described the event as "a huge win." Although he had open source experience through several years of working on the Transterpreter virtual machine project, he said that he still went into POSSE 2009 with questions about how best to interact with and sustain open communities, adding "we got that in spades." Seeing up close how large-scale open communities operate was a revelation, he said. "There is a difference between 'knowing' and 'understanding'. I think I *knew* some things about open development processes, but now I'm beginning to *understand* a few, and can see more clearly what I don't understand. That's an exciting feeling. ... And, in seeing it, it became less mysterious and more tractable." DeKoenigsberg also regarded the event as a success, and noted that the information went two ways:
I was surprised at how much I learned
about what it is that I do. It's very much in vogue to talk about
"community managers" and "the art of community" and so forth, and it's easy
for us in the open source world to feel like we invented all of this stuff.
But Matt Jadud and Cameron Seay, two of our professor participants,
introduced me to a whole world of educational theory that describes our
work in "community management" with eerie precision. Turns out that open
source is a textbook example of a "community of practice," and concepts
that we put into practice every day to build our community have a huge body
of supporting pedagogy behind them.
Education and the open source communityBringing the education and open source communities closer together is a win-win scenario, said DeKoenigsberg. Participating in open source gives students the opportunity to work in real-world coding projects, on a real-world scale, that the classroom simply cannot emulate. "The upside seems so huge," he observed. "Students get invaluable experience. Open source projects get badly needed help. Moribund CS programs, most of which are struggling with slumping enrollments, get a shot in the arm." The difficulty, he observed, is practical. "Over the last few years, I've had discussions with a lot of professors on this subject. Their responses have been largely the same: yes, they're interested in open source; yes, they'd love to teach it to their students; they don't know how to get started; open source is intimidating; they don't have time to dig in and learn." Professors have significant demands on their time outside the classroom, he added, making it difficult to acquire the knowledge necessary to guide students around open source. POSSE tackles the challenge of winning over professors by putting them in touch with like-minded peers, he said. "That's the hypothesis of POSSE: that professors will respond to other professors, and that a community of professors working together to solve these problems will be more successful." Humphrey and Tyler's work at Seneca demonstrates that teaching open source participation in the classroom works; their students have a proven track record of success contributing to Mozilla and Fedora, respectively. Bringing the two communities together involves more than just reaching out to professors, however — open source projects must look for ways in which they can foster mentoring relationships and be more accessible to student participation. DeKoenigsberg cited Mozilla as an example of a project with good student outreach. "Mozilla does a good job of this in a number of ways; they have a special tag in Bugzilla that can denote particular tickets as 'student friendly', which is something we're hoping to replicate in Fedora." Mozilla and Fedora were the two projects spotlighted in POSSE 2009, but it was a pragmatic choice. "We certainly don't want to limit professors to participating in particular communities," DeKoenigsberg said. "We used Mozilla and Fedora projects as the mechanism to introduce professors to open source development, but many professors may already be engaged in research that leads quite naturally to interest in other communities." Planning for the school year and beyondThe professors that attended POSSE 2009 are making their own plans for integrating what they learned with their curriculum, although the integration might be difficult for the coming semester. Jadud said that he plans to use open projects to a limited degree in the coming term, most immediately in the data structures class, where he plans to have students study the Mozilla codebase (among others) so that they can read and learn from structures used "in the wild". Further out, he plans to apply POSSE's lessons to Transterpreter, but would also like to collaborate on coding projects with some of his colleagues at Allegheny. "It may be that we can renovate our technical writing course so that our students are working on and contributing to living, community-written documents while learning to write and edit technical prose. Mind you, this was a revelation for me at POSSE, that these large projects have so *much* going on, there are many, many ways to get people involved." For its part, TeachingOpenSource.org plans to keep in touch with the POSSE 2009 participants in the coming school year, working with them in the classroom. The group specifically wants to hear from open source projects that would like to work with a class of CS students for an entire semester, and are willing to provide mentoring, but individual mentors and guides are encouraged to join as well. Other efforts still to come include a collaboratively-drafted textbook about teaching open source and associated classroom reference materials, and a one-day Teaching Open Source Summit to be held in October at the Free Software and Open Source Symposium in Toronto. Those who could not attend this summer's inaugural workshop need not worry, more events like POSSE 2009 are in the works. DeKoenigsberg said that the group is already planning to expand the reach of next year's POSSE beyond CS, to include professors in technical writing and other related fields. It also hopes to run multiple POSSE sessions, although the limiting factor is currently the number of professors actively involved in open source software. As with its other projects, TeachingOpenSource.org encourages anyone who is interested in helping to organize a POSSE event in his or her own area to join the mailing list. As DeKoenigsberg observed, when one asks open source developers how they learned their development skills, most reply "I taught myself." Although the open source community's ability to apprentice and mentor to new recruits is admirable, it does little formal recruiting and training. At the same time, thousands of CS students come up through college programs that focus mostly on proprietary tools and development models. Better integrating the two communities could expand the open source talent pool, and equip students with more skills as they prepare to enter the job market.
New Releases LFS-6.5 ReleasedThe Linux From Scratch community has announced the release of LFS Version 6.5. "This release includes numerous changes from LFS-6.4 (including updates to Linux-2.6.30.2, GCC-4.4.1, and Glibc-2.10.1) and security fixes. It also includes editorial work on the explanatory material throughout the book, improving both the clarity and accuracy of the text."
Ubuntu Karmic Koala Alpha 4 releasedThe Alpha 4 release of Ubuntu's upcoming Karmic Koala distribution has been announced. "Alpha 4 is the fourth in a series of milestone CD images that will be released throughout the Karmic development cycle. The Alpha images are known to be reasonably free of showstopper CD build or installer bugs, while representing a very recent snapshot of Karmic." Other available varients include Ubuntu Server UEC, Kubuntu, Xubuntu, Ubuntu Studio and Mythbuntu.
Distribution News Debian GNU/Linux Bits o' Bugs from the BTSClick below for some bits from the Debian Bug Tracking System. Topics include New features, Architecture changes, Future, and a Call for Volunteers.
Bits from Debian Pure BlendsDebian Pure Blends were previously known as Custom Debian Distributions. In these bits you can find out more about the Rename finished, New Blends, New features, Blends needing more support, and Ways to help Blends and Debian users in General.
Debian Policy 3.8.3.0 releasedVersion 3.8.3.0 of Debian Policy is available. "I've just uploaded Debian Policy 3.8.3. The next time you upload a package, please check it against the new version of Policy and update Standards-Version in debian/control accordingly. A new release of Lintian calibrated for this release of Policy will be uploaded shortly."
Happy Birthday DebianOn August 16, 1993 Ian Murdock announced the Debian Linux Release on comp.os.linux.development. "This is just to announce the imminent completion of a brand-new Linux release, which I'm calling the Debian Linux Release. This is a release that I have put together basically from scratch; in other words, I didn't simply make some changes to SLS and call it a new release. I was inspired to put together this release after running SLS and generally being dissatisfied with much of it, and after much altering of SLS I decided that it would be easier to start from scratch. The base system is now virtually complete (though I'm still looking around to make sure that I grabbed the most recent sources for everything), and I'd like to get some feedback before I add the "fancy" stuff."
Fedora Fedora Board RecapClick below for a brief recap of the August 13, 2009 meeting of the Fedora Advisory Board. Topics include Russian Fedora Initiative, Thai community domain, and Spins and Download site redesign.
SUSE Linux and openSUSE OpenSUSE cuts maintenance period to 18 monthsThe openSUSE project has sent out a brief note to the effect that the maintenance period for distribution releases is being reduced. "openSUSE will shorten the maintenance period to 2 versions plus 2 months which translates with the current release cycle of 8 months to 18 months instead of 24 months we had with openSUSE 11.1 and previous releases."
Creating a group of Users and Novell partners concerned about openSUSE lifespanClick below for a post with some thoughts about a longer life span for openSUSE or an openSLE offering similar to CentOS. "At some of the event I and others I talk with have attended it is often asked "Why doesn't Novell offer an openSLE alternative?" People using the fedora->CentOS->RHEL talk of how many of the business they support move this route to become RHEL customers. I think we (being the SUSE prefered) really would benefit from a similar path. That is why I am trying to somehow get a group organized. So we are able to have our voice heard at the higher levels of Novell."
Other distributions A possible change of direction for Foresight LinuxForesight Linux is a derivative of rPath's distribution, focused on getting leading-edge software to users quickly. Michael K. Johnson, a familiar name currently at rPath, has posted an interesting set of suggestions on ways to reinvigorate Foresight development; he starts by suggesting that they drop rPath as the base system. "I think that Foresight needs to be based on an upstream distro that is regularly fully updated and refreshed, and that is maintained by distro specialists with experience and expertise that is just plain missing within the Foresight development community. That distro needs to be imported into a Conary repository; that will allow Foresight to continue to use Conary to manage the process of building a set of consistent modifications relative to that upstream distro, providing a true rolling release. That would allow Foresight developers to concentrate on only the problems inherent in integrating the very latest development source against a recent base that is relatively close to the basis on which the software is maintained."
CentOS 4.8 release delays againDag Wieers reports that CentOS 4.8 has been delayed again. "After the big CentOS 5.3 release delay in the beginning of 2009, the community witnesses history repeating with CentOS 4.8 being delayed even longer. It is unfortunate that 13 weeks after Red Hat released RHEL 4.8, CentOS is unable to release their own rebuild. It is not unusual people inquire about a new release only hours after Red Hat's release, but in this case repeating inquiries get positive response, but nothing materializes weeks after. The latest word comes from main developer Johnny Hughes." The CentOS 4.8 release notes are available.
Distribution Newsletters CentOS Pulse #0904 - The CentOS NewsletterThis month's issue of the CentOS Pulse is available. "I give you the next monthly release of the Newsletter. It was mostly written at HAR2009 where CentOS had its only village and was visited by many people from the Community. There was a lot to discuss as the recent events have left an impact. The Open Letter to Lance resulted in a vast response from many and it seamed to be the News of the day. But this is not the only things that has happened."
Misc Debian developer news (#17)This edition of miscellaneous news for Debian developers covers PTS news: accessibility, piuparts, l10n, cvs.debian.org (and its webwml repo) moved to Alioth, Git user's survey 2009, New source formats, and New mailing list debian-user-dutch.
DistroWatch Weekly, Issue 316The DistroWatch Weekly for August 17, 2009 is out. "Many people who use Intel graphics and a recent Linux distribution must have come to the same conclusion: this combination is a disaster. Performance and stability issues affecting thousands of users have so far filled many pages on various forums. But, as Caitlyn Martin reports, despite the best of effort to find workarounds and solve the problems, a universal solution that would work across all Intel graphics chipsets has yet to be found. In the news section, Ubuntu updates its netbook remix interface for "Karmic Koala", Novell appoints a dedicated group of developers for openSUSE, FreeBSD prepares for the grand launch of a major new version of its operating system, and the Linux community continues to examine the recent CentOS conflict. Also in the news, some development updates on two lesser-known but highly interesting distributions - Foresight Linux and GoboLinux. Finally, if you are interested in helping to test the upcoming release of Fedora 12, don't miss our tips section describing the way to upgrade Fedora 11 to the latest "Rawhide" with one command. Happy reading!"
Fedora Weekly News 189The Fedora Weekly News for August 16, 2009 is out. "In this week's issue, an update on the progress of Fedora 12 (Constantine) Alpha release gets us started in Announcements. Our Marketing beat is offered by a new beat writer, Chaitanya Mehandru, who reports on the latest happenings with the Marketing Team, including an update on zikula deployment for Fedora Insight. In Ambassador news, an announcement of the three winners of the Fedora 11 release events contest, from three different regions of the globe. Quality Assurance offers detail on several past and upcoming Test Days and weekly meetings, and updates on Fedora 12 bug blockers. In news from the Translation Team this week, updates on the Fedora 12 release schedule as it pertains to translation and documentation, and announcement of the Translation Quick Start Guide in Russian, Polish, Dutch and Brazilian Portuguese. The Art/Design Team beat this week leads with a summary of discussion on the Fedora 12 theme meeting, followed by a report on the initial work in creating an Art Studio Fedora spin and rounds out with a discussion on the need for source control for Fedora Themes. Our issue rounds out with updates from the various virtualization communities and teams, including the availability of new Xen packages for Fedora for testing, and details on libguestfs 1.0.67 and libvirt 0.7.0 and their new features."
OpenSUSE Weekly News/84This issue of the openSUSE Weekly News covers openSUSE 11.2 Milestone 5 released, People of openSUSE: Marcus Schaefer, Linux.com/Rob Day: The Kernel Newbie Corner: Kernel and Module Debugging with gdb, Guillaume DE BURE: More skrooge features, LDN: Kernel Log - Coming in 2.6.31 - Part2: Graphics, Audio and Video, and more.
Ubuntu Weekly Newsletter #155The Ubuntu Weekly Newsletter for August 15, 2009 is out. "In this issue we cover: Karmic Alpha 4 released, New Ubuntu Members, Developer News, Reporting Ubuntu Community Problems: Jono Bacon, Ubuntu US Teams, UbuCon Atlanta 2009, Brazilian Council & New Brazilian Ubuntu Members, Zim & the art of wiki development, Ubuntu Server Tips - Help Wanted, Ubuntu Community Learning Project, Ubuntu Podcast #32, and much, much more!"
Distribution meetings Ubuntu Developer WeekThe next Ubuntu Developer Week has been scheduled for August 31 - September 4, 2009. Ask your questions in #ubuntu-classroom-chat, and join #ubuntu-classroom on irc.freenode.net to participate in the sessions. Click below for more information.
Announcing FUDCon Toronto 2009The next North American Fedora Users and Developers Conference (FUDCon) has been announced. This FUDCon is scheduled for December 5 - 7, 2009 in Toronto, Canada at the Seneca @York campus.
Distribution reviews Preview of Jolicloud: The social Netbook OS (Cnet)Cnet reviews a Jolicloud beta release. "Although it's not done yet, there are some definite key features that make Jolicloud more than just a re-skinning of Linux. The idea that you can discover new applications and manage what you have installed on your machine in the same place is downright cool. So is the idea of having all your apps and settings synced up between multiple machines. I'm less enthralled by the idea of having to basically install bookmarks, and do away with having multiple windows open in the same desktop area--something I've grown very accustomed to on Macs and PCs. It's also still Linux, and comes with some of the same hang ups and the often-steep learning curve."
Page editor: Rebecca Sobol Development Scribus 1.3.5 releasedThe popular open source Desktop Publishing (DTP) application Scribus has been bumped up to version 1.3.5, after two years in development. The new version incorporates substantial tool improvements, new import filters, native rendering for content created with external tools like LaTeX, the ability to create PDF presentations, and a native build for the Mac OS X platform. Source code and binary packages are available from www.scribus.net for Linux, Mac OS X, Windows, and OS/2 (yes, seriously). Distribution-specific installation instructions are provided for Debian and Ubuntu, SUSE, Red Hat and Fedora, CentOS, and Mandriva. The only major dependency change is Qt4, up from Qt3 in previous versions. The official release notes indicate that Qt 4.5.0 is the minimum supported version. Scribus developer Peter Linnell described the upgrade to Qt4 as one of the most important advances in the new release, particularly because it made the native OS X package possible. The DTP world has a significantly higher percentage of Mac users than the overall desktop market, so the availability of an easy-to-install .DMG disk image should open doors to many more users. File formats and application compatibilityScribus: The Official ManualGregory Pittman and Christoph Schäfer are Scribus developers and co-authored this manual, published in May by FLES Books. Much of what is included in the manual is available through the online documentation or built-in Scribus help, but in book form this is an especially effective guide to using and understanding Scribus. As a manual, it is both well-written and, more importantly, well-organized. Scribus is large and complex application, designed to create complex documents. Understanding all that is does, how, and why, is not something you can pick up by playing around with it for a few minutes. The book combines reference material, real-world tutorials, and, wisely, explanations of DTP itself. The illustrations are appropriately sized, which makes a world of difference. If you have ever gotten frustrated by trying to make a multi-page OpenOffice.org document look the way you want it to, this book may have the answers you are looking for. In my experience, most people who try Scribus for the first time run into stumbling blocks not from Scribus itself, but caused by their unfamiliarity with DTP programs in general. DTP is a different beast than text editing or word processing, and the different metaphors and conventions can be a legitimate source of confusion. Ideas like Frames, Master Pages, and Pre-flight Verification seem strange to the uninitiated, but a clear explanation of them instantly makes a DTP application like Scribus more useful. Like understanding why photo editors have a fist and what appears to be a lollipop labeled "burn" and "dodge," respectively, knowing the background of DTP will help anyone appreciate Scribus in a new light. Scribus: The Official Manual is not an evangelistic effort; it is just a useful guide to a powerful piece of open source software. But for those who are curious about Scribus or about DTP in general, it is worth checking out. The central idea of a DTP application is that it is used to assemble and lay-out the output from other applications — text, photos, vector artwork, etc. — so file format compatibility is critical. Scribus can already read a wide variety of file formats (the list at the Scribus wiki has not yet been updated, but it gives a rough idea); new to this release are Adobe Illustrator (.ai), Xfig (.fig) and Windows Metafile (.wmf). ![[Scribus Sample Document]](/images/scribus-scrapbook_sm.png)
Scribus 1.3.5 also allows documents to use PDF and Embedded PostScript (EPS) files as images, saving an import or file conversion step. Unlike a word processor, Scribus does not import external content such as image files into its own documents; rather, they are linked in from the original sources. Consequently, the Scribus developers are reticent to use the term "embedding" for images and other content. Since PDF and EPS files can themselves contain raster image data, not converting them for embedding saves space, memory, and (for lossy image compression) a generation of conversion. Scribus 1.3.5 boasts improvements in solid color handling, including usability improvements that make it possible to replace any color throughout a file, and the ability to import color palettes from other sources. Scribus can import color palettes from external sources, including proprietary systems such as Pantone, and can extract palettes contained within images, such as Illustrator files. Tool improvementsThe new release also adds several tool options for manipulating page contents and for working with large documents. Shapes, which had previously been fixed, can now be edited using path tools like those found in a vector graphics editor. A new line editor allows the creation of custom line styles, and more default shapes and lines are available. All items in a page, including text and image frames, can be manipulated with standard transformation tools: scaling, translation, rotation, and skew. The image manager underwent a substantial rewrite; the previewer can now display detailed information on each image used in a document, and can jump to where an image is used in the document — particularly useful in large documents. Furthermore, Scribus can now launch an an external image editor from within the image manager, and can apply its own non-destructive image effects to an image inside the Scribus document. This last feature allows changing color curves or saturation levels without altering the original image. As developer Christoph Schäfer explained, it can be used to create duotone, tritone, or spot-color images, feats no other open source graphics application can yet do. ![[Scribus Tritone]](/images/scribus-tritone_sm.png)
Scribus's "scrapbook" feature allows the user to store frequently-used items (text, images, or other content) in a floating palette for convenient reuse, either in the same document or saved and reopened for use in another document. Scrapbooks have also been upgraded in 1.3.5; now multiple scrapbooks can be open simultaneously, scrapbooks can automatically store items copied with the "Copy" command, and scrapbooked items can be pasted into a document in their original coordinates from the right-click menu. Totally newTwo entirely new features make their debut in Scribus 1.3.5, "render frames" and PDF presentation effects. Render frames allow Scribus to incorporate content from documents that must be rendered into final output form just like it does for text or images. This includes mark-up languages like TeX / LaTeX, graphic elements produced by Gnuplot or POV-Ray and even musical scores generated by LilyPond. In each case, time, space, and accuracy are preserved by having the external document rendered by the appropriate tool only when necessary, and at the appropriate resolution. As Schäfer observed, "Think about musical notation. Without render frames, you'd have to create a PS file with LilyPond, import it into Scribus and hope that all goes well. With render frames, you insert the markup into the editor, render it and see the result immediately." In addition to the pre-configured renderers, adding support for new types of render frame documents is as simple as editing an XML description file. The Scribus documentation provides a reference for developers who wish to add support for a new type of content. The PDF 1.5 specification added support for transitions and other animation effects between pages of a document to better facilitate using PDF as a presentation format. Scribus 1.3.5 now supports these presentation effects, so users can create full-fledged presentations that are usable on any platform with a modern PDF viewer. The effects are exposed in the application's PDF export tool, so they are not visible when creating a document, only when exporting it to its final presentation form. DevelopmentLinnell and Schäfer said that the plan is to accelerate the development schedule now that 1.3.5 is out of the door. This release took longer than expected due in part to the difficulty of migrating the code from Qt3 to Qt4. "We can sympathize with the KDE folks on what it takes to port Qt3 to Qt4," Linnell said. "Qt2 to Qt3 took a weekend." Once a few remaining issues with the Qt migration and the associated refactoring are finished, the plan is to rename this branch 1.4, and return to a more traditional odd-for-development, even-for-stable release numbering scheme. The 1.4.x code may receive minor updates, but not significant new features — a 1.5.x tree already exists in Subversion. Linnell and Schäfer had a few comments about the direction of future releases, but not much is definite. Linnell mentioned better non-Latin character support as an oft-requested feature, in particular for Indic and Arabic languages, plus features to enable easier management of extremely long documents like books. Schäfer added the possibility of UniConvertor integration, which would add support for more document formats including CorelDraw. This release contains two changes that could widen Scribus's appeal.
First, it is difficult to Apart from those new possibilities, Linux DTP enthusiasts will find much to like in this upgrade. The addition of render frames opens the door to a lot of new typesetting uses, and the new image, path, and transformation tools bring Scribus additional editing power that in prior releases would have required dropping into external image editors. Scribus has always been one of open source's best-kept-secrets, not approaching the high profile of Firefox, GIMP, or even OpenOffice.org with the mainstream. Scribus 1.3.5 continues the tradition of strong, stable releases and will hopefully bring more well-earned attention to the project.
System Applications Audio Projects MPD 0.15.2 releasedVersion 0.15.2 of MPD, the Music Player Daemon, has been announced. "This release includes metadata parsing fixes, stuck pause in the shout plugin and a few memory leaks."
Rivendell 1.5.1 announcedVersion 1.5.1 of Rivendell, a radio station automation system, has been announced. This version adds several new features and a German translation.
Database Software PostgreSQL Weekly NewsThe August 16, 2009 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL DBMS articles and resources.
Interoperability Samba 3.2.14 maintenance release is availableMaintenance release 3.2.14 of Samba has been announced. "This is the last bug fix release for Samba 3.2."
Web Site Development Hatta 1.3.3 wiki engine releasedVersion 1.3.3 of Hatta wiki engine has been announced, some new capabilities have been added. "Hatta is a small wiki engine designed to run locally or via WSGI inside a directory in a Mercurial repository. All the pages are normal text or binary (for images and such) files, also editable from outside of the wiki -- the page history is taken from the repository."
Desktop Applications Audio Applications Ardour Lirc OSC 0.1 releasedThe initial release of Ardour Lirc OSC has been announced. "Here's the first version of an lirc/Ardour's OSC wrapper I wrote a while ago. Since it's working for me, it's time for you to enjoy it! * Allows controlling Ardour from any lirc remote * Uses a perl script to map lirc commands to Ardour's OSC interface".
Mixxx 1.7.0 releasedVersion 1.7.0 of Mixxx has been announced. "Mixxx is currently the most popular open source djing software package, providing everything you need to make your mixes in a completely open source environment. The Mixxx development team is proud to announce the release of version 1.7.0, available for Linux, Mac (Intel and PPC) and Windows. Exactly one year has passed since the release of Mixxx 1.6.0 and many exciting improvements have taken place in this time."
NJL and VCF LADSPA plugins ported to LV2The NJL and VCF LADSPA plugins have been ported to the LV2 plugin architecture. "The set consists of: IEEE floating point noise generator Integer noise generator Risset Scales tone generator Experiments in Representation."
TAP-plugins 0.7.1 releasedVersion 0.7.1 of TAP-plugins has been announced. "A bugfix version of TAP-plugins has been released. It aims to fix: * problems on 64-bit (silence in EQ, etc) * denormal problems * GCC compiler warnings * uninitialised variables (detected via Valgrind)".
Desktop Environments GNOME 2.28.0 Beta 1 (2.27.90) releasedVersion 2.28.0 Beta 1 of the GNOME desktop has been announced. "This is the sixth development release, and the first beta, towards our 2.28 release that will happen in September 2009. By now most things are in place, and your mission is easy: Go download it. Go compile it. Go test it. And go hack on it, document it, translate it, fix it."
GNOME Software AnnouncementsThe following new GNOME software has been announced this week:
KDE Software AnnouncementsThe following new KDE software has been announced this week:
Xorg Software AnnouncementsThe following new Xorg software has been announced this week:
GUI Packages Python bindings for QT released under the LGPLThe PySide project has been launched. "The PySide project provides LGPL-licensed Python bindings for the Qt cross-platform application and UI framework. PySide Qt bindings allow both free open source and proprietary software development and ultimately aim to support all of the platforms as Qt itself."
Mail Clients Sylpheed 2.7.1 releasedStable version 2.7.1 of the Sylpheed email client has been announced. "Changes from 2.7.0 * The feature to import and export .eml files was added. * Progress is displayed during import and export now. * The warning about non-exist plug-in directory was removed. * The comments within Content-Type header are handled now. * The order of signals emitted at moving messages was modified. * The sylpheed.spec file was fixed."
Medical Applications VistA HTML note rendering now available (LinuxMedNews)LinuxMedNews covers the latest feature additions to the VistA electronic medical record system. "A whole new era for Veterans Affairs VistA has begun with Kevin Toppenberg, MD's new TMG-CPRS 1.0.26.76 (TMG v1.1) client. The new tmg-cprs client enables clinical notes to be rendered in html. This allows mixed typefaces, bold, center, right justification, left justification and italics in clinical notes while maintaining compatibility with Veterans Affairs cprs."
Music Applications Impro-Visor project announcedThe Impro-Visor project has been launched. "The Impro-Visor project, an open-source Java-based notation tool to help jazz musicians learn to improvise, through improvisation advice and play-along".
Virtual MIDI Piano Keyboard 0.2.6 releasedVersion 0.2.6 of Virtual MIDI Piano Keyboard has been announced, it includes some new features and bug fixes. "Virtual MIDI Piano Keyboard is a MIDI events generator and receiver. It doesn't produce any sound by itself, but can be used to drive a MIDI synthesizer (either hardware or software, internal or external). You can use the computer's keyboard to play MIDI notes, and also the mouse."
Office Applications xlutils 1.4.0 releasedVersion 1.4.0 of xlutils has been announced, it includes new features and bug fixes. "This is a small collection of utilities that make use of both xlrd and xlwt to process Microsoft Excel files."
Miscellaneous BleachBit 0.6.1 releasedVersion 0.6.1 of BleachBit has been announced. "BleachBit deletes junk to free disk space and cleans trace files to maintain privacy. Notable changes for 0.6.1: * Wipe free disk space to hide previously-deleted files * Clears Nautilus usage history * Vacuums gPodder and clears its cache * Vacuums Yum * Cleans inactive Yum repositories * Fix several bugs * Adds translations for Croatian, Korean, Ukranian, and Thai * Updates 18 other translations".
Languages and Tools JSP Pyjamas 0.6 releasedVersion 0.6 of Pyjamas has been announced. "Pyjamas is a port of Google Web Toolkit to Python, and thus enables the development of Rich Media AJAX applications in Python, with no need for special browser plugins. Pyjamas contains a stand-alone python-to-javascript compiler, and also a Widget Set API that looks very similar to Desktop Widget Set APIs (such as PyQT4 or PyGTK2)."
Perl Parrot 1.5.0 releasedVersion 1.5.0 of Parrot has been announced. "On behalf of the Parrot team, I'm proud to announce Parrot 1.5.0 "TEH PARROTZ!." Parrot is a virtual machine aimed at running all dynamic languages."
Python mpmath 0.13 releasedVersion 0.13 of mpmath, a pure-Python library for arbitrary-precision floating-point arithmetic, has been announced. "Version 0.13 implements about 30 new special functions, including Kelvin, Struve, Coulomb, Whittaker, associated Legendre, Meijer G, Appell, incomplete beta, generalized exponential integral, Hurwitz zeta and Clausen functions. The algorithms for hypergeometric-type functions have been greatly improved to robustly handle arbitrarily large arguments and limit cases of the parameters. Other new features and bug fixes are included as well."
Python 3.1.1 releasedVersion 3.1.1 of Python has been announced. "This bug fix release fixes many normal bugs and several critical ones including potential data corruption in the io library. Python 3.1 focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter."
Python-URL! - weekly Python news and linksThe August 15, 2009 edition of the Python-URL! is online with a new collection of Python article links.
Tcl/Tk Tcl-URL! - weekly Tcl news and linksThe August 12, 2009 edition of the Tcl-URL! is online with new Tcl/Tk articles and resources.
Cross Compilers Arduino 0017 releasedVersion 0017 of Arduino, an open-source development system for Atmel AVR microprocessors, is available. See the release notes for more information.
Libraries libtheora 1.1beta2 releaseVersion 1.1beta2 of the libtheora video library has been announced. Changes include: "- Improves rate control with difficult-to-encode input (the huskies issue) - Has all the example code ported to the 1.0 api - Builds on OpenBSD and Apple Xcode - TH_ENCCTL_SET_SPLEVEL is work again for trading of encode speed for quality. There's now a TH_ENCCTL_GET_SPLEVEL as well for reading the default/current setting. - The encoder/decoder source tree split has been removed; everything is in lib now."
Test Suites Linux Desktop Testing Project 1.7.0 releasedVersion 1.7.0 of Linux Desktop Testing Project, a test suite for desktop applications, has been announced. "We are proud to announce the release of LDTP 1.7.0. This release features number of important breakthroughs in LDTP as well as in the field of Test Automation. This release note covers a brief introduction on LDTP followed by the list of new features and major bug fixes which makes this new version of LDTP the best of the breed."
Page editor: Forrest Cook Linux in the news Recommended Reading Requests for Linux drivers flowing in (ZDNet Asia)ZDNet Asia reports that manufacturers are requesting Linux drivers for their hardware. "According to Greg Kroah-Hartman, Novell programmer and Linux Driver Project lead, the group of some 400 programmers at the Project receive requests to port existing closed-source drivers to open source drivers for Linux "all the time", and has been "doing a lot of work on this over the past few years"."
Business Linux is booming, but unpaid adoption may hurt vendors (Cnet)Matt Asay looks at market data from IDC and worries about unpaid Linux deployments. "It gets better (or worse, depending on your view). If one adds in the RHEL clone CentOS and Red Hat's own community distribution Fedora Core, Red Hat and its offspring dominate the global Linux deployments market with 57.1 percent market share. This might not be so bad, if the trend were toward more paid Linux adoption, but it's not. While paid Linux server deployments will grow at an impressive rate, nonpaid deployments will grow even faster, nearly reaching parity with paid deployments in 2013."
Linux Adoption Dell: Linux netbook returns a "non-issue" (ZDNet)Adrian Kingsley-Hughes covers comments on netbook returns by Dell's Todd Finch on a ZDNet blog. "According to uber-OEM Dell, the whole debate about Linux netbook returns is a non-issue. Speaking at OpenSource World, a Dell executive deflated Microsofts enthusiasm for making a case out of the number of Linux netbooks returned by unhappy customers. Todd Finch, Dell senior product marketing manager, said the number of Linux returns are approximately the same as those for Windows netbooks. He categorized the matter of returns as a non-issue. Finch went on to say that Microsoft are making something of nothing."
Reviews LMMS: The Linux MultiMedia Studio (Linux Journal)Dave Phillips reviews LMMS in the Linux Journal. "LMMS combines a lightweight DAW (digital audio workstation) with editors for the composition of musical material, including a beat/bassline editor, a piano-roll window for writing MIDI parts, and a song editor for organizing your materials into larger forms. The DAW includes a few amenities, such as track-based automation for gain and plugin parameters, and a 64-channel effects mixer with support for LADSPA and VST plugins."
Nokia's Linux strategy broadens with upcoming Maemo 5 device (ars Technica)ars Technica takes a look at Nokia's upcoming Maemo 5. "A Nokia product codenamed RX-51 recently cleared FCC approval and has now appeared in leaked photos that made their way onto the Internet; it appears to be the long-awaited Maemo 5 product. The source code of Maemo 5 provided some early clues about the RX-51 last year. Maemo fans have been poring through it and documenting various technical details that provide insight into the hardware. The new pictures also seem to indicate that the device is a phone, and not just a Web tablet like its predecessors. This would be a major step forward for Maemo and could reflect a more Linux-centric mobile strategy for Nokia."
Miscellaneous Will The G1 Continue To Get One? (Linux Journal)Linux Journal looks at updates for the Android G1 mobile phone. "Like any device, the G1 has certain physical limitations — only so much stuff can fit in the case, and among the stuff being stuffed in is its memory. Apparently, according to one of Google's developers, not enough memory was stuffed when the stuffing was good, and now G1 owners may find themselves short on updates."
Page editor: Forrest Cook Announcements Non-Commercial announcements Open Source for America welcomes The Linux BoxOpen Source for America has announced its newest member, The Linux Box. "Joining a broad cross-section of more than 1,000 companies, academic institutions, communities, related groups and individuals, The Linux Box is now part of Open Source for America, a unified voice for the promotion of open source in the U.S. Federal government sector. Open Source for America strives to effect change in government to encourage broader support of open source technologies and the open source development community."
Commercial announcements Opera 10 beta 3 releasedVersion 10 beta 3 of the Opera browser has been announced. "Opera 10 beta (codenamed Peregrine) sports a surprising array of new features, a fresh look and feel, and enhanced speed and performance. Beta 3 includes many bug fixes and polished skin elements."
New Books The Art of Community - New from O'ReillyO'Reilly has published the book The Art of Community by Jono Bacon.
flex and bison - New from O'ReillyO'Reilly has published the book flex and bison by John Levine.
O'Reilly publishes book excerptsThe latest O'Reilly book excerpts include: The Criteria API - Harnessing Hibernate and Hibernate Types - Harnessing Hibernate.
Resources digiKam digest (KDEDot)KDE.News has announced the August 16, 2009 edition of the digiKam digest. "Looks like summer finally caught up with digiKam developers! This week the digest will be very short: ongoing work on refactoring color profiles code; libkdcraw updated to libraw-0.8.0-beta5 (support for RAW files bigger than 2GB); new features in Flickr export. A total of 10 bugs were closed (including several crashes) while 8 new ones were reported."
FSFE NewsletterThe July, 2009 edition of the FSFE Newsletter is online with the latest Free Software Foundation Europe news. Topics include: "1. Fresh air at WIPO, but old habits die hard 2. A farewell to Richard Rothwell 3. FSFE supports OpenRuhr 4. FSFE booth at RMLL Nantes, France, 07-11 July 5. Fellowship Meeting in Berlin, 09 July 6. The Fellowship interviews: Smári McCarthy".
Linux Foundation kernel authorship paper updatedThe Linux Foundation has announced the release of an updated study of kernel code authorship [PDF] written by Greg Kroah-Hartman, Amanda McPherson, and Jonathan Corbet. "The updated study finds that since April 2008, there has been a 10 percent increase in the number of developers contributing to each kernel release and that a net of 2.7 million lines of code have been added. This level of activity has resulted in an average of 5.45 patches being accepted per hour, an increase of 42 percent since the original study." The information will be familiar to LWN readers, naturally, but it's a slicker presentation and it considers a longer time period than LWN usually does.
Linux Foundation NewsletterThe August, 2009 edition of the Linux Foundation Newsletter is online. Topics include: "* Linux Foundation Introduces Linux-Branded Affinity Visa Platinum Credit Card * LinuxCon Early Registration Deadline, New Keynote Topics * Training Courses Open for LinuxCon * Open Source for America Promotes FOSS for Government * Telco Planning Joins Linux Foundation * LinuxCon Keynote Speaker Garbee Interviewed * Linux Foundation in the News * From the Director".
ETH Zurich ODBMS lecture series announcedThe ETH Zurich ODBMS lecture series is available for download. "This is by far the most up-to-date and comprehensive lecture series on object databases, developed by Michael Grossniklaus, and Moira Norrie at the renowned Swiss Federal Institute of Technology (ETH) Zurich."
Tux Droid NewsletterThe August, 2009 edition of the Tux Droid Newsletter has been published. Topics include More user friendly - More easy : New Control Center, New gadget: Facebook!, Quick survey: last call and new Gifts!!! and Linux Users. Tux Droid is an animated penguin robot from Kysoh.
Contests and Awards Call for proposals - Open Innovation AwardsA call for proposals has gone out for the Open Innovation Awards. "On 2 October 2009, during the Open World Forum in Paris, twenty companies innovating in the Open Source sector will each have an opportunity to make a 7-minute presentation to Venture Capitalists and major systems integrators to promote their company and projects. They will also be nominated and compete for the "Open Innovation Awards" that will be awarded by an international jury of experts to the most promising businesses innovating in the Open Source sector, and presented during the closing keynote address, ensuring maximum visibility and media coverage for the awardees."
Calls for Presentations ClubHack2009: call for papers/speakersA call for papers and speakers has gone out for ClubHack2009. The event will take place in India in late November or Early December. Submissions are due by October 15.
IMF 2009 call for participationA call for participation has gone out for IMF 2009, the 5th International Conference on IT Security Incident Management & IT Forensics. The event takes place in Stuttgart, Germany on September 15-17th.
KIWICON ]|[ - 2009 call for papersA call for papers has gone out for KIWICON. The event takes place in Wellington, New Zealand on November 28-29. Submissions are due by October 31. "With a current record of three arrests, seven conceptions and one committal Kiwicon is back for 2k9. The time has come to fake up an abstract and submit it to the Kiwicon Crue for judgement. In the coming months, we predict you will spend more time dreaming of kudos and UID 0 than actually working on your slides, since you'll be doing them the night before anyway."
PyCon 2010: Call for ProposalsA call for proposals has gone out for PyCon 2010. The event will be held in Atlanta, Georgia on February 17-25, 2010. Submissions are due by October 1. "Want to showcase your skills as a Python Hacker? Want to have hundreds of people see your talk on the subject of your choice? Have some hot button issue you think the community needs to address, or have some package, code or project you simply love talking about? Want to launch your master plan to take over the world with python? PyCon is your platform for getting the word out and teaching something new to hundreds of people, face to face."
Static analysis tool exposition (SATE) 2009 - call for participationA call for participation has gone out for SATE 2009. "We are preparing an exposition for static analysis tools that find security relevant defects. Briefly, participating tool makers run their tools on real programs. Researchers led by NIST analyze the tool reports. Everyone reports results and experiences at a workshop. The tool reports and analysis are made publicly available later. The plan is at http://samate.nist.gov/SATE.html. We plan to provide the test sets by 19 August, and to hold the workshop on 6 November."
Upcoming Events EuroBSDcon 2009EuroBSDcon 2009 will take place in Cambridge, UK on September 18-20. "A day of tutorials followed by 2 days of conference talks covering a wide variety of BSD related topics. This is the European BSD Community's annual event to meet, share and interact across the projects and between friends."
Events: August 27, 2009 to October 26, 2009The following event listing is taken from the LWN.net Calendar.
If your event does not appear here, please tell us about it.
Page editor: Forrest Cook
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[KMyMoney 1.0]](/images/ns/grumpy/kmm-new-sm.png)
![[KMyMoney 1.0 new transaction]](/images/ns/grumpy/kmm-trans-entry-sm.png)
![[KMyMoney 1.0 graph]](/images/ns/grumpy/kmm-graph-sm.png)