Home Blog Page 359

​The Killer Chromebook: Google’s i7 Pixelbook

Want the best of all Chromebooks? Then get Google’s Pixelbook.

Now, I’ve liked Chromebooks since the experimental Cr-48rolled out in late 2010. And, when Google released its first high-end Chromebook, 2013’s Pixel, I was sold. I slowly but surely put away my Linux-powered Lenovo ThinkPads and started replacing them with Google’s high-end Chromebooks. Why? Because they’re better than any other laptop out there.

Besides, as my tech buddy Mike Elgan points out, today’s high-end Chromebooks “run more apps without dual- or multi-booting than any other computing platform. Chromebooks can run apps from Android, Linux, and Windows concurrently in the same session.”

Read more at ZDNet

GitLab’s High-End Plans Are Now Free for Open Source Projects and Schools

The fact that Microsoft is buying GitHub has left a lot of developers with a deep feeling of unease and a lot of them are now looking for alternatives. One of those is GitLab and that company has decided to strike the iron while it’s hot. To attract even more developers to its platform, GitLab today announced that its premium self-hosted GitLab Ultimate plan and its hosted Gold plan are now available for free to open source projects and educational institutions.

“Most education and open source projects don’t have access to enhanced security or performance management tools for their software projects,” GitLab CEO Sid Sijbrandij told me. “At GitLab, we are happy to have achieved a level of success that allows us to extend the full set of features to these important communities by offering GitLab Ultimate & GitLab Gold plans for free.”

Read more at TechCrunch

Linux Kernel 4.17, “Merciless Moray,” Offers Improved Performance and Security

Linus Torvalds released version 4.17 of the Linux Kernel on Sunday, nine weeks after the prior version. Although Linus says he is running out “of fingers and toes to keep track of minor releases,” he has decided not to call this release “5.0” because he is saving that for 4.20.

As with the 4.16 cycle, 4.17 has been a relatively smooth, save a few hiccups due to those pesky chip issues. It turns out the shadow of the Spectre vulnerability is still long, and the last two weeks before the release were a busy ones, with patches designed to counteract the effects of Spectre v4 making up a significant portion of all the code submitted. That said, and even though Linus does not like large amounts of changes so late in the release cycle, he skipped an rc8 and released the final version of 4.17 anyway.

Be as it may, 4.17 also comes with plenty of other improvements. There is the set of changes that will improve the power consumption on most machines, for example. These changes affect what is called the “idle loop” of the kernel. Even if your machine is apparently not doing anything, as long as it is powered up, the kernel is working. The new code optimizes the “downtime” processes and, according to its author Rafael Wysocki, power consumption could go down “10% or more.” This means battery charges will last longer on laptops, clusters will be more efficient, and machines will be more eco-friendly across the board.

Something that is not often mentioned in these reports are the various curios — the leftovers from times gone by that still have developers working on them — such as the case of the Macintosh PowerBook 100 series, a laptop series manufactured by Apple in the early 1990s which used a Motorola processor. These things are still being maintained, and 4.17 comes with several improvements for the devices. I wonder if it is too late to get the support for the Commodore 64 in there.

Although the PowerBook 100 is still being supported, on a more pragmatic note, other architectures have been dropped. Such is the case of eight obsolete CPUs, including the Unicore32, Blackfin, and Hexagon, among others. All of these processors are very niche and are being superseded by other more modern alternatives. Support for POWER4 and POWER4+ processors is also being removed. Considering IBM is now on the ninth generation of POWER, it was probably about time. Dropping these architectures has had the side effect of making 4.17 one of the lightest releases in recent years, where the number of lines removed is larger than the number of lines added. All told, getting rid of code for obsolete architectures eliminates about half a million lines from the kernel.

