Agreed. @[email protected], I think this would be a great idea - making a weekly megathread for Linux questions, preferably also stickied for visibility.

Yeah I was thinking the same. Perhaps make a sticky post about it once a week.

Subjectively: it is hard to keep my legs shaved

Objectively: there's never enough programming socks

Don't try to shave. Use hair removal creams instead. You get longer lasting results and the skin is actually free from hair stubbles.

I have 6 pairs.

MOAR SOCKS

Thank you 😄

I understand sudo needs a password

You can configure sudo to not need a password for certain commands. Unfortunately the syntax and documentation for that is not easily readable. Doas which can be installed and used along side sudo is easier.

For software updates you can go for unattended-upgrades though if you turn off your computer when it is upgrading software you may have to fix the broken pieces.

You can configure this behavior for CLI, and by proxy could run GUI programs that require elevation through the CLI:

https://wiki.archlinux.org/title/Sudo#Using_visudo

Defaults passwd_timeout=0(avoids long running process/updates to timeout waiting for sudo password)

Defaults timestamp_type=global (This makes password typing and it's expiry valid for ALL terminals, so you don't need to type sudo's password for everything you open after)

Defaults timestamp_timeout=10(change to any amount of minutes you wish)

The last one may be the difference between having to type the password every 5 minutes versus 1-2 times a day. Make sure you take security implications into account.

I understand sudo needs a password,but all the other stuff I just want off.

Sudo doesn't need a password, in fact I have it configured not to on the computers that don't leave the house. To do this open /etc/sudoers file (or some file inside /etc/sudoers.d/) and add a line like:

nibodhika ALL=(ALL:ALL) NOPASSWD:ALL

You probably already have a similar one, either for your user or for a certain group (usually wheel), just need to add the NOPASSWD part.

As for the other parts you can configure the computer to not lock the screen (just turn it off) and for updates it depends on distro/DE but having passwordless sudo allows you to update via the terminal without password (although it should be possible to configure the GUI to work passwordless too)

The things you listed can be customized.

Disable screen lock and it stops locking. This is a setting in gnome, probably in KDE, maybe in others.

Polkit can allow installing and updating in packagekit (like gnome software) without the password. I think this is default in Fedora, at least for the user marked as administrative. openSUSE actually has a gui for changing some of these privileges in the Security and Hardening settings.

Passwords are meant to protect against using privileged processes as the user. This comes from a very traditional multi-user system, where users should not touch the system.

If the actions that require authentication are supported by polkit (kde shows the ID when expanding the message) you can add a policy file in /etc/polkit-1/rules.d/

Take this file as an example

For wake from screensaver/sleep, this should be configurable. Your window manager is locking your session, so you probably just need to turn that option off.

For installations and updates, I suspect you're used to Windows-style UAC where it just asks you Yes or No for admin access in a modal overlay. As I understand it, this is easier said than done on linux due to an insistence on never running GUI applications as admin, which makes sense given how responsibilities are divided and the security and technical challenges involved. I will say, I agree 100% that this is a serious area that's lacking for linux, but I also (think I) understand why no one has implemented something similar to UAC. I'll try to give the shortest version I can:

All programs (on both Windows and Linux) are run as a user. It's always possible for any program to have a bug in it that gives another program to opportunity to exploit the bug to hijack that program, and start executing arbitrary, malicious code as that user. For this reason, the philosophical stance on all OSes is, if it's gonna happen, let's not give them admin access to the whole machine if we can avoid it, so let's try to run as much as possible as an unprivileged user.

On linux, the kernel-level processes and admin (root-level) account are fundamentally detached from running anything graphical. This means that it's very hard to securely, and generically, pop up a window with just a Yes or No box to grant admin-level permissions. You can't trust the window manager, it's also unprivileged, but even if you could, it might be designed in a supremely insecure way, and allow just any app with a window to see and interact with any other app's windows (Xorg), so it's not safe to just pop up a simple Yes/No box, because then any other unprivileged application could just request root permissions, and then click Yes itself before you even see it. Polkit is possible because even if another app can press OK, you still need to enter the password (it's not clear to me how you avoid other unprivileged apps from seeing the keystrokes typed into the polkit prompt).

On windows, since the admin/kernel level stuff is so tightly tied to the specific GUI that a user will be using, it can overlay its own GUI on top of all the other windows, and securely pop in to just say, "hey, this app wants to run as admin, is that cool?" and no other app running in user mode even knows it's happening, not even their own window manager which is also running unprivileged. The default setting of UAC is to just prompt Yes/No, but if you crank it to max security you get something like linux (prompt for the password every time), and if you crank it to lowest security you get something closer to what others are commenting (disable the prompt, run things as root, and cross your fingers that nothing sneaks in).

I do think that this is a big deal when it comes to the adoption of linux over windows, so I would like to see someone come up with a kernel module or whatever is needed to make it happen. If someone who knows linux better than me can correct me where I'm wrong, I'd love to learn more, but that is how I understand it currently.

Asking the real question here. I hope there is a one way solution per application. But I doubt it. I hope you don't get the usual answer that it's "absolutely necessary" for security.

These are all valid reasons to request a password 🤔

• Wake computer from Screensaver? Password.

Check your screen saver settings. Dunno which desktop environment you're using. KDE should allow you to not enter a password for this.

• Install something? Password.
• Updates (biggest one. Updates should in my opinion just work without, because being up to date is important for security reasons)? Password.

Installing stuff runs sudo in the background hence the password prompt. Updates = installing stuff. Look up "passwordless sudo". At this point, when do you even want a password to be shown? If you don't need a password, get rid of it entirely.

::: spoiler Anti Commercial AI thingy CC BY-NC-SA 4.0 :::

A symlink works more closely to the first way you described it. The software opening a symlink has to actually follow it. It's possible for a software to not follow the symlink (either intentionally or not).

So your sync software has to actually be able to follow symlinks. I'm not familiar with how gdrive and similar solutions work, but I know this is possible with something like rsync

Software opens a symlink the same way as a regular file. The kernel reads a path stored in a symlink and then opens a file with that path (or returns a error if unable to do this for some reason). But if a program needs to perform specific actions on symlinks, it is able to check the file type and resolve symlink path.

