Tag Archives: linux

Outreachy Summer 2019 Applications Open With Expanded Eligibility


Outreachy, the program formerly known as the Outreach Program for Women and intended to get more females and other under-represented groups in technology engaged with Linux/open-source projects, has opened up their application process for those seeking a summer internship while receiving a $5,500 USD stipend.

Outreachy has been going for a number of years now and for the summer 2019 round they’ve expanded the eligibility slightly to encourage more under-represented groups engaged with open-source development. The main focus of Outreachy remains with “women (both cis and trans), trans men, and genderqueer people to apply. We also expressly invite applications who are residents and nationals of the United States of America of any gender who are Black/African American, Hispanic/[email protected], Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.

But beginning this round, they are also opening the application process to “anyone who faces systemic bias or discrimination in the technology industry of their country is invited to apply.” For evaluating the systemic bias or discrimination, an essay question was added to the application process about what discrimination they may have faced or otherwise think they could face in seeking employment.

Also different beginning this round is only students (update: for non-student participants, this restriction does not apply) from the Northern Hemisphere can apply to this May to August round while the Southern Hemisphere round is being deemed the December to March round moving forward.

Another change with Outreachy for students applying is they no longer need to be full-time students but could be part-time students. Questions about school credits/classes have been dropped from the application while warning that false information is against their Code of Conduct.

Among the open-source projects participating in Outreachy for this upcoming round include Fedora to work on “Fedora Happiness Packets”, LibreHealth to improve code and documentation, OCaml with testing, OpenStack, and Wikimedia.

More details on this next round of the program at Outreachy.org.

Wine Developers Release Hangover Alpha To Run Windows x86_64 Programs On 64-Bit ARM


Wine developers André Hentschel and Stefan Dösinger have been working on “Hangover” as a means of running Windows x86/x86_64 applications on 64-bit ARM (AArch64) Linux and Android or even Windows for ARM. They are out today with the project’s first alpha release.

Hangover 0.4 is the first (alpha) release from this project for running x86/x86_64 Windows programs now on 64-bit ARM Linux distributions. Besides GNU/Linux platforms, Hangover can also run on Android as well. This also lays the groundwork for supporting Windows games on AArch64 using Direct3D/WineD3D though due to upstream Wine limitations that doesn’t yet work on Android due to WineD3D not working off OpenGL ES at this time.

Hangover makes use of Wine but also QEMU and other components. Hangover 0.4 Alpha is capable of running some Windows programs so far but is very much a work in progress.

Besides the performance overhead of Wine itself, there is greater “cost” involved due to emulating the x86/x86_64 architecture. The documentation outlines, “Don’t expect this to be fast. The main bottleneck at the moment is the speed of the code qemu generates from the input x86 code. To provide a rough comparison, my Nvidia Shield Android TV device (running a regular desktop Linux, not Android) runs games from the late 1990s to early 2000s at playable speed. The DirectX 9 SDK samples run fairly well because they contain little logic of their own and just call out of the VM into d3d, so all the heavy lifting is done natively. Warhammer 40k: Dawn of War starts a fresh game at around 30 fps but slows to a crawl as soon as a few units are built.

Those wanting to learn more about Hangover can do so at the GitHub project site.

WireGuard Released For macOS, WireGuard Windows Coming & Linux Kernel Bits Still Pending


The initial version of the WireGuard open-source secure VPN tunnel is now available for macOS, following the WireGuard for iOS port a few months prior. But sadly on the Linux front, the kernel bits still have yet to be mainlined.

WireGuard lead developer Jason Donenfeld announced the release of WireGuard for macOS on Saturday along with the cooperation of other developers. This macOS port is built from the same sources as their iOS app and integrates into Apple’s networking stack.

In the announcement about WireGuard for macOS, Donenfeld commented that the Windows client is still on its way but is taking a while due to writing a new TUN driver for Windows 7 and newer. This new driver should be safer and faster than the current OpenVPN TUN driver for Windows.

