How to use cron in Linux

 This article was originally published in November 2017 and has been updated to include additional information.

One of the challenges (among the many advantages) of being a sysadmin is running tasks when you'd rather be sleeping. For example, some tasks (including regularly recurring tasks) need to run overnight or on weekends, when no one is expected to be using computer resources. I have no time to spare in the evenings to run commands and scripts that have to operate during off-hours. And I don't want to have to get up at oh-dark-hundred to start a backup or major update.

Instead, I use two service utilities that allow me to run commands, programs, and tasks at predetermined times. The cron and at services enable sysadmins to schedule tasks to run at a specific time in the future. The at service specifies a one-time task that runs at a certain time. The cron service can schedule tasks on a repetitive basis, such as daily, weekly, or monthly.

In this article, I'll introduce the cron service and how to use it.

Common (and uncommon) cron uses

I use the cron service to schedule obvious things, such as regular backups that occur daily at 2 a.m. I also use it for less obvious things.

• The system times (i.e., the operating system time) on my many computers are set using the Network Time Protocol (NTP). While NTP sets the system time, it does not set the hardware time, which can drift. I use cron to set the hardware time based on the system time.
• I also have a Bash program I run early every morning that creates a new "message of the day" (MOTD) on each computer. It contains information, such as disk usage, that should be current in order to be useful.
• Many system processes and services, like Logwatch, logrotate, and Rootkit Hunter, use the cron service to schedule tasks and run programs every day.

The crond daemon is the background service that enables cron functionality.

The cron service checks for files in the /var/spool/cron and /etc/cron.d directories and the /etc/anacrontab file. The contents of these files define cron jobs that are to be run at various intervals. The individual user cron files are located in /var/spool/cron, and system services and applications generally add cron job files in the /etc/cron.d directory. The /etc/anacrontab is a special case that will be covered later in this article.

Using crontab

The cron utility runs based on commands specified in a cron table (crontab). Each user, including root, can have a cron file. These files don't exist by default, but can be created in the /var/spool/cron directory using the crontab -e command that's also used to edit a cron file (see the script below). I strongly recommend that you not use a standard editor (such as Vi, Vim, Emacs, Nano, or any of the many other editors that are available). Using the crontab command not only allows you to edit the command, it also restarts the crond daemon when you save and exit the editor. The crontab command uses Vi as its underlying editor, because Vi is always present (on even the most basic of installations).

New cron files are empty, so commands must be added from scratch. I added the job definition example below to my own cron files, just as a quick reference, so I know what the various parts of a command mean. Feel free to copy it for your own use.

# crontab -e
SHELL=/bin/bash
MAILTO=root@example.com
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

# Set the hardware clock to keep it in sync with the more accurate system clock
03 05 * * * /sbin/hwclock --systohc

# Perform monthly updates on the first of the month
# 25 04 1 * * /usr/bin/dnf -y update

The crontab command is used to view or edit the cron files.

The first three lines in the code above set up a default environment. The environment must be set to whatever is necessary for a given user because cron does not provide an environment of any kind. The SHELL variable specifies the shell to use when commands are executed. This example specifies the Bash shell. The MAILTO variable sets the email address where cron job results will be sent. These emails can provide the status of the cron job (backups, updates, etc.) and consist of the output you would see if you ran the program manually from the command line. The third line sets up the PATH for the environment. Even though the path is set here, I always prepend the fully qualified path to each executable.

There are several comment lines in the example above that detail the syntax required to define a cron job. I'll break those commands down, then add a few more to show you some more advanced capabilities of crontab files.

01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

This line in my /etc/crontab runs a script that performs backups for my systems.

This line runs my self-written Bash shell script, rsbu, that backs up all my systems. This job kicks off at 1:01 a.m. (01 01) every day. The asterisks (*) in positions three, four, and five of the time specification are like file globs, or wildcards, for other time divisions; they specify "every day of the month," "every month," and "every day of the week." This line runs my backups twice; one backs up to an internal dedicated backup hard drive, and the other backs up to an external USB drive that I can take to the safe deposit box.