Other stuff to look forward to in kernel 4.17

  • Kernel 4.17 also comes with HDCP, or High-bandwidth Digital Content Protection. This is the technology that “protects” proprietary content by making perfectly functional, but uncertified hardware underperform or directly useless. This may seem counterintuitive, and it is. No buts. The idea is that, to protect music and videos, manufacturers must certify their video cards, monitors, and HDMI cables (and pay up considerable amounts of money) so that HDCP-protected content will play on the devices. If making software act as an obstacle on perfectly adequate hardware sounds like a bonkers idea, that’s because it is. But that’s the state of the protection of copyrighted material nowadays. At least in theory, the inclusion of HDCP is a step towards allowing user to be able to play protected content.

  • Fortunately, most code in this release improves performance on the users’ machines. Changes in the realm of drivers/controllers and AMD video cards received a big boost this time around. In 4.17, AMDGPU DC is enabled by default, for example, and is now in the mainline kernel. This means you won’t need to install an external DKMS driver for your Radeon card at full capacity, and you will have HDMI/DP audio out of the box. Another improvement is that AMDKFD is now also part of the mainline kernel. This is important for using AMD GPUs in high performance computing, where GPUs are used to carry out complex and consuming calculations.

  • Speaking of performance enhancements, work has begun on code that allows users to tweak the power management of their cards and the first changes have also been incorporated into 4.17: On other platforms, Radeon WattMan allows users to control the voltage, fan speed, engine clock and so on of their cards, and that is what developers are starting to work into the Linux kernel.

  • Support for the RISC-V, the open source processor architecture, is also chugging along nicely. Developers have added dynamic ftrace on RISC-V, cleaned up the atomic and locking routines, as well as the module loading support. The latter is now enabled by default.

As always, to find out more, you can check out Kernel Newbies (when it becomes available) and Phoronix.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

An Introduction to FRRouting

I recently learned about FRRouting (FRR), an IP routing protocol suite for Linux and Unix platforms. FRR has been under rapid development since the first release in April 2017. So, they just turned one, and they recently released version 4.0 of the software. According to the website, this release brings various enhancements aimed at creating the best routing protocol stack available.

How did I not know about all this? Doubtless due to a personal defect. In any case, the contributors designed FRR to streamline the routing protocol stack. FRR can be used for connecting hosts, virtual machines, and containers to the network, for network switching and routing, and much more. Here’s what I learned about the excellent FRRouting project and how it came to be.

FRR has its roots in the Quagga project, which I covered here. In fact, it started as a fork by some long-time Quagga developers who combined their efforts to improve on that project’s well-established foundation.

Why Fork?

Anyone can fork an open source project, which can be either an advantage or a disadvantage. A fork can double the workload, divide the contributor community, or make two “meh” projects instead of one great one. It can create hard feelings. Or, a fork can succeed, by reviving a moribund project and bringing new energy and enthusiasm. It can also rescue a code base from the clutches of a bad commercial steward. Forking a project is rarely done on a whim because it’s a such a big step.

Examples of successful forks include Ubuntu, forked from Debian (although arguments rage over whether it is really a fork or some other weird thing nobody can think of a word for), the LibreOffice fork of OpenOffice, and my favorite, the MariaDB fork of MySQL.

MariaDB is the all-time great “having your cake and eating it” story. The short version is Sun Microsystems bought MySQL for a cool billion dollars and hired the talent that built it. But the MySQL executive team, including Monty Widenius and Marten Mickos, were publicly unhappy with Sun. They left Sun, taking their billion dollars with them. Then Oracle bought Sun, which motivated Widenius to fork MySQL and found MariaDB, which has been a clear success. (A longer version is here: Migrating to MariaDB from MySQL.)

Why Fork Quagga?

Quagga was created as a fork of the GNU Zebra project, which had died. So, FRR is a fork of a fork. I asked on the FRR developer’s mailing list about this and received a wealth of interesting answers. (You can read the whole thread on the dev list archive.)

Here’s what people said:

“There was a desire for a project that was governed by community consensus and documented process.”

“I find the FRR community very welcoming, very friendly, extremely helpful and respectful. It is very rare I come across communities like this and it is a real pleasure to engage in conversation and work on issues with them. If one needs a few eyes on a bit of code all you have to do is ask and you get constructive input, almost all of the time from multiple people.”

“The easy and pleasant direct access to the developers is a great bonus.”

Community-driven development

There was a point in time where Quagga was running on a skeleton crew, and thousands of patches were backed up from a variety of contributors, sitting, aging, and going nowhere. Thus, working through the backlog and creating a fast-paced, community-oriented project governed by consensus and documented process are some of the primary FRR drivers. A lot of the work on FRR is devoted to implementing new protocols and features, including cloud networking technologies.

Governance

Governance is also a necessary part of any OSS project, and it can make or break a project. FRRouting managed this by joining the vendor-neutral Linux Foundation, which is home to many important projects including the Node.js Foundation, Let’s Encrypt, and of course the Linux kernel.

FRRouting has a six-member technical steering committee, and members are elected to one-year terms. Maintainers have regular open meetings, and there is an official charter. This governing structure helps the project handle the numerous issues that any large, complex, and essential software project has to deal with, such as development direction and priorities, differences of opinion, licensing, finances, and so on.

Getting and Using FRR

