Fedora Developers Look At Packaging Up The Radeon Open Compute Stack (ROCm)

While the ROCm "Radeon Open Compute" stack has been fully open-source for a while and in recent months even able to work fine off a mainline Linux kernel, a barrier to its adoption has been officially just have binaries produced by AMD for RHEL/CentOS/Ubuntu and not seeing these components including its OpenCL driver available through Linux distribution repositories. Fortunately, in 2019, that may finally be changing.

Over the Linux kernel releases in 2019 we saw the AMDKFD "Kernel Fusion Driver" support in the mainline Linux kernel get into good shape so that it's running well with recent discrete graphics cards and jiving with the latest releases of ROCm. Previously, ROCm depended upon an out-of-tree DKMS kernel module due to necessary functionality not being mainlined. That was a blocker to ROCm's wider/easier adoption but is no longer the case and new Linux kernel releases continue tacking on improvements to AMDKFD.

Qubes OS 4.0.1 Released, Plasma 5.14.15 Is Out, Software Freedom Conservancy Fundraiser, ClearCube Launches C3xPi Thin Client for RPi 3 Model B+ and Ubuntu Touch Announces OTA-7

Qubes OS 4.0.1 was released today, marking the first stable point release in the 4.0 series. Updates include all 4.0 dom0 updates, Fedora 29 TemplateVM, Debian 9 Template VM, Whonix 14 Gateway and Workstation TemplateVMs, and Linux kernel 4.14. You can get Qubes 4.0.1 from the Downloads Page.

Máirín Duffy: Which new Fedora logo design do you prefer?

How to install Shutter screenshot tool on a Fedora Linux

nightly builds are too fast and too slow

When you write code and test it, you want that feedback loop to be as tight as possible. Write code, save, compile, test - the faster these things happen, the faster your brain stays engaged.

If you have to sit and wait a few minutes to get information back about whether your code is correct or your build process succeeded, you're going to context switch to something else and lose time when you forget to switch back.

When we reach build processes that take hours, now we're in the "Meh, I'll check it when I'm back from lunch" territory. At that rate, you're probably only going to be running that process three or four times a day, max. Your workday is only eight hours, after all. The thoroughput for your changes drops through the floor.

Now imagine extending that feedback loop even further, to a full 24 hours. You've just arrived at the "nightly build".

When that nightly build breaks, you have eight working hours to fix it and then you get to wait again for tomorrow morning when you find out the new problem.

After a few days of this, you no longer arrive at work with the same positive mental energy. Your morning email inbox experience becomes a thing where you discover what has gone wrong during the night, because you never saw it go right during the daytime.

Operational tempo slides further, because it feels like "everything takes so long around here." Teams lower their optimistic expectations that anything should ever happen quickly.

I've seen several odd knock-on effects here.

Sometimes what happens then is that you have multiple "nightlies" for a single day. One is the first broken nightly that ran in cron, and the others are multiple attempts where someone ran the script by hand trying to get it to pass. The "nightly" is no longer nightly. Odds are that those manual runs did not do everything exactly like the full cron job did. More confusion ensues across the organization.

AdamW’s Debugging Adventures: Python 3 Porting 201

Hey folks! Time for another edition of AdamW’s Debugging Adventures, wherein I boast about how great I am at fixin’ stuff.

Today’s episode is about a bug in the client for Fedora’s Koji buildsystem which has been biting more and more Fedora maintainers lately. The most obvious thing it affects is task watching. When you do a package build with fedpkg, it will by default “watch” the build task – it’ll update you when the various subtasks start and finish, and not quit until the build ultimately succeeds or fails. You can also directly watch tasks with koji watch-task. So this is something Fedora maintainers see a lot. There’s also a common workflow where you chain something to the successful completion of a fedpkg build or koji watch-task, which relies on the task watch completing successfully and exiting 0, if the build actually completed.

Fedora Participates in Google Code In 2018

Red Hat Summit 2019 registration is now open!

We’re heading back to Boston and the Boston Convention and Exhibition Center on May 7-9, 2019, where we expect thousands of customers, partners and technology industry leaders from around the world to come together for a high-energy week of innovation, education and collaboration.

Automatically Update Red Hat Container Images on OpenShift 3.11

Red Hat OpenShift manages container images using a registry. This is the place where it caches upstream container images and stores the images from your own builds as well. Each build or container image correlates to an ImageStream, which is an object that defines any number of related images by tags. For example, one specific version of a Ruby container might be v2.5-22, but you can have one ImageStream definition that holds ruby tags and correlates images for v2.5, v2.4, v2.3 and so on.

Combining Federation V2 and Istio Multicluster

In a previous post, we saw how to leverage Istio Multicluster to deploy an application (bookinfo) on multiple Red Hat OpenShift clusters and apply mesh policies on all of the deployed services.

We also saw that the deployment process was relatively complex. In this post we are going to see how Federation V2 can help simplify the process of deploying an application to multiple clusters.

First Commercial Quantum Computer From IBM Features An Awe Inspiring Design

With CES 2019 underway, IBM has unveiled the world’s first commercial quantum computing system Q System One. Visually, it’s nothing less than a piece of art. Q System One lays the foundation of IBM’s plans to make quantum computing systems a commercial reality.

These former Red Hat employees just got $25 million to try to find a new business model for open source software

Back in the early 2000s, people would balk at the notion of using free, open source software to run a serious business — companies like Red Hat, which bet its business model on the concept, were seen as oddities. But times have changed: Open source software is key to most modern computing infrastructures. And over a decade later, IBM plans to acquire Red Hat for a colossal $34 billion.

Now, a group of former Red Hat employees have co-founded Tidelift, a startup that wants to repeat the trick and pioneer a new business model for open source software. To that end, Tidelift announced on Monday $25 million in new funding from General Catalyst, Foundry Group, and former Red Hat CEO Matthew Szulik.

Tidelift Raises $25M Series B Just Seven Months After Last Funding

Tidelift, a startup focused on helping developers work with open source technology, announced today the close of a $25 million Series B round of funding just seven months after its last raise.

The Boston company has now raised a total of $40 million since it was founded in 2017.

Tidelift’s “Netflix for Open-Source Software” Model Gets $25M Boost

Tidelift, a startup trying to solve some of the open-source software industry’s problems around compensation and security, said it wrapped up a $25 million investment to gather more publicly maintained software projects under its umbrella.

The Boston-based company, founded in 2017 by four Red Hat vets, said it is trying to recreate what Red Hat (NYSE: RHT) did with the Linux open-source computer operating system—but with as large a swath of the open-source realm as possible.

Open source monetization startup Tidelift raises $25m series

Open source startup Tidelift grabs $25 mln Series B

Former Red Hat CEO Backs Tidelift’s $25M Series B

Open source software company Tidelift raised $25 million in a Series B funding round, which followed closely on the heels of its $15 million Series A just seven months ago. General Catalyst, Foundry Group, and former Red Hat Chairman and CEO Matthew Szulik co-led the Series B. All three investors also co-led the startup’s Series A.

The Boston-based company provides support services for open source projects including JavaScript, Java, Python, Ruby, Apache Struts, and Mongoose by partnering with project maintainers.

Its business model works like this: companies pay Tidelift a subscription, and in return they receive professional support for the open source projects they use from the developers who created and maintain these projects. This includes security updates, maintenance, and legal assurances.

Tidelift, in turn, pays the developers to provide this support. And this cycle “makes open source work better for everyone,” wrote co-founder and CEO Donald Fischer in a blog about the Series B. “More than 35 million open source repositories now depend on packages that are included in the Tidelift Subscription.”