Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AZ
Posts
5
Comments
465
Joined
2 yr. ago

  • Well, if you actually want to invest some time in learning, Arch is great for that, while also being awesome distro. Some say that you should NEVER use it for your first time with Linux, but I disagree. You should never use it if you have short attention span and unable to read, but if that’s not the case, you’re good to go.

    My recommendation is to not try to learn everything at once. Burn archiso on USB stick, boot into it, use archinstall to get in set up easily, and then search ArchWiki for topics of your interest, for instance the installer won’t install printing support, but if you google “archwiki printing” the very first result you get is CUPS page with basically all that you need to get printing up and running.

    During the installation there might be some choices that aren’t entirely clear. For example which graphics drivers to use - it depends on your hardware, if you’re on Intel or AMD graphics, simply select “all open-source” and for nvidia there different choices. If you get to choose option for audio, Pipewire is the best choice. For profile choose desktop and select the one you want. If you don’t know, I highly recommend KDE Plasma, but you might also like GNOME if MacOS is your thing. For networking use NetworkManager for easy integration with your desktop.

    I also recommend installing Flatpak and use it as primary source for installing apps, rather than defaulting to system packages.

    It might take more effort with Arch to get something functional, but it is more rewarding as you can get exactly the setup you want and can learn a lot.

  • Generally the industry shifted in a direction where it heavily relies on containers for running cloud applications. This solves many problems with traditional server systems where you'd be sticking to certain distro, so certain dependencies are in fixed versions, which brings some limitations. Container is an environment to run process in an isolated way so that it had its own root filesystem, its own view on what resources are available, sort of like it was separate machine, but it’s still running on the same machine natively using the same kernel as the host. You can then have multiple of such containers, all serving its narrow purpose and they all come with the complete fs and whatever distro release they are tested with. Nowadays cloud computing is all about containers and they come from images that are built in OCI format using Dockerfile syntax. After building an image, it is typically pushed into registry where it can be pulled from over network to be utilized across different nodes, which makes it pretty easy to scale and propagate changes in cloud environments.

    Now what that means to Bazzite/Universal Blue is that it uses similar tech to deploy the system, though the target here is your local machine. Of course some of the characteristics aren’t relevant in this scenario, but it solves some of the same problem - build predictable and reproducible environment that can be thoroughly tested before publishing. The general idea is similar to how devops build cloud apps: there is CI pipeline that runs the build using giant Dockerfile (or Containerfile, same thing) inside of which they include everything that the system needs (running traditional package manager and act as it was normal Linux distro during the build), which then results as image that’s being pushed to registry. Bazzite users then install updates by pulling new version of the image and 'rebasing' to it. It is called rebasing here, because rpm-ostree lets users add additional layers with more packages on top of that.

    EDIT: here’s the Containerfile I've been talking about: https://github.com/ublue-os/bazzite/blob/main/Containerfile Might give you some idea on how this works.

  • That’s awesome choice, even though I wouldn’t choose Mint for myself at that point.

    It’s really nice you read on Linux, that will help you a lot if you decide to give Arch a try. Don’t bother putting it straight on your hardware. Experiment in VM first and commit to it if you feel confident and like it :)

  • That depends on the graphics driver and API:

    • On NVIDIA it works pretty much seamlessly, though there might be some caveats with vkd3d games. It (nvapi) is now enabled by default in Proton/Wine I think? (someone please correct me if not true)
    • On AMD it works with both radv and amdvlk drivers, though radv is still a little slower than amdvlk/the Windows driver.
  • I saw that right after donating, right after restarting my laptop after long time and seing the notification. I saw the chart and was like “dang, there was more poeple like me, also xmass time or smh” xD

  • No idea why you consider KDE buggy. Maybe the distro you've used ships old version or the build is low quality, maybe it’s the matter of using Wayland vs X11 and outdated NVIDIA drivers? For me, the current Plasma 6.2 is rock solid on multiple machines.

    Other than that, for try this https://github.com/diodon-dev/diodon Or this https://github.com/hluk/CopyQ

  • Steam home console now makes more sense than ever given that the current console generation is sort of ass. A box with gigantic library of games from day 1, supporting all modern TV features, new titles all the time guaranteed, flexibility, not being locked down to just one ecosystem… And if it’s comparable to PS5/Xbox it can get a lot of traction, just like Steam Deck.