This confused me at first with Nextcloud also. What I think OP means is that by default the Nextcloud stores the files shared in a database, not the server’s local filesystem. My first question when I setup Nextcloud was literally, "Ok, now that I’ve set things up and got the mobile app accessing it, how the heck to I access those files when I ssh into the server running Nextcloud. You can share directories from the server’s filesystem with Nextcloud. But it’s not obvious at first how to do that, especially if you’re running Nextcloud from a docker container. If you’re used to the way Dropbox works and (almost) the way OneDrive works, this distinction can be confusing and frustrating. It still frustrates me, because it complicates access control over those files and I practically never have a need for the files stored in Nextcloud’s default places. I’m not sharing the Nextcloud instance or the server with anyone else and I want to access files from the CLI always, so I don’t have any use for Nextcloud’s defaults.

All the kids here seem to get really annoyed whenever anyone suggests Ubuntu for “new to Linux” people. My story in particular seems to draw out the trolls, the know-it-alls, and the ricers. I had the same questions as OP 26 years ago, I made the choice you’re recommending (and getting down voted for), I’d do it again, and I have no regrets. Here’s my story anyway in case it resonates with someone.

I picked Ubuntu for my “mostly a server, but sometimes a workstation, sometimes a multimedia PC” before Mint or Arch were even a thing. I knew about and tried Debian, but support for games and hardware at the time wasn’t there for me. Back when we used BitTorrent to literally mostly download Linux ISOs, I was a relatively new Linux user. I’d tried Debian, Slackware, Corel, SUSE, Redhat, etc. Played around distro hopping. But when it came time to build my next machine I landed on Ubuntu LTS mostly because a few important pieces of software I needed to run (paid real money for and needed for university) ONLY came packaged as Deb. Ubuntu turned out to be well documented, well supported, easy to learn, and stable enough that after a decade it was the hardware that failed me, not the operating system. Then, there was the Unity debacle. Then, there were snaps. But, by that time those issues were meaningless to me because I knew I could easily avoid snaps and unity altogether if they bothered me. I never even touched the app store. I guess I stopped caring about the desktop because by that point I was mostly only accessing the CLI remotely or tunneling individual X apps over ssh. When I rebuilt that machine, I considered other options, but ultimately all the choices had mostly insignificant differences except for my familiarity with them. So, I picked Ubuntu LTS again, and it’s been trucking along without getting in my way for nearly another decade.

Arch and those other new distros are interesting. I can see the benefits of that kind of system. But it’s not for everyone. It’s not for me. 99% of users are not going to benefit from bleeding edge software updates. Moreover, there seems to be this widespread misinterpretation that stable and long term release cycles don’t get security updates. These days with snaps, flatpacks, docker, and VMs, running a flashy new bit of bleeding edge software on a long term or stable release cycle distro is easier than it ever has been. It may be slightly difficult for a new user, but it’s still easier than reinstalling and setting up a new distro with a host of undocumented bugs. I can’t even begin to imagine how awful it would be to try to learn about Linux and troubleshoot an issue as a noob in this post-search AI slop wasteland that is the dead Internet.

Anyway, I guess the point I’m getting at is that I chose Ubuntu because it was easy, I chose it again because it continued to be easy, and now that I’ve been using it for a couple decades I’d choose it again because I care more about using my machine than tinkering with my machine. And ultimately, the choice of distro matters a whole lot less when you’re not new to Linux.

Managing windows in a VM with a Linux host on bare metal is long term much more manageable and headache free than dual booting. It’s also a lot easier for Linux to host files to be shared between Linux and Windows than it is to manage a filesystem on bare metal that each alternates access to and to which they can both read and write. Easy sharing of files between systems is going to make the transition a lot less painful. That’s just a lot easier with Linux hosting a VM of windows in my experience. Makes backing up data easier too.

There is plenty of documentation for various options. I have mostly use a mix of samba and NFS to share between various Windows, Linux, Android, and iOS devices for decades. It’s scales well from a single device hosting multiple VMs, to dual booting and accesing shared files on an independent server, to ahomelab with a mix of devices and operating systems, accessing levels, and automatic backups.

Start with the man pages. Running the command man followed by a space and then followed by the command you’re using will almost always give you a man page of the basics of how that command works. The fstab has its own man page too. An internet search “man fstab” or whatever command you’re interested in should also net many mirrors of the those man pages as well.

For me at least, it’s not that you’re asking questions. I answered, so obviously I’m sympathetic to confusion in this area. I’m just trying to encourage you to seek your answers in the documentation and manuals FIRST. The way your question was worded led me to believe that you had not read the manuals at all and were simply copying snippets of code and commands from some random question and answer style forum that did not teach you anything about the fundamentals of what those commands and code actually did. That’s fine too, lots of people started off that way, myself included. Reading the manuals gives you the context to step back and understand how those commands work and what they’re really doing. If you do, you’ll be much better able to troubleshoot your own problems, you’ll be able to ask better questions in forums like this, and you’ll get better and more useful responses.

