
For years, Ubuntu was the undisputed king of the Linux desktop for those who wanted a stable, reliable and easy to use desktop environment. It was the "default" choice for many, including myself.

From the early days of 16.04, it was the reliable and worked amazingly well as your "daily driver", but the landscape of Linux has shifted. After 10 years I've made the move to Fedora, specifically Fedora KDE, and the experience has been nothing short of liberating.

In this article I'll try to explain the nuances of the move, and why Fedora has become my new daily driver.

### The Elephant in the Room: The Rise of Snaps

For me, the defining moment that broke the camel's back and made me want to leave Ubuntu was the forceful push of Snaps.

While the concept of universally package-managed applications is a worthy goal, the implementation and execution of Snaps have been increasingly problematic for users like me.

#### The "Firefox Incident" as a Turning Point:

The most common example was the shift of Firefox, a core component of any desktop Linux experience, to a Snap-only distribution model in recent Ubuntu versions. This wasn't just a change in package management; it felt like an imposition.

Forced Compliance: When I tried to install Firefox via the standard apt command on Ubuntu 22.04, even with common workarounds found on Reddit, it's still forced to install it as a Snap package.

The Problem with a Closed Ecosystem: This move highlighted a fundamental flaw in the Snap system. While Fedora's Flatpaks and Arch's AUR promote decentralized repositories and user control, Snaps are heavily controlled by Ubuntu's Snap Store. The proprietary nature of the Snap backend, the centralized control over the Snap Store, and the lack of a true, community-driven alternative made it feel less like an open-source solution and more like a walled garden.

Slow Start Times: The single biggest complaint about Snaps, and one that I personally experienced on some applications, is the slow startup time. My Firefox browser would hang for an agonizing few seconds before opening, a noticeable degradation in performance compared to the native .deb package. For any user who values responsiveness, this was a major deal-breaker.

Beyond Firefox: The Ubiquity of Snaps

It wasn't just Firefox. More and more software was being "snapped," often without a clear reason or a direct benefit to the user. This aggressive promotion of Snaps, coupled with the slow development and adoption of Flatpak in Ubuntu, created a sense of a forced ecosystem. Users were being nudged, or outright pushed, into a specific path, often sacrificing choice and performance along the way.

### The Contrasting World of Flatpaks and Fedora:

Fedora, by contrast, takes a different approach. While they are a major driver of the Flatpak format, they don't force it upon users. You can still install software via the traditional dnf package manager. Furthermore, the Flatpak ecosystem, with Flathub as a central repository, feels much more collaborative and community-driven. This distinction is crucial, as it speaks to the philosophies of the two projects.

### The KDE Plasma Renaissance: Customization without Chaos

The second major reason for my migration was the sheer brilliance of the KDE Plasma desktop environment. For a long time, I was content with GNOME, the default on Ubuntu. Its simplicity and focus on getting things done were appealing. However, as I grew more comfortable with Linux and my needs evolved, I craved more control and a sense of ownership over my desktop.

For example, for my work, I use Mac for years now, and switching from Mac to any other Linux distro might feel in-affective, but with KDE Plasma, I can still use my Mac-like workflow (Only for the things I like about Mac)and still have the power of Linux.
This results in a more efficient and productive workflow and usage of my desktop.

### GNOME's Limitations

GNOME, while elegant, often feels restrictive. The "GNOME way" of doing things can sometimes feel like a straightjacket, where customization is limited and often requires extensions that can be unstable and poorly maintained. The removal of features, like the desktop icons and the tray icon, felt like a step backward in terms of usability for me.

### Enter KDE Plasma

My first experience with KDE Plasma was a revelation. It wasn't just another desktop environment; it was a suite of tools and a framework for building your ideal workspace. The beauty of Plasma is that it can be as simple or as complex as you want it to be, and you can easily customize it to your needs. On some aspect, I even built a custom plugin for KDE Plasma Search to improve my workflow.

#### Ultimate Customization:

Every aspect of Plasma is customizable. From the themes, icons, and fonts to the window managers, panels, and widgets, you are in complete control. Want a traditional Windows-like taskbar? You can do it. Prefer a Mac-like dock? No problem. Crave a minimal, tiling-inspired setup? Plasma has you covered.

