The open source community is working on many simultaneous challenges, not the least of which is addressing vulnerabilities in the core of our projects, securing the software supply chain, and protecting it from threat actors. At the same time, community health is equally as important as the security and vitality of software code. 

We need to retain talented people to work on complex problems. While we work urgently on implementing security best practices such as increasing SBOM adoption to help mitigate the fallout from another Log4J scenario, we can’t put the health of our communities on the open source back burner, either. 

Our communities are ultimately made up of people who contribute, have wants and needs, and have feelings and aspirations. So while having actionable data and metrics on the technical aspects of open source projects is key to understanding how they evolve and mature, the human experience within project communities also requires close examination. 

How participants in open source projects interact with each other and whether they feel included make up a large component of a community’s overall long-term health. It can determine whether or not they can continue productively and positively, attract new participants, create representative technologies, and spawn new projects and communities.

Motivations for a DEI study at the Linux Foundation 

DEI was always something that we wanted to include in the early days of the Linux Foundation Research agenda. The topic fell into the category of “ecosystem” research, where uncovering insights about the community at large was as critical as digging into the state of open source in a given technology horizontal or industry vertical.

As community health and DEI are core values of the Linux Foundation, conducting new research in this area was a complementary and necessary activity to support related inclusion and belonging initiatives already underway.

Research, in general, is essential to dispel myths and misperceptions about open source, regardless of the subject matter. DEI insight, generated through new research, is a vital tool to evaluate success criteria beyond looking solely at the growth of open source in terms of the supply and demand of code. With data, we can determine gaps, trends, and opportunities broadly.

This is why in the spring of 2021, we were thrilled to work with GitHub, the CHAOSS project, and Jessica Groopman from Kaleido Insights on a dedicated study on DEI in open source expanding on GitHub’s Open Source Survey in 2017. Together, we formed a working group to design and deliver the study, manifesting the notion that research really is a team sport. 

The importance of understanding DEI in open source

We have so many team members working on DEI initiatives, so this topic was a natural area of interest across the organization and within our project communities. Fortunately, we also had a dozen organizations provide sponsorship for this research, which enabled the translation of the survey into ten different languages. The goal of translation was to make the survey as accessible as possible for non-native English speakers.

The research was structured to determine how well we were doing as a community in terms of diversity, but importantly, how underrepresented groups feel within open source – do they feel welcome or unwelcome? Over time, we’ll want to see how this dynamic will change for the better.  

People of varying backgrounds and nationalities participate in open source, so how we measure their sentiment when they show up to work is important. There was no shortage of questions needing answers. For example, how do people view the efficacy of codes of conduct, or do people believe that they are given fair and equal opportunities? And for underrepresented groups, in particular, do they face barriers that others do not? How do we treat each other? 

We designed this research to uncover gaps in belonging within open source so that we can begin not just to think about how we can “do better,” but to inspire the implementation of inclusion strategies. Why? Because study after study shows that diverse teams are smarter and financially outperform their less diverse peers.

Barriers and challenges to achieving DEI in open source

From the data, we know that barriers in open source communities exist depending on the demographics or different segmentations of participants. Whether specific to race, gender, sexual orientation, language, geographic region, or religion – which we didn’t specifically study in this report – there are clear obstacles we need to remove. For example, communities can be more conscious about not scheduling conferences or meetings during religious holidays, such as Rosh Hashanna or Yom Kippur.

Download this infographic for key takeaways from the LF DEI study

We also need to be mindful that off-color jokes, sexual imagery, hostility, unwelcome sexual advances, rudeness, and name-calling don’t go over very well in open source, nor in any community for that matter. We need greater awareness that these types of behaviors exist and methods to improve how we deal with them when they occur.

And although English is the lingua franca of open source projects, native language and English fluency are barriers for some open source participants, as are geopolitical factors.

The uncomfortable truth revealed in the survey data is that people from the LGBTQ+ community are more likely to experience threats, inappropriate language, sexual advances, and other forms of toxic behavior. 

So what do we do about it? We need a full-fledged commitment to abiding by and enforcing codes of conduct within our communities. It is incumbent upon us to not tolerate inappropriate and toxic behavior and appropriately support community members when abuse arises.

Above all, it’s perhaps too easy to forget the human being at the other end of a transaction or professional exchange, especially as COVID-19 exacerbated the remote nature of our interactions.

The remedy is to engage all facets of our society – not just open source communities – to dedicate resources, inspire leadership, demonstrate moral courage, pursue greater educational initiatives and spread awareness of the opportunities that come from diverse communities. 

Let’s remember that diverse teams, where inclusion practices are upheld, are stronger, better teams that make more robust, more thoughtful, and higher performing technologies.

You can help the Linux Foundation spread awareness of DEI in your Open Source community by using these graphics and suggested verbiage for including in your social posts.

Linux Foundation DEI Report: By the numbers