With all due respect, RTFM. Mount and umount are two sides of the same operational coin. You mount the drive to use it and unmount it when you’re done. fstab is just a file system table used to remember and consistently apply the options used whether you’re mounting the drives manually or telling the system to do it at boot.

Deleting a line from fstab is not the same as unmounting, it is just a shortcut to tell the system how you want that drive mounted when you or the system run the mount command. Mount directories (usually the folders in /media/ or /mnt/ ) also do not get automatically deleted just because you “yanked the drive”. Again, those directories are just where your system is expecting to mount the drive. When the drive is mounted they will be the root path to its contents, when the drive is unmounted they will be empty but they still exist. If your planning on mounting the drive again leave them there. If you’re not planning on mounting them again, delete them.

If you’re not planning on regularly mounting a particular drive, it probably shouldn’t be listed in fstab and you should just run the mount command with the appropriate options (again fstab is just a table for remembering those options for the mount command).

Many desktop Linux distros are also capable of automatically mounting new removable drives in such a way that the user can access them and doesn’t have to worry about touching fstab or the mount directories.

I did say fancy.

Aren’t sqilte files themselves (like most other things) just fancy text files?

The whole article is the why. Not just a single headline-appropriate bullet point.

Just in time for Google to kill RCS and move on to something else.

That view of the driver, looking out from the front passenger side out the driver’s window always makes me anxious for this reason. It’s like Chekhov’s gun. Why would they pick that angle unless the characters were about to get T-boned?

That one actually has some basis in reality though. My terminal still dings at me, it’s just that having it ding too much is annoying and out of fashion now. Does no one else remember PCs piezoelectric beeping, even before you upgraded to an actual soundcard?

No, I don’t use the podcast feature on the Plex. But I do use Plex for listening to audiobooks. Just be aware that MP4/m4b cannot be in the same library as mp3s.

The other podcast thing is a solution totally outside of Plex. It is running on the same machine though and accessing the same files. dir2cast + webserver like Nginx or apache reads a directory of mp3 files and builds an RSS feed out of them. In some ways it works better than Plex because it’s simpler on the user side to listen offline as long as you sync the feed at home. I tend to do a separate feed for each series or author. It’s a bit fiddly to get setup and adding a new feed requires a bash one liner and editing some HTML after the files are sorted and named perfectly because podcast apps have some funny limitations when it comes to actually grouping, sorting, and displaying metadata.

I use podcast addict in much the same way. I can control it using my WearOS watch or even just via the Bluetooth controls of my headphones. I use podcast addict mostly for podcasts (obviously), but I also have (a very manual and kludgey) RSS server at home to feed me and the rest of the home audiobooks via podcast addict. I’ve started to move that listening more to Plex via PlexAmp on my phone, which is also controllable from my watch. The Plex audiobook experience isn’t perfect, but it is a lot easier to manage.

I haven’t found a need or advantage to an external player yet. But, I have found some codecs that the Plex app has struggled with, which might benefit from an external app. I haven’t had the issue in a while though and didn’t think of using the external player then, so no guarantees.

Armchair pseudo-scientific thinking like this was why Mythbusters became so popular. They even devoted at least one episode to this very myth. Spoiler, hydrogen wasn’t what made that particular lead ballon unsafe.

Blocklists are ineffective by design. Each and every member of the swarm can collect all the data necessary to flag you to your ISP. Obviously any professional collecting this kind of data can avoid a blocklist. There is no such thing as a better blocklist.

Teach us then 😭

I think this hits on another big generational difference. Those who grew up in the early days of personal computing and the Internet didn’t have teachers or a hallucinating language model to spoon feed them instant answers. They had to actually RTFM thoroughly before they could even think of asking in some arcane BBS, forum, or IRC for help from elders that had absolutely zero tolerance for incompetence or ignorance. MAN pages and help files came bundled, but the Internet (if you had it) was metered and inconvenient on a scale more like going to the library than ordering a pizza. They had to figure out how to ask the right questions. They had to figure out how to find their own answers. The Internet was so slow that all the really interesting bits were often just text. So much indexed and categorized one might need to learn a little more just to find the right details in that sea of text. There was a lot less instant gratification and no one expected to be able to solve their problems just by asking for help.

I’ve seen way too many kids give up at the first pebble in their path because they are so accustomed to the instant gratification that has pervaded our culture since the dawn of smart phones.

A decade ago we figured out blacklists were ineffective. What’s changed?

Hot take: to Most windows users (not you) probably shouldn’t be able to access power shell or cmd.exe at all.

You could proyget pretty good bandwidth with a tube full of portable digital storage. Latency will suck though.