On the Linux kernel front for the long-awaited mainlining of the WireGuard kernel bits, there is unfortunately nothing new to report. It doesn’t look like WireGuard will be merged for Linux 5.1 as the code has yet to be staged in net-next. When I asked Donenfeld about it on Saturday, he said he expects to have a new revision of those patches available for review soon and that work is happening behind the scenes.

Those unfamiliar with this very promising, open-source secure VPN tunnel software can learn more at WireGuard.com.

Bitmain SoC Support Coming To Linux 5.1 – Sophon ARMv8 + RISC-V Chip For Deep Learning


Queued for mainlining with the upcoming Linux 5.1 kernel cycle is initial support for Bitmain SoCs. Bitmain is the Chinese company that started out designing ASICs for Bitcoin mining with the Antminer and other products. The company has also been venturing into designs for artificial intelligence and deep learning.

With the upcoming Linux 5.1 kernel will be initial support for Bitmain’s BM1880 System-on-a-Chip as well as the “Sophon Edge” developer board.

The Bitmain BM1880 SoC features a dual-core ARM Cortex-A53 processor plus a single core RISC-V subsystem as well as a Tensor processor subsystem. But with the initial state for Linux 5.1, only the A53 cores are enabled at the moment. The BM1880 is marketed as an “edge TPU” capable of delivering [email protected] performance, a single-core RISC-V processor capable of reaching 1GHz, and optimized for deep learning while only pulling around 2.5 Watts. The BM1880 is found in their Neural Network Stich, a Neural Network Module, and the Edge TPU Developer Board “Sophon Edge”.

With Linux 5.1, besides adding the BM1880 Sophon processor support there is also the Sophon Edge developer board that’s supported. Sophon Edge complies with Linaro’s 96Boards specifications and features 1GB of LPDDR4 memory, 8GB eMMC, Gigabit Ethernet, WiFi, USB 3.0, 40-pin GPIO header, and H.264/MJPEG encode/decode. Pricing on this board starts at around $130 USD and more details can be found via 96Boards.org.

So with Linux 5.1 is just the initial support and hopefully in succeeding releases the upstream kernel gets the enabling bits for the tensor and RISC-V subsystems to really make this SoC support interesting. Linaro developers have been the ones working on this upstream kernel support.

With Habana Labs Goya AI Processor also working on a mainline Linux driver, exciting times ahead for mainline kernel support on next-generation AI / deep learning hardware. All these recent efforts are what is leading to a likely hardware accelerator subsystem for the kernel.

Assess USB Performance While Exploring Storage Caching | Linux.com

The team here at the Dragon Propulsion Laboratory has kept busy building multiple Linux clusters as of late [1]. Some of the designs rely on spinning disks or SSD drives, whereas others use low-cost USB storage or even SD cards as boot media. In the process, I was hastily reminded of the limits of external storage media: not all flash is created equal, and in some crucial ways external drives, SD cards, and USB keys can be fundamentally different.

Turtles All the Way Down

Mass storage performance lags that of working memory in the Von Neumann architecture [2], with the need to persist data leading to the rise of caches at multiple levels in the memory hierarchy. An access speed gap three orders of magnitude between levels makes this design decision essentially inevitable where performance is at all a concern. (See Brendan Gregg’s table of computer speed in human time [3].) The operating system itself provides the most visible manifestation of this design in Linux: Any RAM not allocated to a running program is used by the kernel to cache the reads from and buffer the writes to the storage subsystem [4], leading to the often repeated quip that there is really no such thing as “free memory” in a Linux system.

An easy way to observe the operating system (OS) buffering a write operation is to write the right amount of data to a disk in a system with lots of RAM, as shown in Figure 1, in which a rather improbable half a gigabyte worth of zeros is being written to a generic, low-cost USB key in half a second, but then experiences a 30-second delay when forcing the system to sync [5] to disk. 

Read more at ADMIN magazine