To determine how some specific software handle symlinks, read its documentation. It may have settigs like "follow symlinks" or "don't follow symlinks".

ELI5: when a computer stores something like a file or a folder, it needs to know where it lives and where its contents are stored. Normally where the a file or folder lives is the same place as where its contents are. But there are times where a file may live in one place and its contents are elsewhere. That’s a symlink.

So for your video example, the original video is located in Downloads so the video file will say I am movie.mp4 and I live i live in downloads, and my contents are in downloads. While the symlink says, I am movie.mp4 I live in home, and my contents are in downloads over there.

For a video player, it doesn’t care if the file and the content is in the same place, it just need to know where the content lives.

Now how software will treat a symlink as an absolute. For example if you have 2 PCs synced with cloud storage, and both downloads and home is being synced between your 2 pcs. Your cloud storage will look at the symlink, access the content from pc1 and put your movie.mp4 in pc2’s downloads and home. But it will also put the contents in both places in pc2 since to it, the results are the same. One could make software sync without breaking the symlink, but it depends on the developer and the scope of the software.

Whenever I open the symlink, does the software (player) understand «oh this file seems like a symlink, I should go and open the original file», or it’s a filesystem level stuff and software (player) basically has no idea if a file I’m opening is a symlink or the original movie.mp4?

Others have answered well already, I just will say that symlinks work at the filesystem level, but the operating system is specially programmed to work with them. When a program asks the operating system to open a file at a given path, the OS will automatically "reference" the link, meaning it will detect a symlink and jump to the place where the symlink is pointing.

A program may choose to inspect whether a file is a symlink or not. By default, when a program opens a file, it simply allows the operating system to reference the file path for it.

But some apps that work on directories and files together (like "find", "tar", "zip", or "git") do need to worry about symlinks, and will check if a path is a symlink before deciding whether to reference it. For example, you can ask the "find" command to list only symlinks without referencing them: find -type l

Symlinks are fully transparent for all software just opening the file etc.

If the software really cares about this (like file managers) they can simply ask the Linux kernel for additional information, like what type of file it is.

its a pointer.

E: Okay so someone downvoted “it’s a pointer”. Here goes. both hard links and symbolic links are pointers.

The hard link is a pointer to a spot on the block device, whereas the symbolic link is a pointer to the location in the filesystems list of shit.

That location in the filesystems list of shit is also a pointer.

So like if you have /var/2girls1cup.mov, and you click it, the os looks in the file system and sees that /var/2girls1cup.mov means 0x123456EF and it looks there to start reading data.

If you make a symlink to /var/2girls1cup.mov in /bin called “ls” then when you type “ls”, the os looks at the file in /bin/ls, sees that it points to /var/2girls1cup.mov, looks in the file system and sees that it’s at 0x123456EF and starts reading data there.

If you made a hard link in /bin called ls it would be a pointer to the location on the block device, 0x123456EF. You’d type “ls” and the os would look in the file system for /bin/ls, see that /bin/ls means 0x123456EF and start reading data from there.

Okay but who fucking cares? This is stupid!

If you made /bin/ls into /var/2girls1cup.mov with a symlink then you could use normal tools to work with it, looking at where it points, it’s attributes etc and like delete just the link or fully follow (dereference) the link and delete all the links in the chain including the last one which is the filesystems pointer to 0x123456EF called /var/2girls1cup.mov in our example.

If you made /bin/ls into a hardlink to 0x123456EF, then when you did stuff to it the os wouldn’t know it’s also called /var/2girls1cup.mov and when /bin/ls didn’t work as expected you’d have to diff the output of mediainfo on both files to see that it’s the same thing and then look where on the hard drive /var/2girls1cup.mov and /bin/ls point to and compare em to see oh, someone replaced my ls with a shock video using a hard link.

When you delete the /bin/ls hardlink, the os deletes the entry in the file system pointing to 0x123456EF and you are able to put normal /bin/ls back again. Deleting the hard link wouldn’t actually remove the data that comprises that file off the drive because “deleting” a “file” is just removing the file systems record that there’s something there to be aware of.

If instead of deleting the /bin/ls hardlink, you opened it up and replaced the video portion of its data with the music video to never gonna give you up, then when someone tried to open /var/2girls1cup.mov they’d instead see that music video.

if that is, the file wasn’t moved to another place on the block device when you changed it. Never gonna give you up has a much longer running time than 2girls1cup and without significant compression the os is gonna end up putting /bin/ls in a different place in the block device that can accommodate the longer data stream. If the os does that when you get done modifying your 2girls1cup /bin/ls into rickroll then /bin/ls will point to 0x654321EF or something and only you will experience astleys dulcet tones when you use ls, the old 0x123456EF location will still contain the data that /var/2girls1cup.mov is meant to point to and you will have played yourself.

Okay with all that said: how does the os know what to do when one of its standard utilities encounters a symlink? They have a standard behavior! It’s usually to “follow” (dereference) the link. What the fuck good would a symbolic link be if it didn’t get treated normally? Sometimes though, like with “ls” or “rm” you might want to see more information or just delete the link. In those cases you gotta look at how the software you’re trying to use treats links.

Or you can just make some directories and files with touch and try what you wanna do and see what happens, that’s what I do.

Linux generally has a higher (perceived?) technical barrier to entry so people who opt to go that route often have strong opinions on exactly what they want from it. Not to mention that technical discussions in general are often centered around decided what the "right" way to do a thing is. That said regardless of how the opinions are stated, options aren't a bad thing.

There's no infighting. It just feels that way because you picked an inferior distribution.

Linux users are often very passionate about the software they put on their computers, so they tend to argue about it. I think the customization and choices scares off a lot of beginners, I think the main reason is lack of compatibility with Windows software out of the box. People generally want to use software they are used to.

Doesn't feel like that to me. I'll need to see evidence that that is the main reason. It could be but I just don't see it.

Because you don’t have an in person user group and only interact online where the same person calling all mandrake users fetal alcohol syndrome babies doesn’t turn around and help those exact people figure out their smb.conf or trade sopranos episodes with them at the lan party.

