Depending on how far in the past your experience came from, it may be worth mucking around on a spare machine if you have one from time to time. I transitioned from EL8 to F34 earlier this year (moved to F35 this past weekend) and for my use cases it's been wonderfully solid.
Fedora used to be on the bleeding edge ages ago.... For anybody who abandoned it after FC8, I'd say you can definitely give it another shot. A lot has changed in the past decade. I run it even in my production servers (yeah, I know RHEL is there but I don't want to pay for subscription) alongside Debian and it has never crashed on me.
First of all, I used to be a Fedora user. The experience most of the time was excellent. Updating was a breeze and via external repos most packages were readily available. Most desktops/spins are well supported like sway, i3, xfce.
Nowadays I use Arch which I also think it's a great distro. The only thing I miss are delta RPMs.
Also, since CentOS was shut down, Fedora is a good way to learn how Red Hat based distros internals work.
CentOS most certainly was shut down, and replaced with CentOS Stream, which is a similar product that went from at least as stable as RHEL and not having ABI breakage, to the beta for the next RHEL and having ABI breakage. Close enough for many uses, but not the same thing.
As a future version of RHEL, CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist. I'll say it again:
CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist.
All packages that exist in Stream repos have passed the same internal gating test suites that RHEL has.
I'm sorry if this comes off as rough but it is very annoying seeing this "ABI incompatibility" statement be thrown around constantly without people fully understanding what it actually means in the context of RHEL. It is _not_ an all-encompassing policy that applies to the every part of the distribution the same like it would be implied for a library strictly following semver. There are levels and nuance, and some packages don't even make the list (which is why there are packages without a -devel subpackage).
It is okay to say that Stream may not be bug-for-bug identical to released versions of RHEL, but it will be ABI compatible.
I was thinking specifically in the context of ZFS, which break on minor releases because kernel-internal symbols are not fully stable (unless I've seriously misunderstood https://github.com/openzfs/zfs/issues/11320). And since Stream is a rolling release, users will therefore experience breakage unless they specifically pin their kernel version (or possibly use DKMS). That's ABI breakage, and RH explicitly saying that it doesn't count doesn't stop it breaking stuff that would work in a non-rolling release.
Again, please review the Kernel ABI knowledge base resource I provided, specifically the last two bullet points in the article.
If OpenZFS happens to work throughout an entire RHEL minor release and they are using non-kABI symbols (which they are), that is not ABI compatibility: that's _luck_. It is in no-way-shape-or-form any kind of ABI compatibility the way it is defined for RHEL. You can't call RHEL kABI/ABI compatibility something it's not, it has an explicit meaning and definition.
Per the GH issue you provided the project explicitly stated they did their best to reduce as much as possible their reliance on non-kABI symbols. This was accomplished through symbols being added to the RHEL stablelist and OpenZFS reducing the symbols they actually use. If they didn't have to use non-kABI symbols there wouldn't be a problem. I've had NVIDIA kmod's from ELRepo fail _multiple_ times in a single minor release because non-kABI symbols changed, not to mention between minor releases. This is still not an example of RHEL kABI/ABI breakage.
Not specifically about Fedora but Fedora Silverblue for me:
The key value for me is, if an update breaks something, I immediately roll back to the previous image (with just 1 terminal command) and don't have to deal with it unless I actually want to do so.
> SELinux [is] kinda esoteric and hard to understand
I don't totally disagree with you, but a thought suddenly struck me: maybe, exactly like Git, it isn't hard to understand, it's just that the UI, UX, and attendant documentation are not written for the majority of their potential audience. And thus, in the same way that many people fix Git problems by simply blowing away their local repo and starting over, SELinux users simply `setenforce 0` and walk away.
> You get updates every 6 months with a really nice upgrade experience. It is not rolling.
Also worth noting that these updates are optional. A given release has a ~13 months of support:
---
We say maintained for approximately 13 months because the supported period for releases is dependent on the date the release under development goes final. As a result, Release X is supported until one month (4 weeks) after the release of Release X+2.
This translates into:
- Fedora 34 will be maintained until four weeks after the release of Fedora 36.
- Fedora 35 will be maintained until four weeks after the release of Fedora 37.
You get upgrades every 6 months, but updates are rolled out constantly. For example Fedora gets the very newest kernels at the same pace as something like Arch, even for older releases. Fedora 33 currently has the same kernel as Fedora 35.
I would consider it "semi-rolling". It has major releases, and a few packages are pinned for the duration of the release, core stuff like glibc, systemd, GNOME, compilers / toolchains for various languages and so on. But the rest of the system is kept very up to date.
I think a big advantage of Fedora (also Ubuntu) is that a lot of its maintainers are being paid by Red Hat to maintain it. A lot of times your bug reports are going to be quickly read, you know it's very likely there is someone who is getting paid to ensure whatever problems you may have, don't happen. I know a lot of other distros have this too, but Red Hat employs a lot of Fedora maintainers.
OTOH, you're kinda subject to Red Hat's will. But then, every project is subject to its controllers. It's not like the Debian people are doing a good job just because they're not subject to a for-profit company.
Personally, I am very thankful for fact that the Fedora project is often the first to adopt certain technologies and inflict in their users the pain of fixing the first bugs and stabilizing the technology. Then a few years later I get it in Debian and it works just fine.
Fedora is Red Hat's "flagship" distro, in the sense that it's where all the cool new changes debut. Since Red Hat's pretty involved in core Linux development, Fedora is often one of the first places you can get major changes without having to set it up yourself. Like Pipewire for example: it's been available on Arch and Fedora for a while now but Fedora's the first place you can use it without having to set it up yourself afaik.
Has Fedora fixed its package management? I eventually deleted my Fedora partition and installed Ubuntu because package management was so painfully slow.
DNF is actually faster for me than APT on Ubuntu. 700 packages can get updated on 100Mbps link in a few minutes. Large package updates took 5+ minutes on Ubuntu.
I haven't used Fedora since 2015 or so, but at the time, I always felt DNF to be very slow or heavyweight. For example, I remember installing one random small package with few or no dependency installs at all could take something between 30 seconds and more than one minute, while apt-get would usually install the thing in a breeze. I wonder if this has changed.
Ah, but 'dnf install' does also what 'apt-get update' does when necessary. So, dnf is faster for me than 'apt-get update && apt-get install'. I think there is a flag you can alias to force disable updating repos. Though the delay is rare for me.
The flag you're thinking of is '-C | --cacheonly'. It is very useful for doing stuff like 'dnf [search|rq|list|etc...]', but it is not allowed with upgrade/install type runs.
dnf will do a check when running subcommands like 'install' to see if it _needs_ to update the cache data (as you noted), it won't always do it. There are a few factors that play in, but you can also adjust the cache expiry time in dnf.conf.
I believe some of the default settings for DNF are to blame. Editing the dnf.conf file to allow for more simultaneous
downloads and selecting the closest mirrors can really speed it up.
That's because dnf metadata is massive compared to apt's. If you're installing something on Fedora for the first time, dnf needs to download about 100mb of metadata.
It has improved a lot in the last few years, but a few things to point out:
* It's slower partly due to the sheer quantity of metadata. This metadata can be quite useful sometimes but whether it's worth the price can be debated.
* It's slower partly because DNF is transactional and is keeping track of the changes made to your system. This allows you to do things like view the history of your actions, rollback entire package operations, roll back every operation since $date, and so on. And also it can tell you whether any given package was installed directly by the user, installed as a dependency for something else, which repository it came from or whether it was installed directly from a file, and so on. All of that is super useful for auditing and recovering from screw-ups, but it means the package manager is doing a lot more work.
* The default # of parallel package downloads is a little low. It gets a lot faster if you bump it up a bit.
It seems you're being downvoted for a not very contentious experience.
Running "dnf install $pkg" can take upwards of a minute (~40 seconds with default repos for me) while it invokes "dnf update". This can make the act of browsing through and installing lots of packages one by one take many times as long as using apt's cached lists.
It's the only part of dnf I'm less than enamored by.
The 'dnf update'* part only runs sometimes, depending on your cache expiry setting in dnf.conf. If you run a single-package 'dnf install' a bunch of times in the same hour or two, then only the first one is slow while it runs the 'dnf update'* process.
Actually it just updates the metadata - it won't install new versions of packages. It is like the apt-get update, but if you actually run 'dnf update' that's equivalent to apt's update and* upgrade.
dnf tab completion is horribly slow on both RHEL and Fedora. I don't know why this is still a thing, but it has been always bad since the yum days in RHEL 5 or 6.
This defaults to Pipewire (instead of PulseAudio) and some are reporting problems with audio, especially in browser-based conferencing applications like Google Meet. I have Fedora 35 and don't use GMeet, but can report that playing videos (vlc) is fine.
Edit: See reply about the Pipewire default. However people reporting problems with audio in browser conferencing systems is new in F35.
It broke passthrough audio because Pipewire doesn't have that feature yet, so I had to downgrade all the way to ALSA to fix my media center which I have Fedora on.
As a GNOME/Wayland based desktop Fedora 35 is a definite improvement - it looks decent, Firefox looks and performs great with proper Wayland/EGL integration out of the box.
I found the height of the Gnome Top Bar or window title bar are way too big for a laptop screen and I could not find a way to change those (used to be done with CSS but that's gone looks like) - best I could do was to switch to different themes and autohide top bar with an extension. Hacky but at least makes it usable.
I don't know if it's still maintained, but the Minwaita theme (found on the usual theme websites) is just a fork of the default Adwaita theme that has less padding, especially in the top bar and the title bars.
Yeah Minwaita still seems to work - not eye candy but does the job. The Flat remix set of themes have borderless variants that don't give you any vertical space back but at least make it visually less bothersome to look at the title bars.
Windows 11 has the anti-feature of not supporting the old processor anymore. Who knows why. Could be anything from simplifying QA and maintenance effort to not being able to (or not willing to) implement a feature on the older platform.
Compared to that, I don't know of a platform Fedora has recently deprecated. Linux usually takes a really long time to deprecate and remove support for old hardware.
criddell is wondering what thing in common Fedora and Win11 had that made switching to either of them preferable to just sticking with Win10, I believe. As in: why not just stay on Win10, unless it was lacking something that Win11 and—apparently, if it was a viable alternative—Fedora have? What was the thing they both had that Win10 did not?
Windows 10 is still supported until 2025 and nobody would be surprised if they extend it two more years. If I were setting up a new machine today, I would probably still install Windows 10. Anything new is an unknown from a security perspective.
Debian 11, Fedora 35... These two distros are very influential. Both were recently released and both come by default with pipewire and wayland.
We'll have an Ubuntu LTS next year and it will probably be influenced by these releases. A few new problems because of these changes... a lot of fixes because of these changes.
Pipewire and wayland are not the default on Debian 11. You can use wayland on debian 11 fine, but pipewire is still not officially supported (https://wiki.debian.org/PipeWire).
While Pipewire is not default, Wayland absolutely is and has been the defalt on distros defaulting to GNOME for a very long time, unless the distro patched gnome to not do so (like debian did with Stretch)
Fedora Silverblue in particular has changed my workflow, but I came from Ubuntu and I felt like I was lost in an entirely new world so some friends of mine helped me cobble together a set of scripts.
So if you come from Ubuntu and want to give Fedora a shot but you need Ubuntu images, versions, etc then this might help you!
I want the advantages of using an image based OS, if you go look in the Ubuntu 21.10 thread here on HN from that day there's a bunch of complaints about PPAs breaking updates, etc. and Silverblue fixes all this.
EDIT: I did a stream last night trying to explain this to a coworker if you feel like listen to me ramble, sorry about the audio we just decided to do it on the spot: https://www.twitch.tv/videos/1193532435?t=00h22m23s
Hopefully someone else can explain better than me!
"Fedora Silverblue is an immutable desktop operating system. It aims to be extremely stable and reliable. It also aims to be an excellent platform for developers and for those using container-focused workflows."
Not yet, however people have been PRing in Ubuntu images, I just snagged them even though they're not merged.
I link to some build scripts people use in my repo, but yeah it would be nice if there were more distros in toolbox so that people can use whatever they want.
In the original we defaulted to the latest Fedora image (yes, even in the days of CoreOS... blame me for that), but allowed the user to override this with an environment variable (and later a `.toolboxrc` file in their home directory). Thus, IMHO, this is a regression.
Now it seems the new stewards are trying to be "clever" and protect you from yourself, creating "foot-guns" in the process.
Since Toolbox only works with OCI images that fulfill certain requirements, it will refuse images that aren't tagged with com.github.containers.toolbox="true" and com.github.debarshiray.toolbox="true" labels. These labels are meant to be used by the maintainer of the image to indicate that they have read this document and tested that the image works with Toolbox. You can use the following snippet in a Dockerfile for this:
LABEL com.github.containers.toolbox="true"
edit: I forgot part of my point: This is a regression from the original utility.
The main advantage of Silverblue isn't just toolbox (which isn't originally an Ubuntu tool, btw).
The main advantage of Silverblue is its readonly root fs. Toolbox comes as the provided way for devs to be able to work on top of that feature.
I think Debian has/had some energy devoted to turn the root fs read-only as an option (perhaps in order to move to an ostree based distro, ostree being already available as a package in Sid). Hopefully they'll manage to get it working.
Also, please note that it's not a silver bullet. An immutable FS is a good feature for security (both from malicious adversaries and an oblivious self), but of course it's not enough.
I've been using Linux on a secondary machine since 2011, and as my daily driver since 2018. I've distrohopped quite a bit - Ubuntu (2011), Puppy Linux (2012), Manjaro (2013), LXLE (2014), Solus (2016), and then back to Manjaro (2018). I liked Manjaro because I could get newer packages in the repositories (when compared with Ubuntu) and because of access to the AUR.
I made the switch to Fedora 34 a few months ago from Manjaro. It has newer packages than Ubuntu, has more software than Solus, is more modern than LXLE/Puppy Linux, and is more stable than Manjaro in my experience. I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else. I never had a smooth update with Manjaro, which led to me delaying updates for months until I would have time to debug and fix my laptop after the update. Bit of a security issue, especially with how often browsers update.
Fedora has been rock solid, and I haven't had any issues with my machine crashing or not booting into a desktop environment after an update. Congratulations to the team, looking forward to (smoothly) updating my laptop today!
On the flip side, I've been using Manjaro for years without issue, but when I updated my Fedora 33 workstation to 34, KDE showed a black screen oh boot. No matter how hard I tried I was unable to solve this problem, so I will be skipping Fedora from now on..
Yup, folks have different experiences a lot of the time when it comes to distros. I'm not claiming Fedora is always more stable than Manjaro - just that it has been for me.
I remember at the time of setting it up Fedora was the logical choice because they had some of the first support for AMD new graphics card (RX5700?). It was quite stable on my other computer and I recommended it for a while.
Do you use an Nvidia GPU? I think nouveau had issues with KDE Plasma on Fedora 34. Though I believe you could still boot, it would just hang while logging in. I had to install nvidia's proprietary drivers to fix it, though eventually switched to Gnome and haven't had any issues.
As I recall, 34 is where there were some dracut bugs that caused booting to fail too. I don't think it even depended on AMD or not, but perhaps presence or absence of certain peripheral hardware.
I had a working 34 system that suddenly wouldn't boot after a kernel update, while booting with an older kernel worked. But, this was because the older kernel was installed with an older dracut producing its initrd image. It took a while to sort out before it was finally stable again. During that broken period, a network install of 34 would produce the same result and there would not be an earlier boot entry to try instead. As I recall, one could rescue it with a rescue disk, downgrading dracut, and rebuilding the initrd.
I've been using Fedora since around 2004 I think, and this was one of the rare few software-prevents-boot regressions I can remember (as opposed to me-breaks-config or hardware-fails). It was also an example where the default "quiet boot" obscured what was really going on, as a black screen hiding a bunch of boot activities getting stuck and timing out for many minutes.
100% in agreement with you. I liked the idea of Manjaro but the way they deployed Nvidia driver updates made it feel like absolute luck of the draw whether you'd have a login screen waiting for you after rebooting post-update. I've had more Nvidia driver issues on Manjaro in a year than I've had in the past decade+ on Ubuntu or any other distro.
Switched to Fedora a week ago which I like a lot so far, but I still very much miss the AUR.
Flatpak + user maintained copr's have been mostly able to fill that void for me. The only package I've had to compile so far (that would have been available in the AUR) is wrk, a HTTP benchmarking tool. There is a copr available for it, but it doesn't seem to have builds for Fedora 34/35.
Well it's a bit a mix of predictability and stability (not the technical one).
One example Ubuntu...first Unity then Amazon then Snaps, and ubuntu is even considered an "enterprise distro"
But i am really not a distro fanboy (super happy if one uses linux and not windows/mac), in fact i use Free-BSD (no truenas etc...again same rule, take the original (i know technically that would be netbsd)) wherever i can, and if i have/can touch linux i choose a old warhorse-distro, mostly because of future predictability/stability.
Ah well, Manjaro was a blessing for me, so much that I donated to them as well. It feels like the best of both worlds - I don't have the motivation to install the system from scratch, but I'd like to use AUR.
Oh, and as others have said, upgrades are quite a YMMV thing, Manjaro upgrades haven't broken things for me since the last few years.
The difference between mainstream distros is shrinking. Soon, the most popular ones will come with pipewire, wayland and a recent GNOME with few modifications by default.
Thanks to flatpaks, appimages and snaps, I can finally have recently released software with a very stable distro. Hand compiled sofware often goes to /usr/local by default and I can install it without breaking anything. If I want bleeding edge without compiling it myself, I can still resort to guix, nix or homebrew.
The "native package manager" is not something we have to interact with so often these days. Linux on desktop has had some interesting improvements lately and the thing that was pointed by many as its biggest problem - fragmentation - is a much smaller issue now.
> The "native package manager" is not something we have to interact with so often these days
I guess one of the awesome things about Linux is how it manages to keep a wide variety of people happy. For example, one of the reasons I like to use Linux is I want to update everything at one go, and the fact that I have a Software Center app that lets me do exactly that - is awesome!
On another note, I hope Flatpaks keep gaining more popularity among the three. I really like using Flatpaks more than Snap/AppImages.
> I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else.
I did get an update that disabled the trackpad on my Asus laptop around Fedora 32 or so. It was an upstream kernel bug that got fixed in a few days, but it was still pretty annoying. This was during a regular dnf update within the same major version, not an update from 32->33 (the kernel gets updated regularly, not just between Fedora version updates).
The really nice thing about `dnf` is that you can easily downgrade or rollback an update. There's also an easy way to see all of the packages that have been installed by the user to help track down when or what broke a system (which I haven't had to use yet, but it is nice to have).
agreed Fedora is spectacular. Rock solid. Everything works. It has all the components tightly integrated.
>Nvidia’s proprietary driver now includes massively enhanced support for Wayland thanks to tight collaboration between the Fedora, Red Hat, and Nvidia teams.
No surprises there - Fedora sponsors most of the devs for the kernel as well as components like PipeWire, etc
Gnome is beautiful. I have had people carrying Macs ask me what OS im running - on my cool looking carbon fiber white Lenovo Yoga.
I've been using Fedora since 2005 and the one thing I don't like is the gnome desktop. I run a 55" 4K screen and spread out my windows like work on a real desktop. If I want to start something I have to move the mouse 5 miles to the upper-left corner (where there is no visible cue) to get the launcher-bar to appear. And then the bad appears, but all my windows magically rearrange and shrink, and the launcher now appears at the bottom of the screen, so I have to move my mouse 7 miles down to start something. I'd love to have the launcher ever-present and optionally on the left, right or bottom. But as people say, the gnome developers "know what's best for people" and do it how they see fit.
Most everything else about gnome is OK, and Fedora in general is great IMHO.
I don't want the overview. I know someone spent a lot of time on it and is probably proud (as they should be) of their dynamic ordering of the windows so you can see them all, but I don't want that view. Also, like I said I want the launcher available all the time - I've got tons of space for it and don't want to have an extra step to get it. I also don't have a Win key - maybe it's disguised.
You can install an extension (i.e. dash to dock) to make the launcher ever-present on whichever side of the screen you want. The main downside is that the extensions always break on GNOME upgrades and take a little while to get fixed.
> I liked Manjaro because I could get newer packages in the repositories (when compared with Ubuntu) and because of access to the AUR.
> I made the switch to Fedora 34 a few months ago from Manjaro. It has newer packages than Ubuntu
It's interesting to compare the release policies of the those distros.
Manjaro is a rolling distro; Fedora releases every 6 months, with 1 year support; Ubuntu has a mixed model (LTS: release every 2 years, support 4+ years, non-LTS: 6 months release/support).
Technically speaking, Ubuntu can have more up to date packages, if one goes the non-LTS way (I personally don't suggest that, though).
With the LTS versions, there's also the alternative of using official PPAs, repositories and self-contained package managers.
I do upgrade every two years (and I even find it too frequent) and use official PPAs/repos, but 1 year sounds appealing for users wishing out of the box recent packages, without using a rolling release.
> I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else.
I'm a little surprised. I've been running Arch since 2011 and it's been rock stable for me. I've run Fedora on secondary machines, but I never stuck with it because things would break during updates.
I suspect hardware has a lot to do with it. My Arch laptop is a ThinkPad with Intel graphics, and my secondary machines have been whatever is around.
The other variable is the desktop environment. On my primary laptop I used to run LXDE, and then switched to i3, and now sway. I ran ALSA instead of Pulse, but now I'm dipping my toes into PipeWire. When trying out Fedora I would always try Xfce which seemed like a good compromise since Gnome is definitely not for me. Xfce may not be much of a target for Fedora developers though, so it may not get the amount of attention that Gnome or KDE would get.
> having my machine not turn on due to some new kernel change or some video driver change, or something else. I never had a smooth update with Manjaro
Ironically, this was my experience of Fedora 10+ years ago when I dabbled with Linux as a desktop OS. I especially remember spending hours on IRC talking to Fedora folks trying to debug audio issues. I think it was around the time they transitioned from ALSA to PulseAudio.
I switched from Arch to Fedora in 2015. I don't miss anything from AUR. When I was on Arch, I used a bunch of stuff from AUR, but I honestly can't remember what I used.
So, it seems like it's worked out okay. I honestly got tired of using Arch and configuring everything. Things would break, and I'd have to figure out how to fix it. What broke the camel's back was when my window manager, awesome, broke. Don't get me started on the name 'awesome' for a window manager and how difficult it was to search for solutions to problems. By that time, I had grown older, and I just wanted something to work, and Fedora works fine for me.
I'm in a similar situation. Distro hopped quite a bit, (OpenSUSE, Ubuntu, Debian).
For 5 years now, I've ran Fedora on an old laptop that resides at my parents house, 5000 KM away from me. In that time I have not once physically been in contact with that server. I've done all updates via ssh, including full system upgrades (e.g. Fedora 32 -> Fedora 33) without any hiccups.
Nothing in Linux-land excites me anymore as much as running everything in unprivileged userland. Having the most bleeding edge software is overhyped, since it introduces instability into your system... especially if you carefully design it such as with Arch Linux. I can't believe using MacOS 12 and homebrew taught me the values of this. Flatpak or bust!
For example... I have Steam and Chromium happily running in a Flatpak install and it has zero more privileges that my non-sudo user account has.
No sudo in sight and for a start this gives me peace of mind. Zero trust needs to be a bigger deal in the Linux community.
I had similar experience with Arch around 2018 but it's been amazing after that since ~2019. I've never had any problems again and sometimes I would go away from my desktop for several months, come back and update everything in a single `pacman -Syu` with no problems (sometimes not updating in time _was_ the issue before). I've heard a lot about Arch/Manjaro being not stable and breaking things frequently enough, and it was true but isn't anymore (at least for me) which makes me quite sad because the problems from few years before turned away many excited users who are not willing to try again for obvious reasons.
I feel there's a honeymoon period after we distro-hop in which we feel we've found 'our Linux OS' for good. Because it's unlikely that we jump the gun with some random distro on average, We do the due diligence on whether it suits our needs before hopping and when it doesn't match our expectations we do it again!
I think that's the beauty of Linux! There's one for everyone.
How is Fedora's package management compared to Ubuntu's? I guess I've been spoiled by being able to apt install just about anything and 99% of the time there are 3rd party repos with most up to date versions too. Say what you want about Ubuntu, but if there's software for linux out there, the maker will at the very least make sure it works on Ubuntu, but I'm not so sure about other less popular distros.
The arch updates literally never breaks my system but that's because I don't use nvidia. Their drivers are the problem and the reason for millions of failed updates in Arch. If you use Intel it's a super smooth ride with no issues whatsoever.
I have this on a Microsoft Surface Laptop Go, and all the hardware "just works" right after install. Video, external video, touchscreen, sound, networking.
Is Apple still the only company you can pay for both hardware and software support? Because all I want is to drop down a couple grand and never have to think about "computer maintenance" again. I maintain my car myself because it's so infrequent (pretty much just oil changes) but it feels like my computer maintenance is constant.
One of the reasons for that constant maintenance seems to be The Web. Remember when you didn't need 4 gigs of ram to browse the web? When you didn't need a high-power 3D graphics card to look at Google Maps? (bad example but WebGL is mandatory for some simple sites, and if your graphics sucks/doesn't do hardware acceleration...)
I don't remember ever having to upgrade my car every few years just to visit a new local business. At some point we need to admit that this constant tech churn isn't improving our lives, but it is enriching some billionaires.
I completely get what you mean. I love freedom, I love being able to tinker, but these days I just want my machine to work. Linux on laptops is a nightmare, often even on the hardware that "supports" it. MacBooks are good enough that I can get things done and I don't have to think about Wi-Fi drivers or GPU drivers or whether I'm using the wrong CPU governor causing it to pump out heat. So I bought one and so far I haven't looked back.
Why do your machines need monthly updates? Do you constantly update any other machine that you own? Lawnmower, car, oven, microwave, bicycle, watch, reciprocating saw, vaccum, garage door, TV?
Because software is buggy, even Apples. It's not like you are updating hardware (like your other examples) you are doing a software update so that the software interfaces with the hardware better or fixes bugs.
nowadays your TV if it's a smart tv also gets monthly or quarterly updates too. they just tend to happen in off-peak hours. and car software updates are when you take them in for service.
you aren't doing a fair comparison asking why your X hardware doesn't need updates when comparing mostly hardware with simple software and full operating systems.
How is it not a fair comparison? They're machines. Just because we are currently building them in a way that is incredibly fragile and needs constant fixes, does not mean they have to be built that way.
Cars used to be built by hand, had tons of bugs, and were expensive. Then a man came along and found a way to produce them faster, cheaper, and with less bugs. That was pretty amazing for a time, but they still had plenty of bugs. And then some people from a culture of very fastidious craftsmen obsessed with quality began producing cars a little cheaper, and with far fewer bugs, and they lasted much longer. Then the whole world realized, "shit, our machines don't actually need to be so fragile," and they followed suit.
The lessons learned by those people in that culture were promoted around the world, and evolved to shape what we now call Lean and Agile. But the people using these new processes forgot the first lesson: we don't have to accept the status quo.
You can test, but testing does not prove an absence of bugs. It just means your tests did not reveal any. Maybe your testing is flawed, incomplete, inappropriate, biased etc.
Just saying for devs to "not write bugs" is pretty naive. Almost like saying "don't have car accidents". We don't want to have them, yet here we are. In complex environments, things happens that are sometimes outside our immediate control.
So then shouldn't we stop writing software? If it's really impossible to make software that doesn't have tons of bugs, yet it's perfectly possible to make hardware without those bugs, shouldn't we be "making hardware" instead?
Actually, now that I think of it, that's not the problem. The problem is we keep changing the software. My laptop from 15 years ago still functions exactly the same way it used to. It hasn't disintegrated into a puddle of bits. You just can't use it to visit any "modern website" or run any "modern software". If we just stopped upgrading everything every 5 seconds we could keep using old technology.
Apple machines still needs constantly updates, and worse, they keep nagging you.
My only macOS installation is a Catalina one, and Apple keeps wanting me to upgrade it to Big Sur, that I don't want for some reasons. However, the only workaround I found to stop the update badge from appearing (that is really distracting since it confuses me if this is something important or not) is to set some strange flag and kill Finder. If I open settings for any reason, the update badge reappears and this is really infuriating.
My system with the last amount of maintenance is my NixOS installation, where any workaround that I need for software/hardware issues are forever described in my dotfiles. So yeah, I need to find how to fix something once, however afterwards it will just work. Also different from Apple I can do upgrades when I want, they're atomic and I can also do rollbacks, so they're pretty much safe from a user perspective.
Mitigation against security vulnerabilities? Bug fixes? New features?
This question is intentionally missing the point.
If you think an internet-connected computer used for modern workloads can be treated like a lawn mower and doesn't need any updates over its usable life, you're dreaming.
Fedora is my goto distro when I need to get stuff done. I've used it professionally and it has worked just fine with all the proprietary software I needed (jetbrains, zoom, slack, spotify, etc...)
Although Arch has a special place in my heart and I play from time to time with FreeBSD, Fedora pretty much just works out of the box, is very stable (in my experience), has decently newish software (even if it is from flathub...) and it's not to hard to find rpms around for more obscure software.
The only issue that I've come across is with older software... Fedora doesn't seems to care that much about backwards compatibility so if I need to run a software with old ncurses version, tough luck.
> I still cannot understand what is wrong with name "Fedora"?
Nothing whatsoever to 95+% of people, but perhaps 5%, most of whom one might describe as "very online", have decided to strongly associate it with a certain type of annoying guy prone to wearing them (they're more often trilbies, but whatever, the fedora is what's been "meme'd"), to the point that they would choose to be bothered or turned off by an OS named after the hat style.
Honestly, the worst part about Debian is the name. Everything is deb-this and deb-that. Packages are .deb. Which is his ex-wife. Can you imagine getting a divorce and then for the rest of your life have this massive thing associated with your ex and will never go away be named after you? Yick.
I'm a huge fan of Arch. Not only can you quickly search for packages, but the packages are actually maintained and kept up-to-date. With Arch, not only is the software usually up-to-date... even if it isn't, it is easy to modify a PKGBUILD file—but they actually provide a package search on their website.
Even Ubuntu and Debian allows you to search packages on their website, but not Fedora. With Arch, when you search for a package, you can immediately see how the package is built as well.
Yes, Arch is not a distro for people that just want to run Linux with a bunch of out of date software. It is for people that want to take some building blocks and create the perfect distro for them. Unfortunately, the choices can be confusing at times, but it has been well worth the effort on my part to find out what software works for me. Once you do that, just keep a list of the packages you install. If you need to reinstall, it is easy enough providing that package list to pacstrap.
You can search for a package on Fedora's website. Very similar to Debian. Just do a Google/DDG/etc search for "Fedora packages" and click the link. (src.fedoraprojecr.org)
Thanks for sharing. I hadn't seen that before. Unfortunately, just a quick search of some Kubernetes tools that are included are at least 6 months old on Fedora, whereas Arch they are current.
Not switching to another distro is probably just inertia - I like a lot of stuff about Fedora and I'm used to it.
Honestly most of the addons are just cosmetic and minor UI stuff, but I don't really want to "downgrade" when the release version I have is "good enough"
Archlinux doesn't even support Secure Boot. Fedora does, and so does Ubuntu, it is much more pleasant this way when dual-booting with Win10 or Win11.
Fedora does have a VK_ERROR_INITIALIZATION_FAILED Vulkan problem with Nvidia though that Arch does not. F34 or F35 can't launch Wolftestein Youngblood from Steam on X11 session and errors out with VK_ERROR_INITIALIZATION_FAILED. Same system works on Archlinux and can even launch Youngblood in Wayland session.
Under Fedora I notice the following things:
- in wayland session vulkaninfo fails to run unless WAYLAND_DISPLAY is unset like so: WAYLAND_DISPLAY= vulkaninfo
- on Fedora with X11 session vulkaninfo randomly toggles between Mesa's software lavapipe vulkan and nvidia's vulkan implementation
- steam fails to launch a Proton game (Wolfenstein Youngblood) on X11/Wayland with "Startup failure: VK_ERROR_INITIALIZATION_FAILED" message
- I hear you need to set Vulkan variable: export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json before running 'steam', I tried and it fixes running 'vulkaninfo' so lavapipe doesn't randomly activate but it had no effect on steam, still getting VK_ERROR_INITIALIZATION_FAILED
I'm somewhat confused by the "Power Modes" feature ... it's being introduced as a Gnome feature, but why would that be tied to Gnome? Isn't it usable from other window managers/desktop environments?
I've been using Ubuntu since 2005. Most of this time on Thinkpads. My last laptop is the 9th gen X1, and the microphone does not work on the latest Ubuntu (not LTS, but still a very basic function). On a whim I tried a live Fedora On Fedora it just worked. This makes me wonder if it's time to change distro after so many years. I always kept to Ubuntu as a switch would slow me down while I learn where everything is but it seems like that barrier is lower these days....
Is there a "translation" guide for distro hoppers?
Something that I can tell which distro I'm coming from and it would tell me to do X in distro Y, do Z?
Honestly I don't think one really needs such. Nowadays Linux distros are very similar, only thing I could imagine would be a translator for package managers.
What are the advantages of Fedora over Ubuntu - if any?
I have been using Ubuntu as my daily driver for a few years now, without complaints, but as I will be getting a new laptop in the near future I might consider other distros. Back when I installed Ubuntu 18.04 I shortly tried Fedora, but for as simple reason as I did not like the "look" I switched to Ubuntu and ran with it ever since.
I just switched to Fedora after almost a decade and a half of Ubuntu when I got a new laptop that I had to set up from scratch anyway. The switch was relatively seamless for me, as in: it's mostly similar to Ubuntu. The main reason for me was wanting to give GNOME 40 a try after having heard many good things about it, and also Ubuntu starting to feel a bit "off" from the intended GNOME experience. Everything feels more tightly integrated on Fedora, with e.g Flatpaks being a first-class citizen, the software centre working properly, and Pipewire being enabled. Which is weird, because the polished, integrated experience was what got me on Ubuntu in the first place.
Thanks a lot for your description. Could you give me a little more information as to what you find better in GNOME 40? And perhaps what felt off with Ubuntu?
Pipewire may be a candidate for a something that would make me switch, only because I have some issues with Ubuntu and my bluetooth headset, where the microphone is not really working always. Also having to switch back and forth between high quality playback for music and "headset" settings is not really ideal. But I am unaware of Pipewire solving these.
It's not so much that I found things explicitly better, but that the descriptions piqued my interested and I just wanted to experience them for myself. Specifically, trackpad gestures combined with horizontal workspaces. (In practice, I usually have a keyboard and mouse so I don't use the trackpad much, although the horizontal workspaces feel slightly more natural.)
Things feeling off are hard to describe, but a concrete one is the software centre being pretty buggy and Snaps causing there to be many duplicate entries (and also Snaps being dependent on a single, closed-source Canonical server by definition).
But yes, I think Pipewire sealed the deal for me, at least in terms of giving Fedora a try once. I'm not sure why anymore, but I think it had something to do with being able to do screen sharing in Wayland?
In either case, it was mostly curiosity, and the differences really aren't that big. But it worked just fine right away, with nothing much to get used to, so I just stuck with it. Curious to see how the upgrade to v35 will go though.
Thanks a lot for your thorough explanation. I was not aware of the gestures thing. Perhaps I will give it a try when I get a new laptop. Then I can always go back to Ubuntu if I do not like it.
They are, for the most part, going to be the same experience for most people.
I like Fedora because it has newer packages and I interact with more RHEL-like Linux at work, so its more comfy cozy on my personal machines than Debian-like or Arch-like Linux.
182 comments
[ 3.7 ms ] story [ 244 ms ] threadSee also: https://news.ycombinator.com/item?id=29081329
I'm not a fan of Fedora, I had a bad experience(many bugs) in the past. Nevertheless, it's a good distro to check out the newest Gnome.
I've been using Fedora for years and years now and it has never disappointed me. Rock solid.
Nowadays I use Arch which I also think it's a great distro. The only thing I miss are delta RPMs.
Also, since CentOS was shut down, Fedora is a good way to learn how Red Hat based distros internals work.
CentOS Stream isn't geared towards production environments according to the CentOS website.
Please review the following resources before making statements about RHEL ABI compatibility in Stream:
---
RHEL ABI: https://access.redhat.com/articles/rhel8-abi-compatibility
RHEL Kernel ABI: https://access.redhat.com/solutions/444773
Kernel Sources (Module.kabi_<arch>):
Pat Riehecky - Thinking About Binary Compatibility and CentOS Stream: https://www.youtube.com/watch?v=pVZuvoVau-0---
As a future version of RHEL, CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist. I'll say it again:
CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist.
All packages that exist in Stream repos have passed the same internal gating test suites that RHEL has.
I'm sorry if this comes off as rough but it is very annoying seeing this "ABI incompatibility" statement be thrown around constantly without people fully understanding what it actually means in the context of RHEL. It is _not_ an all-encompassing policy that applies to the every part of the distribution the same like it would be implied for a library strictly following semver. There are levels and nuance, and some packages don't even make the list (which is why there are packages without a -devel subpackage).
It is okay to say that Stream may not be bug-for-bug identical to released versions of RHEL, but it will be ABI compatible.
If OpenZFS happens to work throughout an entire RHEL minor release and they are using non-kABI symbols (which they are), that is not ABI compatibility: that's _luck_. It is in no-way-shape-or-form any kind of ABI compatibility the way it is defined for RHEL. You can't call RHEL kABI/ABI compatibility something it's not, it has an explicit meaning and definition.
Per the GH issue you provided the project explicitly stated they did their best to reduce as much as possible their reliance on non-kABI symbols. This was accomplished through symbols being added to the RHEL stablelist and OpenZFS reducing the symbols they actually use. If they didn't have to use non-kABI symbols there wouldn't be a problem. I've had NVIDIA kmod's from ELRepo fail _multiple_ times in a single minor release because non-kABI symbols changed, not to mention between minor releases. This is still not an example of RHEL kABI/ABI breakage.
Delta RPMs just aren't worth the pain. They were a nice idea at the time but the utility of them has not kept up with the cost of supporting them.
The key value for me is, if an update breaks something, I immediately roll back to the previous image (with just 1 terminal command) and don't have to deal with it unless I actually want to do so.
You get to work on a potentially Red Hat Enterprise Linux like distro. Might come in handy professionally.
Hmm, can't think of anything else. I use Arch.
I don't totally disagree with you, but a thought suddenly struck me: maybe, exactly like Git, it isn't hard to understand, it's just that the UI, UX, and attendant documentation are not written for the majority of their potential audience. And thus, in the same way that many people fix Git problems by simply blowing away their local repo and starting over, SELinux users simply `setenforce 0` and walk away.
Compared to Ubuntu, more stuff is upstreamed and the package management is nicer (dnf history undo is a lifesaver).
Also worth noting that these updates are optional. A given release has a ~13 months of support:
---
We say maintained for approximately 13 months because the supported period for releases is dependent on the date the release under development goes final. As a result, Release X is supported until one month (4 weeks) after the release of Release X+2.
This translates into:
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Mai...
I would consider it "semi-rolling". It has major releases, and a few packages are pinned for the duration of the release, core stuff like glibc, systemd, GNOME, compilers / toolchains for various languages and so on. But the rest of the system is kept very up to date.
OTOH, you're kinda subject to Red Hat's will. But then, every project is subject to its controllers. It's not like the Debian people are doing a good job just because they're not subject to a for-profit company.
Personally, I am very thankful for fact that the Fedora project is often the first to adopt certain technologies and inflict in their users the pain of fixing the first bugs and stabilizing the technology. Then a few years later I get it in Debian and it works just fine.
dnf will do a check when running subcommands like 'install' to see if it _needs_ to update the cache data (as you noted), it won't always do it. There are a few factors that play in, but you can also adjust the cache expiry time in dnf.conf.
* It's slower partly due to the sheer quantity of metadata. This metadata can be quite useful sometimes but whether it's worth the price can be debated.
* It's slower partly because DNF is transactional and is keeping track of the changes made to your system. This allows you to do things like view the history of your actions, rollback entire package operations, roll back every operation since $date, and so on. And also it can tell you whether any given package was installed directly by the user, installed as a dependency for something else, which repository it came from or whether it was installed directly from a file, and so on. All of that is super useful for auditing and recovering from screw-ups, but it means the package manager is doing a lot more work.
* The default # of parallel package downloads is a little low. It gets a lot faster if you bump it up a bit.
Running "dnf install $pkg" can take upwards of a minute (~40 seconds with default repos for me) while it invokes "dnf update". This can make the act of browsing through and installing lots of packages one by one take many times as long as using apt's cached lists.
It's the only part of dnf I'm less than enamored by.
Actually it just updates the metadata - it won't install new versions of packages. It is like the apt-get update, but if you actually run 'dnf update' that's equivalent to apt's update and* upgrade.
Edit: See reply about the Pipewire default. However people reporting problems with audio in browser conferencing systems is new in F35.
It broke passthrough audio because Pipewire doesn't have that feature yet, so I had to downgrade all the way to ALSA to fix my media center which I have Fedora on.
I found the height of the Gnome Top Bar or window title bar are way too big for a laptop screen and I could not find a way to change those (used to be done with CSS but that's gone looks like) - best I could do was to switch to different themes and autohide top bar with an extension. Hacky but at least makes it usable.
Doesn't that imply Windows 11 and Fedora have some required feature that Windows 10 lacks?
Compared to that, I don't know of a platform Fedora has recently deprecated. Linux usually takes a really long time to deprecate and remove support for old hardware.
Windows 10 is still supported until 2025 and nobody would be surprised if they extend it two more years. If I were setting up a new machine today, I would probably still install Windows 10. Anything new is an unknown from a security perspective.
We'll have an Ubuntu LTS next year and it will probably be influenced by these releases. A few new problems because of these changes... a lot of fixes because of these changes.
>>As this is the default Debian desktop environment, Wayland is used by default in Debian 10 and newer, older versions use Xorg by default.
https://wiki.debian.org/Wayland
chrome://flags/#enable-webrtc-pipewire-capturer
For Chrome, you need to enable chrome://flags/#enable-webrtc-pipewire-capturer
For more details, what packages need to be installed and what setup done (for sway, for example) see https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar... (yes, arch wiki, the principles are same for all distros).
So if you come from Ubuntu and want to give Fedora a shot but you need Ubuntu images, versions, etc then this might help you!
https://github.com/castrojo/ublue
EDIT: I did a stream last night trying to explain this to a coworker if you feel like listen to me ramble, sorry about the audio we just decided to do it on the spot: https://www.twitch.tv/videos/1193532435?t=00h22m23s
Hopefully someone else can explain better than me!
"Fedora Silverblue is an immutable desktop operating system. It aims to be extremely stable and reliable. It also aims to be an excellent platform for developers and for those using container-focused workflows."
I link to some build scripts people use in my repo, but yeah it would be nice if there were more distros in toolbox so that people can use whatever they want.
It should just be a user configuration.
In the original we defaulted to the latest Fedora image (yes, even in the days of CoreOS... blame me for that), but allowed the user to override this with an environment variable (and later a `.toolboxrc` file in their home directory). Thus, IMHO, this is a regression.
According to the docs (https://github.com/containers/toolbox#image-requirements): edit: I forgot part of my point: This is a regression from the original utility.Oh...well that's unfortunate.
The main advantage of Silverblue is its readonly root fs. Toolbox comes as the provided way for devs to be able to work on top of that feature.
I think Debian has/had some energy devoted to turn the root fs read-only as an option (perhaps in order to move to an ostree based distro, ostree being already available as a package in Sid). Hopefully they'll manage to get it working.
Also, please note that it's not a silver bullet. An immutable FS is a good feature for security (both from malicious adversaries and an oblivious self), but of course it's not enough.
I made the switch to Fedora 34 a few months ago from Manjaro. It has newer packages than Ubuntu, has more software than Solus, is more modern than LXLE/Puppy Linux, and is more stable than Manjaro in my experience. I got tired of running `pacman -Syu`, rebooting, and having my machine not turn on due to some new kernel change or some video driver change, or something else. I never had a smooth update with Manjaro, which led to me delaying updates for months until I would have time to debug and fix my laptop after the update. Bit of a security issue, especially with how often browsers update.
Fedora has been rock solid, and I haven't had any issues with my machine crashing or not booting into a desktop environment after an update. Congratulations to the team, looking forward to (smoothly) updating my laptop today!
I had a working 34 system that suddenly wouldn't boot after a kernel update, while booting with an older kernel worked. But, this was because the older kernel was installed with an older dracut producing its initrd image. It took a while to sort out before it was finally stable again. During that broken period, a network install of 34 would produce the same result and there would not be an earlier boot entry to try instead. As I recall, one could rescue it with a rescue disk, downgrading dracut, and rebuilding the initrd.
I've been using Fedora since around 2004 I think, and this was one of the rare few software-prevents-boot regressions I can remember (as opposed to me-breaks-config or hardware-fails). It was also an example where the default "quiet boot" obscured what was really going on, as a black screen hiding a bunch of boot activities getting stuck and timing out for many minutes.
Switched to Fedora a week ago which I like a lot so far, but I still very much miss the AUR.
And it can work across any Linux distribution.
One example Ubuntu...first Unity then Amazon then Snaps, and ubuntu is even considered an "enterprise distro"
But i am really not a distro fanboy (super happy if one uses linux and not windows/mac), in fact i use Free-BSD (no truenas etc...again same rule, take the original (i know technically that would be netbsd)) wherever i can, and if i have/can touch linux i choose a old warhorse-distro, mostly because of future predictability/stability.
Oh, and as others have said, upgrades are quite a YMMV thing, Manjaro upgrades haven't broken things for me since the last few years.
Archinstall is a thing now.
Thanks to flatpaks, appimages and snaps, I can finally have recently released software with a very stable distro. Hand compiled sofware often goes to /usr/local by default and I can install it without breaking anything. If I want bleeding edge without compiling it myself, I can still resort to guix, nix or homebrew.
The "native package manager" is not something we have to interact with so often these days. Linux on desktop has had some interesting improvements lately and the thing that was pointed by many as its biggest problem - fragmentation - is a much smaller issue now.
I guess one of the awesome things about Linux is how it manages to keep a wide variety of people happy. For example, one of the reasons I like to use Linux is I want to update everything at one go, and the fact that I have a Software Center app that lets me do exactly that - is awesome!
On another note, I hope Flatpaks keep gaining more popularity among the three. I really like using Flatpaks more than Snap/AppImages.
Let me guess, Nvidia?
There were quite a few issues with amdgpu that would get fixed in certain kernel/video driver updates, and broken in other ones.
I did get an update that disabled the trackpad on my Asus laptop around Fedora 32 or so. It was an upstream kernel bug that got fixed in a few days, but it was still pretty annoying. This was during a regular dnf update within the same major version, not an update from 32->33 (the kernel gets updated regularly, not just between Fedora version updates).
So personal anecdotes and YMMV.
>Nvidia’s proprietary driver now includes massively enhanced support for Wayland thanks to tight collaboration between the Fedora, Red Hat, and Nvidia teams.
No surprises there - Fedora sponsors most of the devs for the kernel as well as components like PipeWire, etc
Gnome is beautiful. I have had people carrying Macs ask me what OS im running - on my cool looking carbon fiber white Lenovo Yoga.
I've been using Fedora since 2005 and the one thing I don't like is the gnome desktop. I run a 55" 4K screen and spread out my windows like work on a real desktop. If I want to start something I have to move the mouse 5 miles to the upper-left corner (where there is no visible cue) to get the launcher-bar to appear. And then the bad appears, but all my windows magically rearrange and shrink, and the launcher now appears at the bottom of the screen, so I have to move my mouse 7 miles down to start something. I'd love to have the launcher ever-present and optionally on the left, right or bottom. But as people say, the gnome developers "know what's best for people" and do it how they see fit.
Most everything else about gnome is OK, and Fedora in general is great IMHO.
> I made the switch to Fedora 34 a few months ago from Manjaro. It has newer packages than Ubuntu
It's interesting to compare the release policies of the those distros.
Manjaro is a rolling distro; Fedora releases every 6 months, with 1 year support; Ubuntu has a mixed model (LTS: release every 2 years, support 4+ years, non-LTS: 6 months release/support).
Technically speaking, Ubuntu can have more up to date packages, if one goes the non-LTS way (I personally don't suggest that, though).
With the LTS versions, there's also the alternative of using official PPAs, repositories and self-contained package managers.
I do upgrade every two years (and I even find it too frequent) and use official PPAs/repos, but 1 year sounds appealing for users wishing out of the box recent packages, without using a rolling release.
It never happened to me with Manjaro.
I suspect hardware has a lot to do with it. My Arch laptop is a ThinkPad with Intel graphics, and my secondary machines have been whatever is around.
The other variable is the desktop environment. On my primary laptop I used to run LXDE, and then switched to i3, and now sway. I ran ALSA instead of Pulse, but now I'm dipping my toes into PipeWire. When trying out Fedora I would always try Xfce which seemed like a good compromise since Gnome is definitely not for me. Xfce may not be much of a target for Fedora developers though, so it may not get the amount of attention that Gnome or KDE would get.
Ironically, this was my experience of Fedora 10+ years ago when I dabbled with Linux as a desktop OS. I especially remember spending hours on IRC talking to Fedora folks trying to debug audio issues. I think it was around the time they transitioned from ALSA to PulseAudio.
to those that switch away from Arch, what do you do about this? stop using that software? update/build it yourself from source?
So, it seems like it's worked out okay. I honestly got tired of using Arch and configuring everything. Things would break, and I'd have to figure out how to fix it. What broke the camel's back was when my window manager, awesome, broke. Don't get me started on the name 'awesome' for a window manager and how difficult it was to search for solutions to problems. By that time, I had grown older, and I just wanted something to work, and Fedora works fine for me.
I don't need the last software update right away and if I need it, I have PPA and flatpak.
For 5 years now, I've ran Fedora on an old laptop that resides at my parents house, 5000 KM away from me. In that time I have not once physically been in contact with that server. I've done all updates via ssh, including full system upgrades (e.g. Fedora 32 -> Fedora 33) without any hiccups.
To me, that's amazing.
For example... I have Steam and Chromium happily running in a Flatpak install and it has zero more privileges that my non-sudo user account has.
No sudo in sight and for a start this gives me peace of mind. Zero trust needs to be a bigger deal in the Linux community.
I think that's the beauty of Linux! There's one for everyone.
For the rare packages you can't find in the default repositories you can get through RPM Fusion.
One of the reasons for that constant maintenance seems to be The Web. Remember when you didn't need 4 gigs of ram to browse the web? When you didn't need a high-power 3D graphics card to look at Google Maps? (bad example but WebGL is mandatory for some simple sites, and if your graphics sucks/doesn't do hardware acceleration...)
I don't remember ever having to upgrade my car every few years just to visit a new local business. At some point we need to admit that this constant tech churn isn't improving our lives, but it is enriching some billionaires.
That's just not true. Try a ThinkPad with Fedora and you'll see.
I restart my work and home machines once per month for updates and that's it.
nowadays your TV if it's a smart tv also gets monthly or quarterly updates too. they just tend to happen in off-peak hours. and car software updates are when you take them in for service.
you aren't doing a fair comparison asking why your X hardware doesn't need updates when comparing mostly hardware with simple software and full operating systems.
Cars used to be built by hand, had tons of bugs, and were expensive. Then a man came along and found a way to produce them faster, cheaper, and with less bugs. That was pretty amazing for a time, but they still had plenty of bugs. And then some people from a culture of very fastidious craftsmen obsessed with quality began producing cars a little cheaper, and with far fewer bugs, and they lasted much longer. Then the whole world realized, "shit, our machines don't actually need to be so fragile," and they followed suit.
The lessons learned by those people in that culture were promoted around the world, and evolved to shape what we now call Lean and Agile. But the people using these new processes forgot the first lesson: we don't have to accept the status quo.
It's not defeatist, it's reality.
You can test, but testing does not prove an absence of bugs. It just means your tests did not reveal any. Maybe your testing is flawed, incomplete, inappropriate, biased etc.
Just saying for devs to "not write bugs" is pretty naive. Almost like saying "don't have car accidents". We don't want to have them, yet here we are. In complex environments, things happens that are sometimes outside our immediate control.
Actually, now that I think of it, that's not the problem. The problem is we keep changing the software. My laptop from 15 years ago still functions exactly the same way it used to. It hasn't disintegrated into a puddle of bits. You just can't use it to visit any "modern website" or run any "modern software". If we just stopped upgrading everything every 5 seconds we could keep using old technology.
My only macOS installation is a Catalina one, and Apple keeps wanting me to upgrade it to Big Sur, that I don't want for some reasons. However, the only workaround I found to stop the update badge from appearing (that is really distracting since it confuses me if this is something important or not) is to set some strange flag and kill Finder. If I open settings for any reason, the update badge reappears and this is really infuriating.
My system with the last amount of maintenance is my NixOS installation, where any workaround that I need for software/hardware issues are forever described in my dotfiles. So yeah, I need to find how to fix something once, however afterwards it will just work. Also different from Apple I can do upgrades when I want, they're atomic and I can also do rollbacks, so they're pretty much safe from a user perspective.
This question is intentionally missing the point.
If you think an internet-connected computer used for modern workloads can be treated like a lawn mower and doesn't need any updates over its usable life, you're dreaming.
Although Arch has a special place in my heart and I play from time to time with FreeBSD, Fedora pretty much just works out of the box, is very stable (in my experience), has decently newish software (even if it is from flathub...) and it's not to hard to find rpms around for more obscure software.
The only issue that I've come across is with older software... Fedora doesn't seems to care that much about backwards compatibility so if I need to run a software with old ncurses version, tough luck.
https://fedoramagazine.org/whats-new-fedora-35-workstation/
And also about the differend spins that are available for download.
https://fedoramagazine.org/announcing-fedora-35/
Nothing whatsoever to 95+% of people, but perhaps 5%, most of whom one might describe as "very online", have decided to strongly associate it with a certain type of annoying guy prone to wearing them (they're more often trilbies, but whatever, the fedora is what's been "meme'd"), to the point that they would choose to be bothered or turned off by an OS named after the hat style.
Even Ubuntu and Debian allows you to search packages on their website, but not Fedora. With Arch, when you search for a package, you can immediately see how the package is built as well.
Yes, Arch is not a distro for people that just want to run Linux with a bunch of out of date software. It is for people that want to take some building blocks and create the perfect distro for them. Unfortunately, the choices can be confusing at times, but it has been well worth the effort on my part to find out what software works for me. Once you do that, just keep a list of the packages you install. If you need to reinstall, it is easy enough providing that package list to pacstrap.
ubuntu at least had a gui tool available in their last LTS, though it only worked for the gnome frontend.
nvme fronting a raid is really nice but btrfs and lvm/mdadm options just fall short with write holes and other unacceptable failure modes.
kind of a shame because dnf is so much better than apt, and i'd like to play with silverblue.
This strict adherence to licensing matters certainly saved IBM's ass in SCO v. IBM in regards to IBM's work on JFS for Linux.
Fedora does have a VK_ERROR_INITIALIZATION_FAILED Vulkan problem with Nvidia though that Arch does not. F34 or F35 can't launch Wolftestein Youngblood from Steam on X11 session and errors out with VK_ERROR_INITIALIZATION_FAILED. Same system works on Archlinux and can even launch Youngblood in Wayland session.
Under Fedora I notice the following things:
- in wayland session vulkaninfo fails to run unless WAYLAND_DISPLAY is unset like so: WAYLAND_DISPLAY= vulkaninfo
- on Fedora with X11 session vulkaninfo randomly toggles between Mesa's software lavapipe vulkan and nvidia's vulkan implementation
- steam fails to launch a Proton game (Wolfenstein Youngblood) on X11/Wayland with "Startup failure: VK_ERROR_INITIALIZATION_FAILED" message
- I hear you need to set Vulkan variable: export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json before running 'steam', I tried and it fixes running 'vulkaninfo' so lavapipe doesn't randomly activate but it had no effect on steam, still getting VK_ERROR_INITIALIZATION_FAILED
Vulkan on Fedora is absolute shit show.
BS, learn to read:
https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
Arch OpenSUSE Debian Fedora
I have been using Ubuntu as my daily driver for a few years now, without complaints, but as I will be getting a new laptop in the near future I might consider other distros. Back when I installed Ubuntu 18.04 I shortly tried Fedora, but for as simple reason as I did not like the "look" I switched to Ubuntu and ran with it ever since.
Pipewire may be a candidate for a something that would make me switch, only because I have some issues with Ubuntu and my bluetooth headset, where the microphone is not really working always. Also having to switch back and forth between high quality playback for music and "headset" settings is not really ideal. But I am unaware of Pipewire solving these.
Things feeling off are hard to describe, but a concrete one is the software centre being pretty buggy and Snaps causing there to be many duplicate entries (and also Snaps being dependent on a single, closed-source Canonical server by definition).
But yes, I think Pipewire sealed the deal for me, at least in terms of giving Fedora a try once. I'm not sure why anymore, but I think it had something to do with being able to do screen sharing in Wayland?
In either case, it was mostly curiosity, and the differences really aren't that big. But it worked just fine right away, with nothing much to get used to, so I just stuck with it. Curious to see how the upgrade to v35 will go though.
I like Fedora because it has newer packages and I interact with more RHEL-like Linux at work, so its more comfy cozy on my personal machines than Debian-like or Arch-like Linux.