Tag: Fedora Project community

The kernel team is working on final integration for kernel 5.4. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test week from Monday, December 09, 2019 through Monday, December 16, 2019. Refer to the wiki page for links to the test images you’ll need to participate. Read below for details.

How does a test week work?

A test day/week is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the kernel test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results.

Happy testing, and we hope to see you in the Test Week.

There are over 40 desktops in Fedora. Each desktop has it’s own strengths and weaknesses. Usually picking a desktop is a very personal preference based on features, looks, and other qualities. Sometimes, what you pick for a desktop is limited by hardware constraints.

This article is to help people compare Fedora desktops based on the desktop baseline memory. To narrow the scope, we are only looking at the desktops that have an official Fedora Live image.

Installation and Setup

Each of the desktops was installed on it’s own KVM virtual machine. Each virtual machine had 1 CPU, 4GB of memory, 15 GB virtio solid state disk, and everything else that comes standard on RHEL 8.0 kvm.

The images for installation were the standard Fedora 31 Live images. For GNOME, that image was the Fedora Workstation. For the other desktops, the corresponding Spin was used. Sugar On A Stick (SOAS) was not tested because it does not install easily onto a local drive.

The virtual machine booted into the Live CD. “Install to Hard Disk” was selected. During the install, only the defaults were used. A root user, and a regular users were created. After installation and reboot, the Live image was verified to not be in the virtual CDROM.

The settings for each desktop was not touched. They each ran whatever settings came default from the Live CD installation. Each desktop was logged into via the regular user. A terminal was opened. Using sudo each machine ran “dnf -y update”. After update, in that sudo terminal, each machine ran “/sbin/shutdown -h now” to shut down.

Testing

Each machine was started up. The desktop was logged into via the regular user. Three of the desktop terminals were opened. xterm was never used, it was always the terminal for that desktop, such as konsole.

In one terminal, top was started and M pressed, showing the processes sorted by memory. In another terminal, a simple while loop showed “free -m” every 30 seconds. The third terminal was idle.

I then waited 5 minutes. This allowed any startup services to finish. I recorded the final free result, as well as the final top three memory consumers from top.

Results

• Cinnamon
  • 624 MB Memory used
  • cinnamon 4.8% / Xorg 2.2% / dnfdragora 1.8%
• GNOME
  • 612 MB Memory used
  • gnome-shell 6.9% / gnome-software 1.8% / ibus-x11 1.5%
• KDE
  • 733 MB Memory used
  • plasmashell 6.2% / kwin_x11 3.6% / akonadi_mailfil 2.9%
• LXDE
  • 318 MB Memory used
  • Xorg 1.9% / nm-applet 1.8% / dnfdragora 1.8%
• LXQt
  • 391 MB Memory used
  • lxqt-panel 2.2% / pcmanfm-qt 2.1% / Xorg 2.1%
• MATE
  • 465 MB Memory used
  • Xorg 2.5% / dnfdragora 1.8% / caja 1.5%
• XFCE
  • 448 MB Memory used
  • Xorg 2.3% / xfwm4 2.0% / dnfdragora 1.8%

Conclusion

I will let the numbers speak for themselves.

Remember that these numbers are from a default Live install. If you remove, or add services and features, your memory usage will change. But this is a good baseline to look at if you are determining your desktop based on memory consumption.

Everything in a PC, laptop, or server is represented as binary digits (a.k.a. bits, where each bit can only be 1 or 0). There are no characters like we use for writing or numbers as we write them anywhere in a computer’s memory or secondary storage such as disk drives. For general purposes, the unit of measure for groups of binary bits is the byte — eight bits. Bytes are an agreed-upon measure that helped standardize computer memory, storage, and how computers handled data.

There are various terms in use to specify the capacity of a disk drive (either magnetic or electronic). The same measures are applied to a computers random access memory (RAM) and other memory devices that inhabit your computer. So now let’s see how the numbers are made up.

Suffixes are used with the number that specifies the capacity of the device. The suffixes designate a multiplier that is to be applied to the number that preceded the suffix. Commonly used suffixes are:

• Kilo = 10³ = 1,000 (one thousand)
• Mega = 10⁶ = 1,000,000 (one million)
• Giga = 10⁹ = 1000,000,000 (one billion)
• Tera = 10¹² = 1,000,000,000,000 (one trillion)

As an example 500 GB (gigabytes) is 500,000,000,000 bytes.

The units that memory and storage are specified in  advertisements, on boxes in the store, and so on are in the decimal system as shown above. However since computers only use binary bits, the actual capacity of these devices is different than the advertised capacity.

You saw that the decimal numbers above were shown with their equivalent powers of ten. In the binary system numbers can be represented as powers of two. The table below shows how bits are used to represent powers of two in an 8 bit Byte. At the bottom of the table there is an example of how the decimal number 109 can be represented as a binary number that can be held in a single byte of 8 bits (01101101).

The example bit values comprise the binary number 01101101. To get the equivalent decimal value just add the decimal values from the table where the bit is set to 1. That is 64 + 32 + 8 + 4 + 1 = 109.

By the time you get out to 2³⁰ you have decimal 1,073,741,824 with just 31 bits (don’t forget the 2⁰) You’ve got a large enough number to start specifying memory and storage sizes.

Now comes what you have been waiting for. The table below lists common designations as they are used for labeling decimal and binary values.

Note that all of the quantities of bytes in the table above are expressed as decimal numbers. They are not shown as binary numbers because those numbers would be more than 30 characters long.

Most users and programmers need not be concerned with the small differences between the binary and decimal storage size numbers. If you’re developing software or hardware that deals with data at the binary level you may need the binary numbers.

As for what this means to your PC: Your PC will make use of the full capacity of your storage and memory devices. If you want to see the capacity of your disk drives, thumb drives, etc, the Disks utility in Fedora will show you the actual capacity of the storage device in number of bytes as a decimal number.

There are also command line tools that can provide you with more flexibility in seeing how your storage bytes are being used. Two such command line tools are du (for files and directories) and df (for file systems). You can read about these by typing man du or man df at the command line in a terminal window.

Photo by Franck V. on Unsplash.