I’m on Bazzite and would like to install PyTorch. Bluefin provides ujust pytorch, but Bazzite does not.
It seems like this ujust command is not specific to Bluefin’s configuration, so why not make it available to all images?
Also, wouldn’t it be better to create new ujust commands directly in ublue-os/config by default and only move it to specific images when it only works on this image?
There is already duplication with e.g. ujust ollamaon Bluefin and ujust install-ollamaon Bazzite. The code to execute is nearly identical (Bazzite has an additional echo at the end).
Yeah sometimes we prototype fast in one place (Bluefin in this case) to rev fast and see how it works and then move it to config later if we think it’s useful to others. Sometimes this happens fast and sometimes not. I’ve been demoing ollama a ton so it’s easier to rev faster in Bluefin since config has stricter merge requirements.
Please file an issue in ublue-os/config and then someone interested in it will help consolidate it.
sometimes we prototype fast in one place (Bluefin in this case)
Does this mean that the ujust commands should generally be considered unstable?
Maybe an opt-in branch of ublue-os/config could be used for the prototyping and when the command is ready it could be merged into main.
ujust is a collection of shared aliases and workarounds for things that we can’t yet automate and they’re constantly getting improvements and fixes.
Stability depends on what you’re following. ujust update is probably finished but all the AI stuff will probably be churning depending on who is around to help. There’s also a lot happening in that space.
Ideally I think the play is to use just for aliases and fast “I need a thing” tasks, and then as the tooling matures you use it less and less, but we’ll see what feedback we get over the summer! We don’t want to make “new tasksel but it’s worse” either.
Came across this on GitHub issues. It got me thinking just as I’ve been sort of pondering an idea about spinning up a “Bluefin-CX” spin … or rather “Bluefin Creative Experience” - something akin to the Fedora Design Suite with *.just scripts/tweaks relevant to a creative desktop environment (Like DaVinci Resolve by Blackmagic Design software and Desktop Video driver suite installation, which includes DKMS kernel modules, for BlackMagic Design products). But I digress, I’ll leave my thoughts on this in hopes it might benefit in some way …
Maybe this topic requires some attention before it becomes too difficult to fix down the road in the future? For example - Bazzite GNOME (I don’t know if there’s a Bazzite KDE version or if Bazzite Portal is present in other Bazzite versions) has the “Bazzite Portal” which serves as the welcoming initial setup right after the fresh OS install has completed and user has logged in for the first time … and then there’s also the ‘ujust’ CLI - some of the options present in the Portal are not present in the ujust CLI and the other way around. It’s just one example but as you can see it’s already staring to get somewhat tricky and a bit convoluted.
Personally, I think the current distribution of *.just scripts between ublue distros is rather neatly done - there’s the base image configuration, custom scripts and then each distro has additional custom scripts relevant to each of their intended use. The goal is simple - everything applicable to all ublue spins (like additional HW support or fixes relevant to HW) lives in ublue-os / config and anything relevant to each spin lives in the different customized images. And I like the whole idea of these scripts serving as quick solutions to “I need a thing” situations.
But, as pointed out in the first post with the PyTorch and ollama examples overlapping functionality - division of *.ujust scripts living among different ublue spins may pose a limitation to users who may want/need to take advantage of one or many specific tweaks present in different ublue spins. I’ll throw another rather typical example - Bazzite installs OBS and sets up (or it did - can’t seem to find how it’s done) the tweaks like the ‘obs-glcapture’ and ‘obs-vkcapture’ usually it might be more relevant to just gamers and gaming streamers, thus it’s fair to assume it would belong in Bazzite configs… but, what about developers that make How-To YouTube videos, make live streams to Twitch and etc? Surely they would want to have access to these tweaks from Bazzite while they keep using, say Bluefin-DX or Aurora? Or what about Docker and Incus - what if on my weekend I’d like to run a docker container for personal use on my desktop PC with Bazzite, or do quick fixes to stuff I’ve been working on during the week on my work laptop with Bluefin-DX? Installations for both are available in Bluefin, but absent in Bazzite … sure, there’s Podman but I’ll remind that there are situations where you’re just forced to rely on Docker because of a bug or missing feature in Podman (there’s little to none such feature and mostly it’s just initialization scripts for different projects that are hard-coded to demand docker and flat out fail/break with aliased podman).
In the end I’ll finish up my essay by saying this, while end-users (especially the less tech sawy ones that might not think to just grab the *.just script from across the ublue spins and run them with just -f ~/Downloads/##-some-script-here.just) would benefit from having access to all the available tweaks at their ujust fingertips. A counterpoint would be the amount of *.just scripts exponentially growing and getting out of hand. So instead of a short list of quick tweaks/specific fixes end-users get swamped with this massive wall of text with possible options and features. I wish I had a solution to suggest, but I’m afraid I’m stumped which way to go with this. Maybe moving all the generic tweaks into ujust/config and group them by project/purpose … say all Bluefin tweaks are under Bluefin (bluefin-cli, docker, llama, and others), and Bazzite stuff (like gamemode-video, openrgb, gmod-fix and others) would live in Bazzite group. But overall - all these tweaks would be available to all ublue users.
Yeah I think it comes down to what the end image wants to do. It would depend on the use case, Bazzite uses justfiles for features whereas in Bluefin we tend to use it for workarounds.
There’s nothing stopping anyone from moving bluefin/bazzite specific configs to ublue-os/config. Usually they end up in one and if people care enough someone will move it.
For things like docker, incus, etc. the long term solution is likely a sysext (which would include other Fedora images too so they’d be even more generic) so there hasn’t been a real push to do all of that stuff when we’d have to redo it down the line anyway.
Had a look at sysext - this approach certainly sounds very appealing and it would “fix” (it’s not really an issue yet) the discrepancy how the *.just scripts are used among the different spins. It would certainly make it a lot more pluggable and modular (stuff like nvidia drivers could live in their own image extensions rather than having to put them in their own release. EDIT: perhaps a bad example with nvidia drivers which are cumbersome to work with already). And later on different versions would be just same ublue base image with different collection of extensions, based on their respective intended target use.
Maybe it it could be helpful to point out somewhere in notes of ujust or just documentation how scripts could be borrowed from different ublue spins. On the other hand, that may lead to more issues with something along the lines of “Hey, I just ran this insert-link-to-some-Gist *.just script and now my system isn’t booting” … or “Hey I followed this YouTube tutorial on how to install AMD CPU management software and now my Nvidia system is booting to black screen”.
