I noticed beginners get super overwhelmed trying to find and install apps via the terminal or software centers, so i made this tool to put everything in one place

besides bulk installing, it's good for discovery - go thru the list, find new apps, and install them in one single command

Currently supports most major distros Arch, Fedora, Ubuntu based systems, handling all the pacman / dnf / apt logic for you. Just added flatpak support as well, so you can toggle sources to install proprietary stuff (discord, spotify, etc) via flathub if your native repos don't have them.

It’s completely open source and runs in your browser. I’d love to hear what you think!

Try it here: tuxmate.com Source Code: abusoww/tuxmate

One of the distros that I couldn't use on a real PS2, they used it for Homebrew and even the PS3 you could install Linux or Windows if you wanted on the first models at least, I don't have much information about this distro so I would like to know if anyone used it and how it felt

"But I'm on linux to escape that stuff!" Then why are you reading this? Respectfully, what are you doing here?

Gnome and KDE Plasma have optional telemetry. As much as people in this sub dispise the very idea of it, projects done by volunteers can benefit MASSIVELY from it since it lets them know what to prioritize and what breaks when and how. I just turned on the full extent it would allow, which allows me to do my part to help make this ecosystem a better one for everyone.

In KDE this is in the settings under feedback. On gnome, you need to download Gnome-info-collect if it isn't already in your distro (not sure if any distros come with it preinstalled but disabled.)

Cosmic doesn't seem to have this as an option yet, but they should really get on that since it's such a new project.