The following line sets the hardware clock on the computer using the system clock as the source of an accurate time. This line is set to run at 5:03 a.m. (03 05) every day.

03 05 * * * /sbin/hwclock --systohc

This line sets the hardware clock using the system time as the source.

I was using the third and final cron job (commented out) to perform a dnf or yum update at 04:25 a.m. on the first day of each month, but I commented it out so it no longer runs.

# 25 04 1 * * /usr/bin/dnf -y update

This line used to perform a monthly update, but I've commented it out.

Other scheduling tricks

Now let's do some things that are a little more interesting than these basics. Suppose you want to run a particular job every Thursday at 3 p.m.:

00 15 * * Thu /usr/local/bin/mycronjob.sh

This line runs mycronjob.sh every Thursday at 3 p.m.

Or, maybe you need to run quarterly reports after the end of each quarter. The cron service has no option for "The last day of the month," so instead you can use the first day of the following month, as shown below. (This assumes that the data needed for the reports will be ready when the job is set to run.)

02 03 1 1,4,7,10 * /usr/local/bin/reports.sh

This cron job runs quarterly reports on the first day of the month after a quarter ends.

The following shows a job that runs one minute past every hour between 9:01 a.m. and 5:01 p.m.

01 09-17 * * * /usr/local/bin/hourlyreminder.sh

Sometimes you want to run jobs at regular times during normal business hours.

I have encountered situations where I need to run a job every two, three, or four hours. That can be accomplished by dividing the hours by the desired interval, such as */3 for every three hours, or 6-18/3 to run every three hours between 6 a.m. and 6 p.m. Other intervals can be divided similarly; for example, the expression */15 in the minutes position means "run the job every 15 minutes."

*/5 08-18/2 * * * /usr/local/bin/mycronjob.sh

This cron job runs every five minutes during every hour between 8 a.m. and 5:58 p.m.

One thing to note: The division expressions must result in a remainder of zero for the job to run. That's why, in this example, the job is set to run every five minutes (08:05, 08:10, 08:15, etc.) during even-numbered hours from 8 a.m. to 6 p.m., but not during any odd-numbered hours. For example, the job will not run at all from 9 p.m. to 9:59 a.m.

I am sure you can come up with many other possibilities based on these examples.

Limiting cron access

More Linux resources

• Linux commands cheat sheet
• Advanced Linux commands cheat sheet
• Free online course: RHEL Technical Overview
• Linux networking cheat sheet
• SELinux cheat sheet
• Linux common commands cheat sheet
• What are Linux containers?
• Our latest Linux articles

Regular users with cron access could make mistakes that, for example, might cause system resources (such as memory and CPU time) to be swamped. To prevent possible misuse, the sysadmin can limit user access by creating a /etc/cron.allow file that contains a list of all users with permission to create cron jobs. The root user cannot be prevented from using cron.

By preventing non-root users from creating their own cron jobs, it may be necessary for root to add their cron jobs to the root crontab. "But wait!" you say. "Doesn't that run those jobs as root?" Not necessarily. In the first example in this article, the username field shown in the comments can be used to specify the user ID a job is to have when it runs. This prevents the specified non-root user's jobs from running as root. The following example shows a job definition that runs a job as the user "student":

04 07 * * * student /usr/local/bin/mycronjob.sh

If no user is specified, the job is run as the user that owns the crontab file, root in this case.

cron.d

The directory /etc/cron.d is where some applications, such as SpamAssassin and sysstat, install cron files. Because there is no spamassassin or sysstat user, these programs need a place to locate cron files, so they are placed in /etc/cron.d.

The /etc/cron.d/sysstat file below contains cron jobs that relate to system activity reporting (SAR). These cron files have the same format as a user cron file.

# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

The sysstat package installs the /etc/cron.d/sysstat cron file to run programs for SAR.

