Lots of great advice above.
- Use a virtual machine for the first few months
- Only install software through the Ubuntu Repos, never download files to be installed directly. That includes .deb files, at least until you gain necessary background and skills to understand breakage.
- NEVER download drivers directly from any vendor. Stick with those built-into the Canonical Repos, unless an expert tells you something different.
- Dual boot can be a hassle and MSFT breaks booting other OSes about once a year.
- If your hardware is really new, beware. That's the bleeding edge in Linux and difficult. Drivers may not exist at all or there might be problems for specific drivers on specific kernel versions. Linux desktops are best on a system about 18 - 36 months old.
- If you have a system older than 5 or 10 yrs, it could be that the current "default" desktop will be too heavy. It is very GPU dependent. There are less heavy desktops which run crazy fast on 10 yr old hardware.
- File extensions mean next to nothing to Linux system, but some GUI programs will filter lists of files based on them. It is perfectly valid to have a PDF file that doesn't end in .pdf, for example. Executable files don't actually have any mandatory extensions at all. Humans seem to like extensions, so depending on the humans involved, there may or may not be file extensions. Execute is a permission flag assigned to files and directories at the owner, group and "other" level.
- .rpm files and deb files are packages, but we shouldn't be downloading those directly. .rpm files are typically built for a Redhat-based distro, so the dependencies it specifies inside will follow RH naming, which is slightly different from what Debian/Ubuntu use for package names. Sometimes, there is a 1-to-1 match in the names, but not always. In 3 yrs after you become super-Admin, you can install 1-2 rpm files onto your ubuntu system, probably, and it won't end the world. For my time and effort, it is best not to download any packages to be installed. They will eventually break the package management system, APT on Ubuntu, and make it so the system cannot be patched at all.
Linux package management has had a problem since the beginning. Users can't download a file from a random website, install it safely, and expect it to work perfectly. The Linux OSes move too fast for that, unlike Windows. Every distro release will have a different build of the core libraries which every other program is based on. This means that a .deb package for Ubuntu 16.04 isn't compatible with a .deb file for 18.04 or 20.04 versions of Ubuntu or any Debian version. A number of teams have been trying to solve that problem by making some alternate package formats and tools. The theory is to include all the dependencies in the package which usually means a 32MB program becomes 900MB in size. Basically, it is like on Windows when a program says that MS-DotNet 4.5 is required, but doesn't install it for you. At runtime, that program will use 900MB of RAM to load the code segments. The good thing is that almost always with 18.04 and 20.04, these alternate packages work. In my informal use on 16.04, it is a 50/50 guess whether they will work or not. I have some that don't work on 20.04. Anyways, these "self-contained" packages come in 3 popular file types:
- Ubuntu Snap Packages - aka "snaps"
- Flatpaks
- AppImages
Each has pros/cons. These forums have long discussions about those aspects.
Snaps on your system can be listed using the "snap list" command from any terminal.
Flatpaks have a similar method - flatpak list? I don't know. Never used one.
AppImages usually come as files with a .AppImage extension and can be placed anywhere. Any search tool you like can find them.
In general, all those other package formats are slower and larger than the native .deb packaged version.
If you want to see what a file actually is recognized to contain in the same way as the OS, use the 'file' command.
Code:
$ file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=2f15ad836be3339dec0e2e6a3c637e08e48aacbd, for GNU/Linux 3.2.0, stripped
That is a natively compiled 64-bit program.
Code:
$ file /usr/local/vidcutter-appimage/VidCutter-6.0.0-x64.AppImage
/usr/local/vidcutter-appimage/VidCutter-6.0.0-x64.AppImage: ELF 64-bit LSB executable, x86-64, version 1, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped
Hummm. Thought I was putting all appimages into /usr/local/appimages/. Ok, fixed that. Makes life easier to have them in 1 place for backup reasons.
Anyways, hope this wasn't confusing. Remember, all files and directories are case-sensitive on all Unix systems.
Bookmarks