I am a Linux beginner/amateur and I have sort of had enough of copy and pasting commands I find on the internet without having a good understanding of how they actually work.

I guess my end goal is to be able to comfortably install and use arch Linux with my own customization’s and be able to fix it when things go wrong.

What tips/ideas do you have for getting better at navigating the terminal, and getting a better understanding of how the os works. What is a good roadmap to follow? And how did you, advanced Linux user, get to the stage your at now?

Edit: my current distro is bazzite just in case you were interested and thanks for all the replies you are all really helpful.

  • NiaKitty@beehaw.org
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    5 days ago

    Just giving my +1 about what others have said:

    in terminal man to get an overview of a command and usage, tldr.sh is a “tldr” of those same man pages simplified and very user friendly, and apropos to search man pages by description to find tools that do what you wanna do.

    Ex usage:

    man ls gives an overview of how ls works

    tldr ls gives a quick user friendly overview of how ls works (after installing it, or using the site tldr.sh)

    apropos compress will search man pages and output a list of commands that have “compress” in the description

    Linux has an overwhelmingly large amount of commands or things you can do, it’s good to learn a subset of common things, but arguably more important to learn how to quickly find info on the fly using tools like the above to reference as you do things. I’ve used Linux for about a decade, but still only use the same 5-10 or so commands regularly in the terminal, and look up anything else whenever I need.

  • blob42@lemmy.ml
    link
    fedilink
    arrow-up
    16
    arrow-down
    2
    ·
    5 days ago

    start from man man and learn to use man pages. Get used to lookup man pages for any topic before checking on the internet

    • stinkape@lemm.ee
      link
      fedilink
      English
      arrow-up
      10
      ·
      5 days ago

      This is it. You’re likely not going to get away from needing help from time to time. Instead of focusing on trying to know everything, focus on knowing where to find what you need. It’ll click from there with time.

    • ouch@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      5 days ago

      Learning to read manpages is honestly the best advice. They are pretty dense in information, so maybe that’s why some people go to great lengths to run circles around them looking for inferior sources of information.

  • boredsquirrel@slrpnk.net
    link
    fedilink
    arrow-up
    41
    arrow-down
    1
    ·
    edit-2
    7 days ago
    1. You can always use man command and just read through it. If you want less text, use curl cheat.sh/command (learn how to use aliases) or the tools tldr and cheat
    2. Install the fish shell, it makes using the terminal waaay easier, out of the box.
    3. Install Alpaca flatpak, and use tinyllama or bigger LLM models. Tinyllama is already very sufficient at explaining linux commands and more, and runs fine on my reasonably powerful and modern laptop. Other models may be slow as fuck.
    4. Use the terminal only. Log out, Ctrl+Alt+F2 and login, then use some tools.
    $pwd
    cd
    echo
    ls
    cat
    nano
    less
    more
    chmod
    chown
    #your package manager
    lsblk
    dd #be careful!
    udisksctl
    lsusb
    lspci
    curl
    wget
    ...
    

    Note: use the man for these tools and often multiple tools do the same thing

    1. There is this online terminal game/quiz but I cant find its name.
    • thingsiplay@beehaw.org
      link
      fedilink
      arrow-up
      16
      ·
      6 days ago

      Install the fish shell, it makes using the terminal waaay easier, out of the box.

      Not a good idea if the goal is to learn more about Linux. Fish is not compatible to and is different to Bash in some ways, that it would be hard once not using Fish. Also getting help or sharing scripts with others will be problematic, when having a problem and researching it. For someone coming in to Linux and wanting to learn about it, I highly recommend to learn about Bash first and use it at least for months before even thinking about a custom shell. I used Fish too (and I miss some features), so its not like I wouldn’t know what it is.

      Install Alpaca flatpak, and use tinyllama or bigger LLM models.

      Alpaca is nice. GPT4All is also another one (and one that I prefer). Either way, both are good. But again like previous point, I do not recommend to install and use Ai modesl (LLMs) to learn about Linux and to get used to it. Especially the smaller models often hallucinate and lie with false claims. If you don’t know it better and are currently learning, this could be a problem. I highly discourage from installing and learning with an Ai model alongside when you are new to a topic like Linux. Its also not like there wouldn’t be enough good material out there anyway.

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        3
        ·
        6 days ago

        Fish is just a shell, you can still write and execute bash scripts

        Fish is rewritten in Rust btw

        Also the syntax is waay better, it should totally replace bash

        • thingsiplay@beehaw.org
          link
          fedilink
          arrow-up
          5
          ·
          6 days ago

          My point is that Fish is not standard Linux tool. If the goal is to learn more about Linux, it makes more sense to learn about Bash first. I’m not against Fish. For a newcomer its just confusing when researching stuff or reading others scripts in Bash and constantly think about the differences in Bash and Fish. Or if you want to share a script with someone who does not have Fish. I’m not saying Fish is bad or anything like that. I’m just saying for a newcomer its not a good idea to ignore Bash and learn Fish first for someone who is interested into learning more about Linux and its eco system. Fish itself has the better language, no doubt about it and is actually better than Bash. But the quality is not my main concern in the reply.

          • boredsquirrel@slrpnk.net
            link
            fedilink
            arrow-up
            1
            ·
            6 days ago

            As I said. Fish can just be a shell. I only write bash scripts. All bash scripts have #!/bin/bash at the beginning so it doesnt matter.

            I dont know about fish errors. If something doesnt work, I enter bash and then run it again. I enter exit when I am done.

            That does happen but the workaround is easy

            Apart from that, instant suggestions, history, arguments and available commands already help a lot.

            • thingsiplay@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              5 days ago

              Fish can just be a shell. I only write bash scripts.

              That’s the exact problem. You deal with two languages. I did that too BTW. Now for someone who is experienced, its fine. But for someone who just started learning about Linux and scripting, its not ideal, as it adds unnecessary complications and friction for a learning process that is already complicated. Because learning Bash is a must do in my opinion. Regardless what custom shell you use.

              After that learning process and getting familiar, one still can decide to use Fish as the interactive shell. But that’s AFTER the initial learning process of the basics of Linux.

              • boredsquirrel@slrpnk.net
                link
                fedilink
                arrow-up
                1
                ·
                5 days ago

                I dont get why you shouldnt use fish to run your daily commands, and bash for the scripts. I rarely do anything fancy in the terminal that would be bash specific.

  • fragrantvegetable@sopuli.xyz
    link
    fedilink
    arrow-up
    18
    ·
    6 days ago

    Haven’t seen anyone mention https://overthewire.org/wargames/bandit/ yet. It’s a Linux shell game where you need to solve problems using shell commands that only requires an ssh client on your machine: you ssh into the first server, solve a problem, and the solution points you to the next server. It starts easy (e.g. read out this file using cat) but gets hard quickly. But you can always look up solutions when you’re stuck. It gives a good idea what certain commands are used for and how they can be combined in powerful ways.

    • Yppm@lemy.lol
      link
      fedilink
      English
      arrow-up
      3
      ·
      6 days ago

      This reminds me of a site called hackerslab back in the 2000s. I think you had to ssh in to some Korean server and try to get the password for the next level.

      • pineapple@lemmy.mlOP
        link
        fedilink
        English
        arrow-up
        2
        ·
        5 days ago

        Wait I did this to my main drive everything went black is this suposed to happen? will it start working again?

        • Blisterexe@lemmy.zip
          link
          fedilink
          arrow-up
          1
          ·
          5 days ago

          in case you aren’t joking, rm -rf / (albiet with a warning now) will delete allll the files on your system, so everything going black is the expected result.

          rm is remove, the - is to indicate that you want to pass arguments, and r&f are recursive (delete stuff in the folders in this folder) and force (don’t ask for confirmation). The slash afterwards designates the root folder, the folder with everything in it.

          So “rm -rf /” means “remove, recursively and forcefully, everything in the / directory”

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    27
    ·
    7 days ago

    Just don’t copy paste the commands. Really! Just take the time to understand what the command does, read the manual, and rewrite it yourself instead of pasting it. That alone will help a fair bit and can start guessing what it should be.

    After a while of doing that it stops being a “paste this command to make the service run” and becomes “ask systemd to enable and start the service”. You start associating editing files in /etc with “will probably need to slap a sudo in front of that one”, you start mentally replacing nano/vi/vim/emacs/nvim/sed with your preferred way of editing the file, because you absorb the concept of “this command edits a text file”.

  • kyub@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    6 days ago
    • To learn Arch, install it from scratch (without archinstall), it’ll force you to read the Wiki and learn a lot of necessary commands in the process. After the installation, just keep using it. Using a Linux distro full-time as the only installed OS is the best way to keep at it and truly learn it over time. There’s no magic bullet here. Just keep using it and solving problems or issues as you go, learning more and more stuff as you go. If you need other OSses as well, run those in a VM. I don’t recommend dual-boot setups.

    • Don’t blindly copy/paste commands you don’t understand. Always try to understand them first. Some commands can be very disruptive or even destroy your configuration. If you don’t understand it or are able to adapt it so that it fits to your particular configuration or system, you can EASILY damage a configuration, or even make your system unusable. Also, some people like trolling other people and deliberately share harmful commands. Generally, test potentially destructive commands or complex commandlines before actually running them.

    • Document major config changes that you do. This is useful because you’ll be able to undo certain changes or even replicate your current system configuration fast when you change distros or have to reinstall in the future. For example my current Arch-based setup is fully documented in form of an almost-directly executable shell script. It does require some interactions but very little. If I ever have to reinstall this system, or upgrade my hardware, it can be done insanely fast and it’ll have the exact same configuration. This goes from basic partitioning and encryption all the way up to dotfiles and individual program configurations.

    • Don’t feel the need to learn hard/advanced tools like Vim or Emacs unless you really think you’re getting an advantage from that and aren’t hesitant to put in the time and effort to learn them. Most people don’t need to use them. They’re amazing tools but you need to be prepared to lose quite a lot of time to learn them before you can become productive with them, and this might not be a tradeoff that’s useful for every single user. You can also get away with much simpler tools, like nano (as a console-based editor) or whatever programmer’s text editor you want.
    • Similarly, whether a pure WM or compositor plus assorted tools compared to a full desktop environment is worth it for you or not, is up to you. There’s no wrong or right answer here. I’ve tried out pretty much everything and these days use KDE Plasma because I like the consistency and integrations and dislike having different, inconsistent stand-alone tools for panels, menus, notifications, wallpaper, file manager and so on. But again, there’s no wrong or right answer here. Just what makes more sense for you. It’s worth learning how to be able to configure and use a minimalistic setup, for sure. So trying it out doesn’t hurt and increases your knowledge overall. In general, in the Linux world it’s good to always know enough to not be screwed once some component suddenly doesn’t work anymore. For example, a competent Linux user should be able to deal with (temporarily) not having a GUI and fixing his system via commandline.

    • A minimalistic, DIY distro like Arch can be amazing to learn everything, if you want to do that at least. If you just want a working desktop system with as little effort as possible, then don’t do that. But if you intend to learn every detail, then a distro like Arch is better suited for that goal than a “bloated”, fully pre-configured distro like Mint or Ubuntu is. Because Arch is much simpler on a technical level than those are. It’s much easier to understand e.g. the relatively simple package building process on Arch than it is on Debian/Ubuntu-based distros. But this “simple” explicitly refers to technical simplicity or minimalism. Most users expect something else when they hear “something is simple”. Arch is not simple as in beginner-friendly, but it is simple in terms of technical complexity, which is why many advanced users and tinkerers like it because it doesn’t stand in their way. It also means though that you HAVE to learn many things, e.g. how to configure a firewall, because it doesn’t come with any preinstalled by default. With Arch, the admin is supposed to know about everything and configure every component himself, at least on a somewhat basic level.

    • If you want to go to even more details, you could also try out a source-based distro like Gentoo or Crux, which can also be a great learning experience, but it’s even more details regarding compilations of each package, dependencies, compile-time options, etc. you have to deal with than with a minimalistic binary-package-based distro like Arch, so whether that’s useful for you or not is up to you of course.
    • While we’re at it: LFS (Linux from Scratch) is not a distro per se, it’s a guide on how to build your own distribution from scratch. It’s VERY time intensive and not recommended unless you truly want to learn how to build a complete distribution from scratch, or maybe start your own distro some day which isn’t based on another existing distro.
    • Jode@midwest.social
      link
      fedilink
      English
      arrow-up
      5
      ·
      6 days ago

      documented in form of an almost-directly executable shell script

      I’m annoyed with myself for not thinking of doing this

  • Libb@jlai.lu
    link
    fedilink
    English
    arrow-up
    20
    ·
    6 days ago

    I guess my end goal is to be able to comfortably install and use arch Linux with my own customization’s and be able to fix it when things go wrong.

    What tips/ideas do you have for getting better at navigating the terminal, and getting a better understanding of how the os works. What is a good roadmap to follow? And how did you, advanced Linux user, get to the stage your at now?

    You learn by doing and by failing. Like we learned to walk, to write, to drive, to kiss, to speak a foreign language, or even to lace our shoes (and, yep, even that was a heavy trial and error process for toddler-us back then).

    • Install Arch (in a VM, maybe) and while doing so read the Arch Wiki to understand each step, each action and the role of each app you’re asked to install. The Arch Wiki is an impressively well done documentation.
    • Be fine knowing that it will take time to learn anything new (not just Arch, anything), you won’t get good at it the first time. Don’t rush it, take your time.
    • Be fine knowing that you will face issues and will most likely fail at some point, be it to instal Arch or in doing whatever new. There is no other way to learn, for all of us, than by failing and then trying again, over and over. Once again like we learned to walk (by falling on our butt), to lace our shoes (by making a mess) or to kiss (by not doing it great at first).

    Learning takes time and efforts. Perseverance, and humility. There is no shortcut to learning anything that is worth learning, not just Arch. But the reward is also so much worth it. Einstein had to learn calculus, Da Vinci had to learn how to hold a paint brush, and Tolstoy like Flaubert had to learn to write and I’m willing to bet they all made mistakes while they were learning their respective craft.

    Even without referring to geniuses: the first time I tried to install Arch I ran away screaming and swearing I would never touch that thing again. The second time, I had already managed to read a good chunk of the relevant part of the wiki and used it constantly at each step of the process. I still failed at it but at least I understood why I failed and I felt incredibly more… in charge, despite me failing. The third time, I managed to have it running, and to install most the packages I wanted. That was great. There was no fourth time as, as much as I love Arch (which is a lot), I quickly realized using it that constant updates were not what I wanted from my OS and apps (I’m an old-ish user with very basic needs, I’m not even that much of a geek to be honest). So, I switched to the complete opposite of Arch (Debian, another great love of mine I must say). Still, learning and using Arch taught me a lot about Linux in general and about… myself.

    • Strit@lemmy.linuxuserspace.show
      link
      fedilink
      arrow-up
      8
      ·
      6 days ago

      This is really good advise and it all boils down to one attribute. Patience.

      Don’t get disheartened when something does not work the first time. Take a step back. Look at what went wrong and then try again, hopefully without doing the same mistake again.

      Learn the basic tools of Linux and Bash/Posix. cd, ls, cp, mv and rm are some very basic tools, but it is what we use 80% of the time.

      • Libb@jlai.lu
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        6 days ago

        This is really good advise and it all boils down to one attribute. Patience.

        Thx. Yes, patience is key. As is the ability to

        Take a step back.

        Failing is fine because it’s not about us, it’s not personal. It never is. It’s about learning something and about the process.

    • Artoink@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      6 days ago

      I ran Gentoo for several years. It wasn’t Linux From Scratch but it did required a lot of manual work. It also had great documentation. It forced you to learn all of the pieces encompassing the entire OS.

      Arch seems to be the modern equivalent.

    • tmpod@lemmy.pt
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 days ago

      Very useful, even for someone who has been using Linux for many years. Sometimes you just forget or need that tool you rarely use. tldr can be much handier than parsing a man page when you’re in a pinch.

      I use the tealdeer implementation, but any is fine really.

  • Frater Mus@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    6
    ·
    6 days ago

    What tips/ideas do you have for getting better at navigating the terminal, and getting a better understanding of how the os works

    Running an OS as a virtual is liberating. Dive in, make mistakes, fix them (or not and have to reinstall or redo from the last save). No real consequences for exploring.

  • JTskulk@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    6 days ago

    Read and do! If it’s just a toy you play with sometimes, you might find learning harder. I find that making it your daily driver will motivate you to improve and fix things and in doing that you’ll learn.

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    6 days ago

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

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 days ago

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

    • pineapple@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 days ago

      Is bash ultimately better than dolphin or another file manager? 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. 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) 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. Lastly what are some “user friendly by virtiue of having few moving parts” distro’s that you recommend?

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 days ago

        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.

        • pineapple@lemmy.mlOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          6 days ago

          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.

          Yes I am op.

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

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

          Yes cd .. was what I was looking for thanks!

          • TootSweet@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            6 days ago

            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!

            • pineapple@lemmy.mlOP
              link
              fedilink
              English
              arrow-up
              2
              ·
              6 days ago

              Thanks, I guess I will go with x11 with a tiling window manager, I’ve had enough of windows being on top of each other and I like the idea of using my mouse the least amount possible. One last question most apps and packages don’t support pacman sometimes the only option is to install with apt and you download a .dev file is there a way to get around this?

              • TootSweet@lemmy.world
                link
                fedilink
                English
                arrow-up
                2
                ·
                6 days ago

                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.

                • pineapple@lemmy.mlOP
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  5 days ago

                  Thanks for the reply and I will definitely use some of the less advanced options for now.