The sysstat cron file has two lines that perform tasks. The first line runs the sa1 program every 10 minutes to collect data stored in special binary files in the /var/log/sa directory. Then, every night at 23:53, the sa2 program runs to create a daily summary.

Scheduling tips

Some of the times I set in the crontab files seem rather random—and to some extent they are. Trying to schedule cron jobs can be challenging, especially as the number of jobs increases. I usually have only a few tasks to schedule on each of my computers, which is simpler than in some of the production and lab environments where I have worked.

One system I administered had around a dozen cron jobs that ran every night and an additional three or four that ran on weekends or the first of the month. That was a challenge, because if too many jobs ran at the same time—especially the backups and compiles—the system would run out of RAM and nearly fill the swap file, which resulted in system thrashing while performance tanked, so nothing got done. We added more memory and improved how we scheduled tasks. We also removed a task that was very poorly written and used large amounts of memory.

The crond service assumes that the host computer runs all the time. That means that if the computer is turned off during a period when cron jobs were scheduled to run, they will not run until the next time they are scheduled. This might cause problems if they are critical cron jobs. Fortunately, there is another option for running jobs at regular intervals: anacron.

anacron

The anacron program performs the same function as crond, but it adds the ability to run jobs that were skipped, such as if the computer was off or otherwise unable to run the job for one or more cycles. This is very useful for laptops and other computers that are turned off or put into sleep mode.

As soon as the computer is turned on and booted, anacron checks to see whether configured jobs missed their last scheduled run. If they have, those jobs run immediately, but only once (no matter how many cycles have been missed). For example, if a weekly job was not run for three weeks because the system was shut down while you were on vacation, it would be run soon after you turn the computer on, but only once, not three times.

The anacron program provides some easy options for running regularly scheduled tasks. Just install your scripts in the /etc/cron.[hourly|daily|weekly|monthly] directories, depending how frequently they need to be run.

How does this work? The sequence is simpler than it first appears.

1. The crond service runs the cron job specified in /etc/cron.d/0hourly.

# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly

The contents of /etc/cron.d/0hourly cause the shell scripts located in /etc/cron.hourly to run.

2. The cron job specified in /etc/cron.d/0hourly runs the run-parts program once per hour.
3. The run-parts program runs all the scripts located in the /etc/cron.hourly directory.
4. The /etc/cron.hourly directory contains the 0anacron script, which runs the anacron program using the /etdc/anacrontab configuration file shown here.

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
                                                               
#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

The contents of /etc/anacrontab file runs the executable files in the cron.[daily|weekly|monthly] directories at the appropriate times.

5. The anacron program runs the programs located in /etc/cron.daily once per day; it runs the jobs located in /etc/cron.weekly once per week, and the jobs in cron.monthly once per month. Note the specified delay times in each line that help prevent these jobs from overlapping themselves and other cron jobs.

Instead of placing complete Bash programs in the cron.X directories, I install them in the /usr/local/bin directory, which allows me to run them easily from the command line. Then I add a symlink in the appropriate cron directory, such as /etc/cron.daily.

The anacron program is not designed to run programs at specific times. Rather, it is intended to run programs at intervals that begin at the specified times, such as 3 a.m. (see the START_HOURS_RANGE line in the script just above) of each day, on Sunday (to begin the week), and on the first day of the month. If any one or more cycles are missed, anacron will run the missed jobs once, as soon as possible.

Shortcuts

The /etc/anacrontab file shown above shows us a clue to how we can use shortcuts for a few specific and common times. These single-word time shortcuts can be used to replace the five fields usually used to specify times. The @ character is used to identify shortcuts to cron. The list below, taken from the crontab(5) man page, shows the shortcuts with their equivalent meanings.

• @reboot : Run once after reboot.
• @yearly : Run once a year, ie. 0 0 1 1 *
• @annually : Run once a year, ie. 0 0 1 1 *
• @monthly : Run once a month, ie. 0 0 1 * *
• @weekly : Run once a week, ie. 0 0 * * 0
• @daily : Run once a day, ie. 0 0 * * *
• @hourly : Run once an hour, ie. 0 * * * *

