[HN Gopher] Project Bluefin: an immutable, developer-focused, Cl...
       ___________________________________________________________________
        
       Project Bluefin: an immutable, developer-focused, Cloud-native
       Linux
        
       Author : Santosh83
       Score  : 87 points
       Date   : 2024-01-14 17:23 UTC (5 hours ago)
        
 (HTM) web link (www.ypsidanger.com)
 (TXT) w3m dump (www.ypsidanger.com)
        
       | pkulak wrote:
       | This is the announcement post, which is pretty old by now. Lots
       | of great things have happened since, and it's worth a look! This
       | is my go-to distro when I build a computer for family. It's
       | bullet proof, practical, and everything auto updates with zero
       | user interaction.
        
       | chuckadams wrote:
       | What does "cloud-native" mean in this context, if anything? When
       | I hear the term, I think of things like CoreOS, whereas this
       | looks rather desktop-focused.
        
         | ARussell wrote:
         | I read this article and ended up with the exact same question.
         | Does it mean that it wants to imitate Chromebooks, where the
         | most important app you use is the browser, and all of your apps
         | are in the cloud rather than on the desktop?
        
           | mcmcmc wrote:
           | Cloud-native just means container-first in this context.
           | Nothing is locally installed and the desktop gui itself runs
           | as a container.
        
           | PlutoIsAPlanet wrote:
           | No, the OS itself is a read-only container image booted on
           | bare metal (via OSTree) and includes the tools usually used
           | to build container images (used for kubernetes etc), as well
           | as pushing desktop applications via Flatpak.
        
           | riedel wrote:
           | I guess it makes you feel better as a user to be part of the
           | hyper converged buzzword bingo. But seriously it seems to be
           | both web and container (web) focussed. They should maybe
           | rather say what they are not and what the limitations of
           | their approach is ( I guess isolation comes at some costs)
        
         | CharlesW wrote:
         | It's worth noting that the submitter didn't use the actual
         | title, and TFA doesn't characterize Bluefin as a "cloud-native
         | Linux", but a distribution made by "cloud-native nerds" that
         | integrates tools generally associated with cloud development
         | (kind, flux, helm, kubectl).
        
       | riffic wrote:
       | I would love to know why it's based on Fedora instead of Debian
       | since it seems to be highly influenced by Ubuntu.
       | 
       | EDIT a few minutes of reading and I seem to get it now. this
       | project and some of the others (Silverblue specifically but also
       | devbox and devpod) have been under my radar but I think I'm going
       | to try this out for a bit.
        
         | jcastro wrote:
         | Hi! I work on this. There's no `rpm-ostree` equivalent in
         | Debian, so you'd have to make an image natively with ostree.
         | This is what EndlessOS does: https://www.endlessos.org/os
         | 
         | `rpm-ostree` grew OCI support, which lets us build the entire
         | thing with a dockerfile and github actions, which is much
         | easier, we can run the entire thing out of github.
         | 
         | It would be awesome if you could use Debian for this but alas,
         | no one has made a `deb-ostree`. If someone did it wouldn't be
         | too hard for Universal Blue to publish Debian-based images.
        
       | aerzen wrote:
       | I've opened up the website https://projectbluefin.io, but it
       | turns out that this is not a website, but rather a web
       | application. You cannot do things like this and claim it is built
       | for developers. Scrolling lags, it shows a loading spinner and it
       | does not respect navigation controls.
       | 
       | I cannot take this project seriously. Dope art, though.
        
         | hammyhavoc wrote:
         | Remember the adage about not judging a book by its cover?
         | Usually applies to a lot of cool stuff in software and
         | hardware. Not tried Bluefin, but Debian's site looks quite
         | archaic, yet is very cool as a project. I could go on for
         | hours.
        
           | dotcoma wrote:
           | Yes, we know the adage, but as many people do indeed judge a
           | book by its cover, perhaps greater attention should be put in
           | covers, or websites, and especially websites of new projects.
        
             | hammyhavoc wrote:
             | Perhaps. Or perhaps with finite time, energy, resources and
             | money, we should focus on substance over style. Pull
             | requests are usually welcome when it comes to the sizzle
             | alongside the steak.
        
           | binkHN wrote:
           | I think this summarizes https://www.openbsd.org very well.
        
             | hammyhavoc wrote:
             | Yes! Absolutely came to mind!
        
         | swells34 wrote:
         | Interesting choice of gatekeeping you do here. Complain that
         | it's a "web application" instead of a website, then claim that
         | web applications cannot be built for developers. And to round
         | it all off, whine about scrolling latency, that it has a
         | spinner, and that it "doesn't respect navigation controls",
         | whatever that means. Did I miss anything, or does this sum the
         | contents of your post?
         | 
         | The funny thing, is that it is a website, web applications can
         | be built for developers, the scrolling doesn't lag on my
         | device, the spinner doesn't bother me, and it completely
         | respects my navigation controls. I think you have a "you"
         | problem, and enjoy projecting it at anything that doesn't fit
         | into your mental model of how the world "should be". Go solve
         | that, and you can come back and be a productive participant in
         | these conversations.
        
           | rstat1 wrote:
           | I can't believe I have to say this but your experience is not
           | universal.
           | 
           | On several of my devices that are plenty fast enough for
           | pretty much anything else, the scrolling is still pretty
           | laggy.
           | 
           | Looking at CPU usage I see that having this page open, eats
           | an unnecessary amount (>70%) of CPU for what appears to be a
           | static page, so there's definitely something not quite right
           | there.
        
             | swells34 wrote:
             | You and I are in agreement, that no one's experience is
             | universal. That is why I was compelled to respond to
             | aerzen, who was very much claiming that his experiences and
             | viewpoints are universal across all developers.
             | 
             | Odd that you responded to me saying this, as I made no
             | claims about my experience being universal, I was quite
             | obviously just speaking for myself as an exception to their
             | universal claims. Go read the parent comment again, you
             | still have time to edit yours and point it in the right
             | direction.
        
         | larina3315 wrote:
         | By that line of logic I can't use Debian as a modern desktop
         | linux distro because of that website from 1995
        
       | jcastro wrote:
       | Hi! I'm one of the maintainers of this project and wrote the blog
       | post, I'd be happy to answer questions if you got em!
        
         | vaylian wrote:
         | Are there any special images that are designed for use with
         | Framework computers? For silverblue there is "silverblue-
         | framework": https://universal-blue.org/images/#38_85
        
           | jcastro wrote:
           | Yep: `bluefin-framework` and `bluefin-dx-framework` for the
           | stock and developer version. We also have asus and surface
           | images with their respective kernels.
           | 
           | If you have an AMD Framework the gnome-power-profiles manager
           | has the inprogress patches from AMD already included and are
           | probably better. Upstream Fedora is also in the process of
           | evaluating `tuned` so in the future there may not even need
           | to be a separate image for Framework.
           | 
           | Rebase instructions here: https://universal-blue.org/images/
        
       | bketelsen wrote:
       | Bluefin has been my daily driver for over a year now. Love the
       | community of people just trying to make Linux awesome on the
       | desktop. I'm happy to answer questions about the project too.
        
         | heywoodlh wrote:
         | > Love the community of people just trying to make Linux
         | awesome on the desktop
         | 
         | Couldn't agree more with this! :)
         | 
         | I'd be curious to know what aspects you enjoy about Bluefin
         | that has you using it over, say, stock Fedora Silverblue
         | (especially any features that may not be mentioned in the OP)?
        
         | vaylian wrote:
         | > Love the community of people just trying to make Linux
         | awesome on the desktop
         | 
         | What are the best places to hang out to follow along?
        
           | lazypower wrote:
           | There's a discourse forum if you're into async, or there's a
           | Discord server for more up-to-the-minute updates. Along with
           | the github repos to track bugs, feature requests, and see how
           | the project is made.
           | 
           | take your pick :)
           | 
           | Discourse: https://universal-blue.discourse.group/ Discord:
           | https://universal-blue.org/mission/ (link on left side, click
           | discord) GitHub: https://github.com/ublue-os/
        
       | unshavedyak wrote:
       | What's the immutability aspect of this? I'm trying to find that
       | on the site, no luck yet tho (ctrl-f'ing at least).
       | 
       | Given that i'm on NixOS atm i'm quite interested in this aspect.
        
         | heywoodlh wrote:
         | Second line in the post:
         | 
         | > Bluefin is a custom image of Fedora Silverblue by a bunch of
         | cloud-native nerds.
         | 
         | Fedora Silverblue is an immutable variant of Fedora[0]
         | 
         | [0] https://fedoraproject.org/silverblue/
        
         | CharlesW wrote:
         | This helped me: "Project Bluefin: A customized Fedora
         | Silverblue desktop image" https://lwn.net/Articles/954059/
        
       | ta8645 wrote:
       | It would be so nice to get a brief description of what this is,
       | and why it is useful, without a bunch of project names and
       | buzzwords. Can it be boiled down to a few simple concepts that
       | are delivered by this project?
        
         | vaylian wrote:
         | It is a Linux distribution that is based on Fedora Silverblue
         | (another Linux distribution). What makes these distributions
         | special is that they have an immutable/readonly root file
         | system, which means that only /var (which contains /var/home)
         | and /etc can be manipulated directly by root.
         | 
         | By having less moving parts, it is much easier to provide a
         | Linux operating system that works (more) reliably on many
         | different machines.
        
           | rkagerer wrote:
           | How about the "cloud native" part?
        
             | jcastro wrote:
             | The cloud-native part is that it's built with tools and
             | things you'd see in cloud-native like OCI containers,
             | gitops, etc. Here's the containerfile as an example of how
             | it's put together: https://github.com/ublue-
             | os/bluefin/blob/main/Containerfile
             | 
             | And then all the developer patterns are cloud native like
             | devcontainers instead of using the host packages, included
             | k8s, podman, and docker tooling, etc.
        
             | lazypower wrote:
             | So "Cloud Native" speaks to multiple aspects of how
             | universal-blue is both built, distributed, and some of the
             | guiding principals behind the project.
             | 
             | I'll start at the very basics, where we define "Cloud
             | Native": Cloud native is the software approach of building,
             | deploying, and managing modern applications in cloud
             | computing environments.
             | 
             | I'll get a little hand wavy here as our desktops/laptops
             | aren't typically defined as a "cloud" (read: grouping of
             | machines, typically behind an API that someone else manages
             | but makes available to users or customers). However - we
             | can look at it as a target platform for deployment. How
             | universal-blue gets there is the real interesting part.
             | That "made by cloud native nerds" is a very compact way of
             | describing how the project is built, tested, and rolled
             | out.
             | 
             | Universal-blue images are all built in CI. In this case -
             | its a combination of base layer components - sometimes
             | built in COPR for some projects that are included in the
             | product operating system, and then those COPR built
             | artifacts are included by a Containerfile. Along with all
             | the goodness contained in SilverBlue (fedora rpm
             | artifacts).
             | 
             | That containerfile is built, tested, and signed in GitHub
             | actions, and a manifest is then updated (somewhere, i don't
             | actually know where ublue looks for these manifests to
             | identify it has an update - it might just be the GHCR
             | registry - but don't hold me to that).
             | 
             | Now this probably all sounds like something you see in your
             | day to day if you work in infrastructure, or in a company
             | producing software/services for the web. But what's really
             | unique from a consumed operating system perspective is that
             | those builds and tests effectively gatekeep the "blessed"
             | configuration for universal-blue. Classically you have
             | kernel modules that get built on your machine using a
             | technique known as DKMS (Dynamic Kernel Module System).
             | Every update to the kernel you have to re-build some
             | library as part of the update process. And if your
             | particular version of a module hasn't been vetted with what
             | kernel you just pulled you can be left in a rather bad
             | state - I've had this happen to me with the proprietary
             | nvidia drivers as an example.
             | 
             | How ublue delivers these modules is part of that not-so-
             | secret sauce that makes it wonderful. These modules are
             | built in the cloud in that same release pipeline, and if
             | they fail - they don't get released! You simply don't see
             | an update for that day, and things hum along just fine.
             | This breaking happening somewhere other than your computer
             | is part of that reliability promise - you wont be dealing
             | with kernel module breakage, the release maintainers will
             | have to resolve the break (or communicate with upstream to
             | find a solution) so your incoming stream of updates can be
             | unblocked.
             | 
             | Finally - there are a lot of "patterns" - or process to
             | achieve a desired outcome, that has been piloted in the
             | Cloud Native world. Someone mentioned CloudNative makes
             | them think of CoreOS. I'm glad you brought this up - If you
             | keep your older versions (by pinning, or ublue keeps the
             | last known booted image by default, and you can change this
             | to keep say 10 if you wanted) - you can always roll back to
             | the version that worked before you encountered a fault.
             | This same pattern exists in the base-line SilverBlue
             | distribution.
             | 
             | This is not an exhaustive analysis but I've already penned
             | a good novel here. I hope this helps outline how universal-
             | blue brings Cloud Native to the desktop. I encourage you to
             | kick the tires and try it out, even if only in a virtual
             | machine.
        
           | ta8645 wrote:
           | Thank you. Why isn't Fedora Silverblue sufficient by itself?
           | What does this project add?
           | 
           | And if you don't mind me also asking, what features are
           | described by the term "cloud-native"?
        
             | vaylian wrote:
             | > Why isn't Fedora Silverblue sufficient by itself? What
             | does this project add?
             | 
             | I'm not affiliated with either distribution. Both
             | distributions provide different out-of-the-box experiences.
             | Fedora Silverblue tries to be a general purpose desktop OS
             | while BlueFin has a focus on software development. You can
             | still adapt both of them for the same purposes, but BlueFin
             | might be a nicer starting point if you actually are a
             | developer.
             | 
             | The biggest difference to classic read-write Linux
             | distributions is that you have an immutable base system
             | which includes software that you might find useful or
             | useless. In addition, you can install software as Flatpaks
             | into your home directory. It is also possible to change the
             | software that is part of the immutable base system, but it
             | is typically something you want to avoid.
             | 
             | > what features are described by the term "cloud-native"?
             | 
             | I suppose it refers to the container management software
             | that is included in the immutable base system.
        
             | jcastro wrote:
             | > What does this project add?
             | 
             | This project uses this upcoming feature in Fedora: https://
             | fedoraproject.org/wiki/Changes/OstreeNativeContainer... and
             | switches to its consumption model entirely.
             | 
             | On stock Fedora you're pulling from a distribution-hosted
             | ostree endpoint to do updates. With Bluefin (and other
             | universal-blue.org images) you're pulling from a container
             | registry (in this case ghcr.io, but you can push your
             | builds to any registry or host your own).
             | 
             | We ingest Fedora daily and then add codecs, a bunch of
             | hardware enablement support via udev rules, add a few pain-
             | in-the-ass-otherwise things like the obs virtual cam, xbox
             | controller support, etc. Then that image is pushed to
             | ghcr.io and the local package manager uses that.
             | 
             | We also enable Flathub out of the box and Distrobox:
             | https://github.com/89luca89/distrobox - then ship a few
             | preconfigured boxes for you to play with: Ubuntu, Fedora,
             | and Wolfi.
             | 
             | Then we have another image that you can rebase to by typing
             | `just devmode` in a terminal which adds vscode with
             | devcontainers, devpod, devbox, kvm/qemu, incus/lxc/lxd,
             | some nice monospace fonts, cockpit, kind, docker, and a
             | bunch of associated cluster tools.
             | 
             | And since we build everything in CI there's no local
             | package conflicts like in upstream Fedora when the main
             | repo and rpmfusion repos are conflicting, your PC only ever
             | gets successfully built images.
        
         | 1over137 wrote:
         | It's could native! What more do you need to know?! :)
        
       | lazypower wrote:
       | I've been a consumer of bazzite for almost a full year now. I
       | built an AMD based gaming machine and wanted an experience as
       | pleasant as SteamOS but for HTPC's. That was what first turned me
       | on to the universal-blue project.
       | 
       | I later picked up a framework (exactly 2 weeks ago) and have been
       | daily driving Bluefin on it and the experience is exactly what
       | I'd want from a daily driver. The durability and mindlessness of
       | a Chromebook for updates, options to install all my
       | tools/utilities, and disposable/composable development
       | environments built right into the base system.
        
       | michaelmrose wrote:
       | The information is well thought out and relevant but I have mixed
       | feelings about the envelope its delivered in.
       | 
       | https://projectbluefin.io scrolls in a really really janky way
       | specifically on mobile firefox. It seems to work correctly on
       | desktop firefox, and mobile chrome. It probably performs poorly
       | in other low resource environments as well.
       | 
       | Even on a desktop browser its easy to stimulate noticeable CPU
       | usage merely by scrolling and almost 400MB of RAM usage
       | explicitly and only for this tab.
       | 
       | Using the 3G profile in firefox dev tools it takes over 40
       | seconds to load. What is remarkable is how long it took to
       | actually load while only in fact transferring 5MB which is much
       | slower than one would expect even when throttled to 750Kbps.
       | 
       | Even at the DSL profile (2Mbps) its a fairly shockingly slow 16s
       | to load.
       | 
       | Incidentally 2.6 of the 5 is just a png file that could easily be
       | reduced to ~900k without noticeable degradation.
       | 
       | Compare that to the linked blog post which scrolls normally
       | without noticeable CPU usage, loads almost instantly while
       | progressively loading the images and uses about 80MB of RAM.
       | 
       | I must say I love how it looks but it is a triumph of form over
       | function that probably works only if most prospective users are
       | viewing this on fast devices with a fast connection. Bounce rate
       | for websites goes up enormously as one goes over 3-4 seconds.
       | 
       | If your website needs a loading screen and its not a desktop app
       | running in a browser window stop whatever you are doing and throw
       | it away and rethink it.
        
       ___________________________________________________________________
       (page generated 2024-01-14 23:00 UTC)