Just my guess here, but…

The desktop/laptop sort of form factor is associated in people’s minds with unlocked bootloaders. People expect to be able to install Linux on them if they want to. Tablets, game systems, and other sorts of consumer electronics, not so much. I’m thinking Microsoft will do what it can to push hardware manufacturers and the software industry as a whole more in the direction of the kinds of devices that consumers already expect to be locked down like tablets or game systems that are “streaming” game systems. And that way, the bootloader will prevent folks from switching to Linux.

I’m a big fan of jq. It’s a domain-specific language for manipulating JSON data.

ImageMagick is like ffmpeg but for images.

inotify-tools has command-line utilities that can be used in a Bash script or a Bash one-liner to make arbitrary things “happen” when something “happens” to a file or directory. (Then the file is opened or written to or renamed or whatever.)

I probably should mention rsync. It’s like a swiss army knife for copying files from one place to another. And it supports “keeping files syncronized” between two locations.

Of course, there’s tons of stuff that you pretty much can’t talk about Bash scripting without mentioning. Sed, awk, grep, find, etc.

Also, I totally relate about the terminal giving more dopamine. I kinda just hate going on a point-and-click adventure to do things like image editing or whatever. To the point that I’ve written a whole-ass domain-specific-language to do what I want rather than use Gimp. (And I’m working on another whole-ass domain-specific-language to do a traditionally-GUI-app sort of task.)

So, I’ve been using Arch Linux ARM on Raspberry Pis for some “desktop systems” as well as for a janky-ass NAS solution, but that project is kindof dying. They go many months in a row sometimes without any package updates. It’s wild. And when people ask WTF is going on and offer beg to be allowed to help in some way, the admins lock the thread.

So, I’ve been looking to switch my Raspberry Pi’s to something that doesn’t depend so much on some “project” out there to be able to continue to use.

The main Gentoo project fully supports ARM. And even if it didn’t, it’d be a lot easier to use Gentoo without support than Arch.

Switching my main box (not a Raspberry Pi – it’s an x86_64 system) to Gentoo was basically for the purpose of trying out Gentoo again and evaluating whether I want to take the plunge and switch everything to Gentoo.

Aside from that, there’s SystemD which is yucky. (Yes, I know about Artix, but when last I tried it, it didn’t really feel “ready for prime time”. It depends a lot on the main Arch repos.)

Plus, I do kindof like the idea of “more control over my system(s)”. Configuring/compiling my own kernel (yes, you can do that on Arch, it’s much less “in the spirit of” Arch) to make it as minimal as possible and disable everything I don’t need. And of course USE flags are a plus if you want a light system.

Anyway, those are my main reasons.

Me too!

I used Gentoo almost exlusively from like 2003 to maybe 2012 or 2013. I switched to Arch about then. But quite recently I made the switch back to Gentoo on my primary box and I’m happy I did.

Only thing I still need to do to really make it long-term sustainable for my particular use is to set up a build server on my network. My “primary box” is in the room where I sleep and I need it dark and quiet when I’m sleeping. Can’t have MOBO color-shifting LEDs and fan sounds overnight. And I can’t compile something like Chromium in less than the 15-to-16-ish hours I’m awake in a given day. (And I’d prefer to compile it myself rather than using a binary package.) Hence the need for a build server.

I want everything to be owned by myuser, group media

Wait, “everything?” Yeah, that’s probably contraindicated. You don’t want to be changing ownership of stuff in, say, /etc or /bin or whatever to your user. For the most part, stuff in those locations should be owned by root:root. If there are exceptions (things that should be owned by root:<something else>), the package manager will make sure they’re set as they should be.

Whew. My 586 is safe.

That’s awesome! Welcome to the club and don’t be afraid to explore your system and ask questions!

I once tasked the AI DeepSeek

The building of a distro to achieve

With while true ; do beep ; done

As PID 1

AI dubbed the poor distro “Kill Me”

My solution is scp with termux. I can’t suggest any better alternative.

Uninstall it and make the world a slightly better place?

