Have you ever noticed that there are certain directories everyone has? ~/Documents, ~/Downloads, ~/Desktop, and so forth? Some of them you don't need, some of them you might wish were named differently, but any time you rename or delete them, the originals reappear?
You see, these directories follow a standard so that all programs know where they are—with the right tools under your belt, you can customize them.
No need to worry. My suggestion is to begin with a straightforward and user-friendly Linux distribution. Once you become comfortable with the command-line interface and other functions, you can switch to a more advanced distribution. Personally, I utilize the Ubuntu LTS desktop as my primary operating system for completing my tasks. As I am occupied with work, I don't have much time to experiment with the latest technologies. However, your experience may differ.
@nixCraft#Ubuntu was my first intro into using Linux based distros years ago. Used #LinuxMint for a bit (good for transition away from Windows), tried to like #Fedora, went to #Debian for a long while, and now I use #PopOS on a #System76 machine. Recently starting use #OPNsense (a #FreeBSD based router OS). Lots of flavors to fit your needs and tolerances!
I would like to interject for a moment. What you are referring to as GNU/Linux, is in fact, GNU/Linux/Systemd, or as I've recently taken to calling it, GNU+Linux+Systemd. GNU/Linux is not an operating system unto itself, but rather a part of a fully functional operating system that's being run by Systemd. GNU is just a set of core utilities and Linux is just a kernel, while Systemd is another set of utilities that is crucial to the system. Systemd is the initialization system of GNU/Linux, which is the set of tools that starts every other component when the system is booted. Systemd also has other important functions, such as managing user processes, devices, and network connectivity. GNU/Linux is normally used in combination with the Systemd initialization system, but useless by itself; it can only function in the context of a complete operating system. All the so-called "GNU/Linux" distributions are really distributions of GNU/Linux/Systemd.
This is my expression when local (and exclusive) flock() locks on a Linux NFS server don't conflict with POSIX locks obtained over NFS through lockd/NLM/etc. Because these NFS locks may be from flock() on clients.
Augh. This is robot logic and it means 'don't run anything on your NFS servers'.
The interoperability problems are significant. H. Peter Anvin's flock(1) uses flock(2), whereas you are using fcntl(2).
Ironically, this means that #Linux is your worst nightmare, because #Illumos and the BSDs guarantee that those two will (locally) interlock, whereas Linux doesn't and the world has thus got two #flock tools on Linux that don't interlock.
That's going to be a #Unix StackExchange answer somewhen.
Interesting. Another one. At this rate I'm going to have to factor out a list so that I don't keep laboriously repeating the names.
It's worth your having a HISTORY section on your manual page. Speaking from experience of reading HISTORY sections, 20 years from now, people will quietly thank you.
HELLLLL NAAWWWWW this is some bullshit.... I caught my #ISP throttling the connection to the FRICKING #FREEBSD PKG SERVER!
For real, speeds were like 8.3kbps in a fiber connection. And then I confirmed the BS by adding a VPN on top and running pkg upgrade again. Boom, back to 1~2Mbps again. Caught 'em Red. fucking. handed.
Why even do this shit? For real. It's just fucking HTTP!
Welp, #FreeBSD ports flavors are under documented. I want to install git-lite from the ports tree, but devel/git-lite was merged to devel/git. I can't just make install there as it'll install the full version, and searching the handbook only turns up how to make a port flavor, but not install a flavor.
I love you, #FreeBSD, but 14 seconds to resume from S3 sleep on my stinkpad X200 (and no option for S1 or S2) is starting to get on my nerves.
Just upgraded to 13.2-RELEASE, too.
Still 14 seconds to resume when opening the lid, but with the added benefit of just rebooting when trying to resume with the power button now.
UPDATE: No more reboot when resuming from S3, that seems to have fixed itself, so that's good, but I have no leads on the slowness of resume.
With the minor note that the root login shell on #FreeBSD finally changed in 2021. I wonder how many books that obsoleted. It had been the C shell for a long time.
In the process of backing up my #FreeBSD laptop and moving back to #Devuan.
I honestly liked FreeBSD. My only complaints were the 14-second resume from S3 (on such an old and well-understood machine, too) and occasional system clock issues (not having a proper real-time uptime vs running-time uptime, occasionally losing the time altogether and requiring a manual ntpdate). Otherwise I would've been comfortable using it much longer.
@RL_Dane I feel you! I took upon a personal challenge to try out #FreeBSD on as much hardware as I could here, but realized that it's way more picky about which ones it plays nicely with. Which is a pity: it's a real solid OS, but depending on your machine... just nope.
I've had it run really well in two machines: a thinkpad and the RPI 4 (where it runs better than Linux). I haven't tried it on a desktop, though, wonder if it's a different world there.
I think I learned a lesson today when attempting to migrate something unproven: For the love of baphomet, test! And test again! I really want to get #mastodon going on #freebsd so I am going to use a spare domain I have for testing stuff called fugazied.com. It's appropriately named. 😹
So I just decided to search for an official #freebsd port of #mastodon and lo and behold there is one. I guess I like overcomplicating things because I tried to do this the hard way. After my kitty doze, it will be mastodon take two!
Welp, I got sick of trying to get FUSE working on #FreeBSD, and now I'm running
tar cf - . |zstd |ccencrypt |dd sudo dd of=/dev/da0
because I'm an utter raving madman. ;)
Addendum: it actually worked, but I had to append some blank space at the end of it to make sure tar wouldn't spit up. I just
dd if=/dev/zero of=blank bs=1M count=100
then, I
cat my-archive.tar.zst.cpt blank |sudo dd of=/dev/da0 bs=1M status=progress conv=fsync
And then I had to learn the hard way that automatically mounting #ZFS without already loading it from the bootloader is categorically impossible on #FreeBSD.
And it seems like this is a wontfix? Like, wanting to mount ZFS pools/volumes automatically without depending on ZFS before init is invoked is just considered… not valid anymore?
I have this #Bash one-liner to get the amount of available memory on #FreeBSD, but I haven't been able to find a similar one-liner for getting the amount of free or used memory. Anyone who can help me out here?
Me and my clumsy wording.
Honestly, I had a lot of hangups with both the Devuan and Debian installers, because I couldn't figure out how to get #libreboot working with true full-disk encryption. It works fine in #OpenBSD and #FreeBSD, but not #Linux, as far as I was able to tell.
I was surprised that Devuan didn't use the same installer as Debian though.
Nevertheless, thanks for contributing to #Devuan! :D
I'll try Devuan next.
So it turns out that yesterday I somehow managed to fix #Gajim on #FreeBSD, which had been broken (not loading the GUI) since I experimented with updates to 13.2 and back.
This time I truly used the hacker spirit, though, because I probably could've done something in the source code to fix (it's plaintext Python, after all), but instead chose the quick path of a hack that turned to work quite great! Maybe I should write it up in my blog.