Oddly useful Linux tools you probably haven't seen before
https://youtu.be/32O0a6qCQaQ
https://redd.it/1nc5q3z
@r_linux
https://youtu.be/32O0a6qCQaQ
https://redd.it/1nc5q3z
@r_linux
YouTube
Oddly useful Linux tools you probably haven't seen before
some Linux utilities, shell noscripts, etc that I've found oddly useful for one reason or another :-)
0:00 https://github.com/cowtoolz/webcamize
1:32 https://github.com/Canop/dysk
2:39 https://github.com/dylanaraps/pure-bash-bible
4:54 https://wiki.archli…
0:00 https://github.com/cowtoolz/webcamize
1:32 https://github.com/Canop/dysk
2:39 https://github.com/dylanaraps/pure-bash-bible
4:54 https://wiki.archli…
Why Linux has a scattered file system: a deep dive
I've seen a lot of Windows users who have given Linux a shot be confused, annoyed or generally critical of the fact that Windows has a scattered file system where a package will generally install stuff "all over the place" instead of in a simple neat directory. Ideally, programs install their static files: .exe's, .dll's and resources; in `C:\Program Files` , user files in `%APPDATA%` and some small global config in the registry. It's a little more complicated in practice, but that's generally the gist of it. This system does have some advantages. It makes it really easy for a particular program to be installed on a different drive for example. So it does make sense why Windows users would be taken aback by the scattered file system of Linux, where programs have files seemingly all over the place.
And so I wanted to make this post to outline what all of the directories in the Linux file system are, why they exist, and what advantages this design has over "one program <-> one package" design. It should hopefully also serve as an overview for new Linux users looking to learn more about their system. At least, it will be a post I can link to others if I ever need it.
**Chapter I -- what's in** `/`
**Chapter Ia -- system file directories**
These are directories where system files live.
In the traditional Linux view, the "system" basically means "your package manager". So this includes the core system components and programs installed through your package manager (be it apt on Debian/Ubuntu, dnf on RHEL/Fedora or pacman on Arch). There is no difference real between "system files" and "program files" on Linux when the programs are installed as packages. The "base" system, the one you get right after install, is just a bunch of packages, with many "spins" (Fedora KDE, Xubuntu etc.) basically being just different sets of packages to install as base.
Users do not generally do not write files here, but they read or execute them all the time -- programs, fonts, etc.
The directories are:
* `/usr` \-- static files (binaries, libraries, resources, fonts, etc.)
* `/var` \-- dynamic files (logs, databases, etc.)
* `/etc` \-- configuration files
* `/boot` \-- boot files
The reason these are all different directories? Well, you might want to put each of them on different partitions, or only some of them, or have all of them on the same partition, depending on your use case.
For example, you may want to mount `/usr` and/or `/etc` as read only after configuring your system to harden it. You may want to share `/etc` around multiple systems that should be configured identically. You may want to only backup `/etc` and `/var` since `/usr` and `/boot` can be easily recreated by the package manager.
These are not only theoretical use cases. The desktop distro I use is a version of Fedora Immutable, in which `/usr` is mounted as read-only, `/var` is mounted as read-write and `/etc` is mounted as an overlay filesystem, allowing me to modify it, but also allowing me to view what changes I made to system configuration and easily revert if needed.
`/boot` is kept separate because it sometimes needs to be separate, but not always. A use case for this (not the only one) is what I use: most of my disk is encrypted, so `/boot` is a separate, unencrypted partition, so the kernel can launch from there and decrypt the rest of my disk after asking me for the password.
**Chapter Ib -- user file directories**
These are the directories where users can store files and the package manager will not touch (but other system utilities may touch).
These directories are:
* `/home` \-- the home directories of users
* `/root` \-- the home directory of the root user (the administrator account)
* `/srv` \-- files to be served
These are pretty self-explanatory. `/root` is not a sub-directory of home because it's actually more something between a system directory and a user directory. Package managers will sometimes touch it.
Moreover, if you have a bunch of Linux servers that share user lists and have
I've seen a lot of Windows users who have given Linux a shot be confused, annoyed or generally critical of the fact that Windows has a scattered file system where a package will generally install stuff "all over the place" instead of in a simple neat directory. Ideally, programs install their static files: .exe's, .dll's and resources; in `C:\Program Files` , user files in `%APPDATA%` and some small global config in the registry. It's a little more complicated in practice, but that's generally the gist of it. This system does have some advantages. It makes it really easy for a particular program to be installed on a different drive for example. So it does make sense why Windows users would be taken aback by the scattered file system of Linux, where programs have files seemingly all over the place.
And so I wanted to make this post to outline what all of the directories in the Linux file system are, why they exist, and what advantages this design has over "one program <-> one package" design. It should hopefully also serve as an overview for new Linux users looking to learn more about their system. At least, it will be a post I can link to others if I ever need it.
**Chapter I -- what's in** `/`
**Chapter Ia -- system file directories**
These are directories where system files live.
In the traditional Linux view, the "system" basically means "your package manager". So this includes the core system components and programs installed through your package manager (be it apt on Debian/Ubuntu, dnf on RHEL/Fedora or pacman on Arch). There is no difference real between "system files" and "program files" on Linux when the programs are installed as packages. The "base" system, the one you get right after install, is just a bunch of packages, with many "spins" (Fedora KDE, Xubuntu etc.) basically being just different sets of packages to install as base.
Users do not generally do not write files here, but they read or execute them all the time -- programs, fonts, etc.
The directories are:
* `/usr` \-- static files (binaries, libraries, resources, fonts, etc.)
* `/var` \-- dynamic files (logs, databases, etc.)
* `/etc` \-- configuration files
* `/boot` \-- boot files
The reason these are all different directories? Well, you might want to put each of them on different partitions, or only some of them, or have all of them on the same partition, depending on your use case.
For example, you may want to mount `/usr` and/or `/etc` as read only after configuring your system to harden it. You may want to share `/etc` around multiple systems that should be configured identically. You may want to only backup `/etc` and `/var` since `/usr` and `/boot` can be easily recreated by the package manager.
These are not only theoretical use cases. The desktop distro I use is a version of Fedora Immutable, in which `/usr` is mounted as read-only, `/var` is mounted as read-write and `/etc` is mounted as an overlay filesystem, allowing me to modify it, but also allowing me to view what changes I made to system configuration and easily revert if needed.
`/boot` is kept separate because it sometimes needs to be separate, but not always. A use case for this (not the only one) is what I use: most of my disk is encrypted, so `/boot` is a separate, unencrypted partition, so the kernel can launch from there and decrypt the rest of my disk after asking me for the password.
**Chapter Ib -- user file directories**
These are the directories where users can store files and the package manager will not touch (but other system utilities may touch).
These directories are:
* `/home` \-- the home directories of users
* `/root` \-- the home directory of the root user (the administrator account)
* `/srv` \-- files to be served
These are pretty self-explanatory. `/root` is not a sub-directory of home because it's actually more something between a system directory and a user directory. Package managers will sometimes touch it.
Moreover, if you have a bunch of Linux servers that share user lists and have
`/home` mounted on the network (allowing the user to log into any server and see their files), the `/root` home should still be per-server.
`/srv` is just a convenient place to store files, such as those shared via FTP, HTTP, or any other files you need to store that is not just "a user's files". It's entirely unstructured. No tools that I know of create directories here without being told to, so it's a nice place to just put stuff on a server. Not very useful on a desktop.
**Chapter Ic -- temporary mount points**
These are mostly empty directories (or directories of empty directories) made for mounting partitions, removable drives, .ios's etc. that would not make sense anywhere else in a filesystem -- usually temporarily
These directories are:
* `/mnt` \-- for manual mounting
* `/media` \-- for automatic mounting of removable media
You generally do not need to worry about `/mnt` unless you are doing some command line work. Same for `/media`, if you just insert a USB stick, it'll be mounted here, but you'll also get a GUI icon to click on that will take you here, you don't generally have to manually navigate here.
**Chapter Id -- virtual file systems**
These are directories who's contents don't "actually exist" (on disk). One of Linux's great strengths, especially from a developer perspective, is that everything is a file, be it a real one on disk, or a virtual one. Programs that can write to a file, can also write to virtual files, be they disks, terminal windows or device control files.
These directories are:
* `/run` and `/tmp` \-- temporary files stored in RAM
* `/proc` and `/sys` \-- low level process and system information respectively
* `/dev` \-- device files
Now, you can safely ignore `/proc` and `/sys` as a regular user. When you open the GUI ~~Task Manager~~ System Monitor, the GUI System Monitor will read from these places, but you don't need to do so manually.
The `/run` and `/tmp` files are in-RAM places for temporary files. The reason there are two is historical and I won't go into it.
`/dev` is where all of the devices are represented. You will be exposed to this when you, for example, flash a USB stick, and the flashing utility will allow you to select `/dev/sdb` (SATA drive B) to flash to. Hopefully, you will also get a user-friendly name ("Kingston DataTraveller 32GB) next to it.
**Chapter Ie -- the** `/opt` **directory**
There are some cases where programs do want to be installed in a Program Files manner with a huge directory of stuff. This is either stuff that was lazily ported, or stuff with a lot of data (100GB Vivado installs).
This is what the `/opt` directory is for.
The package manager will generally not touch it, but graphical installers of proprietary software may default to this place.
In the case of large installs, it also makes it easier to put some of the sub-directories of `/opt`, or the entire thing, on a separate drive/partition. It also allows large installs to be networked mounted, in the case of many small computers using proprietary software from a local NFS server.
**Chapter II -- the structure of** `/usr`
**Chapter IIa -- the useful sub-directories of** `/usr` **that will always be there**
These directories are:
* `/usr/bin` \-- executable meant to be run by users
* `/usr/lib` \-- shared libraries (dll's) (see bellow)
* `/usr/share` \-- non-executable resource files
The reason libraries are all together is that each binary is generally dynamically linked, so if the same library is used by 10 different executables, it exists only once in the system.
The reason binaries are all together is so that the shell can search in one place for all of them.
**Chapter IIb -- the less useful or situational sub-directories of** `/usr` **that will usually always be there**
These directories are:
* `/usr/src` \-- sources for packages on the system, generally installed by special `*-src` packages, usually empty or almost empty
* `/usr/include` \-- stuff for C programming. Should arguably be a sub-directory to `/usr/share`, but hey, C is the big daddy and gets special
`/srv` is just a convenient place to store files, such as those shared via FTP, HTTP, or any other files you need to store that is not just "a user's files". It's entirely unstructured. No tools that I know of create directories here without being told to, so it's a nice place to just put stuff on a server. Not very useful on a desktop.
**Chapter Ic -- temporary mount points**
These are mostly empty directories (or directories of empty directories) made for mounting partitions, removable drives, .ios's etc. that would not make sense anywhere else in a filesystem -- usually temporarily
These directories are:
* `/mnt` \-- for manual mounting
* `/media` \-- for automatic mounting of removable media
You generally do not need to worry about `/mnt` unless you are doing some command line work. Same for `/media`, if you just insert a USB stick, it'll be mounted here, but you'll also get a GUI icon to click on that will take you here, you don't generally have to manually navigate here.
**Chapter Id -- virtual file systems**
These are directories who's contents don't "actually exist" (on disk). One of Linux's great strengths, especially from a developer perspective, is that everything is a file, be it a real one on disk, or a virtual one. Programs that can write to a file, can also write to virtual files, be they disks, terminal windows or device control files.
These directories are:
* `/run` and `/tmp` \-- temporary files stored in RAM
* `/proc` and `/sys` \-- low level process and system information respectively
* `/dev` \-- device files
Now, you can safely ignore `/proc` and `/sys` as a regular user. When you open the GUI ~~Task Manager~~ System Monitor, the GUI System Monitor will read from these places, but you don't need to do so manually.
The `/run` and `/tmp` files are in-RAM places for temporary files. The reason there are two is historical and I won't go into it.
`/dev` is where all of the devices are represented. You will be exposed to this when you, for example, flash a USB stick, and the flashing utility will allow you to select `/dev/sdb` (SATA drive B) to flash to. Hopefully, you will also get a user-friendly name ("Kingston DataTraveller 32GB) next to it.
**Chapter Ie -- the** `/opt` **directory**
There are some cases where programs do want to be installed in a Program Files manner with a huge directory of stuff. This is either stuff that was lazily ported, or stuff with a lot of data (100GB Vivado installs).
This is what the `/opt` directory is for.
The package manager will generally not touch it, but graphical installers of proprietary software may default to this place.
In the case of large installs, it also makes it easier to put some of the sub-directories of `/opt`, or the entire thing, on a separate drive/partition. It also allows large installs to be networked mounted, in the case of many small computers using proprietary software from a local NFS server.
**Chapter II -- the structure of** `/usr`
**Chapter IIa -- the useful sub-directories of** `/usr` **that will always be there**
These directories are:
* `/usr/bin` \-- executable meant to be run by users
* `/usr/lib` \-- shared libraries (dll's) (see bellow)
* `/usr/share` \-- non-executable resource files
The reason libraries are all together is that each binary is generally dynamically linked, so if the same library is used by 10 different executables, it exists only once in the system.
The reason binaries are all together is so that the shell can search in one place for all of them.
**Chapter IIb -- the less useful or situational sub-directories of** `/usr` **that will usually always be there**
These directories are:
* `/usr/src` \-- sources for packages on the system, generally installed by special `*-src` packages, usually empty or almost empty
* `/usr/include` \-- stuff for C programming. Should arguably be a sub-directory to `/usr/share`, but hey, C is the big daddy and gets special
privileges
* `/usr/games` \-- name is self explanatory. No, this directory is not used today. It's a relic.
**Chapter IIc -- the** `/usr/lib` **debacle**
`/usr/lib` is meant to hold shared libraries (32-bit and 64-bit if multilib is supported) and also "executable resources" of packages. The major distros do not agree on where to put each of these things.
On Debian/Ubuntu we have:
* `/usr/lib/<package>` \-- executable resources not meant to be run directly by users
* `/usr/lib/x86_64-linux-gnu` \-- 64-bit libraries
* `/usr/lib/i686-linunx-gnu` \-- 32-bit libraries
On Red Hat/Fedora we have:
* `/usr/lib` \-- 32-bit libraries
* `/usr/lib64` \-- 64-bit libraries
* `/usr/libexec` \-- executable resources not meant to be run directly by users
On Arch we have:
* `/usr/lib` \-- 64-bit libraries
* `/usr/lib32` \-- 32-bit libraries
* `/usr/libexec` \-- executable resources not meant to be run directly by users
**Chapter IId -- the** `/usr/sbin` **debacle**
`/usr/sbin` is a directory meant for binaries that are not meant to be run by users, but only by administrators and such. It's kind of a relic of the past, and Fedora has moved to replace `/usr/sbin` with a link to `/usr/bin` (it's that way on my system)
**Chapter IIe -- the** `/bin`/`/lib` **debacle**
Back in the olden days, there used to be a difference between the core system that lived on `/` and the fat system that lived on `/usr`. This is a relic of the past. For backwards compatibility, the following links exist:
* `/bin -> /usr/bin`
* `/sbin -> /usr/sbin`
* `/lib -> /usr/lib`
* `/libexec -> /usr/libexec` (on Red Hat/Fedora and Arch)
* `/lib64 -> /usr/lib64` (on Red Hat/Fedora)
* `/lib32 -> /usr/lib32` (on Arch)
**Chapter IIf --** `/usr/local`
A copy of all the directories described above exist under `/usr/local` (eg. `/usr/local/bin`, `/usr/local/lib`). This exists for packages that maintain the standard bin, lib, share structure, so would not fit in /opt. but are installed by the admin user manually and not through the package manager.
This is to avoid conflicts and unwanted overwrites. Most source packages (eg. what you find on GitHub) default to installing here after compilation.
**Chapter III -- the structure of** `~`
**Chapter IIIa -- the wild wild** `.west`
Programs need to store per-user data and they will generally do this in the user's home. This is `/home/bob`, `$HOME` or just `~`.
Now, back in the olden days they did this with no real structure. In Linux, directories that start with a dot are "hidden", so they would just throw some directory in the home and store everything there: `~/.vim`, `~/.steam`, `~/.ssh`, etc.
**Chapter IIIb -- the XDG directory system**
Recently, an effort has been made to standardize the places programs put user files. This system mirrors the system hierarchy, but uses more modern naming for things.
* `~/.local/share` \-- equivalent to `/usr/share`
* `~/.local/state` \-- partially equivalent to `/var`; for program state
* `~/.local/bin` \-- equivalent to `/usr/bin`
* `~/.config` \-- equivalent to `/etc`
* `~/.cache` \-- partially equivalent to `/var`; for temporary files too big to store in RAM
* `/run/user/<uid>` \-- in RAM temporary files
More details [here](https://specifications.freedesktop.org/basedir-spec/latest/).
**Chapter IIIc -- flatpaks**
Flatpaks are containerized desktop apps. Flatpak stores it's data in `~/.var`
https://redd.it/1nc40h2
@r_linux
* `/usr/games` \-- name is self explanatory. No, this directory is not used today. It's a relic.
**Chapter IIc -- the** `/usr/lib` **debacle**
`/usr/lib` is meant to hold shared libraries (32-bit and 64-bit if multilib is supported) and also "executable resources" of packages. The major distros do not agree on where to put each of these things.
On Debian/Ubuntu we have:
* `/usr/lib/<package>` \-- executable resources not meant to be run directly by users
* `/usr/lib/x86_64-linux-gnu` \-- 64-bit libraries
* `/usr/lib/i686-linunx-gnu` \-- 32-bit libraries
On Red Hat/Fedora we have:
* `/usr/lib` \-- 32-bit libraries
* `/usr/lib64` \-- 64-bit libraries
* `/usr/libexec` \-- executable resources not meant to be run directly by users
On Arch we have:
* `/usr/lib` \-- 64-bit libraries
* `/usr/lib32` \-- 32-bit libraries
* `/usr/libexec` \-- executable resources not meant to be run directly by users
**Chapter IId -- the** `/usr/sbin` **debacle**
`/usr/sbin` is a directory meant for binaries that are not meant to be run by users, but only by administrators and such. It's kind of a relic of the past, and Fedora has moved to replace `/usr/sbin` with a link to `/usr/bin` (it's that way on my system)
**Chapter IIe -- the** `/bin`/`/lib` **debacle**
Back in the olden days, there used to be a difference between the core system that lived on `/` and the fat system that lived on `/usr`. This is a relic of the past. For backwards compatibility, the following links exist:
* `/bin -> /usr/bin`
* `/sbin -> /usr/sbin`
* `/lib -> /usr/lib`
* `/libexec -> /usr/libexec` (on Red Hat/Fedora and Arch)
* `/lib64 -> /usr/lib64` (on Red Hat/Fedora)
* `/lib32 -> /usr/lib32` (on Arch)
**Chapter IIf --** `/usr/local`
A copy of all the directories described above exist under `/usr/local` (eg. `/usr/local/bin`, `/usr/local/lib`). This exists for packages that maintain the standard bin, lib, share structure, so would not fit in /opt. but are installed by the admin user manually and not through the package manager.
This is to avoid conflicts and unwanted overwrites. Most source packages (eg. what you find on GitHub) default to installing here after compilation.
**Chapter III -- the structure of** `~`
**Chapter IIIa -- the wild wild** `.west`
Programs need to store per-user data and they will generally do this in the user's home. This is `/home/bob`, `$HOME` or just `~`.
Now, back in the olden days they did this with no real structure. In Linux, directories that start with a dot are "hidden", so they would just throw some directory in the home and store everything there: `~/.vim`, `~/.steam`, `~/.ssh`, etc.
**Chapter IIIb -- the XDG directory system**
Recently, an effort has been made to standardize the places programs put user files. This system mirrors the system hierarchy, but uses more modern naming for things.
* `~/.local/share` \-- equivalent to `/usr/share`
* `~/.local/state` \-- partially equivalent to `/var`; for program state
* `~/.local/bin` \-- equivalent to `/usr/bin`
* `~/.config` \-- equivalent to `/etc`
* `~/.cache` \-- partially equivalent to `/var`; for temporary files too big to store in RAM
* `/run/user/<uid>` \-- in RAM temporary files
More details [here](https://specifications.freedesktop.org/basedir-spec/latest/).
**Chapter IIIc -- flatpaks**
Flatpaks are containerized desktop apps. Flatpak stores it's data in `~/.var`
https://redd.it/1nc40h2
@r_linux
specifications.freedesktop.org
XDG Base Directory Specification
1 Introduction # Various specifications specify files and file formats. This specification defines where these files should be looked for by defining one or more base directories relative to which files should be located. 2 Basics # The XDG Base Directory…
Linux Gaming is Much Better on AMD Radeon..
https://youtu.be/6wxT6D0lYk4?feature=shared
https://redd.it/1ncbt49
@r_linux
https://youtu.be/6wxT6D0lYk4?feature=shared
https://redd.it/1ncbt49
@r_linux
YouTube
Linux Gaming is Much Better on AMD Radeon..
Find the eGPU on Amazon : https://lon.tv/z79bq and the PC: https://lon.tv/4eil5 (compensated affiliate links) - In a follow-up to my last gaming on Linux video, I take a look at performance using an AMD GPU vs. the Nvidia GPU we tried in our last video.…
Autocad on Linux
Is there any way to use CAD tools on Linux??? The CAD tools available for Linux are really bad. I’m a civil engineer and I use Linux for some personal projects, but I rely on Windows for professional tools like AutoCAD and ACCA Edificius. I’ve tried using only Ubuntu, but having to create a virtual machine just to run these tools defeats the purpose of using Ubuntu.
https://redd.it/1ncwz77
@r_linux
Is there any way to use CAD tools on Linux??? The CAD tools available for Linux are really bad. I’m a civil engineer and I use Linux for some personal projects, but I rely on Windows for professional tools like AutoCAD and ACCA Edificius. I’ve tried using only Ubuntu, but having to create a virtual machine just to run these tools defeats the purpose of using Ubuntu.
https://redd.it/1ncwz77
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Best Barebones Linux OS
I'm looking for a barebones Linux OS that isn't heavy on RAM or CPU. All I need to do is update the OS, move some files on a USB that I plug in irregularly, and open one tab on a web browser so I can remote in to my home server that have a desktop OS on it. What would y’all recommend and why? Give me some info on why you recommend the particular flavor.
Computer details:
2010’s Toshiba Satellite C655-S5195
i3 processor, 8 GB of RAM, 250 GB Storage
https://redd.it/1nd2rcu
@r_linux
I'm looking for a barebones Linux OS that isn't heavy on RAM or CPU. All I need to do is update the OS, move some files on a USB that I plug in irregularly, and open one tab on a web browser so I can remote in to my home server that have a desktop OS on it. What would y’all recommend and why? Give me some info on why you recommend the particular flavor.
Computer details:
2010’s Toshiba Satellite C655-S5195
i3 processor, 8 GB of RAM, 250 GB Storage
https://redd.it/1nd2rcu
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Arch package man - checkpac - command line package checker update
https://github.com/zeroz41/checkpac
AUR install : https://aur.archlinux.org/packages/checkpac
Let me know if this is too pacman/arch specific. but i really wanted to share the package tool i've been working on to the broader community.******** -also posted this in r/archlinux
This is a new software release i wanted to share.
==================================================================================
Hey all, I have just added some updates to a useful tool to both just lookup what current packages you have via keyword, denoscription or exact match. It also can tell you if it is behind remote version for both AUR and ARCH official repos. It uses lightning fast lookup and does not rely on your package cache slowly.
(shows current version vs remote version and color codes if out of date)
Search locally or remote dirs with -r flag, search for denoscriptions as well via -d flag, or exactly match package names via -e flag. Mixing and matching of flags is allowed!
It's as easy as "checkpac nvidia" to list all locally installed packages with nvidia in the name.
OR "checkpac -r nvidia" to see what else is available on both arch remote and aur remote.
You can also specify multiple searches at once. "checkpac nvidia wine"
New 0.9.4 features:
I've added integration testing to actually test lookup speed via noscript before release and test combination of arguments to make sure they work. some things weren't quite there last release. Fixed multiterm speed and performance.
0.9.5 hotfix:
just fixed a slight issue to make sure my reddit thread goes well!
\--------------------------------------------------------------------------------------------------------------
Please see my github link for more usage examples and for how nice it looks on command line!
Hope you guys like it, please give it a try. I find it convenient personally
https://redd.it/1nd3iqa
@r_linux
https://github.com/zeroz41/checkpac
AUR install : https://aur.archlinux.org/packages/checkpac
Let me know if this is too pacman/arch specific. but i really wanted to share the package tool i've been working on to the broader community.******** -also posted this in r/archlinux
This is a new software release i wanted to share.
==================================================================================
Hey all, I have just added some updates to a useful tool to both just lookup what current packages you have via keyword, denoscription or exact match. It also can tell you if it is behind remote version for both AUR and ARCH official repos. It uses lightning fast lookup and does not rely on your package cache slowly.
(shows current version vs remote version and color codes if out of date)
Search locally or remote dirs with -r flag, search for denoscriptions as well via -d flag, or exactly match package names via -e flag. Mixing and matching of flags is allowed!
It's as easy as "checkpac nvidia" to list all locally installed packages with nvidia in the name.
OR "checkpac -r nvidia" to see what else is available on both arch remote and aur remote.
You can also specify multiple searches at once. "checkpac nvidia wine"
New 0.9.4 features:
I've added integration testing to actually test lookup speed via noscript before release and test combination of arguments to make sure they work. some things weren't quite there last release. Fixed multiterm speed and performance.
0.9.5 hotfix:
just fixed a slight issue to make sure my reddit thread goes well!
\--------------------------------------------------------------------------------------------------------------
Please see my github link for more usage examples and for how nice it looks on command line!
Hope you guys like it, please give it a try. I find it convenient personally
https://redd.it/1nd3iqa
@r_linux
GitHub
GitHub - zeroz41/checkpac: Arch Linux tool to check pacman and aur installed packages
Arch Linux tool to check pacman and aur installed packages - zeroz41/checkpac
Is Linux viable for engineering software?
I recently bought a Huawei Matebook 14 and windows on laptop is generally disgusting and bloated, I want to download Linux on my machine but most people are saying that software that I will need as a mechanical engineer such as: Ansys, CAD, Comsol, Matlab etc. Will not work well on Linux and this is why I need windows.
Does windows actually have better compatibility with this software because most of them support Linux.
So do I stick with windows or install Linux?
https://redd.it/1nd6b5c
@r_linux
I recently bought a Huawei Matebook 14 and windows on laptop is generally disgusting and bloated, I want to download Linux on my machine but most people are saying that software that I will need as a mechanical engineer such as: Ansys, CAD, Comsol, Matlab etc. Will not work well on Linux and this is why I need windows.
Does windows actually have better compatibility with this software because most of them support Linux.
So do I stick with windows or install Linux?
https://redd.it/1nd6b5c
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Change my mind: Windows Subsystem for Linux should be Linux Subsystem for Windows
I'm serious. Isn't WSL essentially a Linux environment running on top of Windows, rather than a Windows environment running on Linux?
If that’s the case, it feels like the naming is a bit backward. WSL stands for Windows Subsystem for Linux, which makes sense in a very literal sense: it’s a subsystem provided by Windows to support Linux. But when you think about it, the direction of the virtualization is key. Typically, when we talk about virtual machines or subsystems, we name them in the format of what is running inside what. Here, Linux is the thing running on top of Windows, not the other way around. So wouldn’t it be more logical to call it LSW, Linux Subsystem for Windows?
I'm posting here for the first time so sorry if this breaks the rules, I don't know whether we're allowed to discuss Linux VMs
EDIT: Since most of you agree that the naming is shit, should I raise a PR?
https://redd.it/1ndc5hs
@r_linux
I'm serious. Isn't WSL essentially a Linux environment running on top of Windows, rather than a Windows environment running on Linux?
If that’s the case, it feels like the naming is a bit backward. WSL stands for Windows Subsystem for Linux, which makes sense in a very literal sense: it’s a subsystem provided by Windows to support Linux. But when you think about it, the direction of the virtualization is key. Typically, when we talk about virtual machines or subsystems, we name them in the format of what is running inside what. Here, Linux is the thing running on top of Windows, not the other way around. So wouldn’t it be more logical to call it LSW, Linux Subsystem for Windows?
I'm posting here for the first time so sorry if this breaks the rules, I don't know whether we're allowed to discuss Linux VMs
EDIT: Since most of you agree that the naming is shit, should I raise a PR?
https://redd.it/1ndc5hs
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Switching from W11 to Linux.
Hello i have a few questions about switching to linux (i am thinking about using nobara)
Here are my specs:
I am using a lenovo laptop (Lenovo LOQ 15IRH8)
GPU: Geforce RTX 4060
CPU:13th Gen Intel(R) Core(TM) i7-13620H
RAM: 16GB of Ram
SSD: 1TB
So. I need alternative apps for the following things and other options for:
I use Lenovo Vantage for limiting my battery charge to 80%, changeing my GPU working mode to dGPU because on windows at least ive had a few instances where it would change to hybrid mode on its own.
I also need to know if the nvidia app is on Nobara same with the control panel.
Alternative for clipping with Medal.
I also need to know if things like Epic games Launcher works. And i dont play many games with anticheat.
And Ubisoft games also.
Taskmanager alternative cause i use it alot.
Also definetely gonna use Wine.
_______________________________________________________________________________________________________________
I Mainly wanna switch from W11 to Nobara because of the KB5063878 update not wanting to risk my drive.
I wanna know anything i should know before factory resetting and swapping to Linux (Nobara)
I am completely New to Linux btw.
https://redd.it/1nddxwl
@r_linux
Hello i have a few questions about switching to linux (i am thinking about using nobara)
Here are my specs:
I am using a lenovo laptop (Lenovo LOQ 15IRH8)
GPU: Geforce RTX 4060
CPU:13th Gen Intel(R) Core(TM) i7-13620H
RAM: 16GB of Ram
SSD: 1TB
So. I need alternative apps for the following things and other options for:
I use Lenovo Vantage for limiting my battery charge to 80%, changeing my GPU working mode to dGPU because on windows at least ive had a few instances where it would change to hybrid mode on its own.
I also need to know if the nvidia app is on Nobara same with the control panel.
Alternative for clipping with Medal.
I also need to know if things like Epic games Launcher works. And i dont play many games with anticheat.
And Ubisoft games also.
Taskmanager alternative cause i use it alot.
Also definetely gonna use Wine.
_______________________________________________________________________________________________________________
I Mainly wanna switch from W11 to Nobara because of the KB5063878 update not wanting to risk my drive.
I wanna know anything i should know before factory resetting and swapping to Linux (Nobara)
I am completely New to Linux btw.
https://redd.it/1nddxwl
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
BCacheFS is being disabled in the openSUSE kernels 6.17+
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/TOXF7FZXDRFPR356WO37DXZLMVVPMVHW/
https://redd.it/1ndhsow
@r_linux
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/TOXF7FZXDRFPR356WO37DXZLMVVPMVHW/
https://redd.it/1ndhsow
@r_linux
Reddit
From the linux community on Reddit: BCacheFS is being disabled in the openSUSE kernels 6.17+
Posted by ehempel - 13 votes and 2 comments
Desktop Linux has come a long way..and is easier than windows for new users
Back in the day (2000s) installing Linux on typical laptops or desktops was a pita (CUPS, ALSA drivers etc). I dabbled in Ubuntu when it was new (they used to mail you actual DVDs if you requested it) and it didnt go well. Before that I had tried Mandriva and Suse, which again didn't go well.
Back to 2024, I assembled my own PC and just realized how long drawn Windows installs are - it forces you to go online, you have to hunt for drivers and in my case it seems the basic ethernet drivers werent present in Windows. So I had to download all of them from my mac onto a USB disk (four - five reboots to install everything).
I got tired of Windows 11 with constant ads and random shit on the start menu and decided I genuinely dont need Windows for anything. Even gaming part is mostly solved as per Reddit posts. Anyways, I just got popos and it works out of the box. Nothing needed from me apart from specifying to delete Windows and take over the SSD. Thats it, no extra steps, no downloads, no incompatibility. ITs actually easier to use for a newbie than Windows.
https://redd.it/1ndimuw
@r_linux
Back in the day (2000s) installing Linux on typical laptops or desktops was a pita (CUPS, ALSA drivers etc). I dabbled in Ubuntu when it was new (they used to mail you actual DVDs if you requested it) and it didnt go well. Before that I had tried Mandriva and Suse, which again didn't go well.
Back to 2024, I assembled my own PC and just realized how long drawn Windows installs are - it forces you to go online, you have to hunt for drivers and in my case it seems the basic ethernet drivers werent present in Windows. So I had to download all of them from my mac onto a USB disk (four - five reboots to install everything).
I got tired of Windows 11 with constant ads and random shit on the start menu and decided I genuinely dont need Windows for anything. Even gaming part is mostly solved as per Reddit posts. Anyways, I just got popos and it works out of the box. Nothing needed from me apart from specifying to delete Windows and take over the SSD. Thats it, no extra steps, no downloads, no incompatibility. ITs actually easier to use for a newbie than Windows.
https://redd.it/1ndimuw
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community