Does it really do any good for the drive to be encrypted if it doesn’t require a password (or Yubikey or retinal scan or other authentication factor) on boot? If you’re just going to put the plaintext key/password on the same drive but in a partition that’s not encrypted, there’s no point encrypting the drive, right?

So maybe “it asks for a password on boot” is more of a “works as intended” thing?

How will I access the encrypted devices after installation? (System Startup) During system startup you will be presented with a passphrase prompt. …

The quote above is from Fedora documentation here

This is your root FS that’s encrypted that we’re talking about, correct?

If you really want an encrypted root but no password on boot and the plaintext decryption password/key on the same drive, there are ways to do it. (It would probably require customizing the initramfs somehow. But it’s Linux, and Linux certainly isn’t going to prevent you from doing such things. Just try to dissuade you.)

If we’re not talking about a root filesystem, that would likely change some things. If it’s Luks, I’m pretty sure it wouldn’t matter particularly where on your filesystem the key was so long as your /etc/crypttab refers to it. I’d say that sort of setup would probably only provide additional security if the encrypted drive is an external drive that you might worry could be stolen or physically accessed when the attacker doesn’t have physical access to your root filesystem.

Also, if you shared what encryption scheme was in use (Luks, Anaconda, etc), that would probably help as well.

Edit: Ah. Ok. You gave more info while I was typing the above response. What you want is unlocking via ssh. For sure.

Great question!

So, first off, if I knew what app(s) specifically you have in mind, that’d help me answer better, but in general:

• First off, I’ll say it’s mostly less that they support pacman than that Arch supports them. There may be some exceptions, but it’s usually Arch developers building the pacman packages rather than the author of the software in question. Even when it’s a proprietary application, it’s usually bundled into a packman package (or at least a PKGBUILD for it lives on AUR, but we’ll get to that) by one of the Arch developers or other volunteers.
• Your first option for software that isn’t in the official Arch repositories is AUR. It’s for packages that aren’t as officially supported as those in the official Arch repositories. Anything in AUR, you’ll have to build the package itself (which usually involves compiling, unless it builds the package from an already-compiled binary), but the process is usually pretty straightforward. (Download and unzip the tarball from AUR somewhere, cd into the directory, and then makepkg -sf && sudo pacman -U <something>.tar.xz. You can also get some helper scripts that do some of those steps for you for convenience. Definitely worth having the experience of doing it manually a few times first, though, I’d say.) Even if the only way to get the software in question from the publisher is in .deb form, you may still find a package on AUR that will unpackage the .deb and package the result up into an Arch package.
• You can run the software in an isolated way. There are snap packages and flatpacks, but… well, there are good reasons why they get a bad rap. Lol. Another option is to build an Ubuntu chroot in which to install the package in there. The cleanest and most straightforward option for running software isolated like this is probably Docker. (Running graphical apps in Docker can definitely be done, though it is a little tricky.)
• You can grab the software in question and install it manually somewhere in your home directory. Somewhere like $HOME/install/<softwarename>. This can work even if the software is only available as a .deb file. You can just extract the .deb without installing it with the command ar x <blah>.deb and a tar -xf data.tar.gz and then put the files from within that .deb file where you want them.
• There are some other options that I’ve never tried (and only learned of just now by googling) that… aren’t recommended. Here’s a link for reference, but to somewhat explain the problems that those approaches there can cause, when you install a package from any particular package manager, the package manager installs dependencies. (Typically those dependencies are shared libraries. Think ".dll"s.) And those dependencies live in specific places. But if, say, you had pacman and apt-get installed on the same system and install the same dependency (including if that dependency is installed automatically as part of installing something else) via both package managers, it’s likely to get one version of the dependency from one package manager and another from the other. Either one package manager is going to error out (“these files already exist in the filesystem, I think something’s wrong that a human should fix”) or overwrite files potentially breaking things. (Now, all that said, I know that pacman is actually in the official Ubuntu repositories and can be installed on Ubuntu alongside apt get. I have to admit I don’t know if and if so how it goes about avoiding problems if both are installed. Maybe it’s not a good idea to install pacman on Ubuntu for the same reason. Who knows!)
• So, there is also the option to write your own PKGBUILD. (A “PKGBUILD” is a script that tells your Arch system how to build a Pacman package. They’re what you download from AUR when you want to build/install something from AUR. A couple of reference links.) It does require doing a little Bash programming, but It’s not as hard as it sounds. (And it’s easier than building Ubuntu packages.) I’ll talk about what to do if you truly can’t get the package in question anyhow except in .deb form. But first, if you can get the source code, you can typically grab a PKGBUILD from the official Arch repositories or from AUR that installs something “similar” to what you’re wanting to install and modify it. (Like, for a simple example, if you’re trying to install something written in C, you can look for a PKGBUILD for something written in C that would probably have similar dependencies.) If you can’t get the source code but can get a compiled distribution of the software in question, you can still write a PKGBUILD, and you’ll probably be able to find some PKGBUILDs to start from that would be pretty similar to what you need.
• If you truly can’t get the software in question except in .deb form and you want to write a PKGBUILD for it, that can be done. It just involves writing a PKGBUILD that extracts the files from the .deb file and then packages them back up into an Arch package. I’ve done this before and I have a funny personal story about that. More info here in an answer to another question in this same Lemmy community.