These shortcuts can be used in any of the crontab files, such as those in /etc/cron.d.

More on setting limits

I use most of these methods for scheduling tasks to run on my computers. All those tasks are ones that need to run with root privileges. It's rare in my experience that regular users really need a cron job. One case was a developer user who needed a cron job to kick off a daily compile in a development lab.

It is important to restrict access to cron functions by non-root users. However, there are circumstances when a user needs to set a task to run at pre-specified times, and cron can allow them to do that. Many users do not understand how to properly configure these tasks using cron and they make mistakes. Those mistakes may be harmless, but, more often than not, they can cause problems. By setting functional policies that cause users to interact with the sysadmin, individual cron jobs are much less likely to interfere with other users and other system functions.

It is possible to set limits on the total resources that can be allocated to individual users or groups, but that is an article for another time.

For more information, the man pages for cron, crontab, anacron, anacrontab, and run-parts all have excellent information and descriptions of how the cron system works.

The /etc/hosts file

 As your machine gets started, it will need to know the mapping of some hostnames to IP addresses before DNS can be referenced. This mapping is kept in the /etc/hosts file. In the absence of a name server, any network program on your system consults this file to determine the IP address that corresponds to a host name.

Following is a sample /etc/hosts file:

IPAddress Hostname Alias 127.0.0.1 localhost deep.openna.com 208.164.186.1 deep.openna.com deep 208.164.186.2 mail.openna.com mail 208.164.186.3 web.openna.com web

The leftmost column is the IP address to be resolved. The next column is that host's name. Any subsequent columns are alias for that host. In the second line, for example, the IP address 208.164.186.1 is for the host deep.openna.com. Another name for deep.openna.com is deep.

After you are finished configuring your networking files, don't forget to restart your network for the changes to take effect.

[root@deep] /# /etc/rc.d/init.d/network restart

Setting network parameters [ OK ] Bringing up interface lo [ OK ] Bringing up interface eth0 [ OK ] Bringing up interface eth1 [ OK ]

How To Run Windows Applications On Linux [Beginners Guide] wine

https://itsfoss.com/use-windows-applications-linux/

As you’re here, I’m going to assume that you’re a Linux user. And every once in a while, you find yourself asking: can I run windows applications on Linux?.

Answer to that question is yes. Yes, you can run Windows applications in Linux. Here are some of the ways for running Windows programs with Linux:

• Installing Windows on a separate HDD partition
• Installing Windows as a virtual machine on Linux

Both of them works just fine. But they are somewhat resource hungry.

If you only need to use a small Windows application, installing Windows on a separate HDD partition or as a Virtual Machine is not efficient. Moreover, Virtual Machine can’t utilize the total power of your machine. So, what is the solution?

No worries, there is another way to use Windows software on Linux. It’s called Wine. If you aren’t yet familiar with it or you are a beginner in the world of Linux, this article is for you.

In this beginner’s guide, I’ll show you what is Wine and how to use it to run Windows software on Linux. I have used Ubuntu here as Ubuntu is one of the best Linux distros for beginners, but any other Linux distribution will have more or less same steps (except for the commands in Arch or Fedora based distros).

Using Wine to run Windows programs in Linux

Wine stands for Wine Is Not an Emulator. And WINE is actually an acronym for that. And as previously stated, it’s not even a virtual machine.

Rather it is a compatibility layer for running Windows applications on UNIX-like or POSIX-compliant operating systems (e.g. Linux, Mac, BSD). While a virtual machine or emulator simulates internal Windows logic, Wine translates those Windows logic to native UNIX/POSIX-complaint logic.

In simple and non-technical words, Wine converts internal Windows commands to commands your Linux system can natively understand.

Installing Wine

There are various ways to install Wine on your system. As this is a beginners’ guide, I’ll describe the most straightforward one here.