FRR is hosted on GitHub. You may clone the repository, download source tarballs, or download .deb and .rpm packages. The documentation is quite good, and there is detailed information on becoming a contributor. The FRR user guide also provides a great overview of the architecture.
Visit FRRouting to learn more about the project. Also check out FRRouting on Juniper’s Advanced Forwarding Interface for an interesting example of where FRR is already finding a home in advanced networking architectures.

Upstream Linux Support for New NXP i.MX 8

The i.MX 6 platform has for the past few years enjoyed a large effort to add upstream support to Linux and surrounding projects. Now it is at the point where nothing is really missing any more. Improvements are still being made, to the graphics driver for i.MX 6, but functionally it is complete. The i.MX8 however, is a different story.

By Robert Foss, Software Engineer at Collabora.

The i.MX 6 platform has for the past few years enjoyed a large effort to add upstream support to Linux and surrounding projects. Now it is at the point where nothing is really missing any more. Improvements are still being made, to the graphics driver for i.MX 6, but functionally it is complete.

Etnaviv driver development timeline

The i.MX8 is a different story. The newly introduced platform, with hardware still difficult to get access to, is seeing lots of work being done, but much still remains to be done.

That being said, initial support for the GPU, the Vivante GC7000, is in place and is able to successfully run Wayland/Weston, glmark, etc. This should also mean that running Android ontop of the currently not-quite-upstream stack is possible using drm_hwcomposer.

An upstream display/scanout driver does currently not exist, since the display IP in the i.MX 8 is different and more capable than the IP in the i.MX 6 platform, the current imx-drm driver is not capable of supporting it.

A driver is provided by the NXP base support package. This BSP driver is based on KMS Atomic and supports most of the bells and whistles one would hope for, but is currently not in an upstreamable shape.

i.MX8 Kernel Support

But patches for the gpio, clk, netdev & arm-kernel subsystems have been submitted to their respective mailing lists by Lucas Stach.

The direct support for the i.MX8 that has landed in the kernel at this point is mostly done by NXP engineers.

But there are lots of components that currently have no support. The Video Processor Unit IP, the Hantro G1/G2, does not have any upstream support.

i.MX8 U-Boot Support

Looking at bootloader support, U-Boot has good support for the i.MX 8M platform since early 2018, and can be expected to just work.

Looking forward

While lot’s of support is still missing for the i.MX 8, the platform is under active development, with many new pieces of the hardware seeing attention.

Purism is one of the vendors who currently is actively working towards full Open Source support of the i.MX 8 platform.

Devboards

WandPi 8M is a series of 3 different boards based on the i.MX 8M platform.

Nitrogen 8M is another i.MX 8M based option, made by Boundary Devices who also made the popular Sabre Lite series of boards for the i.MX 6.

10 Principles of Resilience for Women in Tech

Women in technology roles have dropped from its peak in 1991 at 36% to 25% today, according to a report by NCWITHarvard Business Review estimates that more than half of the women in tech will eventually leave due to hostile work conditions. Meanwhile, Ernst & Young recently shared a study and found that merely 11% of high school girls are planning to pursue STEM careers.

We have much work to do, lest we build a future that is less inclusive than the one we live in today. We need everyone at the table, in the lab, at the conference and in the boardroom.

I’ve been interviewing both women and men for more than a year now about their experiences in tech, all as part of The Chasing Grace Project, a documentary series about women in tech. The purpose of the series is to help recruit and retain female talent for the tech industry and to give women a platform to be seen, heard, and acknowledged for their experiences. We believe that compelling story can begin to transform culture.

Read more at OpenSource.com

Tesla Starts to Release its Cars’ Open-Source Linux Software Code

It’s an open secret: Tesla cars are powered not only by batteries but by open-source software. Until recently, though, Tesla hasn’t lived up to its obligations under open-source licenses, but now Tesla is finally releasing some of its Linux source code for the Model S and X cars.

The Tesla GitHub repository contains the code for the Model S/X 2018.12 software release. Specifically, it holds the system image on the Tesla Autopilot platform, the kernel sources for its underlying hardware, and the code for its Nvidia Tegra-based infotainment system.

Tesla will release additional open-source code for other systems in their cars soon. According to Tesla, “Work is underway on preparing sources in other areas as well, together with a more coordinated information page. We wanted to let you know about this material as it is available now while work continues on the other parts.” 

Read more at ZDNet

The Open Source, Private Cloud Alternatives to Dropbox and Slack

It’s part of a growing trend to replace cent1rally hosted services with those that can be run on servers under an individual or organization’s control in their own legal jurisdictions—and customed to their specific needs.