Just in case it’s useful to you, I’ll share the PKGBUILD I wrote for converting the Ubuntu kernel into an Arch package. It demonstrates how you’d go about extracting files from a .deb file in order to build them into an Arch package.

pkgname='linux-ubuntu'
pkgdesc='The Ubuntu kernel, modules, and headers'
pkgver='5.15.0'
_pkgver="$(cut '-d.' -f 1,2 <<< "${pkgver}")"
_firmware_ver='1.187.29'
_suffix_ver='20.04.2'
pkgrel='25'
arch=('x86_64')
options=('!strip')
url='http://ubuntu.com/'
source=(
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_'"${_firmware_ver}"'_all.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-headers-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-hwe-'"${_pkgver}"'-headers-'"${pkgver}"'-'"${pkgrel}"'_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_all.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-signed-hwe-'"${_pkgver}"'/linux-image-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-modules-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-hwe-'"${_pkgver}"'/linux-modules-extra-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux.preset'
)
noextract=(
    'linux-firmware_'"${_firmware_ver}"'_all.deb'
    'linux-headers-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-hwe-'"${_pkgver}"'-headers-'"${pkgver}"'-'"${pkgrel}"'_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_all.deb'
    'linux-image-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-modules-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
    'linux-modules-extra-'"${pkgver}"'-'"${pkgrel}"'-generic_'"${pkgver}"'-'"${pkgrel}"'.'"${pkgrel}"'~'"${_suffix_ver}"'_amd64.deb'
)
sha256sums=(
    '22697f12ade7e6d6a2dd9ac956f594a3f5e2697ada3a29916fee465cc83a34a1'
    '595794e8ad28ed130af60e6ec8699313e1935ae70f7530a00b06dff67fb4d40e'
    '22dbdc1895f91d3ad9d4c5b153352f1cc8359291dba6ea1a0e683cc6871b0f58'
    '5705cefab39dd5512bcc515918d09153715c7bb365d6bc29cc9b0580e5723eef'
    '3d207388812e957447162c067fb637b4d06eccb4f303b801e8402046a7d3cf48'
    '2f1214dbb04cb47ce8d096bff969fca9c78c26ec21a395c12922eca43cc18e26'
    '75d7d4b94156b3ba705a72ebbb91e84c8d519acf1faec852a74ade2accc7b0ea'
)

package() {
    for f in "${noextract[@]}" ; do
        ar x "${f}"
        tar -xf "data.tar.xz" -C "${pkgdir}"
    done
    rm -r "${pkgdir}"'/usr/share'
    rm -r "${pkgdir}"'/usr/lib'
    mv "${pkgdir}"'/lib' "${pkgdir}"'/usr'
    install -Dm644 'linux.preset' "${pkgdir}"'/etc/mkinitcpio.d/linux.preset'
}

