Language Selection

English French German Italian Portuguese Spanish

Red Hat

Richard Hughes: Breaking apart Dell UEFI Firmware CapsuleUpdate packages

Filed under
Red Hat
Hardware
GNOME

When firmware is uploaded to the LVFS we perform online checks on it. For example, one of the tests is looking for known badness like embedded UTF-8/UTF-16 BEGIN RSA PRIVATE KEY strings. As part of this we use CHIPSEC (in the form of chipsec_util -n uefi decode) which searches the binary for a UEFI volume header which is a simple string of _FVH and then decompresses the volumes which we then read back as component shards. This works well on plain EDK2 firmware, and the packages uploaded by Lenovo and HP which use IBVs of AMI and Phoenix. The nice side effect is that we can show the user what binaries have changed, as the vendor might have accidentally forgotten to mention something in the release notes.

Read more

A beginner's guide to Silverblue

Filed under
Red Hat

At Red Hat Summit 2019, I became fascinated with Fedora Silverblue, an immutable (i.e., unchangeable) variant of Fedora Workstation that primarily uses Flatpak to install apps. I've used Fedora for nearly three years (and Linux for about 22 years) and recently upgraded my machines (home and work) to Fedora 30. But I liked the idea of an immutable desktop and resolved to try it out when I got home.

According to the Fedora Silverblue User Guide:

"Fedora Silverblue is an immutable desktop operating system. It aims to be extremely stable and reliable. It also aims to be an excellent platform for developers and for those using container-focused workflows."

The day I returned from Red Hat Summit, I downloaded the latest image of Silverblue from the main Silverblue website. I burned it to a USB drive (do you really "burn" to a USB drive?) and tried to install it. The process failed, but I was jet-lagged, so I headed to bed suspecting that the problem might lie with the USB drive—I've found that about 50% of USB drives have problems when you try to install Linux from them. I woke up early (jet lag still), found a new USB drive, and tried again.

Read more

Also: PHP version 7.1.30, 7.2.19 and 7.3.6

GNOME and Fedora/Red Hat: Translation, Rust, Sysprof and EPEL

