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.

Instead of installing packages through a package manager one at a time and configuring your system by digging into individual config files, NixOS has you write a single config file with all your settings and programs declared. This lets you more easily configure your system and have a completely reproducible system by just copying your nix files to another nixos machine and rebuilding.

It’s also an immutable distribution, so the base system files are only modified when rebuilding the whole system from your config, but during runtime it’s read only for security and stability.

Subjectively: it is hard to keep my legs shaved

Objectively: there’s never enough programming socks

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.

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.

Kali is a pentesting distro, it’s not designed for malware analysis. The distro you’d want to use for malware analysis is REMnux, but it’s mostly meant for static analysis. Static analysis is fine, but you may not be able to dig deep unless you’re familiar with decrypting code and using tools like Cutter, Ghidra, EDB etc for debugging. Naturally you’d also need intimate low-level coding experience, familiarity with assembly language and/or Win32 APIs (or whatever APIs the malware is using). So this isn’t an area a casual security researcher can just get into, without some low-level coding experience. But you can at least do some beginner-level analysis like analysing the PE headers and using some automated tools which employ signature-based detection, or you could analyse strings and URLs embedded in the malware; stuff like that.

Dynamic analysis is far more easier to get into and more “fun”, but the problem is of course, with most malware being made for Windows, Linux is kinda irrelevant in this scenario. But you could still run Linux as a VM host and run the malware inside a Windows VM. The problem with running malware in VMs though is that these days any half-decent malware would be VM/context aware and may evade detection, so for accurate results you’d really want to run the malware on a real machine, and use tools like procmon, IDA, wireshark etc for analysis. But again, decent malware may be able to evade tools like procmon, so it can get quite tricky depending on how clever your malware is. You’d normally employ a combination of both static and dynamic analysis.

Industry pros these days often use cloud-based analysis systems which can account for many such scenarios, such as Joe Sandbox, Any.Run, Cuckoo etc. These offer a mix of both VM and physical machine based analysis. You can use these services for free, but there are some limitations of course. If you’re doing this for furthering your career, then it’s worth getting a paid subscription to these services.

Coming back to Kali Linux - it’s not something you’d want to install permanently on physical machine, as its meant to be an ephemeral thing - you spin it up, do your pentesting, and then wipe it. So most folks would use it inside a VM, or run Kali from a Live USB without installing it.

There are also alternatives to Kali, such as ParrotSec and BlackArch, but really from a pentesting toolbox point of view, there’s not much of a difference between them, and it doesn’t really matter (unless you’re a Linux nerd and like the flexibility Arch offers). Most industry folks use Kali mainly, so might as well just stick to it if you want to build up familiarity in terms of your career.

As for your Surface Go - you could install a normal daily-driver Linux distro on your Surface if you really want to, and then run Kali under KVM - which is personally how I’d do it. Running Linux on Linux (KVM) is pretty convenient has a very low performance overhead. You can also employ technologies like ballooning and KSM to save RAM, if your system has low RAM.

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

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.

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)

In Terminal land, Ctrl+C has meant Cancel longer than it’s meant copy. Shift + Insert does what you think Ctrl+V will do.

Also, there’s a separate thing that exists in most window managers called the Primary buffer, which is a separate thing from the clipboard. Try this: Highlight some text in one window, then open a text editor and middle click in it. Ta da! Reminder: This has absolutely nothing to do with the clipboard, if you have Ctrl+X or Ctrl+C’d something, this won’t overwrite that.

Old timer here! As many others replying to you indicate, Ctrl+C means SIGINT (interrupt running program). Many have offered the Ctrl+Shift+C, but back in my day, we used Shift+Insert (paste) and Ctrl+Insert (copy). They still work today, but Linux has 2 clipboard buffers and Shift+Insert works against the primary.

As an aside, on Wayland, you can use wl-paste and wl-copy in your commands, so git clone "$(wl-paste)" will clone whatever repo you copied to your clipboard. I use this one all the time

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.

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

Agreed. @cypherpunks@lemmy.ml, I think this would be a great idea - making a weekly megathread for Linux questions, preferably also stickied for visibility.

Are you using Ubuntu Long Term Release or not ?

• I’m subscribed to Ubuntu and Debian announcements via email, and I see much more often Linux kernel updates for Ubuntu than for Debian. It makes me wonder whether the Debian kernel is slimmed down, and that Ubuntu is focused on Enterprises with their kernel.

I wonder, if you are asking two different questions:

1. Why don’t you receive notifications about updated packages?
2. Two: Security and bugfixes

For 1. it depends which desktop environment you use, Gnome/KDE have this update notifications out of the box, for other DEs (Xfce, LXDE, etc.) you might need to enable this with the installation of synaptic or similar.

For 2. Debian stable does not ship bugfixes but Debian stable ships security fixes. I highly recommend to subscribe to Debians Security mailing list, especially for security fixes concerning browsers and other stuff.

Edit: I have enabled automatic updates and I still receive regular notifications via Gnome Software, at least once per week.

Debian favors stability over anything else so the packages are thoroughly tested before release and then only upgraded for security issues, until the next release 2 years later when everything gets an update.

Ubuntu favors releasing more recent package versions constantly throughout the period between major releases.

You can install packages on Debian from the backports repo if you occasionally need an package to be a more recent version.

Another option is to install apps from Flatpak. The apps in Flatpak have their own separate dependency system and can be used on any distro.

If neither of these works for you and you find yourself constantly wishing packages were newer you may want to consider a different distro.

Some people switch their Debian from stable to testing to get similar updates to Ubuntu. You can try that but please understand you may experience the occasional issues.

Be wary of adding external repos (that don’t point to debian. org) because they can mess with the package dependencies and prevent you from upgrading to the next version when it comes out. (This also applies to Ubuntu.)

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.

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

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

A symlink is a file that contains a shortcut (text string that is automatically interpreted and followed by the operating system) reference to another file or directory in the system. It’s more or less like Windows shortcut.

If a symlink is deleted, its target remains unaffected. If the target is deleted, symlink still continues to point to non-existing file/directory. Symlinks can point to files or directories regardless of volume/partition (hardlinks can’t).

Different programs treat symlinks differently. Majority of software just treats them transparently and acts like they’re operating on a “real” file or directory. Sometimes this has unexpected results when they try to determine what the previous or current directory is.

There’s also software that needs to be “symlink aware” (like shells) and identify and manipulate them directly.

You can upload a symlink to Dropbox/Gdrive etc and it’ll appear as a normal file (probably just very small filesize), but it loses the ability to act like a shortcut, this is sometimes annoying if you use a cloud service for backups as it can create filename conflicts and you need to make sure it’s preserved as “symlink” when restored. Most backup software is “symlink aware”.

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

Nope.