(I omitted the linux.preset file. It’s just in the same directory with the PKGBUILD and it gets bundled into the Arch package. But it’s not really important for what you’re doing unless you’re trying to install a different kernel than the official Arch kernel on an Arch system.)

The part that extracts the files from the .deb packages is the ar x command and the tar -xf command. The package() function there is what decides exactly what files will be in the Arch package and where. And makepkg builds the package archive after running package().

That covers all the options for installing software not in the Arch repos that I can think of.

Yes I am op.

Ha! That’s what I get for posting on Lemmy at 2:00 am. Lol.

So I guess I should just skip anything with a desktop environment like manjaro and just figure out how to install bare arch?

You can certainly start with a bare Arch install and install on top of that a graphical environment. (Without a graphical environment, you wouldn’t be able to run a full-featured browser like Firefox or Chromium or whatever, for instance. I’d think if you intend to use this system as your daily driver – and I’d recommend you do for learning sake – you’ll probably want a graphical environment.) But, yeah. I’d say Arch isn’t that unapproachable to install without going the Manjaro route or the “archinstaller” route.

With Arch, everything’s just packages. The difference between non-graphical Arch and graphical Arch is just that non-graphical Arch doesn’t have any graphical system packages installed.

Now, I keep talking about “graphical systems”. There are two ways to go with that. There is X11 which is mature but a bit dated. And there’s Wayland which is the new hotness but support for it is still a bit lacking, so some features like screen grab may not be supported by all programs and some programs won’t work as straightforwardly on Wayland. (Basically, any time a program grabs an image or video of any portion of the screen of your graphical environment, that uses the “screen grab” API. Wayland does that differently than X11, so a lot of programs aren’t updated to use Wayland’s way yet.)

I guess I’d probably lean toward recommending X11 at this point. I personally use a Wayland compositor (Sway, specifically), but I don’t think running Wayland is going to teach you much that X11 won’t, and running Wayland at this point is likely to introduce frustrating wrinkles. If after you have your Linux “sea legs” you want to try switching, that’s always an option as well.

As for minimal X11 environments, first off, I’d say avoid things that describe themselves as “desktop environments”. They’re likely to hide details from you. Prefer “window managers.” Tiling window managers tend to be more minimal, but if you want to go with a more draggy-droppy, mouse-driven window manager that feels more like what you’re probably used to (but also doesn’t hide details), I’d recommend IceWM.

And, finally, as far as a “bare Arch install”, the place to start is the install guide on the Arch Wiki. It goes step-by-step on how to do things. And take the time to understand the commands you’re running as you’re running them. There are a lot of links in the install guide to more in-depth articles. For instance, the “partitioning” section links to an article called “partitions” that goes in depth on what a “partition” even is.

There’s a lot to learn, but it also pays off. Both in terms of just having the power to do the stuff you want with your own systems and in terms of benefits to your career. And it’s just plain fun!

Good luck! I’m honestly a little jealous of you getting to start this journey for the first time!

Is bash ultimately better than dolphin or another file manager?

1. Yes. (Disclaimer, some statements contain opinion.)

2. OP was specifically asking how to learn more about Linux. And it’s nearly unquestionable that OP is going to learn more about how Linux works if they use the lower-level tools rather than take-you-by-the-hand point-and-click-adventure programs your grandmother could probably figure out.

I always thought that it just seamed slow having to read things out with no icons and having to type the filename instead of double clicking.

So, again, this is just me spouting my own preferences here, but I don’t often touch the mouse. Moving my hand from keyboard to mouse takes time. I can use a keyboard shortcut to open a terminal, cd into the proper directory (using tab complete and set -o vi to make things quicker still), and start dealing with files much quicker than I could navigate a menu to get to, say, Dolphin, wait for it to load (if you use a minimal terminal, it should load basically instantaneously), and then start navigating.

And I have been avoiding installing applications through terminal because I can’t find how to properly uninstall them including all data (the fedora software center does this really easily)

Not sure I can help you there. I’ve never used Fedora. I used CentOS once for a short time, but it was a long time ago and I basically don’t remember it at all.

