NHow do we encourage users to think in containers?
NWe need guides on how to switch a normal workflow from just installing packages, to deciding and planning ahead on where those packages make sense. Examples:
Workflow 1: layer something.
Workflow 2: install Nix packages.
Workflow 3: install Dev softwsre in Fedora container.
Workflow 4: Gaming in an Arch container.
Workflow 5: coming from a Debian based distro? Install and export from Ubuntu container.
Workflow 1: layer something.
Workflow 2: install Nix packages.
Workflow 3: install Dev softwsre in Fedora container.
Workflow 4: Gaming in an Arch container.
Workflow 5: coming from a Debian based distro? Install and export from Ubuntu container.
NWhat gotchas are there with these approaches?
Why would you choose one over another?
Why would you choose one over another?
NWhat is the best way to deploy the exact same configuration across multiple personal machines?
How do we get the average desktop user doing this?
How do we get the average desktop user doing this?
NCan just and fleek be used to make really easy to reproduce builds like what NixOs offers?
One file, one configuration?
One file, one configuration?
NGui tools and scripts are our friends. There's a reason Emudeck is so appealing.
NPain points I've encountered are:
How to/ should you: keep a container pinned in a known good state?
Gtk errors from containerized apps when trying to launch.
Need to tweak/ set up xdg open, and/or allow better cross talk between apps.
How to/ should you: keep a container pinned in a known good state?
Gtk errors from containerized apps when trying to launch.
Need to tweak/ set up xdg open, and/or allow better cross talk between apps.
NClick on link to open browser usually doesn't work with my current setup.
NWe need switching from non Linux, and switching from traditional Linux docs.
NCan/ do distrobox containers create snapshots on updates too?
NShould a container/VM first approach be standardized?
NHow do these new approaches affect running local servers/ self hosting?
NWhat about remote desktop/ management software, how is this affected on an ostree system?
BHow to deploy exact same config simple makr custom image and move as much as you can into it, if you are using distrobox prebuild a container
Lgnome has excellent builtin RDP. gnome connections is also a decent app that's available for interfacing with RDP hosts
Lmay i share some thoughts on the questions above?
NGo right ahead, that's what this is for! 
Lwhat should be emphasised
Lis the customisation aspect while still retaining reliability and stability
Lthe quote unquote gitops approach
Linstead of editing your root system directly you make a fork on github and create an image of your own. in the same manner people should be encouraged to create dev/cli environments using the same infrastructure-as-code methodology. an example: https://github.com/castrojo/wolfikit
GitHub
A blingier starting image for Toolbx and Distrobox. - GitHub - castrojo/wolfikit: A blingier starting image for Toolbx and Distrobox.
Lso basically you create your own distrobox upload it on github as a container image and do
docker pull ghcr.io/image or whatever the distrobox equivalent isLso to get people thinking in containers they need to get used to infrastructure as code and github deployment of their environments. the advantages of this approach should be made readily apparent through propaganda simple to understand documentation
Lthe linux experiment definitely missed out on this
NWhat about offline backups? I know it's possible to self host git solutions. What about doing the same process, but instead of backing up to Github, it goes to a drive on your desk?
Byou can have your own self hosted git, you can host your own container registry...
Lthe perk of using github here is using their infrastructure for building the image (automatically every day) and hosting the package for you. there's nothing that stops anyone from building their ublue fork/distrobox container locally with buildah. it's just way more convenient on github
Bits all selfhostable but great thing about github is its all accessable wherever you
Bi have backup of everything in my personal instance of gitlab and my own registry
NOh believe me, I love offsite backups. I'm just thinking about barriers to entry.
Bgithub has least barrier to entry honestly
Bgithub makes it easy to automate
NIt does, it's still foreign to a lot of users though. I'm thinking long, long term, it might make sense to have a deja dup like tool, but for backing up your images.
NI want people who've never used Linux before to switch to Ublue.
Byou dont really backup images
Bthere is no such thing
Bwe should make better generation of images tools but images are for all intents and purposes disposable pieces important bits are in /var and /etc
NOkay, I see your point. I was using backup in the broader sense of, I have a copy of a desired file or files, stored somewhere safe where I can retrieve or reproduce it.
Lif the problem here is "what if github goes away" then there could be a graphical app made for startingpoint similar to the web installer (https://github.com/orgs/ublue-os/discussions/173) that allows you to build images locally
GitHub
Introduction I originally made create-ublue-image as a way for people (me) to easily and properly set up a repo for building a custom image (based on startingpoint). I always thought that a shell s...
NThe problems are, yes, what if Github goes away, what if I have to work offline for security reasons, what if I'm new and Github scares me. Lol
That last one is more aimed at the person who's never used Linux crowd.
That last one is more aimed at the person who's never used Linux crowd.
Lwhat if I'm new and Github scares me
Lwelllllll
NLol
NMy larger point is that if we provide simple education and more automatic tools, we might be able to make computers less scary for everyone.
Lif you have intentions to customise your setup beyond what ublue/main would provide you'll have to learn a thing or two. similar to how if youre gonna do a cool minimal hacker i3wm/sway/whateverwm setup youre gonna have to learn how to install a minimal system (arch) then build your desktop on top of that
Llike, if you need customisation beyond what gnome/kde already provide (which is a lot, you can do a lot with extensions), or you need an unorthodox package where distrobox would no longer suffice, youll need to learn how to do things the cloud-native way
Lim not saying git gud but
Lum
NRight, I'm just thinking of ways to make it easier for people to git gud lol
NThat's really cool, how does that work? Rather than, I have to figure out how this works so I can see whether it's cool or not.