Red Hat, VMware, GitHub, GitLab, Intel, Comcast, Renesas, Panasonic, Fujitsu, Hitachi, Huawei, and NEC. It was written by Hilary Carter, VP of Linux Foundation Research, and Jessica Groopman of Kaleido Insights. Researcher/Analyst Lawrence Hecht performed a quantitative analysis of the data with the support of Stephen Hendrick, VP of Linux Foundation Research, who conducted a peer review of the survey instrument.

2 Authors

2 Analysts

2 Designers

3 Editors

4 Deliverables

10 Survey Languages

14 Sponsors

24 Infographics

30 Research Contributors

2350 Survey Completes

7000+ Survey Respondents

Open Source Summit continues to focus on covering the most critical topics, innovative technologies and pivotal open source projects as the premier event for the open source community.

SAN FRANCISCO, January 19, 2022 —  The Linux Foundation, the nonprofit organization enabling mass innovation through open source, has announced that SupplyChainSecurityCon, an event launched last fall at KubeCon + CloudNativeCon North America, will be hosted in 2022 as part of Open Source Summit North America, June 21-24, in Austin, TX and virtual.

Open Source Summit is the premier event for open source developers, technologists, and community leaders to collaborate, share information, solve problems, and gain knowledge, furthering open source innovation and ensuring a sustainable open source ecosystem.

Co-hosted by CNCF and OpenSSF, along with The Linux Foundation, SupplyChainSecurityCon will gather security practitioners, open source developers, and others interested in software supply chain security to explore the security threats affecting the software supply chain, share best practices and mitigation tactics, and increase knowledge about how to best secure open source software.  

SupplyChainSecurityCon will be one of thirteen events held under the Open Source Summit North America 2022 umbrella. As the open source ecosystem continues to evolve, Open Source Summit will do so as well, as a conference umbrella composed of a collection of events that will always cover the most important projects, technologies and topics in open source today – in one place.

Open Source Summit North America 2022 is comprised of the following events:

  • LinuxCon – the precursor to OS Summit and the event for Linux developers

  • SupplyChainSecurityCon – addressing supply chain security

  • CloudOpen – covering cloud infrastructure and cloud native for developers

  • OSPOCon – for those working in open source program offices
  • Embedded Linux Conference – the premier vendor-neutral technical conference for developers working on embedded Linux since 2005

  • Critical Software Summit – for developers working to increase dependability of OS projects in safety, mission and business critical applications

  • ContainerCon – for those adopting containerization to further automation, portability and efficiency
  • Emerging OS Forum – where to find out about the latest trends and technologies touching open source
  • Open AI + Data Forum – a forum to drive open source innovation in the AI, ML, DL, and Data domains

Save the Date.
Open Source Summit will be held on the following dates and locations:

Additional locations to be announced shortly. Registration will open in February 2022.

Submit to Speak.
The Call for Proposals for Open Source Summit North America events and Open Source Summit Europe events are now open. View suggested topics and submit talks for all events at the links provided.

The Linux Foundation strongly values the need to increase diversity, equity and inclusion in open source, and a great place for that to begin is on a conference stage. We encourage those from all marginalized communities to submit to speak. We also welcome and encourage first-time speakers to submit.

Open Source Summit North America 2022 is made possible thanks to our sponsors, including Diamond Sponsor: Google, and Gold Sponsors: InfluxData and Styra. Open Source Summit Europe 2022 is made possible thanks to our sponsors, including Diamond Sponsor: Google, and Gold Sponsor: Styra. For information on becoming an event sponsor, click here or email us.

Members of the press who would like to request a press pass to attend should contact Kristin O’Connell.

About the Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 2,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit

The Linux Foundation Events are where the world’s leading technologists meet, collaborate, learn and network in order to advance innovations that support the world’s largest shared technologies.

Visit our website and follow us on Twitter, Linkedin, and Facebook for all the latest event updates and announcements.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: Linux is a registered trademark of Linus Torvalds. 


Media Contact
Kristin O’Connell
The Linux Foundation

WASHINGTON (January 13, 2022) Today marks an important moment in the Linux Foundation’s history of engagement with public sector organizations. The White House convened an important cross-section of the Open Source developer and commercial ecosystem along with leaders and experts of many U.S. federal agencies to identify the challenges present in the open source software supply chain and share ideas on ways to mitigate risk and enhance resilience.

At the meeting, the Linux Foundation and the Open Source Security Foundation (OpenSSF) represented their hundreds of communities and projects by highlighting collective cybersecurity efforts and sharing their intent to work with the administration across public and private sectors.

Linux Foundation Executive Director Jim Zemlin said, “Safeguarding critical infrastructure includes securing the software that runs its banking, energy, defense, healthcare, and technology systems. When the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted. This isn’t a problem unique to the US government; it’s a global concern. We applaud the US government’s leadership in facilitating a stronger focus on open source software security and look forward to collaborating with the global ecosystem to make progress. In particular, the OpenSSF is our key initiative to address the broad set of open source software supply chain challenges, and it was very heartening to hear our work identified and endorsed by other participants in the meeting as a basis for further collaboration.” 