I have also had some trouble going further back that my user folder in the terminal I still havn’t figured out how to do that.

Like, to the parent directory of your home directory? cd .. should always go to the parent directory of your current working directory. (/ is its own parent, I believe, so you can’t go any further up the chain than that.)

Lastly what are some “user friendly by virtiue of having few moving parts” distro’s that you recommend?

Gentoo and Arch. I’ve never used Void, but it sounds to me like Void is very minimal (has few moving parts) while also being much less of a learning curve than Gentoo and Arch.

When I say “few moving parts”, I mean, roughly speaking, fewer lines of source code. KDE (just for instance) is a huge beast. It tries to accomplish user friendliness by adding layers upon layers of abstraction, in the process obscuring what’s really going on at lower levels from the user. It… doesn’t really work. What it gains you in reduced learning curve becomes an obstacle the moment something goes wrong or you want to peek under the hood. Ubuntu (just as another example) installs tons of stuff to try to shield you from the nitty gritty details. But again, that causes more problems than it solves unless you’re dead set against ever looking under the hood for any reason.

The term “user friendly” tends to mean “my grandmother can use it without having to learn anything in the process.” In the comment about “user friendly by virtiue of having few moving parts”, I didn’t mean “user friendly” in the same sense. I don’t think “user friendly” in the more common sense id mutually exclusive with “fewer moving parts.” At least not in theory. But in practice, that does seem to be the trend.

More than anything, what leveled up my Linux knowledge was switching to Gentoo back while I was in college.

Before that, I used SuSE, and I switched specifically because I felt like I wasn’t learning anything really about Linux just by using point-and-click tools like YAST.

I’ve used Arch for the last… 7-ish years? (Though now I’m basically in the process of switching back to Gentoo. In terms of learning Linux, Arch is… close to as good as Gentoo for that purpose. Not quite as good, but pretty close.)

As for the best approach for learning, though, you know how they say the best way to learn a language is “immersion”? As in, to move to where they speak the language. In the same way, if what you’re going for is to learn, just take a dive. Install Arch over top of your current OS and don’t look back. Just commit to it.

Also, use the most minimal stuff you can. Skip KDE and use dwm. Skip the login manager and start your GUI from the command line. Don’t install a file manager and instead use Bash directly. (It’s more than capable.) Don’t install anything you can do instead with a Bash one-liner or a small Bash script. If after you’ve gotten pretty used to minimal stuff you still want something that the heavier alternatives offer, you can of course switch, but if your aim is to learn, avoid using the kind of stuff that tries to be “user friendly” by hiding all the internal implementation details from you. (Instead use the stuff that is user friendly by virtue of having so few moving parts that understanding how it works under-the-hood is trivial.)

And, don’t settle for “it’s fucked beyond repair.” If it’s fucked, google your ass off. If that doesn’t work, ask on the official Arch forums or here or wherever. (Don’t worry, they don’t bite.)

Remember the “Jitterbug” mobile phone made specifically for older users?

Kindof in the spirit of that.

Don’t hide things in a “start menu” or anything like that. No task bar. Just put a small number of big icons on the “desktop”. Open all applications in fullscreen. Don’t allow two applications to run at the same time. Optimally, the browser wouldn’t be as general-purpose as Firefox or Chromium or whatever. No address bar. Just links to a few bookmarked sites. In fact, no home page on the browser would be good. Just make the websites they have available to go to more icons on the GUI’s main desktop. Don’t make them right-click for anything, only left-click. But make it easy for people’s family to get at the guts, including remotely, to customize the experience for the intended user.

Step 1) Install a file manager…

Oh jeez. I forgot about that. I had that running on my DS back in the day from a GBA flashcart with a big-ass CompactFlash card sticking out the bottom. Good times.

I imagine there was a time when this wasn’t obscure, but I’m guessing people today don’t remember Caldera OpenLinux. That was the first Linux distro I installed/used. A guy from church gave his copy.

Caldera eventually became SCO. But I’m pretty sure I was using Caldera OpenLinux before the whole Novell patent suit thing.