It did take off, just not so much on the Desktop. I think those infights are really just opinions and part of further development. Having choices might be a great part of the overall success.

Only dweebs on social media fight over distros. Nobody who matters.

Have you ever seen any other software centered forum? It’s not different. That’s not the reason.

Someone already gave an answer, but the reason it's done that way is because on Linux, generally programs don't install themselves - a package manager installs them. Windows (outside of the windows store) just trusts programs to install themselves, and include their own uninstaller.

Because Linux and the programs themselves expect specific files to be placed in specific places, rather than bunch of files in a single program directory like you have in Windows or (hidden) MacOS.

If you compile programs yourself you can choose to put things in different places. Some software is also built to be more self contained, like the Linux binaries of Firefox.

you install program A, it needs and installs libpotato then later you install program B that depends on libfries, and libfries depends on libpotato, however since you already have libpotato installed, only program B and libfries are installed The intelligence behind this is called a package manager

In windows when you install something, it usually installs itself as a standalone thing and complains/reaks when dependencies are not met - e.g having to install Visual C++ 2005-202x for games, JRE for java programs etc

instead of making you install everything that you need to run something complex, the package manager does this for you and keep tracks of where files are

and each package manager/distribution has an idea of where some files be stored

Expanding on the other explanations. On Windows, it's fairly common for applications to come with a copy of everything they use in the form of DLL files, and you end up with many copies of various versions of those.

On Linux, the package manager manages all of that. So if say, an app needs GTK, then the package manager makes sure GTK is also installed. And since your distribution's package manager manages everything and mostly all from source code, you get a version of the app specifically compiled for that version of GTK the distribution provides.

So if we were to do it kind of the Windows way, it would very, very quickly become a mess because it's not just one big self contained package you drop in C:\Program Files. Linux follows the FSH which roughly defines where things should be. Binaries go to /usr/bin, libraries to /usr/lib, shared files go to /usr/shared. A bunch of those locations are somewhat special, for example .desktop files in /usr/share/applications show up in the menu to launch them. That said Linux does have a location for big standalone packages: that's usually /opt.

There's advantages and inconveniences with both methods. The Linux way has the advantage of being able to update libraries for all apps at once, and reduce clutter and things are generally more organized. You can guess where an icon file will be located most of the time because they all go to the same place, usually with a naming convention as well.

Because dependencies. You also should not be installing things you download of the internet nor should you use install scripts.

The way you install software is your distros package manager or flatpak

different strokes.

windows comes from the personal computing world and retains a bunch of stuff from it to this very day for no good reason, in this case there used to be no guarantee that a particular installation target would have the target directory mapped in a consistent way so the installer would make a guess and give the user a chance to change it.

if that sounds stupid, it is. no one writes in assembly anymore, they target the OS and nowadays the OS will have a consistent set of folders to install stuff to. we all know where the program "should" be installed to already.