#### The Power of Widgets:

Plasma's widget system is incredibly powerful. You can add widgets for everything from system monitoring and media controls to weather and calendar. This ability to tailor your desktop to your exact needs is unparalleled.

#### The Elegant Side of Plasma:

Modern Plasma is a thing of beauty. The design is clean, polished, and contemporary. The default Breeze theme is fantastic, but you can easily change it with a single click.

What makes the Fedora KDE spin so compelling is the polish and care that goes into it. This isn't just a stock KDE installation slapped on top of Fedora; it's a well-integrated, cohesive experience. The default configurations are thoughtful, and the KDE team's focus on stability and performance shines through.

#### Performance and Stability: Fedora's Secret Weapon

One of the most immediate and pleasant surprises after moving to Fedora was the significant improvement in performance. Fedora feels faster, and more responsive than Ubuntu, even on older hardware.

Fedora's secret lies in its philosophy of using the latest upstream software and its leaner default installation.

Bleeding-Edge but Stable: Fedora is known for using newer kernel versions and more recent versions of software packages. This gives you access to the latest performance improvements and features. However, unlike rolling release distributions like Arch, Fedora's release schedule is biannual, which provides a level of stability and predictability that I appreciate.

dnf vs. apt: While both are excellent package managers, I've found dnf to be generally faster and more efficient than apt, especially when dealing with large updates. The use of delta RPMs also helps to speed up the process.

Fedora's "First Principles" Approach: Fedora is developed by Red Hat, a company with a long history of investing in the Linux ecosystem. This means that Fedora benefits from Red Hat's expertise in core Linux technologies like the kernel, systemd, and GNOME. This focus on "upstream first" development means that Fedora often gets improvements and new features earlier than other distributions.

Fedora's "Upstream First" philosophy is another major plus for me. This means that Fedora developers contribute their work directly to the upstream projects (like the Linux kernel, GNOME, KDE, etc.) rather than maintaining a separate fork of the software. This approach benefits the entire Linux ecosystem and ensures that the improvements are available to everyone.

---

To sum up, my migration to Fedora has been a journey of discovery and a reclaiming of my freedom as a Linux user. The push towards Snaps and the rigidity of the default desktop environment in Ubuntu became points of frustration, while Fedora's embrace of Flatpaks, the power and flexibility of KDE Plasma, and the distribution's focus on performance and innovation have made it a superior choice for my needs.

Fedora KDE feels like the future of the Linux desktop. It's a system that respects user choice, prioritizes performance and stability, and provides a level of polish and integration that is truly impressive. Whether you're a seasoned Linux pro or just starting your journey, I highly encourage you to give Fedora a try. You might just find your new desktop home.

![my-fedora-workstation](/images/fedoraworkstation.jpeg)


After years of using Ubuntu GNOME, I have decided to switch to Fedora KDE Plasma. A Migration to Freedom and Modernity.

Goodbye Ubuntu, Hello Fedora!


I'll start with a disclaimer - I'm far from a Linux expert. But Linux fascinates me, and i'm using a Linux based OS on a daily basis. That's why i'm not writing this blog post from an expert point of view, but rather from a curious one.

