Today, I’m excited to share some big news with you—Fedora Workstation will be available on Lenovo ThinkPad laptops! Yes, I know, many of us already run a Fedora operating system on a Lenovo system, but this is different. You’ll soon be able to get Fedora pre-installed by selecting it as you customize your purchase. This is a pilot of Lenovo’s Linux Community Series – Fedora Edition, beginning with ThinkPad P1 Gen2, ThinkPad P53, and ThinkPad X1 Gen8 laptops, possibly expanding to other models in the future.
The Lenovo team has been working with folks at Red Hat who work on Fedora desktop technologies to make sure that the upcoming Fedora 32 Workstation is ready to go on their laptops. The best part about this is that we’re not bending our rules for them. Lenovo is following our existing trademark guidelines and respects our open source principles. That’s right—these laptops ship with software exclusively from the official Fedora repos! When they ship, you’ll see Fedora 32 Workstation. (Models which can benefit from the NVIDIA binary driver can install it in the normal way after the fact, by opting in to proprietary software sources.)
Obviously, this is huge for us. Our installer aims to make the complicated process of installing Fedora to replace another operating system as easy as possible, but it’s still a barrier even for tech-literate people. A major-brand laptop with Fedora pre-installed will help bring Fedora to a wider audience. That and Lenovo’s commitment to fixing issues as part of the community means that everyone benefits from their Linux engineering work in the true spirit of open source collaboration.
As Mark Pearson, Sr. Linux Developer, from Lenovo said, “Lenovo is excited to become a part of the Fedora community. We want to ensure an optimal Linux experience on our products. We are committed to working with and learning from the open source community.” Mark Pearson will be the featured guest in May’s Fedora Council Video Meeting – get your questions ready.
I’ll have more details about this project as we get closer to the launch. In the meantime, I invite you to come to our Open Neighborhood virtual booth at Red Hat Summit on April 28-29. The entire event is free and open to all.
Editor’s comment: The format of this article is different from the usual article that Fedora Magazine has published: a Fedora origins story told from the point of view of a Fedora user. The author has chosen to tell a story, since to simply present the bare facts is akin to just reading the wiki page about it.
Hello World!
Hello, I am… no, I’m not going to give my real name. Let’s say I’m female, probably shorter and older than you. I used to go by the nick of Isadora, more on that later.
Here you have one of the old RH boxes
Now some context. Back in the late ’90s, internet became popular and PCs started to be a thing. However, most people didn’t have either because it was very expensive and often you could do better with the traditional methods. Yes, computers were very basic back then. I used to play with these pocket games that were fascinating at the time, but totally lame now. Monochrome screens with pixelated flat animations. Not going to dive there, just giving an idea how it was.
In the mid-90s a company named Red Hat emerged and slowly started to make a profit of its own by selling its own business-oriented distribution and software utilities. The name comes from one of its founders, Marc Ewing, who used to wear a red lacrosse in university so other students could spot him easily and ask him questions. Of course, as it was a business-oriented distribution, and I was busy with multiple other things, I didn’t pay much attention to it. It lacked the software I needed and since I wasn’t a customer, I was nobody to ask for additions. However, it was Linux and as such Open Source. People started to package stuff for RHL and put it in repositories. I was invited to join the community project, Fedora.us. I promptly declined, misunderstanding the name. It was the second time I got invited that I asked ‘what is with the “US” there (in the name)?` Another user explained it was ‘us’ as in ‘we’ not as in the ‘United States.’ They explained a bit about how the community worked and I decided to give it a go.
Then my studies got in the way, and I had to shelve it.
Login Screen in Fedora Core
Press Return
By the time I came back to Fedora.us it had changed its name to Fedora Project and was actively being worked on from within Red Hat. Now, I wasn’t there so my direct knowledge of how this happened is a bit foggy. Some say that Fedora existed separately and Red Hat added/invited them, some say that Fedora was completely RH’s idea, some say they existed independently and at some point met or joined. Choose the version you like, I’ll put some links down there so you can know more details and decide for yourself. As far as I’m concerned, they worked together.
Well, as usual someone dropped some CDs with ISOs for me. If I had an euro for every ISO I’ve been offered, or had tossed at my desk, for me to try it, I would be rich. As a matter of fact, I’m not rich but I do have a big rack full of old distros.
Anyways…
Now it’s the early 2000s and things have changed dramatically. Computers’ prices have dropped and internet speed is increasing, plus a set of new technologies make it cheaper and more reliable. Computers now can do so much more than just a decade ago, and they’re smaller too. Screens are bigger, with better colors and resolution. Laptops are starting to become popular though still expensive and less powerful than desktop PCs.
During this time, I tried both Fedora and Red Hat. Now, as has been said before, Red Hat focuses on businesses and companies. Their main concern is having exactly the software their customers need, with the features their customers need, delivered as rock solid stability and a reliable update & support cycle. A lot of customization, variety of options and many cool new features are not their main core. More software means more testing and development work and bigger chances of things failing. Yet the technology industry is constantly changing and innovating. Sticking too much to older versions or proven formulas can be fatal for a company.
So what to do? Well, they solved it with Fedora. Fedora Project would be the innovative, looking ahead test bed, and Red Hat Enterprise Linux was the more conservative, rock solid operating system for businesses. Yes, they changed the name from Red Hat Linux to Red Hat Enterprise Linux. Sounds better, doesn’t it?
Unsurprisingly, Fedora had a fame of being difficult, unstable and for “hackers only”. Whenever I said I was using Fedora, they would give me odd looks or say something like “I want something stable” or “I’m not into that” (meaning they didn’t fancy programming/hacking activities). Countless individuals suggested I might want to use one of the other, beginner-friendly distributions, without themselves even giving Fedora a try! Many would disregard Linux as a whole as an amateur thing, only valid for playing but not good for serious work and companies. To each their own, I suppose.
Note the F and the bubble already there
Yes, but why?
Those early versions were called Fedora Core and had a very uncertain release pattern. The six months cycle came much later. Fedora Core got its name because there were two repositories, Core and Extras. Core had the essentials, so to speak, and was maintained by Red Hat. Extras was, well, everything else. Any software that most users would want or need was included there, and it was maintained by a wide range of contributors.
From the beginning, one of the most powerful reasons for me to use it was the community and its core values. The Four Foundations of Fedora, Freedom, Features, First & Friends were lived and breathed and not just a catchy line on a website or a leaflet. Fedora Project strove (and still does) to deliver the newest features first, caring for freedom (of choice and software) and keeping a good open community, making friends as we contribute to the project.
I also liked the fact that Fedora, as its purpose was testing for Red Hat, delivered a lot of new software and technologies; it was like opening the window to see the future today.
The downside was its unreliable upgrade cycle. You could get a new version in a few months or next year… nobody knew, there was no agreed schedule.
Note how, despite being Fedora, RH’s logo and signature is omnipresent
What was in the box
Fedora Core kept this name up to the sixth version. From the start, it was meant to be a distribution you could use right after installing it, so it came with Gnome 2, KDE 3, OpenOffice and some browser I forgot, possibly Firefox.
I remember it being the first to introduce SELinux and SystemD by default, and to replace LILO with GRUB. I also remember the hardware requirements were something at the time, although they now sound laughable: Pentium II 400MHz, 256MB RAM (yes, you read it right) and 2GB of space in disk. It even had an option for terminal only! This would require only 64MB RAM and Pentium II 200MHz. Amazing, isn’t it?
It had codenames. Not publicly, but it had, and they were quite peculiar. Fedora Core 1 was code named «Yarrow» which is a medium size plant with yellow or white crown-like flowers. Core 2 was Tettnang which is a small town in Baden-Württemberg, Germany. Not sure about Core 3, I think it was Heidelberg, but maybe I’m mixing with later releases. Core 4 was Stentz, if I recall correctly (no idea what it means), Core 5 was a colour, I think Bordeaux, and Core 6 was Zod that I think it was a comic character but I could be wrong. If there was a method in their madness I have no idea. I thought the names amusing but didn’t give a second thought to it as they didn’t affect anything, not even the design of each release.
Ah… good ol` genetic helix
So what now?
Well, of course, Fedora Project has evolved from where we have stopped. But that’s for later articles or this one will be too long. For now, I leave you with an extract of an interview with Matthew Miller, current Project Leader and some links in case you want to know more.
Extracts to interview with Matthew Miller, Project Leader.
Matthew Miller tells about the beginnings in Eduard Lucena’s podcast (transcription here): “Fedora started about 15 years ago, really. It actually started as a thing called Fedora.us.” Back in those days, there was Red Hat Linux.” “Meanwhile, there was this thing called Fedora.us which was basically a project to make additional software available to users of Red Hat Linux. Find things that weren’t part of Red Hat Linux, and package them up, and make them available to everybody. That was started as a community project.”
“Red Hat (then) merged with this Fedora.us project to form Fedora Project that produces an upstream operating system that Red Hat Enterprise Linux is derived from but then moves on a slower pace.”
“We were then two parts, Fedora Core, which was basically inherited from the old Red Hat Linux and only Red Hat employees could do anything with and then Fedora Extras, where community could come together to add things on top of that Fedora Core. It took a little while to get off the ground but it was fairly successful”
“Around the time of Fedora Core 6, those were actually merged together into one big Fedora where all of the packages were all part of the same thing. There was no more distinction of Core and Extras, and everything was all together and, more importantly, all the community was all together.
They invited the community to take ownership of the whole thing and for Red Hat to become part of the community rather than separate. That was a huge success.”
The Fedora Project is pleased to announce the immediate availability of Fedora 32 Beta, the next step towards our planned Fedora 32 release at the end of April.
Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices like the Raspberry Pi 2 and 3:
New in Fedora 32 Workstation Beta is EarlyOOM enabled by default. EarlyOOM enables users to more quickly recover and regain control over their system in low-memory situations with heavy swap usage. Fedora 32 Workstation Beta also enables the fs.trim timer by default, which improves performance and wear leveling for solid state drives.
Fedora 32 Workstation Beta includes GNOME 3.36, the newest release of the GNOME desktop environment. It is full of performance enhancements and improvements. GNOME 3.36 adds a Do Not Disturb button in the notifications, improved setup for parental controls and virtualization, and tweaks to Settings. For a full list of GNOME 3.36 highlights, see the release notes.
Other updates
Fedora 32 Beta includes updated versions of many popular packages like Ruby, Python, and Perl. It also includes version 10 of the popular GNU Compiler Collection (GCC). We also have the customary updates to underlying infrastructure software, like the GNU C Library. For a full list, see the Change set on the Fedora Wiki.
Testing needed
Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in the #fedora-qa channel on IRC Freenode. As testing progresses, common issues are tracked on the Common F32 Bugs page.
A Beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the Beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora, but Linux and free software as a whole.
More information
For more detailed information about what’s new on Fedora 32 Beta release, you can consult the Fedora 32 Change set. It contains more technical information about the new packages and improvements shipped with this release.
COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.
This article presents a few new and interesting projects in COPR. If you’re new to using COPR, see the COPR User Documentation for how to get started.
Contrast
Contrast is a small app used for checking contrast between two colors and to determine if it meets the requirements specified in WCAG. The colors can be selected either using their RGB hex codes or with a color picker tool. In addition to showing the contrast ratio, Contrast displays a short text on a background in selected colors to demonstrate comparison.
Installation instructions
The repo currently provides contrast for Fedora 31 and Rawhide. To install Contrast, use these commands:
Pamixer is a command-line tool for adjusting and monitoring volume levels of sound devices using PulseAudio. You can display the current volume of a device and either set it directly or increase/decrease it, or (un)mute it. Pamixer can list all sources and sinks.
Installation instructions
The repo currently provides Pamixer for Fedora 31 and Rawhide. To install Pamixer, use these commands:
PhotoFlare is an image editor. It has a simple and well-arranged user interface, where most of the features are available in the toolbars. PhotoFlare provides features such as various color adjustments, image transformations, filters, brushes and automatic cropping, although it doesn’t support working with layers. Also, PhotoFlare can edit pictures in batches, applying the same filters and transformations on all pictures and storing the results in a specified directory.
Installation instructions
The repo currently provides PhotoFlare for Fedora 31. To install Photoflare, use these commands:
Tdiff is a command-line tool for comparing two file trees. In addition to showing that some files or directories exist in one tree only, tdiff shows differences in file sizes, types and contents, owner user and group ids, permissions, modification time and more.
Installation instructions
The repo currently provides tdiff for Fedora 29-31 and Rawhide, EPEL 6-8 and other distributions. To install tdiff, use these commands:
COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.
This article presents a few new and interesting projects in COPR. If you’re new to using COPR, see the COPR User Documentation for how to get started.
Nu
Nu, or Nushell, is a shell inspired by PowerShell and modern CLI tools. Using a structured data based approach, Nu makes it easy to work with commands that output data, piping through other commands. The results are then displayed in tables that can be sorted or filtered easily and may serve as inputs for further commands. Finally, Nu provides several builtin commands, multiple shells and support for plugins.
Installation instructions
The repo currently provides Nu for Fedora 30, 31 and Rawhide. To install Nu, use these commands:
NoteKit is a program for note-taking. It supports Markdown for formatting notes, and the ability to create hand-drawn notes using mouse. In NoteKit, notes are sorted and organized in a tree structure.
Installation instructions
The repo currently provides NoteKit for Fedora 29, 30, 31 and Rawhide. To install NoteKit, use these commands:
Crow Translate is a program for translating. It can translate text as well as speak both the input and result, and offers a command line interface as well. For translation, Crow Translate uses Google, Yandex or Bing translate API.
Installation instructions
The repo currently provides Crow Translate for Fedora 30, 31 and Rawhide, and for Epel 8. To install Crow Translate, use these commands:
dnsmeter is a command-line tool for testing performance of a nameserver and its infrastructure. For this, it sends DNS queries and counts the replies, measuring various statistics. Among other features, dnsmeter can use different load steps, use payload from PCAP files and spoof sender addresses.
Installation instructions
The repo currently provides dnsmeter for Fedora 29, 30, 31 and Rawhide, and EPEL 7. To install dnsmeter, use these commands:
The release of Fedora 31 drops the 32-bit i686 kernel, and as a result bootable images. While there may be users out there who still have hardware which will not work with the 64-bit x86_64 kernel, there are very few. However, this article gives you the whole story behind the change, and what 32-bit material you’ll still find in Fedora 31.
What is happening?
The i686 architecture essentially entered community support with the Fedora 27 release. Unfortunately, there are not enough members of the community willing to do the work to maintain the architecture. Don’t worry, though — Fedora is not dropping all 32-bit packages. Many i686 packages are still being built to ensure things like multilib, wine, and Steam will continue to work.
While the repositories are no longer being composed and mirrored out, there is a koji i686 repository which works with mock for building 32-bit packages, and in a pinch to install 32-bit versions which are not part of the x86_64 multilib repository. Of course, maintainers expect this will see limited use. Users who simply need to run a 32-bit application should be able to do so with multilib on a 64-bit system.
What to do if you’re running 32-bit
If you still run 32-bit i686 installations, you’ll continue to receive supported Fedora updates through the Fedora 30 lifecycle. This is until roughly May or June of 2020. At that point, you can either reinstall as 64-bit x86_64 if your hardware supports it, or replace your hardware with 64-bit capable hardware if possible.
There is a user in the community who has done a successful “upgrade” from 32-bit Fedora to 64-bit x86 Fedora. While this is not an intended or supported upgrade path, it should work. The Project hopes to have some documentation for users who have 64-bit capable hardware to explain the process before the Fedora 30 end of life.
If you have a 64-bit capable CPU running 32-bit Fedora due to low memory, try one of the alternate desktop spins. LXDE and others tend to do fairly well in memory constrained environments. For users running simple servers on old 32-bit hardware that was just lying around, consider one of the newer ARM boards. The power savings alone can more than pay for the new hardware in many instances. And if none of these are on option, CentOS 7 offers a 32-bit image with longer term support for the platform.
Security and you
While some users may be tempted to keep running an older Fedora release past end of life, this is highly discouraged. People constantly research software for security issues. Often times, they find these issues which have been around for years.
Once Fedora maintainers know about such issues, they typically patch for them, and make updates available to supported releases — but not to end of life releases. And of course, once these vulnerabilities are public, there will be people trying to exploit them. If you run an older release past end of life, your security exposure increases over time as a result, putting your system at ever-growing risk.
The Fedora Project is pleased to announce the immediate availability of Fedora 31 Beta, the next step towards our planned Fedora 31 release at the end of October.
Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments, as well as images for ARM devices like the Raspberry Pi 2 and 3:
The newest release of the GNOME desktop environment is full of performance enhancements and improvements. The beta ships with a prerelease, and the full 3.34 release will be available as an update. For a full list of GNOME 3.34 highlights, see the release notes.
Fedora IoT Edition
Fedora Editions address specific use-cases the Fedora Council has identified as significant in growing our userbase and community. We have Workstation, Server, and CoreOS — and now we’re adding Fedora IoT. This will be available from the main “Get Fedora” site when the final release of F31 is ready, but for now, get it from iot.fedoraproject.org.
Fedora CoreOS remains in a preview state, with a planned generally-available release planned for early next year. CoreOS is a rolling release which rebases periodically to a new underlying Fedora OS version. Right now, that version is Fedora 30, but soon there will be a “next” stream which will track Fedora 31 until that’s ready to become the “stable” stream.
Other updates
Fedora 31 Beta includes updated versions of many popular packages like Node.js, the Go language, Python, and Perl. We also have the customary updates to underlying infrastructure software, like the GNU C Library and the RPM package manager. For a full list, see the Change set on the Fedora Wiki.
Farewell to bootable i686
We’re no longer producing full media or repositories for 32-bit Intel-architecture systems. We recognize that this means newer Fedora releases will no longer work on some older hardware, but the fact is there just hasn’t been enough contributor interest in maintaining i686, and we can provide greater benefit for the majority of our users by focusing on modern architectures. (The majority of Fedora systems have been 64-bit x86_64 since 2013, and at this point that’s the vast majority.)
Please note that we’re still making userspace packages for compatibility when running 32-bit software on a 64-bit systems — we don’t see the need for that going away anytime soon.
Testing needed
Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in #fedora-qa on Freenode. As testing progresses, common issues are tracked on the Common F31 Bugs page.
A Beta release is code-complete and bears a very strong resemblance to the final release. If you take the time to download and try out the Beta, you can check and make sure the things that are important to you are working. Every bug you find and report doesn’t just help you, it improves the experience of millions of Fedora users worldwide! Together, we can make Fedora rock-solid. We have a culture of coordinating new features and pushing fixes upstream as much as we can. Your feedback improves not only Fedora, but Linux and free software as a whole.
More information
For more detailed information about what’s new on Fedora 31 Beta release, you can consult the Fedora 31 Change set. It contains more technical information about the new packages and improvements shipped with this release.
Today the GNOME project announced the release of GNOME 3.34. This latest release of GNOME will be the default desktop environment in Fedora 31 Workstation. The Beta release of Fedora 31 is currently expected in the next week or two, with the Final release scheduled for late October.
GNOME 3.34 includes a number of new features and improvements. Congratulations and thank you to the whole GNOME community for the work that went into this release! Read on for more details.
GNOME 3.34 desktop environment at work
Notable features
The desktop itself has been refreshed with a pleasing new background. You can also compare your background images to see what they’ll look like on the desktop.
There’s a new custom application folder feature in the GNOME Shell Overview. It lets you combine applications in a group to make it easier to find the apps you use.
You already know that Boxes lets you easily download an OS and create virtual machines for testing, development, or even daily use. Now you can find sources for your virtual machines more easily, as well as boot from CD or DVD (ISO) images more easily. There is also an Express Install feature available that now supports Windows versions.
Now that you can save states when using GNOME Games, gaming is more fun. You can snapshot your progress without getting in the way of the fun. You can even move snapshots to other devices running GNOME.
The Fedora 31 Workstation Beta release is right around the corner. Fedora 31 will feature GNOME 3.34 and you’ll be able to experience it in the Beta release.
bpftrace is a new eBPF-based tracing tool that was first included in Fedora 28. It was developed by Brendan Gregg, Alastair Robertson and Matheus Marchini with the help of a loosely-knit team of hackers across the Net. A tracing tool lets you analyze what a system is doing behind the curtain. It tells you which functions in code are being called, with which arguments, how many times, and so on.
This article covers some basics about bpftrace, and how it works. Read on for more information and some useful examples.
eBPF (extended Berkeley Packet Filter)
eBPF is a tiny virtual machine, or a virtual CPU to be more precise, in the Linux Kernel. The eBPF can load and run small programs in a safe and controlled way in kernel space. This makes it safer to use, even in production systems. This virtual machine has its own instruction set architecture (ISA) resembling a subset of modern processor architectures. The ISA makes it easy to translate those programs to the real hardware. The kernel performs just-in-time translation to native code for main architectures to improve the performance.
The eBPF virtual machine allows the kernel to be extended programmatically. Nowadays several kernel subsystems take advantage of this new powerful Linux Kernel capability. Examples include networking, seccomp, tracing, and more. The main idea is to attach eBPF programs into specific code points, and thereby extend the original kernel behavior.
eBPF machine language is very powerful. But writing code directly in it is extremely painful, because it’s a low level language. This is where bpftrace comes in. It provides a high-level language to write eBPF tracing scripts. The tool then translates these scripts to eBPF with the help of clang/LLVM libraries, and then attached to the specified code points.
Installation and quick start
To install bpftrace, run the following command in a terminal using sudo:
Note that you must run bpftrace as root due to the privileges required. Use the -e option to specify a program, and to construct the so-called “one-liners.” This example only prints hello world, and then waits for you to press Ctrl+C.
BEGIN is a special probe name that fires only once at the beginning of execution. Every action inside the curly braces { } fires whenever the probe is hit — in this case, it’s just a printf.
This example prints the parent process name (comm) and the name of every new process being created in the system. t:syscalls:sys_enter_execve is a kernel tracepoint. It’s a shorthand for tracepoint:syscalls:sys_enter_execve, but both forms can be used. The next section shows you how to list all available tracepoints.
comm is a bpftrace builtin that represents the process name. filename is a field of the t:syscalls:sys_enter_execve tracepoint. You can access these fields through the args builtin.
All available fields of the tracepoint can be listed with this command:
bpftrace -lv "t:syscalls:sys_enter_execve"
Example usage
Listing probes
A central concept for bpftrace are probe points. Probe points are instrumentation points in code (kernel or userspace) where eBPF programs can be attached. They fit into the following categories:
kprobe – kernel function start
kretprobe – kernel function return
uprobe – user-level function start
uretprobe – user-level function return
tracepoint – kernel static tracepoints
usdt – user-level static tracepoints
profile – timed sampling
interval – timed output
software – kernel software events
hardware – processor-level events
All available kprobe/kretprobe, tracepoints, software and hardware probes can be listed with this command:
$ sudo bpftrace -l
The uprobe/uretprobe and usdt probes are userspace probes specific to a given executable. To use them, use the special syntax shown later in this article.
The profile and interval probes fire at fixed time intervals. Fixed time intervals are not covered in this article.
Counting system calls
Maps are special BPF data types that store counts, statistics, and histograms. You can use maps to summarize how many times each syscall is being called:
Some probe types allow wildcards to match multiple probes. You can also specify multiple attach points for an action block using a comma separated list. In this example, the action block attaches to all tracepoints whose name starts with t:syscalls:sys_enter_, which means all available syscalls.
The bpftrace builtin function count() counts the number of times this function is called. @[] represents a map (an associative array). The key of this map is probe, which is another bpftrace builtin that represents the full probe name.
Here, the same action block is attached to every syscall. Then, each time a syscall is called the map will be updated, and the entry is incremented in the map relative to this same syscall. When the program terminates, it automatically prints out all declared maps.
This example counts the syscalls called globally, it’s also possible to filter for a specific process by PID using the bpftrace filter syntax:
bpftrace attaches the action block to the write syscall return probe (t:syscalls:sys_exit_write). Then, it uses a filter to discard the negative values, which are error codes (/args->ret > 0/).
The map key comm represents the process name that called the syscall. The sum() builtin function accumulates the number of bytes written for each map entry or process. args is a bpftrace builtin to access tracepoint’s arguments and return values. Finally, if successful, the write syscall returns the number of written bytes. args->ret provides access to the bytes.
Read size distribution by process (histogram):
bpftrace supports the creation of histograms. Let’s analyze one example that creates a histogram of the read size distribution by process:
Histograms are BPF maps, so they must always be attributed to a map (@). In this example, the map key is comm.
The example makes bpftrace generate one histogram for every process that calls the read syscall. To generate just one global histogram, attribute the hist() function just to ‘@’ (without any key).
bpftrace automatically prints out declared histograms when the program terminates. The value used as base for the histogram creation is the number of read bytes, found through args->ret.
Tracing userspace programs
You can also trace userspace programs with uprobes/uretprobes and USDT (User-level Statically Defined Tracing). The next example uses a uretprobe, which probes to the end of a user-level function. It gets the command lines issued in every bash running in the system:
To list all available uprobes/uretprobes of the bash executable, run this command:
$ sudo bpftrace -l "uprobe:/bin/bash"
uprobe instruments the beginning of a user-level function’s execution, and uretprobe instruments the end (its return). readline() is a function of /bin/bash, and it returns the typed command line. retval is the return value for the instrumented function, and can only be accessed on uretprobe.
When using uprobes, you can access arguments with arg0..argN. A str() call is necessary to turn the char * pointer to a string.
Shipped Scripts
There are many useful scripts shipped with bpftrace package. You can find them in the /usr/share/bpftrace/tools/ directory.
Among them, you can find:
killsnoop.bt – Trace signals issued by the kill() syscall.
tcpconnect.bt – Trace all TCP network connections.
pidpersec.bt – Count new procesess (via fork) per second.
opensnoop.bt – Trace open() syscalls.
vfsstat.bt – Count some VFS calls, with per-second summaries.
You can directly use the scripts. For example:
$ sudo /usr/share/bpftrace/tools/killsnoop.bt
You can also study these scripts as you create new tools.
COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.
Here’s a set of new and interesting projects in COPR.
Duc
Duc is a collection of tools for disk usage inspection and visualization. Duc uses an indexed database to store sizes of files on your system. Once the indexing is done, you can then quickly overview your disk usage either by its command-line interface or the GUI.
Installation instructions
The repo currently provides duc for EPEL 7, Fedora 29 and 30. To install duc, use these commands:
MuseScore is a software for working with music notation. With MuseScore, you can create sheet music either by using a mouse, virtual keyboard or a MIDI controller. MuseScore can then play the created music or export it as a PDF, MIDI or MusicXML. Additionally, there’s an extensive database of sheet music created by Musescore users.
Installation instructions
The repo currently provides MuseScore for Fedora 29 and 30. To install MuseScore, use these commands:
Dynamic Wallpaper Editor is a tool for creating and editing a collection of wallpapers in GNOME that change in time. This can be done using XML files, however, Dynamic Wallpaper Editor makes this easy with its graphical interface, where you can simply add pictures, arrange them and set the duration of each picture and transitions between them.
Installation instructions
The repo currently provides dynamic-wallpaper-editor for Fedora 30 and Rawhide. To install dynamic-wallpaper-editor, use these commands:
Manuskript is a tool for writers and is aimed to make creating large writing projects easier. It serves as an editor for writing the text itself, as well as a tool for organizing notes about the story itself, characters of the story and individual plots.
Installation instructions
The repo currently provides Manuskript for Fedora 29, 30 and Rawhide. To install Manuskript, use these commands:
