j0rge

joined 1 year ago
[–] j0rge@lemmy.ml 2 points 3 months ago (1 children)

Use the distrobox assemble command, that'll let you have an ini file with all the stuff you want and then when the assemble command runs it'll remake the entire thing. Then just toss the assemble in cron and you'll always have a fresh container with your exact setup.

[–] j0rge@lemmy.ml 8 points 3 months ago

Immutable is new to me,

It's best to ignore the whole "immutable" thing as most of the discussion around that is conflating a bunch of other concepts and it just leads to confusion. When it comes to things like host daemons, these systems are designed to deploy daemons the same way as cloud servers, so for mpd it'd be running the service as a container. A quick search of /r/selfhosted shows some options, but I'm on the road so don't have time to recommend a specific image, but generally speaking anything server related is done via containers.

I use the 1password firefox plugin for my password management. There still isn't a flatpak portal that allows flatpaked password managers to talk to flatpaked browsers, that can be a pain point to some people depending on your use case.

As far as how you manage your distroboxes, that's up to you. We differ from fedora here where they default to "just use toolbox" for everything, whereas we default to "just use brew" for everything. I keep an ubuntu and fedora distrobox in case I need to check something from those distros, and arch is a popular choice. If you're happy with your existing distro but want the reliability of atomic updates then this is a good option. For most new users I recommend not caring about distrobox, most of that stuff is for developers or people that know how to linux already and know exactly what they want.

Also, are there any issues with upgrading a distrobox to a new major release over time?

Containers are designed to be ephemeral, so that you can recreate them on the spot when something goes bad. So I never upgrade boxes, I recreate on the spot using my custom configs. That way I have the same experience on all my machines and when something breaks I don't lose any time setting things up again. Distrobox assemble is awesome for this: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?

I don't really layer anything, I use everything via containers or brew. Generally speaking some people might have a few things they have no choice to layer - a good example is a VPN provider that doesn't provide a wireguard config for network manager and instead you have to layer some 3rd party app. But it's also not the end of the world, updates will take longer but 99% of the time I'm asleep when that happens or it happens in the background and is transparent to me. The more you layer the more maintenance you'll have to do when you do upgrades, so if you end up adding a bunch of 3rd party repos it'll behave the same way as a traditional distro and likely need to be babysat.

The system will update all your boxes and your brew packages as well, so whichever one you use you'll never be out of date. Hope this helps!

[–] j0rge@lemmy.ml 24 points 3 months ago (4 children)

I’m unclear how mature the project is and whether it will be updated in a timely manner long term

ublue and bluefin co-maintainer here, we've been around for a while now (3rd birthday coming up!) and have been around in a more unofficial capacity for longer.

Bluefin is feature complete and is in maintenance mode, it's just going to get updated in perpetuity to 41, 42, etc. We invested in automation first so most of the maintenance is automatic and it doesn't take much for our team to do it. Right now most of our major ticket items are waiting for things to finish landing in upstream Fedora, most of which are targetted towards F41. A good portion of the team have been around in OSS for a long time and a bunch of us work in the industry and depend on Bluefin for our jobs, so much so that we have a great working relationship with Framework, so we're supporting those laptops as a community option for them.

Aurora is relatively new, coming in just as Plasma 6 landed in fedora. Most reports with issues we get for it are things like it being a new major release, wayland/nvidia issues, etc.

Hopefully that answers some of your questions, if you have more feel free to ask!

[–] j0rge@lemmy.ml 1 points 7 months ago* (last edited 7 months ago)

Flatcar linux (this is what I use for my NAS/homeserver) and CoreOS are both good.

edit: OpenSUSE has microOS: https://microos.opensuse.org/

[–] j0rge@lemmy.ml 4 points 7 months ago (1 children)

I am unsure of the status of KDE offhand, I'm getting a bit north of 5 hours when on a plane and on wifi.

I would love to find some script or tool that can just grab all my logs and chart them out so people can share their results in a more reliable manner because I suck at keeping track of this kind of stuff by hand.

[–] j0rge@lemmy.ml 16 points 7 months ago (3 children)