I first encountered the Nice term in Linux in my previous work place where we worked on Embedded devices running on ARM architecture with Buildroot as a distribution. We had a bug where one of the processes failed to load on time and we eventually fixed it by tweaking its niceness value (that's in a very high level, but you get the idea).

To understand what is niceness, we need to understand what is process priority and the Linux scheduler first.

Every operating system has a scheduler. The job of the scheduler is to allocate processor time to the various processes that are running in parallel. The scheduler must make decisions about which process to run next and for how long, especially when there are multiple processes requesting CPU time at the same time.

This is where priorities come into play. In Linux, every process is assigned a priority number. The lower this number, the higher the priority. The scheduler uses these numbers to decide which process to run next.

So How is nice related to priority?

Niceness is an indirect representation of priority. Instead of dealing with priorities directly, Linux uses the concept of niceness to allow users to influence the scheduler's decisions in a more user-friendly manner.

Niceness values range from -20 (highest priority) to 19 (lowest priority).
The actual priority value (often referred to as the "nice value") ranges from 1 (lowest priority) to 40 (highest priority).
When a process has a niceness value of 0, its actual priority is 20. A niceness value of -20 would adjust the priority to 0, while a niceness value of 19 would adjust it to 39.

A process with a high niceness value (close to 19) is "nicer" to other processes, implying it's less demanding of CPU time. Conversely, a process with a low niceness value (close to -20) is less "nice," indicating it's more demanding.

![niceness-scale](/images/niceness-scale.png)

For example, let’s say with run a command like `ls`, in most cases it’ll get the 0 niceness priority (default) as all other process unless it was defined differently.
You could, for the sake of the example, run `nice ls` and it’ll result with a niceness level of 10.

Now Let’s say you don’t want to use defaults, you could run `nice -n 15 ls` and it’ll will run with a niceness level of 15.

```bash
$ ps -l
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000 15044 15035  0  80   0 -  7453 wait   pts/29   00:00:00 bash
0 S  1000 15052 15044  0  60   15 -  3976 hrtime pts/29   00:00:00 ls
0 R  1000 15080 15044  0  80   0 -  4680 -      pts/29   00:00:00 ps
```

The whole point of niceness is to not allow normal users to set high priorities for their process. Lets say for example I want to run with high priority `nice -n -20 ls`, you’ll usually get an output like this:

```bash
nice: cannot set niceness: Permission denied
```

And the command will run with default niceness level (in most common cases).
This is because such operation is reserved for root users so normal users won't break their systems.

In practical terms, when we should use which niceness level? Here are some examples:

- A CPU-intensive task that you don't need to finish immediately (like a background data processing job) might be assigned a high niceness value to ensure it doesn't starve other processes of CPU time.
- A real-time task that needs to execute immediately (like audio or video processing) might be given a low niceness value to ensure it gets as much CPU time as it needs.

**Adjusting Niceness**

Suppose you're running a large compilation job, a backup, or any task that can potentially hog all the CPU like dealing with large files. You might want to run it with a high niceness value to prevent it from slowing down other processes.

```bash
nice -n 19 tar -czf backup.tar.gz /home/user
```

For tasks that require immediate processing, like audio/video encoding or real-time simulations, you might want to decrease their niceness value.

```bash
sudo nice -n -10 ffmpeg -i input.mp4 output.mp3
```

Let's say you started a process without modifying its niceness but later realized it's consuming too much CPU. You can dynamically adjust its niceness using `renice` and the process PID (which you can get with a simple `ps -l` command).

```bash
renice -n 15 -p [PID]
```

In the Linux ecosystem, understanding process scheduling, priority, and niceness is invaluable. By tweaking these parameters, software developers can optimize applications for performance, responsiveness, and resource usage. Whether it's ensuring smooth multimedia playback, prioritizing time-sensitive tasks, or preventing resource-intensive processes from overwhelming the system, the power of niceness offers developers a robust tool in system optimization.


Get to know the Linux process priority and Niceness.

Linux Process Prioritization with Niceness


I have decided to write what I know about this topic once I have encountered (and not for the first time) some machines that are running on non-LTS versions of Ubuntu at my current and past workplaces. It's true that it wasn't something production related, but it applies also for CI machines and/or dev machines (desktop or laptop).

But before we do a deep-dive into the topic, let's first understand what is LTS and what is non-LTS and what they mean.

### LTS vs Non-LTS

LTS stands for "Long-Term Support". It is a type of release in the software world and especially for operating systems, particularly in the open-source community, that promises extended support for a more extended period than standard releases. Usually this support involves driver updates, security updates, bug fixes and more.

For Ubuntu, an LTS version is released every two years and is supported for five years, whereas regular releases (Non-LTS) come out every six months and have a support lifespan of only nine months.

### Now that you have a grasp on what LTS stands for, let's explore the reasons to stick with LTS releases of Ubuntu:

**Stability Over Novelty:** One of the primary objectives of LTS releases is to provide users with a stable environment. This means that the software, tools, and packages included in an LTS release have undergone thorough testing to ensure they are free from major bugs and issues. Some users will argue that this is actually a disadvantage, as you have to wait for new updates (such as driver or HW support) much longer than rolling releases.
In my point of view, for the use cases of every day development usage and especially in CI machines, i'd rather go with slower update process to reduce risks. I would also argue that for production environments, this is a must of course.

**Extended Support:** With a five years of support, you don't have to worry about frequent upgrades. If you're running a mission-critical server, this extended support can be a blessing.

**Security Updates:** During the five years of support, the Ubuntu team continues to provide security patches and updates, ensuring that your system remains protected from the latest known threats.

**Predictable Environment:** Many businesses, educational institutions, and organizations prefer an OS environment that remains consistent over time. With LTS versions, there are fewer surprises, allowing IT departments and users to familiarize themselves deeply with the system.

**Reduced Overhead for System Administrators:** Frequent system upgrades can be a drain on resources, especially in large-scale deployments. With LTS versions, system administrators have more time in between major upgrades, reducing the administrative overhead.

**Software Compatibility:** Over the five years of an LTS release's lifespan, developers get to know the ins and outs of that specific release. This means they can fine-tune their applications for compatibility and performance, ensuring users have the best experience possible.

**Hardware Certifications:** Manufacturers often target LTS releases when certifying their hardware for Ubuntu, ensuring optimal compatibility and performance.

**Ideal for Servers and Enterprise Use:** Uptime, stability, and predictability are often paramount for servers and enterprise environments. Given the longevity and stability of LTS releases, they are a natural fit for these use cases.

**Official Support from other SW**: Usually, other important vendors (let's take Steam as an example) announcing that they are supporting LTS release. It doesn't mean things won't work on non-LTS, but it means that they are not testing it on non-LTS and they are not supporting it officially.

**Better Product:** I know this one sounds a little bit weird, but most LTS releases are much better than non-LTS releases (and i'm saying this from experience). However, there are some exceptions to this rule (Looking at you Ubuntu Server 18.04), but in general, LTS releases are much more stable and reliable.

### Not convinced? Let's take a look at the other side of the coin and see why you might want to use non-LTS versions of Ubuntu:

**Shorter Support Lifecycle:** Non-LTS versions receive support for only nine months. This means that if you're using a non-LTS version, you'll need to upgrade your system at least once a year to keep it supported. Failure to do so could leave your system vulnerable to unpatched security issues.

**Increased Maintenance:** Frequent upgrades can be time-consuming, especially if you have customized your system or use software not included in the standard repositories. Each upgrade poses a potential risk of breaking configurations or compatibility with third-party software.

**Stability Concerns:** Non-LTS releases might incorporate newer and less-tested software, which, although feature-rich, might not be as stable or reliable as those in LTS releases. This could lead to unexpected system behavior, crashes, or incompatibilities.

**Hardware Compatibility:** If you're using older hardware, there's a chance that non-LTS versions might not support it as well. LTS releases, being more focused on stability, often ensure broader hardware compatibility.

**No "secure" method to upgrade to LTS release from Non-LTS:** Usually, there is no suggested solution to this. If you're using Non-LTS version of Ubuntu, you'll have to reinstall the OS to get to the LTS version. This is not a big deal for desktops or laptops, but for servers, this is a big no-no.

![ubuntu-lts-vs-non-lts-releases-update](https://res.cloudinary.com/canonical/image/fetch/f_auto,q_auto,fl_sanitize,c_fill,w_720/https://ubuntu.com/wp-content/uploads/c26b/Screenshot-from-2021-09-21-16-45-52.png)

Choosing between LTS and non-LTS versions depends on individual needs and use cases. While non-LTS releases provide early access to the latest features and tools, they come with their set of challenges that in most cases won't fit any production environment or what the Linux community refers as your "daily driver" for desktops users.

For those who prioritize stability, longevity, and reduced maintenance, LTS releases remain the top recommendation. However, for enthusiasts and those wanting to stay on the cutting edge, non-LTS versions might be appealing, provided they are prepared for the associated potential issues. If that's you, I would recommend using other Linux distributions such as Arch.


Using only LTS versions of Ubuntu - The benefits explained.

Why You Should Only Use LTS Version of Ubuntu


Package management lies at the heart of Ubuntu's software ecosystem and linux distros in general, empowering users to install, update, and remove software effortlessly. With various package management systems available, such as APT, Snap, and Flatpak, it's essential to have a solid understanding of how they work and how to leverage them effectively.

Ubuntu incorporates multiple package management systems to cater to different software distribution needs. Up until Ubuntu 22, the default package management system was APT, which is still widely used today. In recent years, Snap and Flatpak have gained popularity, offering cross-distribution compatibility and sandboxed applications. According to [Ubuntu's website](https://ubuntu.com/blog/what-is-snap), "Snaps are containerized software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification."

The direction by Canonical is obvious, switch to a Snap based system. However, the community is not so onboard on this move. Let's understand the differences.

**APT Package Management**

- Most extensive and distributed software repository with a wide range of packages.

- It has efficient dependency management, automatically resolving and installing required dependencies (sometimes..).

- We can say its defiantly the most mature and well-established package management system there is in the Linux distros world.

- It's also by far the fastest package management system there is.

But it does also comes with some builtin disadvantages, such as:

- Limited sandboxing capabilities for applications.

- Dependency conflicts can occur in complex software environments.

- Repository updates may not always include the latest software versions.

![apt](/images/apt-install.png)

**Canonical's case - Snap Packages:**

- Snap is considered as a cross-distribution compatibility, allowing software to run on different Linux distributions.

- It's Easy installation and removal of software, with automatic updates.

- It includes what Canonical's considering as their top ability - Application sandboxing, enhancing security and isolation.

- It bundles dependencies, reducing conflicts and compatibility issues.

- And it'll have wide availability of software in the Snap Store.

But, just like other package managers - it has its disadvantages, most of them are claimed by the Linux users community:

- Relatively larger package sizes, resulting in increased download and storage requirements.

- Can be slower to start compared to traditional packages (Firefox browser for example).

- Limited access to system resources, potentially impacting performance in resource-intensive applications.

![snap](/images/snap-package-manager.webp)

**Flatpak:**

- It's a cross-distribution compatibility, similar to Snap packages.
- Application sandboxing, ensuring security and isolation.
- Ability to bundle dependencies, reducing compatibility issues.
- Independent of the host system, allowing for newer software versions.
- Wide availability of software in Flatpak repositories.

But it has very similar cons just like Snap:

- Larger package sizes compared to traditional packages, resulting in increased download and storage requirements.
- Possible duplication of system libraries, leading to larger disk usage.
- Dependency management can be more complex compared to APT.
- Some software may not be available as Flatpak packages.

![flatpak](/images/flatpak.png)

I didn't try Flatpak yet, but according to a vast majority of the Linux community, it's a better alternative to Snap especially due to Snap performance issues which Canonical is still working on.

Of course, there are many other package managers available out there, but these are the ones I'm most familiar with.

In conclusion, I won't come and say package manager X is the best one - While each package management system has its pros and cons, understanding their differences allows software developers and Linux distro users to make informed decisions based on their specific needs. APT remains a mature and efficient choice, while Snap and Flatpak provide advantages such as cross-distribution compatibility and enhanced security. Evaluating factors like performance, resource usage, and software availability will help determine the most suitable package management system for individual use cases.


Get to know APT, Snap, Flatpak, and more. Optimize software installation, updates, and removals in this overview guide

Package Management in Ubuntu: Overview Guide


I'll start with a personal perspective on this, and I know it might sound cheesy, but that's the how I look at it when looking back at my journey in the tech world.
Switching to a Linux distribution (my case Windows to Ubuntu) was a turning point in my career.

Switching to Linux was more than a mere change of operating systems for me. It was a transformational journey that broadened my technical horizons and significantly impacted my growth as a software developer. As a former Windows user and QA engineer, I was accustomed to a certain work process and mindset. However, taking the leap to Linux opened up an entirely new realm of possibilities.
Don't get me wrong, it wasn't easy at first, but eventually it was worth it.

Firstly, Linux introduced me to the power and efficiency of scripting. By utilizing fairly simple but yet effective bash script.
I could automate many of my testing processes, enhancing productivity and accuracy. The ability to manipulate tasks via a script was a game-changer for me, driving me to delve deeper into programming and the nuances of my system.

Moreover, Linux unlocked a new dimension of community engagement. This was not just about using a new operating system, but joining a global collective of like-minded enthusiasts and professionals. By participating in discussions on platforms like Discord and Reddit, and listening to informative podcasts, I gained a wealth of knowledge and insights. The ability to share, learn, and grow in such a diverse and dynamic environment is truly one of the most fulfilling aspects of being part of the Linux community.

This transition to Linux was not simply a switch in tools; it was a paradigm shift that changed how I approached my work. It provided a deeper understanding of computing principles, exposed me to a broad spectrum of technical paradigms, and connected me a lot more with the software world. And to be honest, I even believe that at some point it made me believe that I can code due to the learning curve and problem solving that I had to do.

**If you're still debating, I prepared a list of reasons why you should switch to Linux right now**:

### Open Source: The Heart of Innovation

Perhaps the most significant advantage of Linux lies in its open-source nature. The source code of Linux is freely available for modification and distribution. This grants engineers an incredible degree of freedom. Not only can you inspect the code to understand the system's inner workings, but you can also modify and optimize it to suit your specific needs. This level of customization leads to vast opportunities for learning and innovation, aligning perfectly with the creative and exploratory nature of a software engineer's work.

### It's The Backbone of the Internet

It's fairly simple, most of the world's servers are running on Linux. From GCP, Azure to Amazon, Linux is the backbone of the Internet. As a software engineer/QA engineer, you'll likely be working with these systems, so it's essential to be proficient in Linux to handle these systems effectively.
P.S, even if you're not working with cloud servers, Linux is still the most popular and widely used for Embedded, IoT and or any other system that you can think of.

### Security and Stability

Linux boasts an outstanding reputation for its security and stability. Unlike other popular OSs that are frequent targets for viruses and malware, Linux is far less susceptible to such threats due to its user privilege model and diversity. Stability is another strong suit for Linux; it can handle numerous processes running simultaneously without a hitch. This trait is crucial for software engineers who need their systems to perform consistently under heavy workloads.

### Superior Command Line Interface

Ah the CLI - Best thing ever. Once you get used it, you can't do anything without it!
For software engineers, the command line is a powerful tool. The Linux command line, also known as the terminal, is exceptionally powerful and flexible, allowing engineers to perform complex tasks with a few keystrokes. This efficiency can lead to improved productivity and a deeper understanding of the tasks at hand.
It also gives you an enormous amount of control over your system, and it's a great way to learn how your system works or even modify it to your needs.

![cli](https://images.unsplash.com/photo-1629654297299-c8506221ca97?ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&w=650&q=30)

### Wide Variety of Distributions & Desktop Environments

The beauty of Linux lies not only in its wide variety of distributions but also in its diverse range of desktop environments.
From Ubuntu and Fedora to Debian and Arch Linux, each distribution offers unique features and caters to specific user preferences. Whether you value hard-core customization, stability, or ease of use, there's a Linux distro to match your needs.

In addition, you have the freedom to choose among numerous desktop environments such as GNOME, KDE Plasma, Xfce, and Cinnamon, to name just a few. Each offers a distinct user experience and different levels of customization. You might prefer the modern and streamlined look of GNOME, the feature-rich and customizable nature of KDE Plasma, or the lightweight and simplicity of Xfce.

![my-ubuntu](/images/myubuntu.jpeg)

### Thriving Community and Great Support

The Linux community is known for its vibrant and supportive culture. This global community is always ready to lend a helping hand to newcomers. For software engineers, this means that help is only a forum post away. Whether you're dealing with a software bug or looking for a new tool, the community can be an invaluable resource.
I can't tell you how many hours i've burned on Reddit and Discord, and it was totally worth it.

On a side note, I'm still hoping Reddit will get it together and realize they're product won't worth much without its core community [(if you don't know what i'm talking about)](http://redd.it/1476ioa)

### Tools Galore: All You Need and More

Linux offers a endless amount of tools like Docker & Git (and much more of course) that form the cornerstone of any developer. By mastering Linux, you're also learning to work and understand these powerful tools effectively.

### Efficient Installation of Applications and Tools

One of the key advantages that Linux provides is the ease with which software applications and tools can be installed. Linux distributions often come with package management systems, like `apt` for Debian-based systems such as Ubuntu, or `yum` and `dnf` for Fedora. These package managers handle the downloading, installation, and updating of software, drastically simplifying the process for users.
With a simple command, you can install your desired software without having to search for and download it from the web.

Moreover, for software not available in the official repositories, third-party repositories and `snap` or `flatpak` application managers offer a wide range of software easily installable from the command line (or GUI). These methods ensure that almost any software you might need is just a command away.

### Cost-Efficiency

Last but not least, Linux is **free**. What else can I say? You get access to a robust, reliable, and high-performing operating system without spending a dime.

## In conclusion

Linux offers a multitude of benefits for software engineers. Its open-source nature fosters innovation and learning, its security and stability ensure reliable performance, and its free cost makes it accessible for all. With a wide variety of distributions and a supportive community, Linux offers an environment where software engineers can thrive.

If you haven't already, perhaps it's time to consider making the switch.


Linux opens possibilities, ignites curiosity & unlocks potential. For me, switching to a Linux distro resulted with a transition from QA a SW dev

Why You Should Switch or Embrace Linux Right Now


Explaining this article without divulging specific product details may be a challenge, but I'll attempt to simplify it.
The product is an embedded device that streams video packets over IP via multiple network interfaces, such as Ethernet, WiFi, or modems, and then bonds (aka, [bonding](https://en.wikipedia.org/wiki/Bonding_protocol)) them on the server to produce clear video without artifacts.

The company's hardware team developed a new device with improved hardware peripherals to achieve certain objectives that the company's existing devices couldn't. The new device was highly anticipated, and time was of the essence.

The new hardware architecture was based on something called PHY to PHY, which means the NIC of the board and the NIC of the video encoder were directly connected to each other, while the network interface was defined as VLAN to run a "keep-alive" traffic between the two.
This architecture was entirely different than what out other products were designed.

![PHY-TO-PHY](/images/phy-system-diagram.jpg)

This required some testing of course.

The test involved physically connecting the two [PCB's evaluation boards](https://www.tempoautomation.com/blog/pcb-evaluation-vs-development-board-what-is-the-difference/#:~:text=The%20evaluation%20board%20is%20used,pertinent%20components%20and%20connectors%20included) with Ethernet cable (RJ45) and generating UDP/TCP traffic between them while measuring the board's CPU usage, network capability and packet losses.

The most common use case for the product was transmitting 100 Mbps of UDP packets from the encoder card to the main system board (IMX6 at the time). The IMX board was based on ARM architecture, and testing tools such as [iperf](https://iperf.fr/) and [mpstat](https://linux.die.net/man/1/mpstat) were added using the [Buildroot](https://buildroot.org/) toolchain to generate network traffic and monitor CPU usage.

Since this was an internal network connected physically, packet loss was unexpected.

So I started testing using Iperf

From the encoder:

```
iperf –c 0.0.0.1 –I 1 -u –b 100m –t 500 -p 9000
```

On the IMX board (receiving board):

```
iperf -s -l 9000
```

![iperf-test](/images/iperf-test.png)

However, during a five-minute test, there were packet losses. In a video use case, video with losses results in artifacts, as shown in the example below.

![videoartifacts](/images/videoartifacts.png)

Kinda bad right?

The company saved a significant amount of time by letting the QA team test the products on PCB evaluation boards before they were actually ready for testing, resulting in a new hardware revision.
I don't know if your'e aware of the heavy cycle in terms on time and research it takes to fix an issue and make it ready for production in the hardware development world, but i'll give you a hint: It's far more than a software cycle.

The issue was eventually determined to be a hardware problem with the [clock signal](https://en.wikipedia.org/wiki/Clock_signal) on the board.


The test that saved my company a significant amount of time and effort - Using two PCB's, RJ45 cable, and the Iperf tool

Linux Articles

All Linux Articles

Goodbye Ubuntu, Hello Fedora!

Linux Process Prioritization with Niceness

Why You Should Only Use LTS Version of Ubuntu

Package Management in Ubuntu: Overview Guide

Why You Should Switch or Embrace Linux Right Now

How I Saved My Company a lot of Money Only Using a Simple Iperf Test