Fedora 35
getfedora.org
getfedora.org
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!
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.
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.
>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 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.
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.
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 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.
For the rare packages you can't find in the default repositories you can get through RPM Fusion.
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 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.
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 think that's the beauty of Linux! There's one for everyone.
It never happened to me with Manjaro.
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.
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.
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.
https://fedoramagazine.org/whats-new-fedora-35-workstation/
And also about the differend spins that are available for download.
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!
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.
Now it seems the new stewards are trying to be "clever" and protect you from yourself, creating "foot-guns" in the process.
According to the docs (https://github.com/containers/toolbox#image-requirements): 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.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 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.
"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."
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!
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.
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).
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.
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.
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.
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.
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.
Arch OpenSUSE Debian 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.
* 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.
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.
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.
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.
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...
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.
Compared to Ubuntu, more stuff is upstreamed and the package management is nicer (dnf history undo is a lifesaver).
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.
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.
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Mai...
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.
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>):
- RHEL 9: https://gitlab.com/redhat/centos-stream/rpms/kernel
- RHEL 8: https://git.centos.org/rpms/kernel/blob/c8s/f/SOURCES
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.
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.
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.
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.