I work on this image and daily drove it for a while. It's basically Matt Hartley's TLP power recommendations out of the box (we collaborated on this, he's the Linux support person at Framework)

I have an intel FW13 and now prefer the newer gnome-power-profile that we ship instead of the TLP-based recommendations. It has all the latest patches from upstream and it works great on both AMD and Intel systems. I don't personally have an AMD Framework but we have enough people using it to know that the gnome-power-profile setup is awesome thanks to AMD's contributions to gnome-power-profile.

Ideally a Framework image shouldn't need to exist


to make things more complicated Fedora is considering switching to tuned which is another, third power manager which should unify the stack. Universal Blue is currently testing this in the bazzite:testing branch of that custom image and we're hoping to get that feedback back to Framework. Hope this helps!

[–] j0rge@lemmy.ml 1 points 7 months ago (1 children)

Maybe make that clear when someone opens the host terminal on bluefin, or let the bluefin installer give this info to the user.

We're working on a dynamic motd system that will give you some guidance when you first run the terminal. Here's the issue if you have some feedback! https://github.com/ublue-os/bluefin/issues/609

So which one should I use now?

Yeah the reason it's ubuntu by default is that's what the target audience uses, but we've been working on a wolfi/brew distrobox that ends up being a better experience, so we're mulling shipping that by default.

Also, why prefer homebrew over something like nix? AFAIK, homebrew leads to the same dependency issues that the traditional package managers have.

We picked homebrew because it's overwhelmingly the most popular package manager for cloud people and has everything people need. nix doesn't really fit in a container world, but we don't stop people from using it, and with devbox there's at least a common devcontainer pattern people can use. I haven't really run into dependency issues with homebrew but the new bluefin-cli container maintains state and is destroyed/rebuilt regularly so that hopefully won't be a problem.

scattered on the ublue website, blog posts and forum posts.

Yeah this is annoying and we're in the middle of consolidating docs, I'm hoping to streamline it by Fedora 40. I'm also working on a 10m "how to use this thing" video, it's just been hard to spend time on it when we're still making it. We're almost feature complete at this point so I'll start on this soon.

Your starter steps are exactly what we want the default to be, do you think we should say that more strongly? Thanks for your feedback! I think we can clean up a bunch of this stuff to make it easier.

[–] j0rge@lemmy.ml 2 points 7 months ago (3 children)

ublue contributor here. We're set up so you can install any cli program from any distro transparently. Should we outline that more in our docs?

[–] j0rge@lemmy.ml 19 points 7 months ago* (last edited 7 months ago)

the package entropy over time will get me the very dependency issues that Flatpak wants to solve.

You can declare your distroboxes so that they get created regularly from scratch instead of upgrading in place: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

That way the entropy never hits you. Then use the Prompt terminal https://gitlab.gnome.org/chergert/prompt to make it just part of your terminal ootb.

[–] j0rge@lemmy.ml 2 points 7 months ago (1 children)

I didn't use any flatpaks on the workstation install. I'm about three years with this setup on 4 computers through multiple OS updates, works great.

[–] j0rge@lemmy.ml 2 points 9 months ago

Here maybe it's easier if I just paste in the differences:

  • Ubuntu-like GNOME layout.

    • Includes the following GNOME Extensions:
      • Dash to Dock - for a more Unity-like dock
      • Appindicator - for tray-like icons in the top right corner
      • GSConnect - Integrate your mobile device with your desktop
      • Blur my Shell - for that bling
  • GNOME Software with Flathub:

    • Use a familiar software center UI to install graphical software
  • Built on top of the the Universal Blue main image

    • Extra udev rules for game controllers and other devices included out of the box
    • All multimedia codecs included
    • System designed for automatic staging of updates
      • If you've never used an image-based Linux before just use your computer normally
      • Don't overthink it, just shut your computer off when you're not using it
  • Starship is enabled by default to give you a nice shell prompt

  • Solaar - included for Logitech mouse management along with libratbagd

  • Tailscale - included for VPN along with wireguard-tools

  • zsh and fish optional

  • Built-in Ubuntu user space

  • Ctrl-Alt-u - will launch an Ubuntu image inside a terminal via Distrobox and your home directory will be transparently mounted for the Ubuntu image to access

  • A BlackBox terminal is used just for this configuration

  • Use this container for your typical CLI needs or to install software that is not available via Flatpak or Fedora

  • Optional ubuntu-toolbox image with Python, and other convenience development tools. just distrobox-bluefin to get started. To configure just follow the guide.

  • Optional universal image with Python, Node.js, JavaScript, TypeScript, C++, Java, C#, F#, .NET Core, PHP, Go, Ruby, and and Conda. just distrobox-universal to get started

  • just assemble shortcut to declaratively build distroboxes defined in /etc/distrobox/distrobox.ini

  • Refer to the Distrobox documentation for more information on using and configuring custom images

  • GNOME Terminal - Ctrl-Alt-t - will launch a host-level GNOME Terminal if you need to do host-level things in Fedora (you shouldn't need to do much).

The difference between silverblue and your image is that silverblue is signed by fedora and yours isn’t.

Of course Fedora only signs Fedora images, we sign our own images.

There’s no reason for anyone but you to use the image. Even if I were to us tailscale and fish, I’d be better off with silverblue.

Then use Silverblue! If you don't understand the features of something then you might not be the target audience!

[–] j0rge@lemmy.ml 1 points 1 year ago

This is the way I set it up or you could have any terminal that supports a custom command on launch do it: https://distrobox.privatedns.org/useful_tips.html#using-distrobox-as-main-cli

view more: ‹ prev next ›