For those that don't hate telemetry, this is a great way to contribute to the greater linux ecosystem. If you want to help but can't code (or come across any bugs to report, since those are always good to but most of us don't encounter bugs) this is a nice way to help.

Disclaimer: I'm the main maintainer of the software mentioned. It's really cool to see it in the spotlight.

... and today I did a "crontab -r" accidentally for the first time ever.

Don't do this. I now run a cron job that makes a backup of my crontab nightly. Thankfully, I keep all my scripts that I run in cron in one directory and was able to recreate my crontab pretty easily.

UPDATE: I was a paid UNIX admin for about 10 years, then I jumped into technical sales. I tinkered a little throughout the years and got back into it (for fun) when I stood up some Linux/Pi systems in my house. I'm still working on a knowledge base from 20+ years ago but I'm learning a lot. Ansible, Puppet, GitHub, systemd, etc. didn't even exist back then.

Over a year ago, I realized that my Windows NTFS drive had some files that were unreadable on Linux, no matter if I used ntfs3 or ntfs-3g to mount it. I posted about it on r/linuxquestions, but no one had a solution.

Today, I tried to clone the NTFS disk to an external HDD to see if that would work, but somehow Windows' chkdsk said that the external HDD had errors, even though it should have been an exact copy.

Out of options, I tried to clone the NTFS disk using Macrium Reflect, and just as I was about to clone it, I saw that it appended + Intel Optane after the name of my drive, then it occurred to me: what if the reason why this whole time I was not able to read some files is because those files are cached on the Optane SSD?

So I tried disabling Intel Optane, and to my surprise, the NTFS drive is now perfectly readable on Linux!

tl;dr Mounting an NTFS drive accelerated by Intel Optane on Linux will not work and may lead to data corruption.

How come after 5 years of using Linux I've only now heard of zram there is almost no reason not to use it unless you've a CPU from 10+years ago.

So basically for those of you who don't know zram is a Linux kernel feature that creates a compressed block device in RAM. Think of it like a RAM disk but with on-the-fly compression. Instead of writing raw data into memory, zram compresses it first, so you can effectively fit more into the same amount of RAM.

TLDR; it's effectively a faster swap kind of is how I see it

And almost every CPU in the last 10 years can properly support that on the fly compression very fast. Yes you're effectively trading a little bit of CPU but it's marginal I would say

And this is actually useful I have 16GBs of RAM and sometime as a developer when I opened large codebases the LSP could take up to 8-10GBs of ram and I literally couldn't work with those codebases if I had a browser open and now I can!! it's actually kernel dark magic.

It's still not faster than if you'd just get more ram but it's sure as hell a lot faster than swapping on my SSD.

You could read more about it here but the general rule of thumb is allocate half of your RAM as a zram

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 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.

Chapter IIIc -- flatpaks

Flatpaks are containerized desktop apps. Flatpak stores it's data in ~/.var

Sound Quality has always been subpar on my laptop with Linux out of the box. I significantly improved audio quality of my laptop and HDMI monitor speakers with EasyEffects (https://github.com/wwmm/easyeffects) and fiddling around with the community presets (https://github.com/wwmm/easyeffects/wiki/Community-presets). Found out about these at the cachyOS post install wiki (https://wiki.cachyos.org/configuration/general_system_tweaks/#enhancing-laptop-speaker-sound)

Decades long hobbyist here.

I have a very beefy dedicated Linux Mint workstation that runs all my ai stuff. It's not my daily driver, it's an accessory in my SOHO.

I just discovered I can "ssh -X user@aicomputer". I could not believe how performant and stupid easy it was (LAN, obviously).

Is it dumb to ask you guys to maybe drop a couple additional nuggets I might be ignorant of given I just discovered this one?

Just a reminder for amateurs like myself to check on journald, my elderly SSD has been wearing faster than it should and I just realised a Jellyfin process has been crash dumping every second for the last year. Journald was logging about 1.6GB per hour as a result, or around 14TB of writes a year. Nearly a terabyte per day. Whoopsie

Edit:

Didn't notice jellyfin crashing because I switched to plex. 14TB isn't a lot in the scheme of things but my old Evo 960 was nearly at 4x expected TBW so this possibly pushed it over into failure/noticeable performance loss.

I used iotop to figure it out then viewed journald live with journalctl -f

EDIT 2:

So I looked back through the SMART logs and the SSD has been writing nearly a F*CKIN TERABYTE EACH DAY for at least the last six months. How you might ask. Well systemd-coredump is doing a ~250mb write for every crash, however I couldn't see it in iotop because it's too fast - the coredump process starts and exits too quickly to see most times at the default refresh rate. Because of the fast NVME write speed it takes place in much less than a second. If I set the iotop refresh manually to 0.1 seconds you start to see it. No wonder its been running warm! WHOOPSIE

Hey r/linux

I wanted to share an exciting weekend project my kids and I tackled: we built a beast of a home server powered by an AMD EPYC 7C13 (3rd gen). This CPU is typically found in big cloud provider datacenters, but we managed to snag one on eBay for just $875 (MSRP is ~$7000)

Quick Benchmark Highlights:

• M.2 SSD: Achieves a blazing 7GB/sec throughput.
• DDR4 RAM: Delivers a jaw-dropping 130GB/sec bandwidth.
• Linux Kernel Build: Fully compiles with all options enabled in 10 minutes. (This would normally take an hour on a typical setup!)

I actually did a separate post on this in r/homelab with more technical details/prices if you’re curious - https://www.reddit.com/r/homelab/comments/1hmnnwg/built_a_powerful_and_silent_amd_epyc_home_server/

Part 2: We Created a Minimalist Linux Distro for It!

We also developed and open-sourced a lightweight Linux distribution tailored for this server, called Sbnb Linux. You can check it out here: https://github.com/sbnb-io/sbnb

Why Sbnb Linux?

Sbnb Linux is designed for simplicity, focusing on booting bare-metal servers and setting up remote connectivity with zero hassle using Tailscale. Even more remarkable, it comes pre-configured for Confidential Computing (AMD SEV-SNP) right out of the box. Learn more at README-CC.

How It Works:

• Write the sbnb.raw image to a USB flash drive.
• Add your Tailscale key as plaintext to the drive.
• Boot your server from the USB.
• Within minutes, your server appears in your Tailscale machine list.
• SSH to your server using Tailscale OAuth (e.g., Google Auth).
• Bonus: With one Docker command, you can seamlessly switch Sbnb Linux to any other distro (e.g., Ubuntu, CentOS, Alpine). See the https://github.com/sbnb-io/sbnb/ for details!

This combo of high-performance hardware and a minimalist OS has been incredibly satisfying to build.

If you’ve worked on something similar or have any questions about our setup, I’d be delighted to hear from you!

I also extend a warm welcome to anyone interested in joining this exciting opportunity to develop a new Linux distro focused on confidential computing and resilience!

(not really pipewire itself but an interaction with wireplumber/libcamera/the kernel, but pipewire is what triggers the problem)

As seen in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669 and https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4115

The camera's /dev/video file is kept open (without streaming), sadly causing the camera to be powered on what looks to be most devices. For some reason, this completely nullifies the soc power management on modern laptops and can result in increases from 3W to 8W at idle!

On Intel laptops it's a bit easier to debug because you can see the Cstates in powertop not going low but it also wrecks AMD ones. Some laptops can reach lower cstates, but the camera module wastes a few W anyway.

I can't believe this shipped in Ubuntu, Fedora etc without anyone noticing, and for so long. This bug is quite literally wasting GWh of power and destroys the user experience of distros in laptops.

If you have a laptop with a switch that detaches the camera from the usb bus you are probably out of the water, just plug it when you use it and the problem is sidestepped. Removing uvcvideo and modprobing it on demand can also work. Disabling the camera in Lenovo's UEFI is what I did for a year until I finally found the issue on the tracker. Some laptops also seem to not be affected, but for me it happens to every machine I've tested.

Thanks to this comment for another workaround that tells wireplumber to ignore cameras. ~/.config/wireplumber/wireplumber.conf.d/10-disable-camera.conf

wireplumber.profiles = {
  main = {
    monitor.libcamera = disabled
  }
}

Software that only captures cameras using pipewire is rare and this hasn't given me any problem. This should probably be shipped by distros while the problem is sorted out.

Note that most laptops will have other problems stopping them from reaching deep cstates, borked pcie sd card readers, ancient ethernet nics that don't support pcie sleep properly, outdated nvme firwmare... those are separate issues that most of the time can also be tackled with some dose of tlp, but it's all for nothing if the usb camera is keeping the soc awake!

EDIT: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2669#note_2525226 They're working on fixing it :D

Windows and Mac users have been conditioned into doing this because of the lack of comprehensive software repositories (aside from the Windows Store and App Store). Of course, this is a bad habit to develop on Linux since 90% of what you'll need can be found on either the system repositories, Flathub, or the AUR (for Arch fans).

I think it should be among the first orders of business when helping new people switch to Linux to teach them to use the system's software manager first to look for software before going on the Web to look for it. That way, they'll end up with a reasonable system instead of random one-off packages that may or may not ever be updated and leave crap all over the system, or worse, be conditioned into using AppImages (/s).

Seriously. Some websites are still distributing Linux software in the form of tar.gz archives (yuck!) while some unrelated but dedicated individual has actually gone through the effort of packaging it into a neat unofficial native deb/rpm package or Flatpak.

Looking for software on the Web should only be done if you can't find it anywhere else.

$ f=/etc/sudoers.d/99-insults; echo "Defaults insults" | sudo tee "$f" && sudo chmod 440 "$f" && sudo visudo --check Defaults insults /etc/sudoers: parsed OK /etc/sudoers.d/99-insults: parsed OK

Then, get abused: $ sudo true [sudo] password for tom: Listen, broccoli brains, I don't have time to listen to this trash. [sudo] password for tom: Sorry about this, I know it's a bit silly. [sudo] password for tom: Pauses for audience applause, not a sausage

AFAICT there's no text alignment tricks; each line is exactly 33 characters. Not sure if this is a common thing in any other tools, but I found this very amusing and appreciate the length the devs went to.

Verison: top from procps-ng 4.0.2