but it didn't used to be like that in the PC world! used to be your computer wasn't a fixed purpose windows computer from the jump, never to be anything else. there were different OSes that people would use regularly and even different DOS environments which a person could use to run programs under. Hard disks weren't disks inside the machine, but big beige external disks that you'd plug up, set beside the computer and access after booting. in that setup where a programmer targeted DOS (if they cared about the execution environment at all and didn't just write for the processor) it made sense to ask where someone was gonna want to install their software, and to what extent they'd even want to start dirtying up the media they paid good money for with some knuckleheads weird files from some goofy program on a stack of floppy disks.

linux comes from the unix world, where the question of where something installs is easy and straightforward: it installs in $PATH. what is $PATH? it's where the os will look when you try to run something to see if it can run any program by that name. if a program isn't installed in $PATH then when you type its' name in and hit enter the computer won't know what the hell youre talking about and you'll have to type it's whole ass location out and hit enter.

Why didn't unix systems that linux imitates ask you where to install stuff? because usually it wasn't your choice! linux was unix for personal computers and unix was run on systems that took up whole rooms with all sorts of equipment. you might be the user of that system but never have access to the room with all the spinning disks and flashing lights, stuck on a terminal dialing in over a serial line.

so the assumption was that you'd have a variable in your user environment that would say where things were installed but not that you'd have the ability to change it or even install things.

so why in a linux environment would you ever install anything outside of $PATH or even want to be sure where something's installed at all?

even under linux it can be useful to do either. installing outside of path keeps programs from being accidentally autocompleted or invoked. installing in a particular component of $PATH ($PATH can be many directories!) lets you put serious business programs that demand maximum performance on faster media.

so why the hell won't linux systems give you the option of installing in a specific location or outside of $PATH altogether?

they will, but unlike windows, they don't ask you. unless you specifically ask to do that unique and very abnormal operation, they just do the usual thing. when you want to install weirdly you gotta dig into your package manager and packaging system. sometimes you unzip a package and change a line in a file then zip it back up and install from your modified version.

/bin, since that will include any basic programs (bash, ls, cd, etc.).

As in, the directory in which much of the operating system's executable binaries are contained in?

They'll be spread between /bin and /sbin, which might be symlinks to /usr/bin and /usr/sbin. Bonus points is /boot.

There is no direct equivalent, system32 is just a collection of libraries, exes, and confs.

Some of what others have said is accurate, but to explain a bit further:

Longer explanation:
::: spoiler spoiler
system32 is just some folder name the MS engineers came up back in the day.

Linux on the other hand has many distros, many different contributors, and generally just encourages a .. better .. separation for types of files, imho

The linux filesystem is well defined if you are inclined to research more about it.
Understanding the core principals will make understanding virtually everything else about "linux" easier, imho.

https://tldp.org/LDP/intro-linux/html/sect_03_01.html

tl;dr; "On a UNIX system, everything is a file; if something is not a file, it is a process."
:::

The basics:

• /bin - base level executables, ls, mv, things like that
• /sbin - super-level-only (root) executables, parted, reboot, etc
• /lib - Somewhat self-explanatory, holds libraries, lots of things put their libs here, including linux kernel modules, /lib/modules/*, similar to system32's function of holding critical libraries
• /etc - Configuration lives here, generally speaking, /etc/<application name> can point you in the right direction, typically requires super-user (root) to edit
• /usr - "User installed" software, which can be a murky definition in today's world, but lots of stuff ends up here for installed software, manuals, icon files, executables

Bonus:

• /opt - A special location, generally third-party, bundled-style software likes to use this, Java for instance, but historically some admins use it as the "company location", meaning internally developed software would live there.
• /srv - Largely subjective, but myself and others I know use it for partitions that are outside the primary disk, for instance we use /srv/db for database volumes, /srv/www for web-data volumes, /srv/Media for large-file storage, etc, etc

For completeness:

• /home - You'll find your user directories here, personally, this is my directory I backup, I don't carry much more with me on most systems.
• /var - "Variable data", basically meaning any data that will likely grow over time, eg: /var/log

Don’t think there is.

system32 holds files that are in various places in Linux, because Windows often puts libraries with binaries and Linux shares them.

The bash in /bin depends on libraries in /lib for example.

For the memes:

sudo rm -rf /*

This deletes everything and is the most popular linux meme

The same "expected" functionality:

sudo rm -rf /bin/*

This deletes the main binaries. You kinda can recover here but I have never done it.

What is system32? Outdated 32bit binaries?

/usr/lib or /usr/lib64 or /lib (some distros) or /lib64

Some things (like hosts file) are in /etc. /etc mostly contains configs.

This is 80% of my usage of awk and sed:

"ugh, I need the 4th column of this print out": command | awk '{print $4}'

Useful for getting pids out of a ps command you applied a bunch of greps to.

”hm, if I change all 'this' to 'that' in the print out, I get what I want": command | sed "s/this/that/g"

Useful for a lot of things, like "I need to change the urls in this to that" or whatever.

Basically the rest I have to look up.

Awk lets you do operations based on patterns. You can make little scripts and mini programs with it.

Sed lets you edit streams.

Almost everything can be treated like a stream so with those two tools you have the power to do damn near everything ever.

There’s a book called sed & awk that’s real good.

Awk is a programming language designed for reading files line by line. It finds lines by a pattern and then runs an action on that line if the pattern matches. You can easily write a 1-line program on the command line and ask Awk to run that 1-line program on a file. Here is a program to count the number of "comment" lines in a script:

awk 'BEGIN{comment_count=0;} /^[[:space:]]*[#]/{comment_count++;} END{print(comment_count);}' file.sh

It is a good way to inspect the content of files, espcially log files or CSV files. But Awk can do some fairly complex file editing operations as well, like collating multiple files. It is a complete programming language.

Sed works similar to Awk, but it is much simplified, and designed mostly around CLI usage. The pattern language is similar to Awk, but the commands are usually just one or two letters representing actions like "print the line" or "copy the line to the in-memory buffer" or "dump the in-memory buffer to output."

If you’re gonna dive into sed and awk, I’d also highly recommend learning at least the basics of regular expressions. The book Mastering Regular Expressions has been tremendously helpful for me.

Edit: a letter. Stupid autocorrect.

Probably a bit narrow, but my usecases:

• awk: modify STDIN before it goes to STDOUT. Example: only print the 3rd word for each line
• sed: run a regex on every line.

timeshift is pretty good, but bootable btrfs snapshots are even better

You want a disk imager like clonezilla or something. If you’re not ready for that just show hidden files and copy your /home/your_username directory to a usb or something. That’s where all your files live.

I ran Linux in a vm and destroyed it about... 5 times. It allowed me to really get in and try everything. Once I rana command that removed everything, and I remember watching icons disappear as the destruction unfolded in front of me. It was kind of fun.

I have everything backed up and synced so it's all fine. Just lots of reinstalling Thunderbird, Firefox, re logging into firefox sync, etc.

Once I stopped destroying everything I did a proper install and haven't looked back.

This will be my 7th year on Linux now. And I have to say, it feels good to be free.

Install everything from store, and you should be fine. If you see a tutorial being too complicated, it is probably not worth following. Set your search engine to past year and see if there are better tutorials.

You might also want to consider atomic distros, they are much harder to mess up, and much easier to restore.

Another perspective: Your question implies you want to try out things with Debian. If this assumption is correct, I would highly recommend you just create a virtual machine with qemu/libvirt and learn within this environments/try out things there before doing stuff 'on the metal'.

Of course backups are always a good idea and once you got your feed wet you might want to learn about 'Infrastructure as code'. Have fun!

It's a distribution completely centered around the Nix package manager. This basically allows you to program how your system should look using one programming language. If you want an identical system, just copy that file and you're set.

Waydroid works, but there's three main things you need to get things going to replicate a typical Android device:

• OpenGapps: For GApps/Play Store. You'll also need to register your device to get an Android ID.
• Magisk: Mainly to pass SafetyNet / Play Integrity basic checks.
• libndk / libhoudini: For ARM > x86 translation. libndk works better on AMD.
• Widevine: (optional) L3 DRM for things that need it, eg Netflix

There are some automated scripts that can set this all up. I used this one in the past with some success.

Also, stay away from nVidia. From what I recall, it just doesn't work, or there are other issues like crashes. But if you're serious about Linux in general, then ditching nVidia is generally a good idea.

Finally, games that use anti-cheat can be a hit-or-miss (like Genshin Impact, which crashed when I last tried it). But that's something that you may face on any emulator, I mean, any decent anti-cheat system would detect the usage of emulators.

By default waydroid uses an x86 android image. Most games are not build for x86.

I have followed this to run an arm android image. https://wiki.archlinux.org/title/Waydroid#ARM_Apps_Incompatible

With that, I was able to install all apps.

Try Android Studio

Most probably, no. I tried to run bluestacks on wine. Some game works, most of em don't

Android apps are sandboxed by default while packages on Linux run with the users permission.

There is already something like this with Flatpak since it also sandboxes every installed program and only grants requested permissions.

Because it requires a very specific framework to be built from the ground up, and FDO doesn't specify these. A lot of breakage would happen if were to shoehorn such changes into Linux suddenly. Android has many layers of security that they're fundamentally different than that of the unix philosophy. That's why Android, even if it's based on Linux, it's not really considered "a distro".

It is technically doable, but that would require a unified method to call when an app needs camera, and that method will show the prompt.

This would technically require developers to rewrite their apps on linux, which is not happening anytime soon.

Fortunately, pipwire and xdg-portal is currently doing this work, like when you screen share on zoom using pipwire, a system prompt will pop up asking you for what app to share. Unlike on Windows, zoom cannot see your active windows when using this method, only the one that you choose to share.

Most application framework, including GTK and electron, are actively supporting pipwire and portal, so the future is bright.

There is a lot of work in improving security and usablity of linux sandbox, and it is already much better than Windows (maybe also better than macos?). I am confident, in 5 years, linux sandbox stack (flatpak, protal, pipewire) will be as secure and usable as on android and ios.

Sandboxing wasn't considered during development of Linux. But recent development incorporates this practice and can be found for example in flatpaks.

Flatpaks get permission though XDG-portals. The difference is there are usually no popups

Software changes. Version 0.5 will not have the same features as Version 0.9 most of the time. Features get added over time, features get removed over time and the interface of a library might change over time too.

As a software dev, the only thing you can do is keep the same API for ever, but that is not always feasible.

Because it's not guaranteed that it'll work. FOSS projects don't run under strict managerial definitions where they have to maintain compatibility in all their APIs etc. They are developed freely. As such, you can't really rely on full compatibility.

That's the same on ANY platform, but windows is far worse because most apps ship a DLL and -never- update the damn thing. With Linux, it's a little bit more transparent. (edit: unless you do the stupid shit and link statically, but again in the brave new world of Rust and Go having 500 Mb binaries for a 5 Kb program is acceptable)

Also, applications use the API/ABI of a particular library. Now, if the developers of the said library actually change something in the library's behavior with an update, your app won't work it no more unless you go and actually update your own code and find everything that's broken.

So as you can understand, this is a maintenance burden. A lot of apps delegate this to a later time, or something that happens sometimes with FOSS is that the app goes unmaintained somewhat, or in some cases the app customizes the library so much, that you just can't update that shit anymore. So you fix on a particular version of the library.

You sometimes can build software that will work with more than one version of a C library, but less and less software is being written that binds only to C libraries. The key topic you want to look up is probably "ABI stability".

IMHO the answer is social, not technical:

Backwarts compatibility/legacy code is not fun, and so unless you throw a lot of money at the problem (RHEL), people don't do it in their free time.

The best way to distribute a desktop app on Linux is to make it Win32 (and run it with WINE) ... :-P (Perhaps Flatpak will change this.)

If you try a distro that does it by default then it is no more complicated then ext4 for the user. The distro will setup things for you. I know that opensuse Tumbleweed and Fedora Workstation set this up by default. Manually configuring is how ever a bit more complicated.

Albeit not completely beginner friendly, the arch wiki explains btrfs features and manual configuration pretty well. If you are looking for a guide to a snapshot tool, then it depends on your distro, but they probably have an article for it as well (also, check the "related articles" section at the top of the page).

Great question!

EndeavourOS has a great little wiki of tutorials around BTRFS and setting up snapshots, that's a lot more friendly than just reading wiki manuals.

Here's a link to the one about getting snapshots and rollbacks set up.

https://discovery.endeavouros.com/encrypted-installation/btrfs-with-timeshift-snapshots-on-the-grub-menu/2022/02/

Alternatively, I run OpenSUSE Tumbleweed on my main production rig and it uses BTRFS and sets up snapshots from the GRUB menu for you by default!

I'm also using Nvidia, so while it's gotten better and I haven't had to roll back in a long time, Snapper has saved my butt once or twice in the past. ;)

Just install your system on btrfs and figure the rest out later

Because there is only one alternative (Xorg/X11), and it’s pretty outdated and not really maintained anymore.

For now it’s probably still fine, but in a couple of years everything will probably use Wayland.

Wayland has better support for some newer in-demand features, like multiple monitors, very high resolutions, and scaling. It's also carrying less technical debt around, and has more people actively working on it. However, it still has issues with nvidia video cards, and there are still a few pieces of uncommon software that won't work with it.

The only alternative is X. Its main advantage over Wayland is network transparency (essentially it can be its own remote client/server system), which is important for some use cases. And it has no particular issues with nvidia. However, it's essentially in maintenance mode—bugs are patched, but no new features are being added—and the code is old and crufty.

If you want the network transparency, have an nvidia card (for now), or want to use one of the rare pieces of software that doesn't work with Wayland/XWayland, use X. Otherwise, use whatever your distro provides, which is Wayland for most of the large newbie-friendly distros.

It's... complicated. Wayland is the heir apparent to Xorg. Xorg is a fork of an older XFree86 which is based on the X11 standard.

X11 goes back... a long time. It's been both a blessing and a liability at times. The architecture dates back to a time of multi-user systems and thin clients. It also pre-dates GPUs. Xorg has been updating and modernizing it for decades but there's only so much you can do while maintaining backward compatibility. So the question arose: fix X or create something new? Most of the devs opted for the later, to start from scratch with a replacement.

I think they bit off a bit more than they could chew, and they seemed to think they could push around the likes of nvidia. So it's been a bumpy road and will likely continue to be a bit bumpy for a bit. But eventually things will move over.

In addition to the other replies, one of the main draws of Wayland is that it's much less succeptible to screen-tearing / jerky movements that you might sometimes experience on X11 - like when you're dragging around windows or doing something graphics/video heavy. Wayland just feels much smoother and responsive overall. Other draws include support for modern monitor/GPU features like variable refresh rates, HDR, mixed DPI scaling and so on. And there's plenty of stuff still in the works along those lines.

Security is another major draw. Under X11, any program can directly record what's on your screen, capture your clipboard contents, monitor and simulate keyboard input/output - without your permission or knowledge. That's considered a huge security risk in the modern climate. Wayland on the other hand employs something called "portals", that act as a middleman and allow the user to explicitly permit applications access to these things. Which has also been a sore point for many users and developers, because the old way of doing these things no longer works, and this broke a lot of apps and workflows. But many apps have since been updated, and many newer apps have been written to work in this new environment. So there's a bit of growing pains in this area.

In terms of major incompatibilities with Wayland - XFCE is still a work-in-progress but nearly there (should be ready maybe later this year), but some older DE/WMs may never get updated for Wayland (such as OpenBox and Fluxbox). Gnome and KDE work just fine though under Wayland. nVidia's proprietary drivers are still glitchy/incomplete under Wayland (but AMD and Intel work fine). Wine/Proton's Wayland support is a work-in-progress, but works fine under XWayland.

Speaking of which, "XWayland" is kinda like a compatibility layer which can run older applications written for X11. Basically it's an X11 server that runs inside Wayland, so you can still run your older apps. But there are still certain limitations, like if you've got a keyboard macro tool running under XWayland, it'll only work for other X11 apps and not the rest of your Wayland desktop. So ideally you'd want to use an app which has native Wayland support. And for some apps, you may need to pass on special flags to enable Wayland support (eg: Chrome/Chromium based browsers), otherwise it'll run under XWayland. So before you make the switch to Wayland, you'll need to be aware of these potential issues/limitations.

Because the older alternatives are hacky, laggy, buggy, and quite fundamentally insecure. X.Org's whole architecture is a mess, you practically have to go around the damn thing to work it (GLX). It should've been killed in 2005 when desktop compositing was starting to grow, but the FOSS community has a way with not updating standards fast enough.

Hell, that's kinda the reason OpenGL died a slow death, GL3 had it released properly would've changed everything

Wayland vs Xorg is mostly equivalent to a beat up 80's car compared to a brand new car.

Mint would probably work for you. Some stuff is outdated, but it has flatpak which is a package manager with more up to date apps. If you're willing to put in the time though, I'd recommend trying some of the more common distros out (Mint, Debian, Ubuntu, Fedora). You can use a liveusb to test them without installing.

Steam is available anywhere so that's not a problem.

Discord officially only has a .deb package, so that's only for Debian based distros (Debian, Ubuntu, Mint). There are other options for almost all distros though - I personally use Webcord

Fl studio might be tricky - supposedly it runs through wine but you might have to do a bit of work. I've personally used Reaper and I works great.

Adding to what others have said I also think Mint is a great option. But I strongly encourage you to install things via the package manager when available, I find that a lot of times when someone complains that something (that should work) doesn't work on Linux is because they're trying to install things manually, i.e. the Windows way (open browser, search for program name, open website, download installer, open installer, follow instructions), that's almost never the correct way on Linux.

Mint is probably the best install and go experience out there.

As a fellow user in similar situation, i can tell that i had tried dual boot a few times but would just switch to windows when i wanted something done that didn't work on linux

3 weeks ago i went full Mint install and left windows altogether. This forced me to find solutions to problems that i otherwise would solve by just switching to windows. Dont expect everything to work though. You will need to tweak some things and you may even need to do some things differently than youre used to. But isn't this why we change in the first place?

Debian desktop user here, and I would happily switch to RHEL on the desktop.

I fully agree, outdated packages can be very annoying (running a netbook with disabled WIFI sleep mode right now, and no, backported kernel/firmware don't solve my problem.)

For some years, I used Fedora (and I still love the community and have high respect for it).

Fedora simply does not work for me:

• Updated packages can/did break compatibility for stuff I need to get stuff done. Fine if Linux is your hobby, not acceptable if you need to deliver something
• In the industry, many times not the last recent packages of development environments are used (if you are lucky, you are only a few months or years behind), so having the most recent packages in Fedora helps me exactly zero
• With Debians 2 years release cycle (and more years of support), I can upgrade to the next version when it is appropriate for me (= 1-2 days when there is a slow week and the worst bugs have been found already)
• My setup/desktop is heavily customized and fully automated via IaC, no motivation to tweak this stuff constantly (rolling) or every 6-12 months (Fedora)
• From time to time I have to use software packages from 3rd parties, with Fedora, I might be one update way from breaking this software packages because of version incompatibilities (yes, I might pin a version of something to use a 3rd party software, but this might break Fedora updates (direct and transitive dependencies)
• I once had a cheap netbook for travel with an infamous chip set bug concerning sleep modes, which would be triggered by some kernels. You can imagine how it is to run Fedora, when you get often Kernel updates and the bug will be triggered or not after double digit numbers of minutes of work.

Of course, I could now start playing around with containerizing everything I need for work somehow and run something like Silverblue, perhaps I might do it someday, but then I would again need to update my IaC every 6-12months, would have to take care of overlays AND containers etc....

When people go 'rolling' or 'Fedora', they simply choose a different set of problems. I am happy we have choice and I can choose the trouble I have to life with.

On a more positive note: This also shows how far Linux has come along, I always play around with the latest/BETA Fedora Gnome/KDE images in a VM, and seriously don't feel I am missing anything in Debian stable.

Debian systems are verified to work properly without subtle config breakages. You can run Debian practically unattended for a decade and it's chug along. For people who prefer their device to actually work, and not just be a maintenance princess, it's ideal.

Noob question?

You do seem confused though... Debian is both a distribution and a packaging system... the Debian Stable distribution takes a very conservative approach to updating packages, while Debian Sid (unstable) is more up-to-date while being more likely to break. While individual packages may be more stable when fully-updated, other packages that depend on them generally lag and "break" as they need updating to be able to adapt to underlying changes.

But the whole reason debian-based distros exist is because some people think they can strike a better balance between newness and stability. But it turns out that there is no optimal balance that satifies everyone.

Mint is a fine distro... but if you don't like it, that is fine for you too. The only objection I have to your objection is that you seem to be throwing the baby out with the bathwater... the debian packaging system is very robust and is not intrinsically unlikely to be updated.

Unlike other commenters, I agree with you. Debian based systems are less suitable for desktop use, and imo is one of the reasons newcomers have frequent issues.

When installing common applications, newcomers tend to follow the windows ways of downloading an installer or a standalone executable from the Internet. They often do not stick with the package manager. This can cause breakage, as debian might expect you to have certain version of programs that are different from what the installer from the Internet expects. A rolling release distro is more likely to have versions that Internet installers expect.

To answer your question, I believe debian based distros are popular for desktop because they were already popular for server use before Linux desktop were significant.

As someone not working in IT and not very knowledgeable on the subject, I've had way less issues with Manjaro than with Mint, despite reading everywhere that Mint "just works". Especially with printers.

Because people have the opposite experience and outlook from what you wrote.

I’m one of those people.

I’m surprised no one brought up the xz thing.

Debian specifically targeted by complex and nuanced multi prong attack involving social engineering and very good obfuscation. Defeated because stable (12 stable, mind you, not even 11 which is still in lots of use) was so slow that the attack was found in unstable.

I'm not sure what planet you are on but Debian is more stable and secure than anything I have ever tested. Maybe Debian gets a bad rap because of Ubuntu.

Does Nvidia hate me?

Yes

Timeshift will save you soooooo much pain. Set it up to auto backup a daily image. You can also manually create as many snapshots as you want.

Timeshift has turned system-destroying mistakes I've made into mere 5-10 minute inconveniences. You can use it in the command line, so even if you blow up your whole desktop environment/window manager, you can still restore back to a known gold state.

I create a snapshot before any major updates or customizations.

Timeshift, make sure to "include hidden files" to recover any configuration for desktop environments

After a few mess ups, you may find yourself not needing to backup everything, only the file(s) that messed up, and that's still a good thing to have Timeshift for

you can't stop windows from fucking up the bios. part of what makes a windows update "better" for everyone else is it fucking up the bios for you.

you can make a bootable usb that you're comfortable using and get familiar with pivoting root to your installed unbootable system and using it's grub repair tools.

i haven't worked with a linux system that didn't include an automated utility that allowed you to straighten grub out with one command as long as you can get to its environment in like 16 years...

Depending on your skill level/experience/will to suffer:

• Do every modification via the command line interface and keep notes
• Create an Ansible configuration for your setup and you have
  • Instant perfect setup for your next installation
  • Ability to replicated your current setup exactly in a virtual machine, tweak it to your liking in the machine via Ansible and replicate your config back on the metal

Launching windows from the bootloader instead of the grub menu should help stop the issue with windows.

The general answer is to enable the RPM Fusion repos. But that won't automagically install the drivers for you, you'll need to manually identify what's needed and install them accordingly. This guide is a decent starting point: https://www.fosslinux.com/134505/how-to-install-key-drivers-on-your-fedora-system.htm

But also consider simply using a distro/spin that has all the drivers included (or automates the install), such as Nobara, or one of the Fedora Universal Blue distros.

By default, you can just type nvidia in the software store and click install, wait 5 to 10 minutes after it finishes and restart.

But you will need to run one command before you restart, to register it with secureboot:

sudo kmodgenca -a
sudo mokutil --import /etc/pki/akmods/certs/public_key.der

See: https://rpmfusion.org/Howto/Secure%20Boot

I use ublue, so I never need to deal with this.

I have a feeling this is a joke. Either way I'm not following sorry 😭

You remove any installed desktop environment, so you only have a commandline. You also remove any command shell. Can't get any less flavoured than that.

Install Linux From Scratch (LFS). Then you can give it your own flavor instead of someone else's.

Install Mint Cinnamon and then take your pick of the available spices.

Start with a minimalist distro that ships without any desktop environment, of which there are many.

COSMIC DE will be in alpha soon. It's written for Wayland, in rust

There are several wlroot based DE, like river, sway, and hyperland. They are all light, but focused on tiling window management and keyboard navigation. Thus, they are not exactly a LXQT replacement.

Start by checking what windowing system you're using as its a fundamental part of problem solving. It's a little confusing how to do this, the top answer in this Stack exchange thread works well.

If you're running the latest KDE then you've almost certainly been moved to Wayland and that will be the source of your problems. Wayland and Nvidia drivers don't work well together, and KDE have defaulted to Wayland in the latest release. I have had very similar issues to you with the move to wayland and have not been able to fix them - they're too fundamental and depend on updates to wayland and/or Nvidia drivers.

I know you don't want a solution but there isn't one at the moment, so you'd be wasting your time. The solution is to log out, then on the log in screen select Plasma (X11) as your session and log in again.

Personally I have had to abandon KDE as I get a different set of problems in X11. I'm on OpenSuSE Tumbleweed so have little choice inrolling back to the previously functioning version of KDE - I'm using Cinnamon instead and contemplating switching to a different Linux distro, probably OpenSuSE Leap in favour of stability over cutting edge.

Meanwhile I have the latest KDE running on another device with AMD GPU without issue.

In terms of when it'll be fixed, there is a change being made to Wayland which will effect how it and the Nvidia drivers interact (something called Explicit sync). It's just been merged into wayland so presumably will appear downstream in the coming next few months in rolling distributions. There have been articles suggesting this is going to fix most problems but personally I think this is a little brave but fingers crossed.

Look in /var/log/Xorg.0.log for Xorg errors.

Check if OpenGL is okay by running glxinfo (from the package mesa-utils) and checking in the first few lines for "direct rendering: Yes".

Check if Vulkan is okay by running vulkaninfo (from the package vulkan-tools) and seeing... if it throws errors at you, I guess. There are probably some specific things you could look for but I'm not familiar enough with Vulkan yet.

You could sudo dmesg and read through looking for problems, but there might be a lot of noise to sift through. I'd start by piping it through grep -i nvidia to look for driver-specific stuff.

Might be worth running nvidia-settings and poking around to see if anything seems amiss. Not sure what you'd actually be looking for, but yeah.

Sometimes switching from linux and nvidia to linux-lts and nvidia-lts can help if the problem is in the kernel or driver. Remember to switch both of these at the same time, since drivers need to match the kernel.

You could also try switching from the nvidia drivers to nouveau. Might offer temporary relief and help narrow down where the problem is, at the expense of probably worse performance in heavy games. Ought to be fine for 2D gaming and general desktopping.

Trying a different window manager is always an option. Don't know how much hassle that is when you use a full DE; I've always been the "just grab individual lightweight pieces and slap 'em together" sort so I don't have any real experience with KDE. But yeah. Find out what the right way to change WM is for your system, then try swapping over to Openbox or something minimal like that and see what happens.

Related to WM/DE, it could be an issue with the compositor maybe. Look up whatever KDE's compositor is and see if you can turn it off and run a different one?

Use gparted live to shrink/expand partitions

You can move partitions so they are next to each other and then expand. The easiest way Ive found is to boot a love USB distro, since the partitions can't be mounted when you do it. Open parted and you can resize and move around.

Backup before you do it!

If they are LVM volumes, it would be possible. Otherwise, you can move the directories you want to the new partition and use symbolic links to point to the new places. Then again some things aren't correctly designed, so they may have problems with symbolic links and YMMV.

I don't think there really is an easy way to do this. For sure not as easy as reinstalling.

As an Arch user (btw), that's rarely an issue thanks to the AUR and it's vast package pool :) But on the very rare occasion that it's not there on the AUR but available as a deb, I can use a tool called Debtap to convert the .deb to the Arch's .tar.zst package.

For rpm-based distros like Fedora and OpenSUSE etc, there's a similar tool called alien that can convert the .deb to .rpm.

In both instances though, dependencies can be a pain, sometimes you may need to trawl thru the dependencies and convert/install them, before to do the main package.

Ideally though, you'd just compile from source. It used to be a daunting task in the old days, but with modern CPUs and build systems like meson, it's not really a big deal these days. You'd just follow the build instructions on the package's git repo, and usually it's just a simple copy-paste job.

Finally, if these packages are just regular apps (and not system-level packages like themes etc), then there are multiple options these days such as using containers like Distrobox, or installing a Flatpak/Appimage version of that app, if available.

I typically search the package name + fedora, it will probably tell me the alternative package that is in fedora.

Nowadays, I have moved to an atomic fedora distro, so I would severely limit the amount of package I install on my system for stability and security.

I think I only have two packages installed on my machine: fish, because it is the only popular shell that follows xdg dir; and a latex-like input method to use in slack.

My first step is usually to figure out whether the package should exist as a separate entity under Gentoo (which, for instance, doesn't have separate dev packages). Then I check the overlay masterlist to see if there's an unofficial package (which there often is).

If there is no package, I can package it myself (since I've been working with the same distro for years and can handle the basic packaging cases), install from source, get the .deb and apply alien or deb2targz and proceed from there, or give the whole thing up as a bad job.

Back in my slackware days I’d just convert other distros packages to the tgz format or compile the package and its requirements.

If the dependencies were really complex I’d draw a picture to help me understand them better.

I usually look at their GitHub or what have you to see if there are packages or instructions there. I have been able to solve most issues this way. Otherwise I see how much of a bitch it will be to compile from source. Depending what it is, I also check to see if there is a docker image instead.

I'm not super familiar with ZFS so I can't elaborate much on those bits, but hardlinks are just pointers to the same inode number (which is a filesystem's internal identifier for every file). The concept of a hardlink is a file-level concept basically. Commands like lsblk, df etc work on a filesystem level - they don't know or care about the individual files/links etc, instead, they work based off the metadata reported directly by the filesystem. So hardlinks or not, it makes no difference to them.

Now this is contrary to how tools like du, ncdu etc work - they work by traversing thru the directories and adding up the actual sizes of the files. du in particular is clever about it - if one or more hardlinks to a file exists in the same folder, then it's smart enough to count it only once. Other file-level programs may or may not take this into account, so you'll have to verify their behavior.

As for move operations, it depends largely on whether the move is within the same filesystem or across filesystems, and the tools or commands used to perform the move.

When a file or directory is moved within the same filesystem, it generally doesn't affect hardlinks in a significant way. The inode remains the same, as do the data blocks on the disk. Only the directory entries pointing to the inode are updated. This means if you move a file that has hardlinks pointing to it within the same filesystem, all the links still point to the same inode, and hence, to the same content. The move operation does not affect the integrity or the accessibility of the hardlinks.

Moving files or directories across different filesystems (including external storage) behaves differently, because each filesystem has its own set of inodes.

• The move operation in this scenario is effectively a copy followed by a delete. The file is copied to the target filesystem, which assigns it a new inode, and then the original file is deleted from the source filesystem.

• If the file had hardlinks within the original filesystem, these links are not copied to the new filesystem. Instead, they remain as separate entities pointing to the now-deleted file's original content (until it's actually deleted). This means that after the move, the hardlinks in the original filesystem still point to the content that was there before the move, but there's no link between these and the newly copied file in the new filesystem.

I believe hardlinks shouldn't affect zfs migrations as well, since it should preserve the inode and object ID information, as per my understanding.

I believe that zfs has its own disk usage utilities

pxe net boot

set up a pxe boot server, set all computers to be imaged to boot over pxe, point them at the server and away you go

I have had issues with using a NAS over SMB because of some malarky about reverting to SMB 1.0 or something. Dunno; I stopped backing up to my NAS and just use external drives.

I'm not sure but I think for pika you need a borg server? I use restic for my backups and have only partially looked at borg so I might be wrong

You have a permissions or addressing problem.

If the nas is seeing your systems requests and saying “no”, it’s a permissions problem. If it’s not seeing your systems requests then it’s an addressing problem.

You can freely manipulate NTFS in Linux. Just make sure your distribution has, after kernel >=5.15, enabled it, otherwise you may need to install the ntfs-eg driver. Other than that, Ach Wiki has info that may help you on any distro:

https://wiki.archlinux.org/title/NTFS

I have done something similar to what you want to do, just needed the ntfs-3g driver installed and "Disks" (gnome disks) application would mount/read/write the disks as usual

I was read/writing on NTFS partitions back in 2004, so your information that Linux doesn't work with NTFS is at least 20 years old.

You can test it from a live usb, generally ntfs works okay though.

linux can read and write ntfs, edit partition tables and resize ntfs partitions

you could (theoretically, do not do this!) free up 8gb of space on your ssd in windows, defragment it then boot a linux installer and use it to shrink the ntfs partition and install ilnux in that 8gb.

It depends on exactly how you plan to do things. The Linux kernel supports reading NTFS but not writing to it. I’m not sure exactly how full your drives are, but you might be able to consolidate some before installing Linux.

There are a couple utilities that let your mount an NTFS file system for read & write, but I wouldn’t trust them for important data.

Edit: This is outdated as of like 2021. Don’t listen to me

The rtl 8125 works