Draft: Handing off ublue-os/bluefin and bluefin-lts to the next generation #4951
Replies: 20 comments 40 replies
|
Yeah ... I think the "Rule of Three" makes a lot of sense - prioritize these going forward:
LTS never made sense to me. I'm on Dakota more or less to stay because pretty much everything I do is a flatpak or can be put in Podman rootless containers. About the only things I'm using from Homebrew are Chairlift and Neovim, and the only I do want to test Utah as long as there's a way I can build and install RPMs on my own machine. If I have to make a container to run a source package I don't need the extra complexity over Dakota. |
|
Server has a dino: Armargasaurus, it's the blue one with the spikes coming out of its neck. I think we'd add it to server. Server is a DDI so it will be trivial to switch kernels on it, we won't need to make an image for it. That one will be an LTS kernel with ZFS, which I think is a good place to put it. Good idea! LTS made sense at the time it was the only pure bootc image - it simplified a TON of ublue, we deleted a ton of stuff, which made it's way back to the rest of the bootc world. We deleted a ton of that rpm-ostree jank. |
|
We fixed the VM thing right? Are you able to get your system virt-manager? |
|
I haven't needed one in weeks - I can try it tomorrow. |
Does that mean projectbluefin/bluefin will lose layering at some point? Sadly, this is a critical feature for me. Should I move back to ublue-os/bluefin then? |
|
I guess? Layering is unsupported in both that's a decision you make. |
Sorry if this should be obvious, but does this mean layering is going away in utah as well? I do currently layer in a couple of VPN related RPMs on bluefin. Probably I could figure out how to pass tap/tun, network namespace etc. through to a container if necessary, but I have found layering to work well enough for my purposes so far even if somewhat old fashioned |
|
It would be nice to have a clear status each image : maintained, in dev or soon to be deprecated; there's so much that has been going on recently. The migration isn't going to happen ? What does that mean for ublue-os/bluefin or projectbluefin/bluefin ? Of course I'd be interested in maintaining it, because I have installed it for my whole family and I'm waiting for Dakota to have a stable release to switch everyone to it. I'm just not sure if I'm the most available guy for it. |
|
If you can help, please join the Discord 🙂 |
|
I think that if Fedorafin is to lack official support, it should be deprecated. I understand that many people are still using it, and that providing an upgrade path to Dakota or Utah may not be possible, but letting people run unsupported software on their computer is just asking for trouble. At that point, I feel it's better to just be honest and ask people to migrate. If you lack time and resources to provide support for both Fedorafin and Dakota, that's ok. You are doing this for free, and it never came with a guarantee the project would run forever. Natural selection at work. I'll probably switch over my laptop to Bazzite-Gnome in the near future, even if I prefer Fedorafin, because I know Bazzite won't be lacking support in the next few months/years, and because that laptop needs a custom image in order to connect to my printer. Long live Dakota. |
|
Yeah but there are over 4k weekly checkins, that's about 10k devices. We're not leaving them hanging, a full grace period is prudent. We're working on making weird printer support distro agnostic. |
|
Sure! You need to announce it at least a couple of months before deprecating it if you were to go that way! Like, starting with Gnome 52, you either migrate to Dakota/Utah, because Fedorafin 51 will be the last one to be supported, or something like that. And better doing it while it's still only 10k devices. |
|
"We're working on making weird printer support distro agnostic." Isn't that like the old joke about the guy who wanted a genie to build a bridge to Hawaii? |
|
Thanks for communicating this! 👍️
Giving the users options is good (especially since there are new options available!). For ublue-os/bluefin users, if I understand correctly, the options are:
And current status (please correct me if I am wrong):
|
We would not do bluefin in the new org we would just keep the old one here. We'd be down to two desktop images, dakota and utah. |
|
Thanks for clarifying, that makes sense, no need to duplicate work. 👍️ Easy choice then: Re-install with Dakota. (or choose Utah if you need RPMs) |
|
Hey @castrojo, I want to take you up on the Raid invite. I’ve been daily driving Bluefin for the past 1.5 year, so I know the system well from a user’s perspective. While I haven't maintained an OS image before, I’m ready to roll up my sleeves and learn the ropes. If the offer for tutoring and mentoring stands, I’d love to help maintain ublue-os/bluefin, tackle the issue backlog, and help with the F45/F46 testing. |
|
That's perfect, we have about three or four half interested maintainers, which is more than the original team so it's off to a great start. For now hop in the discord and intro yourself to the others, then we should probably start on F45! |
|
@castrojo I think I can help too. I took a look at the contributing page. I use git, containers, and bash all the time (I use python too). But I'm a beginner when it comes to GitHub Actions. Also, when it comes to supporting ublue-os/bluefin would we get to piggyback on the existing infrastructure plus the new infrastructure that's up-and-coming? For example, you mentioned a software factory. I also think moving to a bst based system makes sense in the end. I think there are a few of us that rely on bluefin's ability to layer 🫤 (I know it's not supported... but I appreciate it) |
|
Funny how the world works. How can i help @castrojo ?! |
|
Linux and dinos?! This one should be fun :) I'm sure I can contribute somewhere as well🫡 |
|
That's great! We can use all the help we can find. Please join the discord 🙂 : |
|
Thank you for this article (and all the effort going into it, I really appreciate it!). Maybe I can explain my situation a bit, as the recent developments around Bluefin made me a bit insecure. I love Bluefin and the Universal Blue idea. For me, the formula is simple: The most clean and modern approach to linux, with batteries included. Coming from Fedora, I opted for bluefin-lts as I want a system that "just works". I don't need to be an early adopter for the newest features, just want to have a reliable (but of course cleanly architectured) OS. I started to question my decision a bit when ublue-os/bluefin-lts stopped getting updates some months ago. For me, this is the exact opposite to what I was aiming for: Suddenly, the OS was not calm, stable and secure, but rather outdated. I then made the premature switch to projectbluefin/bluefin-lts which is better as it gets updates but more often than not, I land in failed boots. So all in all, I am a bit clueless about how to live on. How does my use case fit into the "new world" of three images as outlined by you, @castrojo ? If you guys tell me there is a sensible way to get where I think my use case lies, I am happy to reinstall my system again. Right now, I would just wish for a more reliable Bluefin (and I am deeply grateful for all the work going in and I am sorry that I don't have the capacities to help). Thank you for your time! |
Same here. My reasosing for choosing an LTS variant was using an LTS versions of Ubuntu (and Pop!_OS since 16.04 I believe) for a long, long time. After using Bluefin LTS for a year now I finaly understood what Richard Brown meant by saying that stable software doesn't have to be old. When I asked myself why did I choose an LTS distros in the first place it occured to me that, one of the main reasons, was fear of breaking stuff during upgrades between releases and two year caddence was optimal. For many reasons - that's not the case here. In fact - I think that sticking to LTS base creates more problems than it solves - on desktop at least. |
|
I too am disappointed with the results. LTS did so much for us but delivered the opposite experience of what we intended. There was a sweet 18M or so period where if you put it up next to anything it was no contest. If we found more maintainers it won't take much to keep it around, people stepped up rather quickly for Bluefin! (Check the updated title). @hanthor maintains this still: https://github.com/tuna-os/tunaOS And he maintained old ublue-os LTS. It would be a rebase. However ... the problem with LTS is the use case you get stuck with is the kernel. I naturally cycled out of LTS due to hardware upgrades, as I got new machines in it just became normal. The problem is that this means we double the amount of images for a use case that is covered by Fedora. Aka. "HWE". Then I made it worse by branding GDX, which is just really the nvidia image, adding complication. With the gaming kernel it's easy, you have to have so much crap on the image that making an actual image makes sense. With LTS I just want a good kernel and to not be messed with. On DDIs you can swap kernels but have one image. Then it'd be easy for more people to use it, you default to 6.12 and offer a variety of kernels. Like the Ubuntu LTS one, etc. I'm figuring out how to build a whole collection for Bluefin Server. It's literally "pick any kernel" and the user can swap it out. I know there's an upstream issue for this in upstream bootc. If someone can find it I'd be happy to go upstream asking for it. Then "Bluefin LTS" is quick assembly, it'd be a ton easier to maintain. For me personally, my time with LTS as a model is over. Now that we have a testsuite I see the problem entirely different - proper testing is something the Linux desktop never had before, I am going to optimize for fully automated testing. Check this out: https://github.com/projectbluefin/utah That screenshot is real, something booted that up and tested it. It updates every time and breaks when it doesn't work. To me the problem looks more like this: new thing -> next -> testing -> stable. If this sounds familiar it's the CoreOS model. I think our mission is to put as many tests in all three of those arrows as possible. I think we'll just end up outtesting other things. But LTS and Enterprise Linux make all the money for a reason. What we ended up with was the slowness of CentOS without the commercial might of enterprise testing. No one at Red Hat runs centos desktops they run Fedora. |
|
I'd like to add that the CoreOS people are actively talking about unifying Silverblue and CoreOS, and for CoreOS to deliver a model just like that. I was at that meeting and said something like "People love how flatcar does it: new thing -> Just ship the whole git tree! |
|
Forgot to comment here but I successfully rebased from Bluefin to Utah in Thursday! (I documented my current progress on Discord a lot) 
Of course it's a very new image so many things weren't there yet (especially Bluefin branding bits + only a few extensions works on GNOME 51), but I think a few weeks from now the basic necessities will be covered and rebasing shouldn't really affect anything. I was working on projectbluefin/bluefin, but this post has convinced me to go to Utah and report/tackle issues there instead. It's a nice lighter base. |
My issue with LTS is CentOS - third-party support for CentOS is pathetic compared with actual RHEL clones like AlmaLinux and Rocky Linux. Case in point: the NVIDIA CUDA Toolkit: 
NVIDIA has essentially dropped support for CentOS entirely. |
|
Those same drivers are the ones we were using. |
|
I'd have to do some digging to find the details - NVIDIA used to support CentOS but some time in the last year or so they slowed down and seem to have stopped going forward. They used to ship container images with CUDA runtimes on all sorts of Linux including CentOS. Now it may be just RHEL and Ubuntu. It comes down to testing resources - if they don't have the resources they'll drop less used distros and CentOS is ... less used. |
|
If someone is also looking for another "Classic DLC" quest: ublue-os/uupd is in need of some love. Manual only, we need to ensure we're taking full advantage of that thing it has some great features. That would also help out Bazzite and Aurora! |
|
Thoughts for integration on this new point?: Why two raptors? Let's just kill the idea that any of this matters. You get the exact same stuff on both. This is more about who you roll with. Both will be good. The contributors feel like F1 drivers, we all want our dream livery! (screenshot of livery options in control center) F1 does this all the time. Imagine Bluefin has two cars in F1, it's an independent team but has a Red Hat logo on the rear wing, something where it's an obviously important partnership. But Red Hat also have their own Factory Team. These kinds of technical partnerships are common in racing. Open wheel, endurance, etc. We're both starting to realize that the list of packages and versions are just abstracted away now, which lets us concentrate on the workload. This little gui control panel will really bring some nice features to bluefin without going crazy, we're levelling up our game! |
|
New subthread, we are getting reports of people rebasing to utahraptor so post here if you've tried it! |
|
I can't - both my machines are on Dakota. But I could install Bluefin Classic on the laptop and attempt a rebase to Utahraptor if that's worth the effort. And I still want to call Bluefin Classic "Deinonychus". |
|
|
I can see switching over to Dakota once it is out of the Alpha stage (when will it be in Beta?). Until then, still a little rough around the edges. Plus, no alsamixer installed which allowed me to change the impedance for my headphones and turn on microphone boost. I know of no other way to do that (PulseAudio Control does allow increasing microphone input signal, but I see no means of changing impedance on headphone output.) |
|
Is there something in the PipeWire / WirePlumber ecosystem that can do that? These days, PulseAudio is a mixture of emulations and shims - the audio devices and streams are managed by the PipeWire daemon and sessions by the WirePlumber daemon. The |
You need to file issues for software you need otherwise it's not going to be included. |
|
I would like to have Brave Origin instead of Firefox in Bluefin Dakota. Is it possible to use BlueBuild to build a Bluefin Dakota image with Brave Origin? I made a Bazzite image with Brave Origin using BlueBuild so I'm hoping I can do the same to make a Bluefin Dakota image with Brave Origin. |
|
Why not just, create (or find) a brew tap and fetch/update it from there? That's what i use for Helium |
|
I depend on Fedora tooling, I want its features, how could you deprecate Fedora flagships, if your other images are in Alpha? Most don't even work and you want to push utah, and Dakota, pick a lane, please. And Utah barely even has any packages, it's built on a minimalist distro, I wanted a working developer distro, Bluefin stable provided that. But now it's being phased out |
|
I run Bluefin on a laptop along with Aurora on another dev laptop and Bazzite on my gaming PC. What's nice about Aurora and Bazzite is there's some stability in things and kept simple. It seems like Bluefin has lost some direction and now there are 3 versions going forward: Classic, Dakotaraptor, and Utah. Not to mention the removal of LTS and GDX. You never explained on why you will keep maintaining Fedora version if Dakota is the future. If you are confident, why not just eventually switch Fedora people over to Dakota? If Dakota isn't going to provide the shared base that Aurora and Bazzite have (Fedora), then why even do Dakota? You are also adding gaming features to Dakota when you already have a dedicated Ublue OS (Bazzite) that fits those needs. I did some research on Fedora Hummingbird and it seems like a rolling modal where the devs are taking Fedora Rawhide with an emphasis of fixing CVEs and this goes downstream and maybe back up to Rawhide. Also, Hummingbird may not take all of the Rawhide packages and is meant to be an image based, bootc compliant AI image. With Utah, is it basically taking Hummingbird as the base and the user gets daily updates in a rolling way like an Arch distro? If so with the daily updates, are we still continuing the image based approach? Maybe its like what Valve does with SteamOS by taking snapshots of Arch and then doing releases. If that's the case, why even base on Hummingbird and just stick to the rolling stable nature of Fedora? We already have the bootc setup where we need to reboot to get a new image but we don't have a notifier in place in any of the Ublue systems when that new image is immediately ready. |
I've said this before (maybe not here), they hired the Universal Blue maintainers and I can't stop other Bluefin maintainers from making it can I? I personally won't be doing it, just supporting the people who are.
I can't guarantee that today but we can eventually, I don't see why we would.
We're Bluefin not Universal Blue, different projects. We don't care about distros. I don't want a different UX I just want to turn on a gaming mode and play games. Only Linux users care about that stuff no one else will care - the entire point is to get more users onto OGC kernels.
The shared base is Freedesktop SDK - there's lots of blog posts here on moving to distroless, here's our announcement from December of last year: https://docs.projectbluefin.io/blog/bluefin-2025/#bluefins-distroless-future and the I think we've been pretty loud and obvious about what we're building. Some of you want to keep RPMs. Classic/Utah is your option. It's not the one I use but I can't stop people making what they want - if everyone's getting what they want what's the problem?
As I've mentioned (and has been obvious to anyone paying attention over the past few years), we are a bootc project. I don't care about "Fedora" or any of that crap, we care about bootc, anything that gets us between us and the payload is filler. Distributions are over in this world. Hummingbird is a committed bootc project, the unofficial images from Fedora ARE NOT official, and have NEVER BEEN. Hummingbird is distroless by design. Silverblue has been stagnant for another 5 years on top of the 5 years when we started. GNOME OS is the clear choice, shipping things that are years away on Fedora. Unless you're going to fix it? Hummingbird has the top talent in the bootc world why wouldn't we use it?
It takes 10 minutes to write a service unit to do this, go for it. By default Bluefin doesn't bother users by default. |
|
Thanks for the details @castrojo. I'm really excited to see the Hummingbird integration with Utah. Would you consider promoting the current "classic" Fedora based version as the default download until Dakota is out of alpha? I remember when Pop!_OS released COSMIC as alpha and were suggesting that to people even if it wasn't ready yet. |
|
No, Dakota is the default. There's a link on the website for people who want the Fedora one. What S76 does with cosmic doesn't have anything to do with us. |
|
I totally agree that Cosmic has nothing to do with you. I love Bluefin and I don't want it to suffer the PR hit like Cosmic did. S76 had a public falling out with the upstream Gnome team and decided to go in their own direction and spent forever in Alpha state and when Cosmic became the default for Pop 24.04, it was still in Alpha state and underwhelming. Part of the reason I want to move a parent's laptop from Pop 22.04 to Aurora or Bluefin. I still think that the Gnome Pop was good, but the base is getting old and Cosmic is too inconsistent to hand off to someone without tech knowledge. |
|
hey @castrojo Funny enough, I’m in a very similar position to @nikhil00shinde and I’d also be interested in taking you up on the mentorship / Raid offer. I’ve been daily driving Bluefin for over a year now, and I’ve also deployed it across my entire company. I’ve installed it for quite a few friends as well, so I’ve ended up depending on ublue-os/bluefin quite a bit more than the average personal desktop user. For the kind of gaming most of us actually do, which is mostly browser games and some Dota 2, Bluefin has also always felt like the better fit. Bazzite is great for what it targets, but for our use case a lot of the extra gaming-specific tooling just felt unnecessary, while we really enjoyed the devtooling setup on Bluefin, so Bluefin ended up being the cleaner everyday desktop for both work and light gaming. Over the last 4-5 months I’ve spent a lot of time fixing our own local user experience because parts of Bluefin had started feeling stale or rough around the edges. That eventually pushed me from just being a user into actually digging through how the images, Homebrew integration, containers and the rest of the stack work, and recently into contributing fixes upstream as well. Long term I’m completely open to where Bluefin is heading. I’ve been following Dakota, Utah and projectbluefin/bluefin closely and I’m very interested in all of them. Right now though, ublue-os/bluefin is still the system I can actually rely on. I’ve tried rebasing my Dell Precision 7560 with NVIDIA to projectbluefin/bluefin and the experience was considerably rougher for me than current Bluefin. I’ve also tried Dakota, but so far I haven’t been able to boot any of the Dakota ISOs on that machine at all. They do boot on my AMD gaming PC, but I’m not comfortable moving my work machines or company systems onto alpha or beta releases yet. So realistically I expect to remain on ublue-os/bluefin until projectbluefin/bluefin, Dakota or Utah reaches the point where I’m comfortable deploying it to machines I depend on every day. That also means I have a pretty strong interest in keeping Classic healthy during that transition. I’ve actually been in the Discord for quite a long time as well. I’ve chatted a few times, but mostly I kept quiet, watched, learned and tried to figure things out on my own. For a long time I felt a bit out of place because I didn’t really understand enough of the system or how everything fit together to feel like I had much useful to contribute. I don’t really feel that way anymore. I still haven’t maintained an OS image before, and there’s obviously plenty I don’t know, but after spending the last several months digging into the stack, fixing things for our own systems and recently even contributed upstream brew, I feel much more comfortable getting involved properly and want to learn more. I was actually planning on PMing you about this on Discord these days, before this annoucement came out... So if the mentorship offer still stands, I’d definitely be interested in starting with ublue-os/bluefin, working through the backlog, helping with F45/F46 testing and learning the maintainer side of things from there. I’m also happy to help with Dakota, Utah or the newer Bluefin work wherever I can be useful and I have lots of spare time. |
You will just stay on |
This is already happening check Github and start sending PRs, etc, same rules apply the contributor guide is all the same. |
|
Thank you very much for writing out at least part of the story here; I think I'm in a very similar boat to many bluefin users, who discovered bluefin at the same time as Bazzite and Aurora. I'm not really a developer and don't have very strong preferences about how my desktop should be; I ran Pop!_OS LTS all the way until last year, and decided I liked gnome better than COSMIC around the same time my system76 machine died. I chose bluefin specifically because it seemed like something that would minimize the headspace of system maintenance, and something that I can install on the laptops of friends and family that want to get away from windows but can't afford to buy into the Apple ecosystem. I hope that y'all accomplish the goals you set out to do, but I'm going to have to move away bluefin because I can't be spending all this time reading blogposts and forums like this trying to figure out what's going on in the sausage factory, and wondering if 'long term support' actually will end up only being ~8 months of support before quasi-abandonment :( I would like to extend my gratitude toward all contributors and supporters; It seems like exciting times for bluefin. Unfortunately, excitement is the opposite of what I need for a linux desktop system. I'll check in down the road when Dakota/Utah are a bit more stable, a bit more boring. |
|
@castrojo hey now! That comment was rude towards @gichiba and not the best approach. I know you have some history of saying things then coming back with "not trying to be rude" and then you do come off as rude and then do an apology. I know you mentioned you have ADHD but gichiba had an honest take and wasn't attacking you. @gichiba give Aurora a try for some stability. You can still stay in the bootc ecosystem tied to Universal Blue without the additional stuff that Bazzite brings. I just don't want rude comments to scare you away. |
|
Thanks for your comment @btegs, and no hard feelings @castrojo, I definitely can see how my comments can be read in a more aggro way than I intended while typing. tbh most of my negative feelings about this situation are just annoyance at having an unavoidable full re-install put on my plate this month; LTS means I'm not on a shared base as Bazzite/Aurora (TunaOS docs say bluefin-lts is an almalinux base, but I'm certain I remember reading it was CentOS 10 in the bluefin docs), and neither yellowfin-hwe nor yellowfin-nvidia (the right ones according to tunaOS docs) will boot properly. Will try skipjack (the centOS 10 base) and if it works try to submit a PR to the tunaOS docs because I think the LLMs did not do their due diligence. If that doesn't work, what the hell, I'll try a messy migration to Dakota as outlined here because I've got nothing to lose! |
|
Against my better judgment, I'd also like to share an unfortunately ironic post I found, in which an actual paleontologist explains why he decided to leave Bluefin for a different distro: https://peterfalkingham.com/2026/09/22/ditching-bluefin-for-cachyos/ |
|
he has a laptop with a 5090 in it - are those even available now? |
|
yeah from this year I think the laptop version is out... Maybe if you do dinosaur biomechanical simulation stuff you can count a kick-ass graphics card as an expense in a grant? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
aka. "Bluefin Classic"
(Fedorafin is a horrible name let's stop using that before it spreads. Bluefin Classic it is!)
Ok we're at F45 beta and only a handful of people showed up to help transition to projectbluefin/bluefin. It doesn't make sense to move so many people without testing and I can't think of anyone on the core team using Fedora.
Since no one is stepping up we'll leave ublue-os/bluefin there and scrap the plans to migrate people over.
The thing is on cruise control, I unclogged some issues the past week. But the issues are piling up and it's getting further behind the others. I can commit to the F45 upgrade, after that F46 will be easy too if people want to keep it as is without the features we're adding in Dakota. Even in this state it's still better maintained than it used to be:
New Incoming Volunteers
Here are our new raptor wranglers for ublue-os/bluefin
There's no way we can guarantee that a Fedora -> Hummingbird migration will work. I am 100% certain as a person that it will, but we still cannot make that guarantee. So we'll play it safe and leave ublue-os/Bluefin as is. You can optionally move to projectbluefin/utah if you want the latest stuff.
Bluefin LTS has a lead maintainer (Hi Robin!) but 1 is not much better than zero. This is similar to the GTS situation, we could do this, and we could also do something silly like put an LTS kernel in Dakota but that doesn't make any sense. Robin and I are working on this printer container thing, which will actually move a needle. I think that's a better use of their talent.
Strong Opinion Here
I can't tell you what to do but I will tell you what I am going to do. Straight from source right to the image is The Final Shape. There is no more efficient method for us to get what we want, using anything but bst is a waste time.
Our project was founded on the belief that using Linux incorrectly is silly. Bluefin is getting pushed into directions she doesn't want to go. We don't care about 99% of the things Linux users say is important. We do not pander to the mythical "new user" that doesn't exist. The only Linux on the client that is anywhere close to be being used by a normal person is Android. No other Linux is in the same league. This project is for people who want to BUILD that for others. We will never lie about the state of things, everyone knows desktop Linux is a tyre fire. Our purpose is to make this problem go away forever. I'll make sure this is more clear on the next revision of the website.
I'm all in on Dakotaraptor and Bluefin Server. And Utahraptor will be the ultimate destination of you want the Fedora stuff. That thing will be ready to hunt faster than Dakota did. They're evolving, these two new ones will give us what we need. A common platform with Bluefin Server. When you control both ends of the user experience, good things can happen!
And I'm also tired. The original spec for moving Fedora to what is basically Universal Blue was targeted for Fedora 39! I'm five years in to a plan that was already delayed five years, my own son turns ten this month! honestly I'm tired of carrying this banner, at this point it doesn't matter if Fedora ever gives a shit about Silverblue. The entire world has changed.
Therefore this iteration of ublue-os/bluefin is a good middleground for "Silverblue Plus" that people want the layering and all of that stuff. Though if there's changes which don't fit with Bluefin we can always rebrand it, plenty of dinos in the world. Some of you are comfortable in your Bluefins, who am I to take it away. It's time for other people to step up though.
Happy to answer questions!
All reactions