KDE Plasma 5.13 Now Available, OpenGear's New NetOps Automation Platform, New Zynthian Raspberry Pi Synthesizer and More

6 days 22 hours ago

News briefs for June 12, 2018.

KDE released Plasma 5.13.0 today. The team has "spent the last four months optimising startup and minimising memory usage, yielding faster time-to-desktop, better runtime performance and less memory consumption. Basic features like panel popups were optimised to make sure they run smoothly even on the lowest-end hardware. Our design teams have not rested either, producing beautiful new integrated lock and login screen graphics." New features in Plasma 5.13 include Plasma Browser Integration, redesigned system settings, new look for lock and login screens, improved KWin graphics compositor and more. See the release announcement for links to download pages for live images, distro packages and source.

OpenGear announced its new NetOps Automation platform, which "provides a solution for automation of NetOps workflows, enabling the management of the network from a central location, and eliminating the need for human intervention on the data center floor or at the edge of the network". NetOps is currently available as a beta product for select customers, and will be generally available in Q4 2018.

There's a new open-source Raspberry Pi synthesizer called Zynthian, which is a "swiss army knife of synthesis, equipped with multiple engines, filters and effects", Geeky Gadgets reports. The synthesizer is completely hackable and "offers an open platform for Sound Synthesis based on the awesome Raspberry Pi mini PC and Linux". See the main website for a video demo and to order.

Wine development release 3.10 is now available. New features include Swapchain support in direct 3D, updated Vulkan support, debugger support for Wow64 processes and more. See the announcement for more details and to download.

Devuan 2.0 ASCII has been released. Devuan is based on Debian Stretch, doesn't use systemd and it lets you choose between SysVinit and OpenRC init systems. With this release, Devuan provides various desktop environments, including Xfce, KDE, MATE, Cinnamon and LXQt. See the Devuan release notes and the It's FOSS post for more information on the distro.

News KDE Plasma Networking Raspberry Pi Wine Distributions
Jill Franklin

New NOVA Filesystem

6 days 23 hours ago
by Zack Brown

Andiry Xu (working with Lu Zhang, Steven Swanson and others) posted patches for a new filesystem called NOVA (NOn-Volatile memory Accelerated). Normal RAM chips are wiped every time you turn off your computer. Non-volatile RAM retains its data across reboots. Their project targeted byte-addressable non-volatile memory chips, such as Intel's 3DXpoint DIMMs. Andiry said that the current incarnation of their code was able to do a lot already, but they still had a big to-do list, and they wanted feedback from the kernel people.

Theodore Y. Ts'o gave the patches a try, but he found that they wouldn't even compile without some fixes, which he posted in reply. Andiry said they'd adapt those fixes into their patches.

The last time NOVA made an appearance on the kernel mailing list was August 2017, when Steven made a similar announcement. This time around, they posted a lot more patches, including support for SysFS controls, Kconfig compilation options and a significant amount of documentation.

One of NOVA's main claims to fame, aside from supporting non-volatile RAM, is that it is a log-based filesystem. Other filesystems generally map out their data structures on disk and update those structures in place. This is good for saving seek-time on optical and magnetic disks. Log-based filesystems write everything sequentially, trailing old data behind them. The old data then can be treated as a snapshot of earlier states of the filesystem, or it can be reclaimed when space gets tight.

Log-based filesystems are not necessarily preferred for optical and magnetic drives, because sequential writes will tend to fragment data and slow things down. Non-volatile RAM is based on different technology that has faster seek-times, making a log-based approach a natural choice.

NOVA goes further than most log-based filesystems, which tend to have a single log for the whole filesystem, and instead maintains a separate log for each inode. Using the log data, NOVA can perform writes either in place like traditional filesystems or as copy-on-write (COW) operations, which keep the old version of a file until the new version has been written. This has the benefit of being able to survive catastrophic events like sudden power failures in the middle of doing a write, without corrupting the filesystem.

There were lots of responses to the patches from Andiry and the rest of his team. Most were bug reports and criticism, but no controversy. Everyone seemed to be interested in helping them get their code right so the patches could get into the main tree quickly.

Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to

Go to Full Article
Zack Brown

What Microsoft's GitHub Deal Promises to Programmers

1 week ago
Microsoft sent tremors through the open source world last week, when it announced that it would acquire the popular developer platform GitHub for $7.5 billion in company stock. The acquisition is expected to close by the end of the calendar year. GitHub, one of the world's largest computer code repositories, is home to more than 28 million developers for collaboration and distribution of projects.
Jack M. Germain

The Lustre Filesystem Dropped from the Linux 4.18 Kernel

1 week ago
by Petros Koutoupis

It's now official: the latest RC1 pull request for the Linux 4.18 will not host the nearly 15-year-old Lustre filesystem.

Greg Kroah-Hartman has been growing weary of the team developing its source code not pushing cleaner and fixed code to the staging tree. The removal was committed on June 5, 2018: with the following notes:

The Lustre filesystem has been in the kernel tree for over 5 years now. While it has been an endless source of enjoyment for new kernel developers learning how to do basic coding style cleanups, as well as a semi-entertaining source of bewilderment from the vfs developers any time they have looked into the codebase to try to figure out how to port their latest api changes to this filesystem, it has not really moved forward into the "this is in shape to get out of staging" despite many half-completed attempts.

And getting code out of staging is the main goal of that portion of the kernel tree. Code should not stagnate, and it feels like having this code in staging is only causing the development cycle of the filesystem to take longer than it should. There is a whole separate out-of-tree copy of this codebase where the developers work on it, and then random changes are thrown over the wall at staging at some later point in time. This dual-tree development model has never worked, and the state of this codebase is proof of that.

So, let's just delete the whole mess. Now the lustre developers can go off and work in their out-of-tree codebase and not have to worry about providing valid changelog entries and breaking their patches up into logical pieces. They can take the time they have spent doing those types of housekeeping chores and get the codebase into a much better shape, and it can be submitted for inclusion into the real part of the kernel tree when ready.

Honestly, I do not blame him. The staging tree is primarily intended for unstable and less than mature code, which ideally should move to the mainline within a short time of further development. It's a temporary (that is, staging) location. It's not that I don't appreciate the Lustre filesystem. In fact, I once wrote about it for Linux Journal in the past.

For those who are less familiar with this filesystem: Lustre (or Linux Cluster) is a distributed filesystem typically deployed in large-scale cluster computing environments. Lustre is designed to be both performant and to scale to tens of thousands of nodes and to petabytes of storage. And as what may have just been alluded to already, a distributed filesystem allows access to files from multiple hosts sharing a computer network.

Go to Full Article
Petros Koutoupis