Almost all the Linux distros come with Wine in their package repository. Most of the time the latest stable version of Wine is available via package repository. Installing Wine on Ubuntu is as easy as firing up a terminal and running these commands:

sudo apt update
sudo apt install wine

However, if you are using an 64bit installation of Ubuntu, you will need to run these additional commands:

sudo dpkg --add-architecture i386

This will add 32bit architecture support on your distro which will benefit you in installing specific software. If you don’t know whether you have a 32bit installation or 64bit, check this article: 32bit or 64bit Ubuntu?

What Windows applications are Supported by Wine?

There is a large number of Windows applications that are currently fully supported by Wine. They will run without any hassle.

However, new Windows applications are being developed every day. Many of them wouldn’t function as we want on Wine. But the development pace of Wine is also rapid, support for new applications is being added all the time.

And there is a dedicated database for keeping track of just that.

Wine Application Database has almost 24,000 applications rated with different status depending upon how well that applications run in Wine. If you want to quickly check the rating of the application you want to use in Wine, you can take a look there. Here are the meaning of those ratings:

• Platinum: These applications install and run flawlessly in out-of-the-box Wine.
• Gold: These applications work flawlessly with some special configuration.
• Silver: Applications with minor issues are tagged as Silver.
• Bronze: The Bronze ones have major issues that seriously affect usage.
• Garbage: These simply won’t run on Wine.

Reviews, Installation Procedure, which Wine version it was tested against and various useful data are also available for each application here.

Of course, Wine Application Database is mostly user-generated data, so you are always welcome to try running an application with a different version of Wine and share your result with rest of the community.

Finding an Application in Wine Application Database

Let’s see how we can find an application in Wine Application Database.

Go to Wine Application Database. Click Browse Apps from the left sidebar.

Finding an App in Wine AppDB

Write the name of the application you want to find in the Name field.

Wine AppDB name filter

Click on the link to the application from the search result.

You’ll see a description of the application. There will be a list of various versions with their compatibility rating with a specific Wine version.

Wine AppDB Application page

Let’s click on the latest version link.

This is the main page you need to check. There will be detailed information about that specific version.

Detailed Information about Application

You’ll get an idea of what will work and what will not. Also, the installation procedure will be included here if any additional tasks are needed for installation.

Getting Started with Wine

Before we go on installing and running applications in Wine, we should have clear idea about a few things and about how to configure Wine for usage:

WinePrefix

Windows applications need a C: drive. Wine uses a virtual C: drive for this purpose. The directory of this virtual C: drive is called wineprefix. First of all, we need to create a wineprefix. For doing that, fire up a terminal and enter this command:

winecfg

This will create a wineprefix and open the configuration window for Wine. You can change the configuration options if you want or let it be as is for time being and close it. Now, you can locate the virtual C: drive at

$HOME/.wine/c_drive

WinePrefix C: Drive

The general rule is to install each new application into a fresh wineprefix. We can create and maintain multiple wineprefix manually. But that task would seem rather tedious for the beginners. So, we will skip that part for now. But, later I’m going to show the way for doing that part with ease.

Installing an Application with Wine

Installing a supported application in Wine is generally as easy as double-clicking on the installation file. However, we are now going to see a step-by-step guide for installing 7-zip on Wine.

First of all, check for 7-zip rating on Wine Application Database. It has Platinum rating, so we are good to go. Open Wine configuration ( winecfg ) and set the Windows Version to Windows 7.

Wine Windows 7

Right-click on the 7-zip installation file and select Open With Wine Windows Program Loader.

7-zip Installation File

See that destination folder path? 7-zip installation has recognized the virtual C: drive from wineprefix.

7-zip Setup Directory on Wine

Finish the installation and go to the installation directory [ $HOME/.wine/drive_c/Program Files/7-zip/ ] from the file browser.

Right-click on 7zFM.exe and go to Properties > Open With.

Set Default .exe Loader

Select Wine Windows Program Loader and close the window. Double-click on 7zFM.exe.

