[HN Gopher] Switching to Fedora Silverblue
___________________________________________________________________
Switching to Fedora Silverblue
Author : todsacerdoti
Score : 68 points
Date : 2023-03-03 18:11 UTC (4 hours ago)
(HTM) web link (yorickpeterse.com)
(TXT) w3m dump (yorickpeterse.com)
| quickco wrote:
| I run Linux on a few dozen servers currently and have been using
| it for at least 20 years.
|
| However, I can't imagine running it as my primary desktop OS.
|
| Reading these posts about the hassle and battles it takes to get
| a desktop linux OS running sounds like madness to me.
|
| And the end result is usually not entirely stable, and often
| involves many tradeoffs like trackpads not working correctly or
| trying to print causing WIFI to drop.
|
| A good operating should Get Out Of The Way, so you can work,
| build, create, explore, play.
|
| Honest question: do you run Linux OS primarily because it is the
| best OS for you, or do you run it more because you identify with
| the philosophy and ethos of open source software? (Both options
| are completely fine.)
| behnamoh wrote:
| I agree. I think some people use Linux to avoid paying Windows
| license fees or Apple's premium. There are tools only developed
| for Linux, but the opposite is also true for Windows and macOS.
| I've found most macOS apps follow Apple's core philosophy to be
| simple, aesthetically appealing, and easy to use. Can't say
| that for Linux packages (and to some extent, even Windows apps
| suck).
|
| I view Linux mostly as an environment where you're free to do
| whatever you want, even shoot yourself in the foot. But I'd
| never recommend that to average Joe, for reasons such as the
| fact that this article exists.
| yjftsjthsd-h wrote:
| > And the end result is usually not entirely stable, and often
| involves many tradeoffs like trackpads not working correctly or
| trying to print causing WIFI to drop.
|
| So have you actually tried desktop Linux, or are you working
| from 20-year-old stereotypes?
|
| > A good operating should Get Out Of The Way, so you can work,
| build, create, explore, play.
|
| That rules out Windows, and MacOS is 50/50 depending on whether
| you stay 100% on the happy path and nothing goes wrong; what
| are you using?
| thinkmassive wrote:
| I've been daily driving Silverblue for the past three weeks and
| it's been great.
|
| Fortunately I haven't yet had to build any RPMs, but this looks
| like an excellent reference for that and more.
|
| The major obstacle for me in the past was getting a good tooling
| window manager set up. This time around I found this, which
| worked flawlessly:
|
| https://github.com/machadovilaca/fedora-silverblue-i3-gnome-...
| deafpolygon wrote:
| Interesting. The whole article reads like a cautionary tale -
| even someone experienced with managing their Linux system and
| all, have trouble with something that purports to be user-
| friendly.
| freedomben wrote:
| I wish the author's complaints about RPMs would be taken
| seriously. I'm a pretty experienced dev and sysadmin, a packaging
| a simple CLI app written in C with an easy compile process (and
| no dependencies other than glibc) was a giant pain in the ass,
| and in the end I doubt I did it the "right" way despite hours and
| hours of effort to do so, as I made use of docker to get builds
| for various active Fedora versions and RHEL versions without
| having to provision a complete system with each.
|
| I don't know if it's documentation or the RPM tools/macros that
| suck, or some combination of both, but it's a real setback for
| someone trying to contribute packages. Getting a contribution
| into the Fedora repos was also a giant pain in the ass, as there
| is process there but the documentation is entirely unclear what
| that process is unless you already know what the process is.
|
| My opinion of the RPM macro system is that I can see why it was
| done that way, and it was an admirable approach to make packages
| easy to read, but there's way too much magic. I'd rather parse a
| couple lines of shell script that made it clear what was
| happening, than have to look through a handful of macros that
| aren't documented well (or good documentation is impossible to
| find). Arch's PKGBUILD format is amazing, and I'd love to see it
| used as inspiration for an RPM replacement (or at least
| alternative approach). I try to be very wary of the "the last
| developer sucked" fallacy when coming into a new and unfamiliar
| project, but there are enough similar experiences to mine that I
| think this criticism is valid.
|
| That said, much appreciation and love for the dedicated people
| who maintain and build RPMs for us. It's often thankless work,
| but without it we would have nothing.
| nix23 wrote:
| >packaging a simple CLI app written in C with an easy compile
| process (and no dependencies other than glibc) was a giant pain
| in the ass
|
| That's why i love to work with FreeBSD-ports and pkgsrc from
| netbsd, it's just so easy and the community helps you quite
| allot if your are in a corner-(case).
| tmtvl wrote:
| I have rolled my own RPMs for OpenSUSE TW. I learned about the
| build process from a site aimed at Fedora and got the syntax
| right(ish) by looking at a bunch of official .SPECs from the
| OpenSUSE project. I also looked at packaging .debs, but that
| looks like an utter pain.
| bravetraveler wrote:
| The 'right' way for your build environments is _mock_
|
| reference: https://rpm-software-management.github.io/mock/
|
| I'd also suggest _fedpkg_ as a sort of extended wrapper.
|
| The Fedora packaging document below covers it, but not very
| narrowly focused:
|
| https://docs.fedoraproject.org/en-US/package-maintainers/Pac...
| YorickPeterse wrote:
| The issue is that mock does nothing for moving sources in
| place, it's just rpmbuild and a chroot. From what I could
| figure out, fedpkg is more about working with existing Fedora
| packages shipped as part of the official repositories, and
| less about "Here's how to get this random project you don't
| own into copr".
| bravetraveler wrote:
| I don't work with _mock_ much, but _fedpkg_ is perfectly
| capable for introducing new things -- that 's exactly why I
| know about/use it.
|
| I draft up specs, build {s,}rpm with _fedpkg_ (indirectly
| _mock_ ), test locally, then ship them off with _copr-cli_
| YorickPeterse wrote:
| Ah interesting. Do you have any guides about fedpkg that
| you'd recommend?
| bravetraveler wrote:
| I wish I did! It's very skewed towards those wanting to
| contribute to Fedora, so the part before makes sense.
|
| The doc above (and a former roommate) are the best
| resources I have!
|
| I've had to expend a bit of trial/error to familiarize
| myself with a number of quirks... the rough process looks
| like this: fedpkg mockbuild
| copr-cli build $ProjectName
| ./results_$PKGNAME/path/to/project.srpm -r $mock_root
|
| This assumes there's an RPM spec file in your working
| directory and proper handling of sources within/nearby.
| Fedpkg will create a 'results' directory with the SRPM
| and RPMs
|
| The _-r $mock_root_ part can be repeated if you want to
| build against multiple targets in COPR
| behnamoh wrote:
| I think the problem is greater than RPM vs DEB vs ... It goes
| all the way back to the Linux philosophy "let the user break
| things".
|
| I think some people use Linux to avoid paying Windows license
| fees or Apple's premium. There are tools only developed for
| Linux, but the opposite is also true for Windows and macOS.
| I've found most macOS apps follow Apple's core philosophy to be
| simple, aesthetically appealing, and easy to use. Can't say
| that for Linux packages (and to some extent, even Windows apps
| suck). I view Linux mostly as an environment where you're free
| to do whatever you want, even shoot yourself in the foot. But
| I'd never recommend that to average Joe, for reasons such as
| the fact that this article exists.
| freedomben wrote:
| If it was a Linux problem (which is an interesting thing to
| think about), wouldn't you expect to see the same issues in
| all the distros? Arch, Alpine, etc seem to have a pretty good
| system. PKGBUILD in particular I found great.
| alexvoda wrote:
| Nobody uses Linux to avoid paying Windows because Windows
| comes preinstalled on most computers and because Windows
| piracy exists and is tolerated by Microsoft in order to
| entrench Windows usage. Switching to Linux is a deliberate
| choice to prefer the benefits only Linux offers and/or to
| avoid the detriments of all other options. The majority use
| the preinstalled default: Windows.
|
| Also nobody uses Linux to avoid Apple's premium because macOS
| is free. A minority of people install Linux on Macs because
| they prefer/need Linux even if they already paid the Apple
| premium. The rest simply use the preinstalled default: macOS.
|
| For a user with basic needs and no dependency on some
| Windows-only software, Linux is a viable choice.
| packetlost wrote:
| My experience with RPM is _fairly_ limited, but I have a
| similar experience with Debian 's .deb format. My rough
| understanding is deb is not _as_ complicated as rpm, but I
| still have yet to succeed at packaging something with either.
| Meanwhile I 've had a much easier time with APK and PKGBUILD
| from Alpine and Arch respectively. Why is it these packaging
| systems make it so much easier while the juggernauts of the
| Linux distro world have such complicated, poorly documented
| messes?
| dima55 wrote:
| I've lots of experience with both. Debian, while not perfect,
| is miles better than the rpm systems. Both require knowledge,
| because thinking of all the multitudes of edge cases makes
| things complicated. Don't have personal experience with
| Alpine or Arch, but I suspect they're not as general. Nobody
| WANTS to create lots of complexity for no reason.
| freedomben wrote:
| > _Nobody WANTS to create lots of complexity for no
| reason._
|
| Agreed. I think in the case of RPMs and Debs, it evolved to
| this point. I would guess the first versions of RPM and the
| macros were amazingly easy to package, probably much better
| than PKGBUILD is now.
|
| The problem happened that software started getting written
| in tons of different languages rather than usually in C,
| with different libraries/dependencies, different strategies
| and edge cases, and the system kept expanding to
| accomodate. Eventually it's a mess because there are too
| many macros, it's now too magical, and documentation hasn't
| been made a high priority because it's a relatively small
| group that uses it, and they don't need the docs. Once you
| know it too, there's not a lot of reason to change it and
| even more reason not to change it (cause that's a ton of
| work for little to no gain among the majority of the
| maintainers). I don't mean this as a criticism, just a
| pattern I've seen over and over having worked on software
| for a long time.
|
| I think the actual package format for RPM probably doesn't
| need to change too much, it's the tooling and docs that do.
| I'd love to see a new project that is compatible with the
| RPM format but uses a system more like PKGBUILD.
| dima55 wrote:
| rpm is heinous. They need to handle comments and then
| expand macros so that you can comment-out stuff in your
| .spec without getting mystery errors from multi-line
| macros. If they can't even get this right after decades,
| they're hopeless.
| elesiuta wrote:
| I have had a similar experience packaging a simple python
| program, coming from zero packaging experience. PKGBUILD was
| the first I did and by far the easiest, deb was about 3x more
| time and effort, and rpm was a bit more time and effort
| still, despite now having experience with the other two. I
| wanted to package for nix next, but got stuck due to the
| program daemonizing and can no longer import its
| dependencies.
| jmmv wrote:
| This is quite dated (2012), but back then I found Fedora's
| packaging system to be quite good:
| https://jmmv.dev/2012/02/brief-look-into-fedoras-packaging.h...
|
| Thanks for the article! Trying out Silverblue is still in my
| backlog, and the list of tips is nice.
| neogodless wrote:
| Articles like this make me happy the distribution I chose was
| Linux Mint, and nearly everything worked without me having to
| learn a bunch of things.
|
| (My changes included installing KDE Plasma 5, and maybe trying a
| few different login managers, i.e. gddm3/lightdm. Not much else!)
|
| Of course, if you like learning how to customize and tinker, then
| these kinds of distributions probably make a whole lot more sense
| to you!
| tapoxi wrote:
| Fedora basically works out of the box, but Silverblue is an
| immutable system that you can modify by layering packages on
| top of the image. It's really cool, and probably The Right
| Way(tm) to handle system upgrades, but its got a bit of a
| learning curve.
|
| Every now and then I give it a spin, but most IDEs aren't great
| at doing development inside of a container just yet, which
| makes it painful to work with.
| thinkmassive wrote:
| I hadn't considered this. It makes me glad I keep as much as
| possible within my shell and browser.
|
| In its current state I would recommend Silverblue to two
| classes of users:
|
| 1. Highly technical with a strong background in immutable
| systems and containerization.
|
| 2. Non-technical users whose app needs are completely
| fulfilled by Flathub.
|
| The latter may require some assistance with initial setup,
| but if I needed to help a friend or family member maintain
| their computer then Silverblue would be my first choice.
| evol262 wrote:
| Silverblue is intended for the opposite of that. It is single
| system image mostly immutable root OS. The goal is to *not*
| tinker with the core OS, and do your tinkering in containers
| (toolbox, distrobox, whatever).
|
| Complaining that rpm-ostree took 2 minutes to update 2 packages
| (rpm-ostree downloaded an entirely new pre-baked filesytem
| snapshot and applied it atomically) is completely missing the
| point, as is complaining about selinux after swapping out a
| bunch of system level stuff. This is like the antithesis of the
| use case for Silverblue, and an author who has somehow never
| had to build a package for anything but Arch (deb would be much
| worse) complaining about the difficulty of building RPMs to
| install/overlay on the host system, which is not the intended
| use case *anyway*, is silly.
| YorickPeterse wrote:
| > and an author who has somehow never had to build a package
| for anything but Arch (deb would be much worse) complaining
| about the difficulty of building RPMs to install/overlay on
| the host system, which is not the intended use case _anyway_
| , is silly.
|
| I can assure you I've built packages for more than just Arch
| Linux, and that building RPMs was by far the most frustrating
| experience of all :)
| frantathefranta wrote:
| I've had the same experience with EndeavourOS (more user-
| friendly Arch). It's running on an old OptiPlex desktop with an
| added GTX1650 GPU. I've had basically no issues for the last 8
| months, with my dual monitor set-up working out of the box.
| I've used Arch prior to this for about 2 years but I wouldn't
| say that stopped me from making some mistakes. Nothing that
| broke the install for me though.
| 2OEH8eoCRo0 wrote:
| I use Fedora and everything works out of the box- even Steam,
| Nvidia drivers from the package manager, and games. This is
| about Silverblue, a bespoke and immutable variant of Fedora
| Workstation.
| neogodless wrote:
| Thank you, I saw it was about Silverblue. It's in the title!
| I didn't claim Fedora (or in particular, Fedora distributions
| separate from Silverblue) doesn't work out of the box. I just
| observed what's in the shared article, which is a lot of
| steps to get things how they want them.
|
| As a Linux Mint user, obviously I don't know a ton about
| every distribution and all of the differences! (There's an
| implicit assumption there, that if you know a lot more, you
| might choose to customize a less "off the shelf"
| distribution, though I don't know if that is accurate!)
|
| I'm just glad my Linux installation process didn't involve
| all the steps that this article included to get up and
| running and being able to use my computer. To be sure, they
| have used Linux for over a decade, and like things a certain
| way, so their pickiness leads to a lot of the tinkering! I'm
| just saying, personally, I don't want to dig that deep if I
| don't have to.
|
| I still think it's funny that everyone is pointing out that
| it's about Silverblue, when it's in the title, and I didn't
| say anything to contradict that. What am I missing here?
| thinkmassive wrote:
| I've been running debian distros exclusively for the past few
| years. A few weeks back I attempted a reinstall, but I was
| blocked by a combo of nonfree firmware (that was incompatible
| w/kernel in stable) and partitioning/bootloader issues in
| testing.
|
| After a few failed attempts at pre-partitioning in stable,
| then installing from testing, I gave up and tried Silverblue.
| Gotta admit, the lack of driver issues out of the box was
| refreshing!
|
| Like any immutable distro, Silverblue has it's quirks, but
| hardware support hasn't been one of them in my recent
| experience.
| freedomben wrote:
| Did you have any regular Fedora experience going into
| Silverblue?
| ab71e5 wrote:
| > That is, sudo pacman -S some-package may lead to problems, so
| it's recommended to use sudo pacman -Syu some-package instead
| (see this section for more details).
|
| I think `pacman -S some-package` is fine, it's `pacman -Sy some-
| package` that could be a problem.
| pkulak wrote:
| Silverblue is pretty great. But it's really been taken to another
| level in the last few months since it started allowing you to
| _boot_ from a container image. That means, you can have some
| automated container build somewhere that you point rpm-ostree too
| which gets automatically pulled down to all your machines. It's
| like building your own distro, but without any of the work.
| Here's mine, for example:
|
| https://github.com/pkulak/filverblue/
|
| And then, of course, I _also_ have an automated Arch build that I
| use with Distrobox on top of my custom Silverblue build. I get
| the stability of an immutable OS layer with the easy installs and
| package availability of Arch.
| YorickPeterse wrote:
| I considered using an Arch container for development, but
| ultimately felt this wouldn't actually make my life easier, as
| I'd still have to deal with updating issues/manual work.
| Instead I'm just running a Fedora 37 container, and thus far
| it's working great.
| pxc wrote:
| > Silverblue is pretty great. But it's really been taken to
| another level in the last few months since it started allowing
| you to _boot_ from a container image.
|
| What was the state of affairs before? Is the main advantage
| that at install time, all you do is download the image (i.e.,
| you don't have to actually run the automation on the target)?
|
| Does the image have to be of Fedora?
| pkulak wrote:
| Well, before it was just a lot more work to create an install
| image and keep it updated. So you'd just stick with the
| official Silverblue image, or the spins (KDE, Sway, etc).
|
| And yeah, the advantage now is that you just pull from your
| image, and all the automations are run on the server
| beforehand. That means, if something breaks, you just don't
| upgrade because there's no new image, everything stays in
| sync across all your machines for free, and you don't have to
| use a bash/ansible/whatever script when you set up a new
| machine. Upgrades are also faster because all the layering
| has been done beforehand, thought that's not much of an issue
| if you have upgrades run in the background, which you should.
| pxc wrote:
| > having gone through this process I think I now understand why
| RPM packages are less commonly available compared to those for
| other distributions.
|
| The most popular option of this kind, DEB, is actually even worse
| to work with imo, due to essentially similar kinds of problems.
| DEB is the most likely format to be supported by application
| vendors solely due to the popularity of Ubuntu.
|
| If Fedora, rather than Ubuntu, was the distro of choice for
| newbies, dilettantes, and overburdened engineers who hope their
| choice of distro will afford them one fewer thing to focus on,
| then RPM would be the format Slack and Discord distribute for
| Linux. (And it would be about as much work for them as
| maintaining their DEB packages is for them now.)
| brnt wrote:
| > The most popular option of this kind, DEB, is actually even
| worse to work with imo
|
| Simply incorrect: https://xyrillian.de/thoughts/posts/argh-
| pm.html
| pxc wrote:
| Maybe interesting, but not actually relevant as far as I'm
| concerned.
|
| When I'm packaging, I don't care about the archive format of
| the binary packages. I care about the contents _inside_ the
| source package archives and the tooling and documentation for
| working with those files.
|
| (I'm also not super interested in third-party tooling like
| the author of the linked blog post was working on. I don't
| want to use something like Holo or FPM or whatever and treat
| the binary archive as a glorified zip file, naive of the base
| system and its conventions. I want to conform to the policies
| and norms of the target distro as far as possible, vendoring
| as few deps as possible, running the same linters that distro
| developers are expected to use, etc.)
| bcrescimanno wrote:
| I've been a user of Arch for the past several years and I've
| always been a huge proponent of the rolling release model. When I
| first picked up Arch, it was because I needed more modern
| versions of several tools than were packaged with Fedora or
| Ubuntu and Arch was a really easy way to get those updates. No
| more waiting 6 months for the next release cycle to get a new
| piece of software (yes, I know, "compile it yourself" is always
| an option--but, I've personally found that nothing destabilizes
| my system like adding a bunch of software from outside the
| package manager).
|
| I find my own argument somewhat less compelling today. With
| systems like Flatpak gaining traction, we're seeing a trend
| towards separating the Operating System (and I'm thinking more of
| the overall foundations of a complete, modern system, not just OS
| = Linux kernel) from the applications for that operating system.
| Existing package managers handling the OS while Flatpak,
| AppImage, Snap, etc. become how applications are installed and
| managed seems to be a good direction.
|
| To be clear, the divide today is far from perfect and we still
| run into the "Are you running the Flatpak or the distro version
| of X?" There are also compatibility issues to be worked out. All
| that said, I do still find the story of "a stable OS with up-to-
| date applications" compelling.
| coldblues wrote:
| >but, I've personally found that nothing destabilizes my system
| like adding a bunch of software from outside the package
| manager
|
| That's why you should be creating your own PKGBUILD.
| bcrescimanno wrote:
| It's so rarely an issue on Arch. Between the massive official
| repos and the incredibly comprehensive AUR, I've only needed
| to do it a couple of times.
|
| My initial comment was about needing to do that on non-arch
| systems. I've created my own RPM and DEB packages in the past
| as well; but, at least when I did it years ago, it wasn't as
| effective as a PKGBUILD on arch.
| bravetraveler wrote:
| Even without Flatpak and the ilk, Fedora is a _great_ place to
| be.
|
| The packaging tooling/infrastructure makes this 'just build
| from source' thing very 'make Fedora yours'.
|
| COPR and fedpkg mean that it's probable that someone has built
| the thing you want, the same way Fedora builds their stuff.
| freedomben wrote:
| I had a very similar experience as the author: I used and adored
| Arch, but the rolling updates got to be over whelming. Fedora
| (not Silverblue in my case, I still need to try that out) was the
| perfect solution. Very similar in philosophy to Arch, enough so
| that the Arch wiki is still 95% applicable, but very stable
| within major releases. It also was a bonus that learning Fedora
| also taught me CentOS/RHEL at the same time, which started coming
| in super handy when I needed super-stable and/or server-side OS.
| Nearly all of the skills (and even scripts) are fully compatible
| with both, with only the occasional minor difference. I still
| have a huge warm spot in my heart for Arch, but I rarely use it
| anymore (mainly on my pinebook pro for building ARM packages of
| my software).
|
| It's definitely time for me to try Silverblue
| colordrops wrote:
| The Arch wiki is very applicable to most distributions.
| tracnar wrote:
| I find Debian-based distros have much more customizations
| compared to more upstream based distros like Fedora and Arch
| Linux.
| freedomben wrote:
| Yes, likewise. Debian-based distros won't be wildly
| dissimilar, but you'll have to modify bash commands and
| stuff to fix paths that are different, conventions, and
| other things, whereas on Fedora it usually just works as
| is, minus a package name and a `dnf` v. `pacman` here and
| there. High level concepts will usually be the same, but
| when tweaking a Debian-based system you'll have to learn
| whether or how your distro of choice does it differently.
| coldblues wrote:
| Other alternatives are Nix (or NixOS entirely) and Guix.
___________________________________________________________________
(page generated 2023-03-03 23:01 UTC)