Filed under
Red Hat
GNOME
  • Why translation platforms matter

    In my opinion, the GNOME platform offers the best translation platform for the following reasons:

    Its site contains both the team organization and the translation platform. It's easy to see who is responsible and their roles on the team. Everything is concentrated on a few screens.
    It's easy to find what to work on, and you quickly realize you'll have to download files to your computer and send them back once you modify them. It's not very sexy, but the logic is easy to understand.
    Once you send a file back, the platform can send an alert to the mailing list so the team knows the next steps and the translation can be easily discussed at the global level (rather than commenting on specific sentences).
    It has 297 languages.
    It shows clear percentages on progress, both on basic sentences and advanced menus and documentation.
    Coupled with a predictable GNOME release schedule, everything is available for the community to work well because the tool promotes community work.

    If we look at the Debian translation team, which has been doing a good job for years translating an unimaginable amount of content for Fedora (especially news), we see there is a highly codified translation process based exclusively on emails with a manual push in the repositories. This team also puts everything into the process, rather than the tools, and—despite the considerable energy this seems to require—it has worked for many years while being among the leading group of languages.

    My perception is that the primary issue for a successful translation platform is not based on the ability to make the unitary (technical, translation) work, but on how it structures and supports the translation team's processes. This is what gives sustainability.

    The production processes are the most important way to structure a team; by putting them together correctly, it's easy for newcomers to understand how processes work, adopt them, and explain them to the next group of newcomers.

    To build a sustainable community, the first consideration must be on a tool that supports collaborative work, then on its usability.

    This explains my frustration with the Zanata tool, which is efficient from a technical and interface standpoint, but poor when it comes to helping to structure a community. GIven that translation is a community-driven process (possibly one of the most community-driven processes in open source software development), this is a critical problem for me.

  • Federico Mena-Quintero: Bzip2 in Rust - Basic infrastructure and CRC32 computation

    I have started a little experiment in porting bits of the widely-used bzip2/bzlib to Rust. I hope this can serve to refresh bzip2, which had its last release in 2010 and has been nominally unmaintained for years.

    I hope to make several posts detailing how this port is done. In this post, I'll talk about setting up a Rust infrastructure for bzip2 and my experiments in replacing the C code that does CRC32 computations.

  • Sysprof Developments

    Earlier this month, Matthias and I teamed up to push through some of our profiling tooling for GTK and GNOME. We took the occasional work I had done on Sysprof over the past few years and integrated that into the GTK-4.x tree.

    Sysprof uses a binary log file to store information about execution in a matter that is easy to write-buffer and read-back using positioned reads. It helps keep the sampling overhead of sysprof low. But it’s too detail oriented for each application supporting the format to write. To make this stuff reusable I created a libsysprof-capture-3.a static library we embed from various layers of the platform.

    GTK-4.x is now using this. Builder itself uses it to log internal statistics, tracing data, and counters for troubleshooting. I’ve also put forward patches for GJS to integrate with it. Georges revamped and pushed forward a prototype by Jonas to integrate with Mutter/Shell and get us frame timings and Cogl pipeline data. With some work we can finish off the i915 data sources that Eric Anholt did to correlate GPU commands too.

    What this means for developers is that soon we’ll be able to capture system information from various layers in the stack and correlate them using similar clocks. We’re only scratching the surface right now, but it’s definitely promising. It’s already useful to quantify the true performance improvements of merge-requests in Mutter and Shell.

  • Sysprof Making Progress For Improved GNOME Profiling

    Christian Hergert of GNOME Builder IDE fame has been working on a round of improvements recently to the Sysprof tool he also leads development on for system profiling in determining the hot functions of a program and related profiling mostly around GNOME components.

    One of the main additions has been adding support to GTK4 for Sysprof's new engine and he is planning on plumbing that new engine support through to at least Mutter and GJS while potentially back-porting it to the likes of GTK3.

  • EPEL Proposal: EPEL Wagontrain (aka Steve Gallagher's EPEL 8 Branch Strategy)

What's new with Red Hat Enterprise Linux 8 and Red Hat Virtualization

Filed under
Red Hat

Red Hat Enterprise Linux (RHEL) 8 is based upon the principles of "operational consistency, security, and cloud foundation." Utilizing kernel 4.18x, RHEL 8 is based on Fedora 28 and will run on Intel/AMD 64-bit processors as well as IBM Power LE, IBM z Systems, and ARM 64-bit.

Red Hat has sought to reduce complexity in RHEL 8, which comes with ten guaranteed years of enterprise support. Their model involves repositories for the base operating system as well as application streams for flexible lifecycle options, which offer multiple versions of databases, languages, various compilers, and other tools to help facilitate the use of RHEL for business models.
Build-in defaults in RHEL 8 include tuned profiles for database options (ready-to-go options out of the box) and ansible system roles to provide a common configuration interface (ensuring standardization and reliability)
The RHEL 8 YUM package manager is now based on the Dandified Yum (DNF) technology, which supports modular content, better performance, and a stable API for integration with tooling. User feedback indicated that "yum is a lot faster than it used to be, and all the commands work well."
Red Hat Insights (tools to provide system administrators with analytics, machine learning, and automation controls) are now included in RHEL 8 along with a session recording feature, which can record and playback user terminal sessions for better security and training capabilities.

Read more

HPC Chips, IBM and Red Hat on Servers

Filed under
Red Hat
Server
Hardware
  • Tachyum Boots Linux on Universal Processor Chip

    Today Tachyum announced it has successfully deployed the Linux OS on its Prodigy Universal Processor architecture, a foundation for 64-core, ultra-low power, high-performance processor. Running an OS directly and natively on its chip, without the need for host processors or other expensive components, reduces the cost of at-scale data centers and enables nearly unlimited flexibility in use.

  • Powering the Future of HPC & AI with OpenPOWER

    It is coming up on one year that the Summit supercomputer based on IBM POWER9 at Oak Ridge National Lab claimed the number one spot on the Top500 ranking. This system represents the culmination of a significant collaboration between OpenPOWER foundation members IBM, Nvidia, Mellanox and Red Hat with the goal of producing well a balanced computing platform for not only traditional HPC workloads such as modelling and simulation, but also AI workloads. With this milestone approaching, we took the opportunity to catch-up with Hugh Blemings, Executive Director at the OpenPOWER Foundation to chat about the foundation, and what lies ahead.

  • The limits of compatibility and supportability with containers

    Many folks who do container development have run Alpine container images. You might have run Fedora, Red Hat Enterprise Linux (RHEL), CentOS, Debian, and Ubuntu images as well. If you are adventurous, you may have even run Arch, Gentoo, or dare I say, really old container images - like, RHEL 5 old.

    If you have some experience running container images, you might be led to believe that anything will just work, all the time, because containers are often thought to be completely portable across time and space. And a lot of the time, they do work! (Until they don't.)

    It’s easy to assume that there is nothing to worry about when mixing and matching the container image userspace and host operating system. This post intends to give a realistic explanation on the limits of compatibility with container images, and demonstrate why bring your own images (BYI) isn't a workable enterprise solution..

  • Unlocking new levels of operational efficiency in financial services

    The financial services industry is changing. While the fundamental principles that the industry is built on remain the same—such as trust, value and customer service—the way financial organizations deliver on these values is far different from what it once was. We are now in an always-on, ever-connected world where banking customers expect to have access to accounts, information and services whenever and wherever they want, and the way organizations handle these operations can make or break the overall customer experience - and the bottom line.

    Financial services institutions need to find a balance between driving new innovations and keeping costs in check—all while meeting regulatory requirements. This culture of real-time engagement and access to information is leading organizations to not only reexamine business operational processes but also to think critically about the capabilities their core back-end banking systems provide, making changes and modernizing systems to keep pace.

  • Multi-architecture OpenShift containers

    Following the initial release of RHEL8-based OpenJDK OpenShift container images, we have now pushed PPC64LE and Aarch64 architecture variants to the Red Hat Container Registry. This is the first time I've pushed Aarch64 images in particular, and I'm excited to work on Aarch64-related issues, should any crop up!

Red Hat and Fedora Miscellany

Filed under
Red Hat
  • AND…now comes digital transformation…

    Hope you all got home safely after a great Red Hat Summit 2019 in Boston. AND was the theme, and it was all about scaling your technology and culture to meet the specific challenges you face – especially in the area of digital transformation for your business.

    One thing that we took away from all the presentations and demos was that hybrid cloud is the infrastructure of choice for enterprises today. We see that enterprises continue to invest in both private and public cloud options for improved operations and greater productivity. Hybrid cloud allows IT managers to control costs and increase security through optimized workload placement.

  • Firefox & Wayland HiDPI screens

    When comes to HiDPI screens and resolutions Firefox has always had some technical debts there. Wayland slightly improved it but we still miss clean user experience.

    We tried hard to improve it and the last piece – hi-res widget rendering – landed in upcoming Firefox 68 (recently Beta). That means Firefox should be fully compatible with HiDPI screens and you shouldn’t see any glitches there.

  • Announcing Alberto Rodríguez Sánchez as next CommOps team lead

    The CommOps team is happy to announce Alberto Rodríguez Sánchez (bt0dotninja) as the next CommOps team lead. Alberto contributes to the CommOps team since July 2016 as a leading member. Starting in the Fedora 30 release cycle, he will succeed leadership from Justin W. Flory.

    Fedora CommOps started in 2015 from a vision. The vision was to enable a new kind of contributor: contributors who worked within Fedora to support sustainable community management practices among other teams of Fedora contributors.

  • Plymouth Adds New Firmware Upgrade Mode For Better Fwupd Integration

    Plymouth, the Linux graphical boot splash screen system/interface used by most Linux distributions out there, now has a "firmware upgrade mode" for offering a tighter level of integration with Fwupd when performing system BIOS/firmware updates.

    The firmware upgrade mode for Plymouth was written by Fwupd/LVFS lead developer Richard Hughes. Richard is employed by Red Hat along with the Plymouth and Fwupd development all being started by and driven by Red Hat developers. This firmware upgrade mode allows for providing localized text string translations for during the firmware update process and also for displaying the vendor BIOS logo (on supported systems) during the firmware update process.

Red Hat and Fedora: Red Hat Satellite, CRI-O and Podman, EPEL Proposal, Outreachy, NeuroFedora and Cockpit

Filed under
Red Hat
  • Red Hat Satellite Ask Me Anything Q&A from April 2019

    For anyone not familiar, the Satellite AMAs are an ask me anything-style event where we invite Red Hat customers to bring all of their questions about Red Hat Satellite, drop them in the chat, and members of the Satellite product team will answer as many of them live as we can during the AMA and we then follow up with a blog post detailing the questions and answers.

  • Why Red Hat is investing in CRI-O and Podman

    As an engineering organization, Red Hat is investing in CRI-O and Podman, participating in the Open Containers Initiative standards body, testing performance and security, as well as driving architectural changes in a number of container projects because the underlying shared components help drive innovation in its products like Red Hat OpenShift and Red Hat Enterprise Linux. These investments are closely related to the operating system itself and provide our customers with the best products we can produce.

  • EPEL Proposal: EPEL Master branch AKA Rawhide

    In order to allow for the ability for faster availability of packages, add rawhide branches for EPEL-7 and EPEL-8. These branches would allow developers to build new packages they aren't sure are ready for either EPEL-N or EPEL-N-testing, and would allow for faster rebuilds of newer features when RHEL has a large feature change. 

  • FHP: Outreachy! Is it that hard to crack?

    Getting into one of the reputed internship programs might seem scary and unachievable especially when you don’t consider yourself an expert in that field, but trust me it’s not that hard to get into. How can I say this with so much certainty? Well, I got into Outreachy, one of the prestigious internships as a Fedora intern and through this article, I want to share my journey with you all.

  • Fedora science/research get together at Flock

    This year, Flock will be held in Budapest from August 8--11. As part of NeuroFedora, we've already proposed a talk to discuss how Free/Open source software links very very well with Free/Open science. Please see the proposal here, and give feedback: https://pagure.io/flock/issue/112.

    Apart from that, given that a large number of community members congregate at Flock, it may be a good chance to get together those of us that work in science/research and related areas. So, if you are planning to attend Flock and work in, or are interested in science/research, please drop a note at this tracker ticket: https://pagure.io/neuro-sig/NeuroFedora/issue/242

  • Cockpit Project: Cockpit 195

    It’s now easier to configure Cockpit’s web server cockpit-ws to run behind a TLS termination proxy. If the proxy runs on the same machine, then cockpit-ws can be run with the new --for-tls-proxy option, which will adjust the allowed Origins and Content-Security-Policy to https:// URLs. With this option, it’s no longer necessary to explicitly configure cockpit.conf.

Fedora 28 End of Life

Filed under
Red Hat

With the recent release of Fedora 30, Fedora 28 officially enters End Of Life (EOL) status effective May 28, 2019. This impacts any systems still on Fedora 28. If you’re not sure what that means to you, read more below.

At this point, packages in the Fedora 28 repositories no longer receive security, bugfix, or enhancement updates. Furthermore, the community adds no new packages to the Fedora 28 collection starting at End of Life. Essentially, the Fedora 28 release will not change again, meaning users no longer receive the normal benefits of this leading-edge operating system.

There’s an easy, free way to keep those benefits. If you’re still running an End of Life version such as Fedora 28, now is the perfect time to upgrade to Fedora 29 or to Fedora 30. Upgrading gives you access to all the community-provided software in Fedora.

Read more

Fedora: Flatpak, NeuroFedora and More

Filed under
Red Hat

When the future isn't clear, don't make a plan

Filed under
Red Hat
OSS

For the past two years at Red Hat Summit, I've argued that traditional planning is dead. The increasing speed of technological innovation, as well as the shift to more open styles of production and organization, are forcing everyone to rethink how we go about setting, executing on, and measuring performance against goals.

Those who've heard me talk about this have been sympathetic—but also skeptical. "I see your point," executives tell me, "but I still need to do something to prepare my organization for the future. And isn't that planning?"

Read more

Syndicate content

More in Tux Machines

Security: Linux 5.2 Dissection, New Patches, New ZDNet (CBS) FUD and Kali NetHunter App Store

  • Kees Cook: security things in Linux v5.2

    Gustavo A. R. Silva is nearly done with marking (and fixing) all the implicit fall-through cases in the kernel. Based on the pull request from Gustavo, it looks very much like v5.3 will see -Wimplicit-fallthrough added to the global build flags and then this class of bug should stay extinct in the kernel. That’s it for now; let me know if you think I should add anything here. We’re almost to -rc1 for v5.3!

  • Security updates for Wednesday

    Security updates have been issued by Debian (libreoffice), Red Hat (thunderbird), SUSE (ardana and crowbar, firefox, libgcrypt, and xrdp), and Ubuntu (nss, squid3, and wavpack).

  • Malicious Python libraries targeting Linux servers removed from PyPI [Ed: Python does not run only on Linux, but Microsoft-funded sites like ZDNet (CBS) look for ways to blame everything on "Linux", even malicious software that gets caught in the supply chain]
  • Malicious Python Libraries Discovered on PyPI, Offensive Security Launches the Kali NetHunter App Store, IBM Livestreaming a Panel with Original Apollo 11 Technicians Today, Azul Systems Announces OpenJSSE and Krita 4.2.3 Released

    Offensive Security, the creators of open-source Kali Linux, has launched the Kali NetHunter App Store, "a new one stop shop for security relevant Android applications. Designed as an alternative to the Google Play store for Android devices, the NetHunter store is an installable catalogue of Android apps for pentesting and forensics". The press release also notes that the NetHunter store is a slightly modified version of F-Droid: "While F-Droid installs its clients with telemetry disabled and asks for consent before submitting crash reports, the NetHunter store goes a step further by removing the entire code to ensure that privacy cannot be accidentally compromised". See the Kali.org blog post for more details.

Ubuntu/Fedora GNOME Feud and GNOME's Sriram Ramkrishna

  • Fedora, GNOME Software, and snap

    A question about the future of package distribution is at the heart of a disagreement about the snap plugin for the GNOME Software application in Fedora. In a Fedora devel mailing list thread, Richard Hughes raised multiple issues about the plugin and the direction that he sees Canonical taking with snaps for Ubuntu. He plans to remove support for the plugin for GNOME Software in Fedora 31. There are currently two major players for cross-distribution application bundles these days: snaps, which were developed by Canonical for Ubuntu and the Snap Store, and Flatpak, which was developed by Alexander Larsson of Red Hat as part of freedesktop.org. Both systems are available for multiple Linux distributions. They are meant to give an "app-like" experience, where users simply install an application, which comes with any dependencies it has that are not provided by the snap or Flatpak runtime. The GNOME Software application has a snap plugin that, when enabled, supports the distribution, installation, and management of snaps. The Fedora project currently provides the snap plugin as a package in Fedora 30, though it is not installed by default. Hughes is the Fedora maintainer for the plugin; he announced his intention to disable the plugin since, he says, he was told that Canonical was not going to be installing GNOME Software in the next Ubuntu Long Term Support (LTS) release.

  • Molly de Blanc: Meet Sriram Ramkrishna

    Sriram Ramkrishna, frequently known as Sri, is perhaps GNOME’s oldest contributor. He’s been around the community for almost as long as it’s been around! [...] But more than that, GNOME was a project that if you think about it was audacious in its purpose. Building a desktop in 1997 around an operating system that was primitive in terms of user experience, tooling, and experience. I wanted to be part of that.

Mozilla: Android, VR and Rust

  • Recent fixes to reduce backlog on Android phones

    Last week it seemed that all our limited resource machines were perpetually backlogged. I wrote yesterday to provide insight into what we run and some of our limitations. This post will be discussing the Android phones backlog last week specifically. The Android phones are hosted at Bitbar and we split them into pools (battery testing, unit testing, perf testing) with perf testing being the majority of the devices.

  • Q&A: Igniting imaginations and putting VR in the hands of students with Kai Frazier

    When you were in school, you may have taken a trip to a museum or a local park, but you probably never got to see an active volcano or watch great whites hunt. As Virtual Reality grows, this could be the way your kids will learn — using headsets the way we use computers. When you were in school, you may have gone on a trip to the museum, but you probably never stood next to an erupting volcano, watching molten lava pouring down its sides. As Virtual Reality (VR) grows, learning by going into the educational experience could be the way children will learn — using VR headsets the way we use computers. This kind of technology holds huge potential in shaping young minds, but like with most technology, not all public schools get the same access. For those who come from underserved communities, the high costs to technology could widen an already existing gap in learning, and future incomes.

  • This Week in Rust 295 [Ed: Just delete GitHub , Mozila, And why you're at it, stop using proprietary software and imposing it on Rust contributors.]

    This Week in Rust is openly developed on GitHub.

  • How to speed up the Rust compiler in 2019

    libsyntax has three tables in a global data structure, called Globals, storing information about spans (code locations), symbols, and hygiene data (which relates to macro expansion). Accessing these tables is moderately expensive, so I found various ways to improve things.

Python Programming Leftovers

  • Generate a List of Random Integers in Python

    This tutorial explains several ways to generate random numbers list in Python. Here, we’ll mainly use three Python random number generation functions. These are random.randint(), random.randrange(), and random.sample(). You can find full details of these methods here: Generate random numbers in Python. All these functions are part of the Random module. It employs a fast pseudorandom number generator which uses the Mersenne Twister algorithm. However today, we’ll focus on producing a list of non-repeating integers only. Go through the below bullets to continue.

  • Coverage.py 5.0a6: context reporting

    I’ve released another alpha of coverage.py 5.0: coverage.py 5.0a6. There are some design decisions ahead that I could use feedback on. [...] I know this is a lot, and the 5.0 alpha series has been going on for a while. The features are shaping up to be powerful and useful. All of your feedback has been very helpful, keep it coming.

  • Gradient Boosting Classifiers in Python with Scikit-Learn

    Gradient boosting classifiers are a group of machine learning algorithms that combine many weak learning models together to create a strong predictive model. Decision trees are usually used when doing gradient boosting. Gradient boosting models are becoming popular because of their effectiveness at classifying complex datasets, and have recently been used to win many Kaggle data science competitions. The Python machine learning library, Scikit-Learn, supports different implementations of gradient boosting classifiers, including XGBoost.

  • What are *args and **kwargs and How to use them
  • Create a Flask Application With Google Login

    You’ve probably seen the option for Google Login on various websites. Some sites also have more options like Facebook Login or GitHub Login. All these options allow users to utilize existing accounts to use a new service. In this article, you’ll work through the creation of a Flask web application. Your application will allow a user to log in using their Google identity instead of creating a new account. There are tons of benefits with this method of user management. It’s going to be safer and simpler than managing the traditional username and password combinations. This article will be more straightforward if you already understand the basics of Python. It would also help to know a bit about web frameworks and HTTP requests, but that’s not strictly necessary.