Executive Director of the Open Source Security Foundation, Brian Behlendorf commented, “During today’s meeting, we shared a set of key opportunities where, with sufficient commitments from everyone, we could make a substantial impact on the critical endeavors needed to protect and improve the security of our software supply chains. The open source ecosystem will need to work together to further cybersecurity research, training, analysis, and remediation of defects found in critical open source software projects. These plans were met with positive feedback and a growing, collective commitment to take meaningful action. Following the recent log4j crisis, the time has never been more pressing for public and private collaboration to ensure that open source software components and the software supply chains they flow through demonstrate the highest cybersecurity integrity.”

Brian continued, “Through efforts such as our working groups on Best Practices, Identifying Critical Projects, Metrics and Scorecards, Project Sigstore, and more to be announced soon, the OpenSSF has already had an impact on many of the key areas discussed during today’s meeting. We are ready to further these efforts and welcome all new participants and resources that this conversation and further such conversations may bring.”

About the Linux Foundation 

Founded in 2000, the Linux Foundation is supported by more than 1,800 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, Hyperledger, RISC-V, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at

About the OpenSSF

The OpenSSF is a cross-industry collaboration that brings together leaders to improve the security of open source software (OSS) by building a broader community, targeted initiatives, and best practices. The OpenSSF brings together open source security initiatives under one foundation.

Media Contacts

Jennifer Cloer


SPDX was designed for tools to produce and consume SBOM documents. A decade of experience has shown us that tools may interpret fields differently – a file may be a valid syntactic SPDX SBOM,  but different tools may fill in different values.  

By coming together as a community to examine the output of multiple tools and to compare/contrast the results, we can refine the guidance to tool vendors and improve the robustness of the ecosystem sharing SPDX documents.   Historically, these events were called Bake-offs, but we’ve evolved them into “DocFests.” 

After a successful SPDX 2.2 DocFest in September of 2021, the SPDX community has decided to host another DocFest on January 27th from 7-11 AM PST. The purpose of this event is to bring together producers and consumers of SPDX documents and discuss differences between tool output and understanding for the same software artifacts. 

Specifically, the goals of this DocFest are to:

  • Come to agreement on how the fields should be populated for a given artifact
  • Identify instances where different use cases might lead to different choices for fields and structures of documents
  • Assess how well the NTIA SBOM minimum elements are covered
  • Create a set of reference SPDX SBOMs as part of the corpus for further tooling evaluation.

This event will require “sweat equity” – participants who can produce SPDX documents are expected to have generated at least one SPDX document from the target set (either source, built from source, or an image/container equivalent). Participants who consume SPDX documents are expected to run at least two SPDX documents through their tooling and share any analysis results. 

Those who have signed up and have submitted files by January 21, 2022, will receive a meeting invite to the DocFest.

To indicate interest to participate, please fill in the following form no later than January 16, 2022:

This is a classic article written by Jack Wallen from the archives. For more great SysAdmin tips and techniques check out our free intro to Linux course.

Quick question: How much space do you have left on your drives? A little or a lot? Follow up question: Do you know how to find out? If you happen to use a GUI desktop (e.g., GNOME, KDE, Mate, Pantheon, etc.), the task is probably pretty simple. But what if you’re looking at a headless server, with no GUI? Do you need to install tools for the task? The answer is a resounding no. All the necessary bits are already in place to help you find out exactly how much space remains on your drives. In fact, you have two very easy-to-use options at the ready.

In this article, I’ll demonstrate these tools. I’ll be using Elementary OS, which also includes a GUI option, but we’re going to limit ourselves to the command line. The good news is these command-line tools are readily available for every Linux distribution. On my testing system, there are a number of attached drives (both internal and external). The commands used are agnostic to where a drive is plugged in; they only care that the drive is mounted and visible to the operating system.

With that said, let’s take a look at the tools.


The df command is the tool I first used to discover drive space on Linux, way back in the 1990s. It’s very simple in both usage and reporting. To this day, df is my go-to command for this task. This command has a few switches but, for basic reporting, you really only need one. That command is df -H. The -H switch is for human-readable format. The output of df -H will report how much space is used, available, percentage used, and the mount point of every disk attached to your system (Figure 1).

Figure 1: The output of df -H on my Elementary OS system.

What if your list of drives is exceedingly long and you just want to view the space used on a single drive? With df, that is possible. Let’s take a look at how much space has been used up on our primary drive, located at /dev/sda1. To do that, issue the command:

df -H /dev/sda1

The output will be limited to that one drive (Figure 2).

Figure 2: How much space is on one particular drive?

You can also limit the reported fields shown in the df output. Available fields are:

  • source — the file system source

  • size — total number of blocks

  • used — spaced used on a drive

  • avail — space available on a drive

  • pcent — percent of used space, divided by total size

  • target — mount point of a drive

Let’s display the output of all our drives, showing only the size, used, and avail (or availability) fields. The command for this would be:

df -H --output=size,used,avail

The output of this command is quite easy to read (Figure 3).

Figure 3: Specifying what output to display for our drives.

The only caveat here is that we don’t know the source of the output, so we’d want to include source like so:

df -H --output=source,size,used,avail

Now the output makes more sense (Figure 4).

Figure 4: We now know the source of our disk usage.


Our next command is du. As you might expect, that stands for disk usage. The du command is quite different to the df command, in that it reports on directories and not drives. Because of this, you’ll want to know the names of directories to be checked. Let’s say I have a directory containing virtual machine files on my machine. That directory is /media/jack/HALEY/VIRTUALBOX. If I want to find out how much space is used by that particular directory, I’d issue the command:

du -h /media/jack/HALEY/VIRTUALBOX

The output of the above command will display the size of every file in the directory (Figure 5).

Figure 5: The output of the du command on a specific directory.

So far, this command isn’t all that helpful. What if we want to know the total usage of a particular directory? Fortunately, du can handle that task. On the same directory, the command would be:

du -sh /media/jack/HALEY/VIRTUALBOX/

Now we know how much total space the files are using up in that directory (Figure 6).

Figure 6: My virtual machine files are using 559GB of space.

You can also use this command to see how much space is being used on all child directories of a parent, like so:

du -h /media/jack/HALEY

The output of this command (Figure 7) is a good way to find out what subdirectories are hogging up space on a drive.

Figure 7: How much space are my subdirectories using?

The du command is also a great tool to use in order to see a list of directories that are using the most disk space on your system. The way to do this is by piping the output of du to two other commands: sort and head. The command to find out the top 10 directories eating space on a drive would look something like this:

du -a /media/jack | sort -n -r | head -n 10

The output would list out those directories, from largest to least offender (Figure 8).

Figure 8: Our top ten directories using up space on a drive.

Not as hard as you thought

Finding out how much space is being used on your Linux-attached drives is quite simple. As long as your drives are mounted to the Linux system, both df and du will do an outstanding job of reporting the necessary information. With df you can quickly see an overview of how much space is used on a disk and with du you can discover how much space is being used by specific directories. These two tools in combination should be considered must-know for every Linux administrator.

And, in case you missed it, I recently showed how to determine your memory usage on Linux. Together, these tips will go a long way toward helping you successfully manage your Linux servers.

This is a classic article written by Jack Wallen from the archives. For more great SysAdmin tips and techniques check out our free intro to Linux course.

Although there are already a lot of good security features built into Linux-based systems, one very important potential vulnerability can exist when local access is granted – – that is file permission-based issues resulting from a user not assigning the correct permissions to files and directories. So based upon the need for proper permissions, I will go over the ways to assign permissions and show you some examples where modification may be necessary.

Permission Groups

Each file and directory has three user based permission groups:

  • owner – The Owner permissions apply only to the owner of the file or directory, they will not impact the actions of other users.
  • group – The Group permissions apply only to the group that has been assigned to the file or directory, they will not affect the actions of other users.
  • all users – The All Users permissions apply to all other users on the system, this is the permission group that you want to watch the most.

Permission Types

Each file or directory has three basic permission types:

  • read – The Read permission refers to a user’s capability to read the contents of the file.
  • write – The Write permissions refer to a user’s capability to write or modify a file or directory.
  • execute – The Execute permission affects a user’s capability to execute a file or view the contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions in your favorite GUI File Manager (which I will not cover here) or by reviewing the output of the “ls -l” command while in the terminal and while working in the directory which contains the file or folder.

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

  1. User rights/Permissions
    1. The first character that I marked with an underscore is the special permission flag that can vary.
    2. The following set of three characters (rwx) is for the owner permissions.
    3. The second set of three characters (rwx) is for the Group permissions.
    4. The third set of three characters (rwx) is for the All Users permissions.
  2. Following that grouping since the integer/number displays the number of hardlinks to the file.
  3. The last piece is the Owner and Group assignment formatted as Owner:Group.

Modifying the Permissions

When in the command line, the permissions are edited by using the command chmod. You can assign the permissions explicitly or by using a binary reference as described below.

Explicitly Defining Permissions

To explicitly define permissions you will need to reference the Permission Group and Permission Types.

The Permission Groups used are:

  • u – Owner
  • g – Group
  • o – Others
  • a – All users

The potential Assignment Operators are + (plus) and – (minus); these are used to tell the system whether to add or remove the specific permissions.

The Permission Types that are used are:

  • r – Read
  • w – Write
  • x – Execute

So for example, let’s say I have a file named file1 that currently has the permissions set to _rw_rw_rw, which means that the owner, group, and all users have read and write permission. Now we want to remove the read and write permissions from the all users group.

To make this modification you would invoke the command: chmod a-rw file1
To add the permissions above you would invoke the command: chmod a+rw file1

As you can see, if you want to grant those permissions you would change the minus character to a plus to add those permissions.

Using Binary References to Set permissions