“As a company, we don’t have any servers—we don’t do any hosting,” says Nextcloud founder and managing director Frank Karlitschek, speaking with Fast Company through his product’s video chat feature. “They put it on whatever hardware or hosting infrastructure they trust.” For a family or couple looking to share files or photos or keep their calendars in sync, that can be something as simple as a the low-cost Raspberry Pi.

The move to the self-hosted cloud isn’t limited to file-sharing tools. Mattermost, a workplace chat tool with features similar to Slack, is designed to be hosted on a company’s private servers, storing chat logs in the company’s databases.

Read more at Fast Company

This Week in Numbers: The Node.js User’s Tech Stack

The Node.js Foundation published its third annual user survey based on 1,626 members of the Node community. In the future, we will look at the package managers and languages these developers are using. For now, readers will be interested to see the types of infrastructure that are most often used by with Node.js.

It is not surprising that React is by far the most used front-end framework. In second place is jQuery, which is often not considered in the same category as Angular and Vue. It is noteworthy that 40 percent of respondents had used either Angular or Angular2.

Read more at The New Stack

CNCF to Host Helm

Today, the Cloud Native Computing Foundation (CNCF) Technical Oversight Committee (TOC) voted to accept Helm as an incubation-level hosted project.

No longer a sub-project under Kubernetes, Helm is a package manager that provides an easy way to find, share, and use software built for Kubernetes. Helm removes complexity from configuration and deployment, and enables greater developer productivity.

“Helm addresses a common user need of deploying applications to Kubernetes by making their configurations reusable,” said Brian Grant, TOC representative and project sponsor, Principal Engineer at Google, and Kubernetes SIG Architecture co-chair and Steering Committee member. “Both the Helm and Kubernetes projects have grown substantially. As Kubernetes shifts its focus to its own core in order to better manage this growth, CNCF is a great home for Helm to continue making it easier for developers and operators to streamline Kubernetes deployments.”

According to a recent Kubernetes Application Survey, 64 percent of the application developers, application operators, and ecosystem tool developers who answered the survey reported using Helm to manage apps on Kubernetes.

“As Kubernetes focuses more on stability, CNCF gives Helm a new home to ensure the community’s needs will be met,” said Chris Aniszczyk, COO of Cloud Native Computing Foundation. “Helm has scaled their community with hundreds of contributors to its core and community charts, and we look forward to growing their community even further.”

The project was started by Deis (now part of Microsoft) in 2015 and later evolved into Kubernetes Helm, the merged result of Helm Classic and the Kubernetes Deployment Manager (built by Google). The project has more than 300 contributors, and more than 800 contributors to the community charts, a successful conference based solely on Helm, and a unique culture in comparison to core Kubernetes.

“In building Helm, we set out to build a tool to serve as an onramp to Kubernetes – one that seasoned developers would not only use, but also contribute back to,” said Matt Butcher, co-creator of Helm and Principal Engineer at Microsoft. “By joining CNCF, we’ll benefit from the input and participation of the community and, conversely, Kubernetes will benefit when a community of developers provides a vast repository of ready-made charts for running workloads on Kubernetes.”

Conceptually, Helm is similar to OS-level package managers like AptYum, and Homebrew in that it handles putting things in the right place for the running application  bringing all of the advantages of an OS package manager to a Kubernetes container platform. Helm’s packaging format, called charts, is a collection of files that describe a related set of Kubernetes resources. Charts are created as files laid out in a particular directory tree, which can then be packaged into versioned archives to be deployed.

Main Features:

  • Find and use popular software packaged as Kubernetes charts
  • Share applications as Kubernetes charts
  • Create reproducible builds of your Kubernetes applications
  • Intelligently manage Kubernetes manifest files
  • Manage releases of Helm packages

Notable Milestones:

  • 330 contributors
  • 5,531 GitHub stars
  • 51 releases
  • 4,186 commits
  • 1,935 forks

As a CNCF hosted project – alongside Incubated technologies like Prometheus, OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd, rkt, CNI, Envoy, Jaeger, Notary, TUF, Vitess, and NATS – Helm is part of a neutral foundation aligned with its technical interests, as well as the larger Linux Foundation, which provide the project with governance, marketing support and community outreach.

Every CNCF project has an associated maturity level: sandbox, incubating, or graduated project. For more information on what qualifies a technology for each level, please visit https://www.cncf.io/projects/graduation-criteria/.

For more on Helm, please visit https://helm.sh/, and read more from co-creator Matt Butcher on the Deis Blog. You can also watch this session from KubeCon + CloudNativeCon Austin on building Helm charts, and read this blog post to see how Helm can be used with other projects.

This article originally appeared at Cloud Native Computing Foundation