7-zip running with Wine

And there you go! For creating a shortcut on your desktop, right click on the file.

Creating 7-zip shortcut

Now move the Link to Desktop.

Move shortcut to Desktop

Now, you can run 7-zip just from your desktop. All you have to do is double-click on the icon.

Run 7-zip from desktop

If you want to access your files on Linux, they are generally located in Z: Drive.

Linux directory in Z: drive

You can use the 7-zip just as you would use it on Windows – for extracting and creating archives and such.

Let’s make things (a lot) Easier

You might have noticed that, at Wine Application Database, with every version of application review a specific Wine version is mentioned.

It is because of the rapid development rate of Wine. Though an application runs with the current version of Wine, it might not run with a future version, because of the changes made.

Also, I’ve mentioned about installing each application in its own fresh wineprefix. So that, an application has no chance of interfering with another. And doing all these manually, usually from the terminal, is time-consuming, tiresome and at times, confusing.

PlayOnLinux is here to rescue. It provides a nice interface for doing all these things easily. For installing PlayOnLinux on Ubuntu, simply run this command:

sudo apt install playonlinux

PlayOnLinux interface

You can easily perform every task related to Wine with PlayOnLinux from a beautiful and intuitive graphical interface:

• Installing & Uninstalling applications.
• Creating, Updating & Removing wineprefixes.
• Maintain Wine of different architecture and versions.
• Run & Create shortcut for installed applications.
• And so on…

But still, you will need to check Wine Application Database for reviews, installation procedures and such.

Advantages of using Wine

When it comes to running Windows applications on Linux system, Wine provides many advantages over using emulators or virtual machines.

• Performance: Wine is immune to the performance loss that otherwise occurs while emulating.
• Native Experience: There is no need to open Wine before running a Windows application. Exactly how Wine works will be more clear from this quote from official site,
  

  Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode.

Wine Derivatives

There are quite a number of projects for running Windows applications on other platforms, based on Wine:

• CrossOver: CrossOver is a developed by the company named CodeWeavers. It is directly based on Wine with a few tweaks and proprietary add-ons. In fact, CodeWeavers employs a large portion of Wine developers. Unlike the rapid releases of Wine, CrossOver releases are more stable. The one and major downside is that Crossover is not free.
• PlayOnLinux: PlayOnLinux is completely based on Wine. And provides easier route for installing and managing application with Wine. PlayOnLinux is free.
  It is also available for Mac as PlayOnMac.
• ReactOS: ReactOS is an entirely different open-source operating system for running Windows applications. It reuses a considerable amount of codes from Wine. However, this is a project under development for more than a decade and I won’t recommend it.

Additional Tips on using Wine

Winetricks

This is another important part of using Wine. Winetricks is a helper script to download and install various redistributable runtime libraries needed to run some applications in Wine. These may include replacements for components of Wine using closed source libraries. Winetricks comes with Wine installation on Ubuntu.

For starting winetricks, run this command:

winetricks

Winetricks

There are many options for helping you with various tasks.

Installing an Application with Winetricks

If you Install an app from winetricks, it will be installed in a separate wineprefix. Let’s install VLC:

Winetricks – Install an app

Winetricks – Install VLC

It will then begin to download the VLC installation files. And then guide you through the rest of the process. It’s pretty simple.

Install Windows DLL or components and others

You can select a wineprefix from winetricks and install various libraries and components required by the application you want to run and also perform other operations.

Winetricks Scripts

Winetricks Libraries & Components

N.B.: If using winetricks seems complicated to you, it’s perfectly okay. I feel the same way too. I always use PlayOnLinux for this reason. PlayOnLinux can do everything you might need to do from winetricks.

For more information you can check Wine FAQ and Documentation.

I hope you find this complete beginner’s guide to using Wine in Linux helpful. Now you can run Windows programs in Linux without installing a virtual machine or dual booting.

Let us know if you have any questions or opinion in the comment section below.