Now that you understand the permissions groups and types this one should feel natural. To set the permission using binary references you must first understand that the input is done by entering three integers/numbers.

A sample permission string would be chmod 640 file1, which means that the owner has read and write permissions, the group has read permissions, and all other user have no rights to the file.

The first number represents the Owner permission; the second represents the Group permissions; and the last number represents the permissions for all other users. The numbers are a binary representation of the rwx string.

  • r = 4
  • w = 2
  • x = 1

You add the numbers to get the integer/number representing the permissions you wish to set. You will need to include the binary permissions for each of the three permission groups.

So to set a file to permissions on file1 to read _rwxr_____, you would enter chmod 740 file1.

Owners and Groups

I have made several references to Owners and Groups above, but have not yet told you how to assign or change the Owner and Group assigned to a file or directory.

You use the chown command to change owner and group assignments, the syntax is simple

chown owner:group filename,

so to change the owner of file1 to user1 and the group to family you would enter chown user1:family file1.

Advanced Permissions

The special permissions flag can be marked with any of the following:

  • _ – no special permissions
  • d – directory
  • l– The file or directory is a symbolic link
  • s – This indicated the setuid/setgid permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a s in the read portion of the owner or group permissions.
  • t – This indicates the sticky bit permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a t in the executable portion of the all users permissions

Setuid/Setgid Special Permissions

The setuid/setguid permissions are used to tell the system to run an executable as the owner with the owner’s permissions.

Be careful using setuid/setgid bits in permissions. If you incorrectly assign permissions to a file owned by root with the setuid/setgid bit set, then you can open your system to intrusion.

You can only assign the setuid/setgid bit by explicitly defining permissions. The character for the setuid/setguid bit is s.

So do set the setuid/setguid bit on you would issue the command chmod g+s

Sticky Bit Special Permissions

The sticky bit can be very useful in shared environment because when it has been assigned to the permissions on a directory it sets it so only file owner can rename or delete the said file.

You can only assign the sticky bit by explicitly defining permissions. The character for the sticky bit is t.

To set the sticky bit on a directory named dir1 you would issue the command chmod +t dir1.

When Permissions Are Important

To some users of Mac- or Windows-based computers, you don’t think about permissions, but those environments don’t focus so aggressively on user-based rights on files unless you are in a corporate environment. But now you are running a Linux-based system and permission-based security is simplified and can be easily used to restrict access as you please.

So I will show you some documents and folders that you want to focus on and show you how the optimal permissions should be set.

  • home directories– The users’ home directories are important because you do not want other users to be able to view and modify the files in another user’s documents of desktop. To remedy this you will want the directory to have the drwx______ (700) permissions, so lets say we want to enforce the correct permissions on the user user1’s home directory that can be done by issuing the command chmod 700 /home/user1.
  • bootloader configuration files– If you decide to implement password to boot specific operating systems then you will want to remove read and write permissions from the configuration file from all users but root. To do you can change the permissions of the file to 700.
  • system and daemon configuration files– It is very important to restrict rights to system and daemon configuration files to restrict users from editing the contents, it may not be advisable to restrict read permissions, but restricting write permissions is a must. In these cases it may be best to modify the rights to 644.
  • firewall scripts – It may not always be necessary to block all users from reading the firewall file, but it is advisable to restrict the users from writing to the file. In this case the firewall script is run by the root user automatically on boot, so all other users need no rights, so you can assign the 700 permissions.

Other examples can be given, but this article is already very lengthy, so if you want to share other examples of needed restrictions please do so in the comments.

This is a classic article written by Jack Wallen from the archives. For more great SysAdmin tips and techniques check out our free intro to Linux course.

There are certain tasks that are done so often, users take for granted just how simple they are. But then, you migrate to a new platform and those same simple tasks begin to require a small portion of your brain’s power to complete. One such task is moving files from one location to another. Sure, it’s most often considered one of the more rudimentary actions to be done on a computer. When you move to the Linux platform, however, you may find yourself asking “Now, how do I move files?”

If you’re familiar with Linux, you know there are always many routes to the same success. Moving files is no exception. You can opt for the power of the command line or the simplicity of the GUI – either way, you will get those files moved.

Let’s examine just how you can move those files about. First, we’ll examine the command line.

Command line moving

One of the issues so many users new to Linux face is the idea of having to use the command line. It can be somewhat daunting at first. Although modern Linux interfaces can help to ensure you rarely have to use this “old school” tool, there is a great deal of power you would be missing if you ignored it altogether. The command for moving files is a perfect illustration of this.

The command to move files is mv. It’s very simple and one of the first commands you will learn on the platform. Instead of just listing out the syntax and the usual switches for the command – and then allowing you to do the rest – let’s walk through how you can make use of this tool.

The mv command does one thing – it moves a file from one location to another. This can be somewhat misleading because mv is also used to rename files. How? Simple. Here’s an example. Say you have the file testfile in /home/jack/ and you want to rename it to testfile2 (while keeping it in the same location). To do this, you would use the mv command like so:

mv /home/jack/testfile /home/jack/testfile2

or, if you’re already within /home/jack:

mv testfile testfile2

The above commands would move /home/jack/testfile to /home/jack/testfile2 – effectively renaming the file. But what if you simply wanted to move the file? Say you want to keep your home directory (in this case /home/jack) free from stray files. You could move that testfile into /home/jack/Documents with the command:

mv /home/jack/testfile /home/jack/Documents/

With the above command, you have relocated the file into a new location, while retaining the original file name.

What if you have a number of files you want to move? Luckily, you don’t have to issue the mv command for every file. You can use wildcards to help you out. Here’s an example:

You have a number of .mp3 files in your ~/Downloads directory (~/ – is an easy way to represent your home directory – in our earlier example, that would be /home/jack/) and you want them in ~/Music. You could quickly move them with a single command, like so:

mv ~/Downloads/*.mp3 ~/Music/

That command would move every file that ended in .mp3 from the Downloads directory, and move them into the Music directory.

Should you want to move a file into the parent directory of the current working directory, there’s an easy way to do that. Say you have the file testfile located in ~/Downloads and you want it in your home directory. If you are currently in the ~/Downloads directory, you can move it up one folder (to ~/) like so:

mv testfile ../ 

The “../” means to move the folder up one level. If you’re buried deeper, say ~/Downloads/today/, you can still easily move that file with:

mv testfile ../../

Just remember, each “../” represents one level up.

As you can see, moving files from the command line isn’t difficult at all.


There are a lot of GUIs available for the Linux platform. On top of that, there are a lot of file managers you can use. The most popular file managers are Nautilus (GNOME) and Dolphin (KDE). Both are very powerful and flexible. I want to illustrate how files are moved using the Nautilus file manager.

Nautilus has probably the most efficient means of moving files about. Here’s how it’s done:

  1. Open up the Nautilus file manager.
  2. Locate the file you want to move and right-click said file.
  3. From the pop-up menu (Figure 1) select the “Move To” option.
  4. When the Select Destination window opens, navigate to the new location for the file.
  5. Once you’ve located the destination folder, click Select.
Nautilus screenshot

This context menu also allows you to copy the file to a new location, move the file to the Trash, and more.

If you’re more of a drag and drop kind of person, fear not – Nautilus is ready to serve. Let’s say you have a file in your home directory and you want to drag it to Documents. By default, Nautilus will have a few bookmarks in the left pane of the window. You can drag the file into the Document bookmark without having to open a second Nautilus window. Simply click, hold, and drag the file from the main viewing pane to the Documents bookmark.

If, however, the destination for that file is not listed in your bookmarks (or doesn’t appear in the current main viewing pane), you’ll need to open up a second Nautilus window. Side by side, you can then drag the file from the source folder in the original window to the destination folder in the second window.

If you need to move multiple files, you’re still in luck. Similar to nearly every modern user interface, you can do a multi-select of files by holding down the Ctrl button as you click each file. After you have selected each file (Figure 2), you can either right-click one of the selected files and then choose the Move To option, or just drag and drop them into a new location.


The selected files (in this case, folders) will each be highlighted.

Moving files on the Linux desktop is incredibly easy. Either with the command line or your desktop of choice, you have numerous routes to success – all of which are user-friendly and quick to master.

This is a classic article written by Jack Wallen from the archives. For more great SysAdmin tips and techniques check out our free intro to Linux course.

It goes without saying that every good Linux desktop environment offers the ability to search your file system for files and folders. If your default desktop doesn’t — because this is Linux — you can always install an app to make searching your directory hierarchy a breeze.

But what about the command line? If you happen to frequently work in the command line or you administer GUI-less Linux servers, where do you turn when you need to locate a file? Fortunately, Linux has exactly what you need to locate the files in question, built right into the system.

The command in question is find. To make the understanding of this command even more enticing, once you know it, you can start working it into your Bash scripts. That’s not only convenience, that’s power.

Let’s get up to speed with the find command so you can take control of locating files on your Linux servers and desktops, without the need of a GUI.

How to use the find command

When I first glimpsed Linux, back in 1997, I didn’t quite understand how the find command worked; therefore, it never seemed to function as I expected. It seemed simple; issue the command find FILENAME (where FILENAME is the name of the file) and the command was supposed to locate the file and report back. Little did I know there was more to the command than that. Much more.

If you issue the command man find, you’ll see the syntax of the find command is:

find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]

Naturally, if you’re unfamiliar with how man works, you might be confused about or overwhelmed by that syntax. For ease of understanding, let’s simplify that. The most basic syntax of a basic find command would look like this:

find /path option filename

Now we’ll see it at work.

Find by name

Let’s break down that basic command to make it as clear as possible. The most simplistic  structure of the find command should include a path for the file, an option, and the filename itself. You may be thinking, “If I know the path to the file, I’d already know where to find it!”. Well, the path for the file could be the root of your drive; so / would be a legitimate path. Entering that as your path would take find longer to process — because it has to start from scratch — but if you have no idea where the file is, you can start from there. In the name of efficiency, it is always best to have at least an idea where to start searching.

The next bit of the command is the option. As with most Linux commands, you have a number of available options. However, we are starting from the beginning, so let’s make it easy. Because we are attempting to find a file by name, we’ll use one of two options:

  • name – case sensitive

  • iname – case insensitive

Remember, Linux is very particular about case, so if you’re looking for a file named Linux.odt, the following command will return no results.

find / -name linux.odt

If, however, you were to alter the command by using the -iname option, the find command would locate your file, regardless of case. So the new command looks like:

find / -iname linux.odt

Find by type

What if you’re not so concerned with locating a file by name but would rather locate all files of a certain type? Some of the more common file descriptors are:

  • f – regular file

  • d – directory

  • l – symbolic link

  • c – character devices

  • b – block devices

Now, suppose you want to locate all block devices (a file that refers to a device) on your system. With the help of the -type option, we can do that like so:

find / -type c

The above command would result in quite a lot of output (much of it indicating permission denied), but would include output similar to:


Voilà! Block devices.

We can use the same option to help us look for configuration files. Say, for instance, you want to locate all regular files that end in the .conf extension. This command would look something like:

find / -type f -name "*.conf"

The above command would traverse the entire directory structure to locate all regular files ending in .conf. If you know most of your configuration files are housed in /etc, you could specify that like so:

find /etc -type f -name “*.conf”

The above command would list all of your .conf files from /etc (Figure 1).

Figure 1: Locating all of your configuration files in /etc.

Outputting results to a file

One really handy trick is to output the results of the search into a file. When you know the output might be extensive, or if you want to comb through the results later, this can be incredibly helpful. For this, we’ll use the same example as above and pipe the results into a file called conf_search. This new command would look like: ​

find /etc -type f -name “*.conf” > conf_search

You will now have a file (conf_search) that contains all of the results from the find command issued.

Finding files by size

Now we get to a moment where the find command becomes incredibly helpful. I’ve had instances where desktops or servers have found their drives mysteriously filled. To quickly make space (or help locate the problem), you can use the find command to locate files of a certain size. Say, for instance, you want to go large and locate files that are over 1000MB. The find command can be issued, with the help of the -size option, like so:

find / -size +1000MB

You might be surprised at how many files turn up. With the output from the command, you can comb through the directory structure and free up space or troubleshoot to find out what is mysteriously filling up your drive.

You can search with the following size descriptions:

  • c – bytes

  • k – Kilobytes

  • M – Megabytes

  • G – Gigabytes

  • b – 512-byte blocks

Keep learning

We’ve only scratched the surface of the find command, but you now have a fundamental understanding of how to locate files on your Linux systems. Make sure to issue the command man find to get a deeper, more complete, knowledge of how to make this powerful tool work for you.

The last two years have demonstrated even more clearly that technology is the crucial fabric that weaves society and the economy together. From video conferencing to online shopping and delivery to remote collaboration tools for work, technology helped society continue to function throughout the pandemic in 2020 and the continuing uncertainty of 2021. All that technology (and more) is powered, quite literally, by open source, in one way or another. Software is eating the world and open source software is becoming the dominant part of software, from the operating system to the database and messaging layer up to the frameworks that drive the user experience. Few, if any, organizations and enterprises could run operations today without relying on open source.

Not surprisingly, as it becomes more pervasive and mission-critical, open source is also proving to be a larger economic force. Public and private companies focused on selling open source software or services now have a collective market value approaching half a trillion dollars. There is no easy way to account for the total economic value of open source consumed by all businesses, individuals, nonprofits, and governments; the value enabled is likely well into the trillions of dollars. Open source powers cloud computing, the Internet, Android phones, mobile apps, cars — even the Mars helicopter launched by NASA. Open source also powers much of consumer electronics on the market today. 

With prominent positions in society and the economy comes an urgent imperative to better address risk and security. The Linux Foundation is working with its members to take on these challenges for open source. We launched multiple new initiatives in 2021 to make the open source technology ecosystem and software supply chain more secure, transparent, and resilient. From the Software Bill of Materials to the Open Source Security Foundation, the LF, its members, and its projects and communities are collaborating with paramount importance to secure the open source supply chain.

Behind risk management and security considerations — and technology development in general — are real people. This is also why the Linux Foundation is making substantial investments in supporting diversity and inclusion in open source communities. We need to take action as a community to make open source more inclusive and welcoming. We can do this in a data-driven fashion with research on what issues hinder our progress and develop actions that will, we hope, drive measurable improvements. 

Working together on collective efforts, beyond just our company and ourselves, is not just good for business; it is personally rewarding. Recently one of our engineers explained that he loves working with open source because he feels it gives him a global network of teachers, all helping him become better. I believe this is why open source is one of the most powerful forces in the world today, and it is only growing stronger. Through a pandemic, through economic challenges, day in, day out, we see people helping each other regardless of their demographics. Open source brings out the best in people by encouraging them to work together to solve great challenges and dream big. This is why in 2021, I am excited to see all the new collaborations, expanding our collective efforts to address truly global problems in agriculture, public health, and other areas that are far bigger than any one project. 

After a successful 2021, and hopefully, with a pandemic fading into our rearview mirrors, I am optimistic for an even more amazing 2022. Thank you for your support and guidance, and I wish you all a Happy New Year!

Nithya Ruff
Chair of the Board of Directors, The Linux Foundation

These efforts are made possible by our members and communities. To learn how your organization can get involved with the Linux Foundationclick here.

This is a classic article written by Jack Wallen from the archives. For more great SysAdmin tips and techniques check out our free intro to Linux course.

Picture this: You’ve launched an application (be it from your favorite desktop menu or from the command line) and you start using that launched app, only to have it lock up on you, stop performing, or unexpectedly die. You try to run the app again, but it turns out the original never truly shut down completely.

What do you do? You kill the process. But how? Believe it or not, your best bet most often lies within the command line. Thankfully, Linux has every tool necessary to empower you, the user, to kill an errant process. However, before you immediately launch that command to kill the process, you first have to know what the process is. How do you take care of this layered task? It’s actually quite simple…once you know the tools at your disposal.

Let me introduce you to said tools.

The steps I’m going to outline will work on almost every Linux distribution, whether it is a desktop or a server. I will be dealing strictly with the command line, so open up your terminal and prepare to type.

Locating the process

The first step in killing the unresponsive process is locating it. There are two commands I use to locate a process: top and ps. Top is a tool every administrator should get to know. With top, you get a full listing of currently running process. From the command line, issue top to see a list of your running processes (Figure 1).

Figure 1: The top command gives you plenty of information.

From this list you will see some rather important information. Say, for example, Chrome has become unresponsive. According to our top display, we can discern there are four instances of chrome running with Process IDs (PID) 3827, 3919, 10764, and 11679. This information will be important to have with one particular method of killing the process.

Although top is incredibly handy, it’s not always the most efficient means of getting the information you need. Let’s say you know the Chrome process is what you need to kill, and you don’t want to have to glance through the real-time information offered by top. For that, you can make use of the ps command and filter the output through grep. The ps command reports a snapshot of a current process and grep prints lines matching a pattern. The reason why we filter ps through grep is simple: If you issue the ps command by itself, you will get a snapshot listing of all current processes. We only want the listing associated with Chrome. So this command would look like:

ps aux | grep chrome

The aux options are as follows:

  • a = show processes for all users

  • u = display the process’s user/owner

  • x = also show processes not attached to a terminal

The x option is important when you’re hunting for information regarding a graphical application.

When you issue the command above, you’ll be given more information than you need (Figure 2) for the killing of a process, but it is sometimes more efficient than using top.

Figure 2: Locating the necessary information with the ps command.

Killing the process

Now we come to the task of killing the process. We have two pieces of information that will help us kill the errant process:

  • Process name
  • Process ID

Which you use will determine the command used for termination. There are two commands used to kill a process:

  • kill – Kill a process by ID
  • killall – Kill a process by name

There are also different signals that can be sent to both kill commands. What signal you send will be determined by what results you want from the kill command. For instance, you can send the HUP (hang up) signal to the kill command, which will effectively restart the process. This is always a wise choice when you need the process to immediately restart (such as in the case of a daemon). You can get a list of all the signals that can be sent to the kill command by issuing kill -l. You’ll find quite a large number of signals (Figure 3).

Figure 3: The available kill signals.

The most common kill signals are:

Signal Name

Single Value







Interrupt from keyboard



Kill signal



Termination signal


17, 19, 23

Stop the process

What’s nice about this is that you can use the Signal Value in place of the Signal Name. So you don’t have to memorize all of the names of the various signals.
So, let’s now use the kill command to kill our instance of chrome. The structure for this command would be:


Where SIGNAL is the signal to be sent and PID is the Process ID to be killed. We already know, from our ps command that the IDs we want to kill are 3827, 3919, 10764, and 11679. So to send the kill signal, we’d issue the commands:

kill -9 3827

kill -9 3919

kill -9 10764

kill -9 11679

Once we’ve issued the above commands, all of the chrome processes will have been successfully killed.

Let’s take the easy route! If we already know the process we want to kill is named chrome, we can make use of the killall command and send the same signal the process like so:

killall -9 chrome

The only caveat to the above command is that it may not catch all of the running chrome processes. If, after running the above command, you issue the ps aux|grep chrome command and see remaining processes running, your best bet is to go back to the kill command and send signal 9 to terminate the process by PID.

Ending processes made easy

As you can see, killing errant processes isn’t nearly as challenging as you might have thought. When I wind up with a stubborn process, I tend to start off with the killall command as it is the most efficient route to termination. However, when you wind up with a really feisty process, the kill command is the way to go.