Fedora Linux 34 is officially here
fedoramagazine.orgWhile pipewire still needs a lot of work and some people will see regressions in their workflow, this change is so much better than the pulseaudio disaster.
It already enables things like more reasonable Bluetooth access, BT codec/profile switching, close to real-time audio, etc. With updated pipewire you can run jack applications like guitarix and ardour and they just work. With pipewire updated from copr repositories and iRig I can use guitarix OOTB and the delay is low enough to ignore.
I can also watch movies with audio going over Bluetooth - pulseaudio had 400+ms delay, pipewire is pretty much synced up. (That's on standard codecs, not aptx) It's better than what either windows or Mac can achieve here.
If it can be useful for anyone, I've been maintaining this COPR for Pipewire (from upstream Fedora, but the patches come a bit quicker to this). https://copr.fedorainfracloud.org/coprs/dbenjaminmiller/pipe...
Pipewire was way rockier even a few months ago. It's gotten quite good especially since 0.3.25.
Ed. mfrey also has a copr with a nightly build. But this is unstable, obviously. My copr just has release builds.
In 34, I've seen a problem with Ardour accessing the JACK API in Pipewire. Apparently one of the API calls is not implemented, which makes Ardour crash from time to time. Sadly, this means I am not comfortable using a completely free/open-source audio production platform yet.
Downvotes are really getting out of hand on this site. It's like a person cannot even express slight negativity. I _want_ to have a completely FOSS audio production stack. I beta-tested Fedora and found a showstopper, which means I need to stick to MacOS for my audio work for the time being. Somebody thinks this means my comment is invalid.
Yup, there's still some things missing. Freewheeling is one of them which makes exports from ardour get stuck. But that's in progress upstream.
I don't get this, does Pipewire work on its own? If it's just another audio layer in the way, how can it work better than just PulseAudio alone? (i.e. Pipewire + PulseAudio vs just PulseAudio)
Pipewire works on its own but has plugins that allow it to mimic the PulseAudio API (as well as others, such as JACK). This makes it compatible with the applications that don't directly integrate with PW.
It's an alternative audio subsystem with a design that is a mix of Pulse and JACK features/architectures. It generally seems to have lower latencies than Pulse but higher latencies than JACK.
I've heard so many good things about pipewire, they should really get the pipewire guy to refactor systemd too :)
Pipewire uses a different architecture than pulseaudio. It's basically "we learned lots of things from low-latency video, let's apply that everywhere", not a refactor.
What do you want to change in systemd specificaly?
one bit of relevant information to add to my comment:
The guy who wrote pulseaudio also designed systemd.
Since pipewire seems to get rave reviews, and pulseaudio grumbles... a natural train of thought would be - get the guy who wrote pipewire to take a stab at systemd.
As to specific systemd changes, I would love if someone:
- Make the systemd config files more intuitive. While the old /etc/init.d/foo files contained arguably too much logic, the systemd service files are stupid enough that logic frequently has to be pushed into (and hidden inside) a daemon.
change the awful directory structure/files/links to something more elegant and organized It's like they threw them all in one directory, and simultaneously sharded them across /etc /lib etc
status commands/journalctl/binary log files. ugh.
How has it absorbed so much into itself?
It's become a little like busybox - making an analogy here - where it absorbs tried-and-true utilities and replaces them with "good enough" that... isn't. One example might be NTP which does time sort of poorly. Yes ntp is crufty, but it does time extremely well.
> a natural train of thought would be - get the guy who wrote pipewire to take a stab at systemd.
Alternative train of thought - Pottering was not great with low latency stream processing, but someone else was. Why expect the people who are good with low latency stream processing to be good with low-level process management? People have different skills/interests.
>this change is so much better than the pulseaudio disaster.
Cant wait until we say the same about systemd.
I've been an Ubuntu user for ages, any reasons to switch to Fedora?
Vanilla gnome, more up-to-date software, package management with dnf is superior than apt. You don't have to have snaps shoved down your throat (but you can still use them if you like).
Fedora is a "makers" distro. Every big innovation in Linux has happened in Fedora first.
I dislike snaps too, but when I used Fedora for a couple of years (around version 25), I didn't like dnf a lot either. It felt very slow in comparison to apt, and also, it was just another new command to learn, after yum et al. In contrast, I've been using the same apt syntax in Debian or Ubuntu installs for two decades now. To me, having the same tool with no breaking changes for ages is a plus.
>It felt very slow in comparison to apt
This is partly true, and partly not.
DNF always updates the local copy of the metadata, so it's more like "apt update && apt upgrade" than just "apt upgrade". I don't recall if Ubuntu has a background task for this, but that might be one reason it's "faster".
DNF also has more metadata to download, and the default parallelism is not very high. If you increase the setting, it gets a lot faster.
And also, DNF records the package update history, so that the origin of every package on the system (whether it was requested installed by a user, or indirectly as a dependency, whether it came from a repo or was side-installed) is auditable. Transactions are recorded and can be viewed and rolled back afterwards. And it uses a more rigorous SAT-solver based approach to dependency solving than apt uses. So it's likely doing more actual work rather than being slower at doing the same thing. Those features can be quite useful.
Once you know the tools, apt and dnf blend in together.
Where dnf shines compared to apt is discoverability. The help is decent. There's no separate apt-cache, and there are few reasons to use rpm directly.
Dnf also offers a plug-and-play installation of debugging symbols via `dnf debuginfo-install`, which have always been a pain for me.
Oh, and `dnf install pkg-config(package)` is nice too.
For me, not being forced into snaps, which for many apps that are forced upon us through snaps makes them remarkably slow, is enough reason to pick Fedora over Ubuntu for a fresh install.
But whether it’s a good enough reason to switch an existing system depends on how much trouble one is having with these issues in their current system.
Is snap actually being forced on users by Ubuntu? I've used a Ubuntu based os for years, the only snap packages i have are third-party ones directly from the app devs themselves, ubuntu's never forced me to use snap...
> Is snap actually being forced on users by Ubuntu?
Chromium is a snap in Ubuntu now for a while, even if you install it with apt it just installs the snap.
Canonical wants to deliver the entire OS via snap in the future, and is already partially there on the server with Ubuntu Core and they recently announced an Ubuntu Core Desktop is coming soon.
Yes, it is installed, running a daemon, and spamming mounts and filesystems (~/snap, /snap, etc) at boot up. Well known packages such as chromium convert themselves to snap without warning or permission, then proceed to load a lot slower because they have to be extracted from an image into memory.
Snap is not discrete in any sense of the word.
> Fedora is a "makers" distro. Every big innovation in Linux has happened in Fedora first.
That's because is the beta version of RedHat. I wouldn't call SystemD and Pulseaudio innovations but ymmv.
You may not like systemd, but it is the de-facto standard in the mainstream of Linux distributions. So maybe "innovations" isn't quite the correct word - but if you want to see the future of Linux then Fedora is the place to find it.
Pop!_OS doesn't have snaps either. What is better about DNF? Also the software wasn't always newer.
More up to date kernel (and associated bits) means usually the best support for hardware (e.g. Fedora is usually faultless on Lenovo laptops, unless you have GPU problems).
More up to date and more vanilla Gnome means that you've got the best state of Wayland implementation, and therefore the best version of multi-monitor, HighDPi etc. (I don't know what Ubuntu is like here though at the moment).
Fedora gets kernel and Mesa (graphics driver) updates roughly as fast as Arch, whereas IIRC Ubuntu freezes them for a release, or at least doesn't update them quickly.
That can also be a downside though, if you're using proprietary hardware drivers.
No "snap" pollution in the home directory.
Package naming conventions are better, IMO (this is a small thing to be fair, normally you'd just do a search, but the names are much more consistent and guessable on Fedora/Red Hat based distros in my experience)
If you can use DKMS for your proprietary drivers then the downsides of the quick updates go away, in my experience
What issues are you having with Ubuntu? Hard to say if Fedora is worth a switch without knowing that detail.
If you are satisfied with Ubuntu and it's meeting your needs, then I would argue there is not enough in Fedora to warrant switching. This isn't to say there's lots of things to like, just that my tolerance for disruption is pretty low.
no snap! This is really my biggest issue.
We use RHEL/rpm-based linuxes at work, and it helps to have a package building environment at home the same as it is at work. Everything else is or can be configured to be the same, for the most part.
I use Fedora because i like to have the vanilla GNOME experience out of the box. I also like that i don't need to undo all the snap stuff like in current Ubuntu versions, just plain old boring packages (snap and flatpak are both optional).
But overall, they are really similar.
flatpak is great for apps like Telegram, Discord, Zoom, Teams, etc.
For telegram you can just use the package from rpmfusion. I do use flatpak for proprietary software like Discord, Zoom, etc.
AppArmor vs SELinux would be another one...
There are some internal differences which may matter to you if you develop software targeting RHEL or CentOS.
I have been running the beta in my laptop perfectly and the multi-touch gestures added in Gnome 40 makes it the best laptop DE for me. When I tried to install on my desktop, Nvidia drivers made the experience a nightmare. Nvidia does make free distros a pain.
> multi-touch gestures added in Gnome 40
This sounds like a great improvement! Is this Gnome-specific or can we soon expect to see this in other DEs as well?
As far as I know the bulk of the magic happens in libinput - the touchpad driver. It is the DE's job to take the recognized gestures and turn them into a useful action. It is even easier in wayland, but only KDE and Gnome seem to be the ones looking into it. I don't expect sway for example to start shipping fancy animations any time soon :D
I just upgraded from Fedora 33 to Fedora 34 and experienced serious issues making my computer usable. There is a rendering issue making the screen flicker/strange pixels patterns appearing for almost every app (including gnome terminal). Interestingly, the only app that seems unaffected is firefox.
The only non-standard thing about my setup is that I have a 1400p 144hz display. My graphics card is Amd 5600xt so I do not think this is the issue.
Has anyone else experienced this?
I am not a sophisticated linux user, but I have been using Fedora for the last 10 years without issue, and usually upgrade when I hear about a new version.
I have the exact same issue, still on 33. Running Ryzen 3600X and RX 480. I think it could be a kernel update, got bumped to 5.11.16 last night, don't recall any Mesa updates in the list (using update-testing repos).
I've got similar hardware here - and just pulled down all my updates on the Fedora33 KDE spin. So far, both GTK and QT windows/UI are behaving fine for me...
Some some relevant hardware/kernel info I yanked out of glxinfo.
I've not looked for any bugreports, but I'm happy to follow one if I might be useful.
AMD Radeon RX 5700 XT (NAVI10, DRM 3.40.0, 5.11.16-200.fc33.x86_64, LLVM 11.0.0) OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5 Monitors: 2 0: +*DisplayPort-0 1920/598x1080/336+0+420 DisplayPort-0 1: +DisplayPort-1 1080/598x1920/336+1920+0 DisplayPort-1Interesting, I ended up testing an older 1080p monitor and had the same issue, so it really seems like it is either an issue with the Amd graphics card driver, or an issue with Fedora 34 in general. I am somewhat surprised since I have fairly common hardware , and not much customization.
I'd highly recommend waiting to upgrade
> I just upgraded from Fedora 33 to Fedora 34 and experienced serious issues making my computer usable
I hope you meant unusable.
I read it as they are having trouble making the computer usable now.
My mind automatically interpreted that spelling as "unstable". It turned out that "unusable" matches the context better.
Ah yes I meant unstable
I blame the flickering screen for the typo.
I had to downgrade to 33 which was slightly annoying but no harm done. I guess I will skip this upgrade cycle and wait for 35
well trust me, what you originally wrote would be a funny story.
"broken computer got more usable, by installing broken software".
and it would probably be funny to debug that! Ü
I’ve been running F34 for about a month now. The move to pipewire has been pretty much flawless. Multi-monitor Waybar is broken with F34 but that’s not the fault of Fedora.
Just in time for Red Hat Summit, which starts today.
Any opinion on the move to BTRFS as the default filesystem? Would it be a transparent change for the user? Obviously it will only apply to fresh installs.
I moved to BTRFS two years ago, before it became the default. It is transparent.
Pros: Fast copies with "cp --reflink" and "btrfs sub snapshot" is great, but this is for power users. I personally do backups by snapshotting my home/ directory, and using restic to backup from the snapshot.
Cons: On my very old hard drive, BTRFS creates a huge performance hit. (No perceptible difference on my NVMe SSD) For virtualization, btrfs file system on qcow2 images stored on brtfs are no bueno. Since all my servers use BTRFS and I use some of its features heavily, I need my VMs to use BTRFS so that I can test my automation. I cheat by using "chattr +C" and raw images.
I think it is a good move for Fedora, especially because they stick to the latest kernel releases. Something like ZFS is probably technically superior for a file server, but for a Linux workstation Btrfs is best option, IMO.
Anecdotally, I've been running Btrfs for over five years with zero problems. And it has saved me from data corruption multiple times.
Would be nice if Fedora improved its GUI package management. It's slow and the interface is pretty bad. I tried every solution I could find over a period of 18 months, but in the end the solution that worked was installing Ubuntu. It was my personal laptop so I was able to give it such a long try; obviously this wouldn't have gone on very long on a work machine.
I actually just slicked the SSD and replaced Fedora with Linux Mint on my personal machine last night for those types of reasons... annoying dnfdragora popups and weird behavior, failed firmware flashes via the GUI utility, mediocre battery life (even with TLP installed), and sluggish performance compared to what I was used to in other distros (admittedly with lighter-weight DEs than the Gnome default). Fedora isn't _bad_ by any means but it certainly feels like a more bleeding-edge experience than I need. I was actually using it mostly so that I could keep a certain level of parity between my work (RHEL/OEL) and personal environments but now that my professional workloads run on k8s and I have a Mac as my daily work driver this is less of a consideration.
just upgrade from Fedora 32 to Fedora 34.
the upgrade really smooth, less than 1 hour.
Interesting...my personal daily driver is on fedora 32,and i was going to go to fedora 33 first...but it seems that you skipped 33? If so, curious why? Was it a sort of "who cares, let's do it", or is there a reason that i should skip 33, etc.??
Unless you want to use 33 then I'd just jump right over to 34. My general purpose Fedora PC has made the two version jump a couple of times in the past without a jelly trouser moment.
> jelly trouser moment
Thank you! I now have a new phrase to use! lol :-D
Thanks for the laugh xD
I keep using F32 because it still supported until F34 out and skip F33 because too lazy, nothing technical.
Just do it and let see what happen :). Make sure 100% your backup working
Very, very tempting! Well, i do have my backups in place...so, what better way to test out my restoration process then to skip a major version and dive into the latest, newest release-which-has-not-been-tested-too-long, eh? :-)
You really shouldnt skip releases, each transition js well tested in order.
Still on Fedora 30... probably time to reformat and install fresh.
Really wish Fedora would cut an official WSL2 image.
It’s always nice starting from a fresh install. But if you’re worried about things breaking during a 30-34 upgrade, i’d suggest doing a backup of your system and trying it out. I’ve been extremely impressed with how flawlessly fedora pulls off dist upgrades in the past.
Generally my big fear is the interaction with the kernel and Nvidia drivers during update... I've been burned a few times on that.
https://fedoramagazine.org/wsl-fedora-33/
Also works for Fedora 34. It results in a very lean image, but works for me as my primary dev image on WSL2.
I'll give this a shot, thanks!
I've been on beta the past month and the experience was great. No issues with pipewire. Gnome's snappy, tho a hot bottom corner was necessary. The only issue for me was the agressiveness of oomd at the beginning of beta.
They managed to increase the distance the mouse cursor has to travel to open the app drawer. The worst case would be to move the cursor to the upper left and then to the bottom right.
Does Red Hat monitor the mouse travel distance to measure "employee productivity," or how did they end up with this design?
> Does Red Hat monitor the mouse travel distance to measure "employee productivity," or how did they end up with this design?
No, as far as I can tell the rationale is just "more familiar to MacOS and Windows users".
Of course, the rationale changes every couple of years, because it's not like Gnome 3 was trying to be a "familiar" design.
Oh well, I've been using extensions to override Gnome's silly decisions forever anyway. As long as they don't take that away...
With GNOME 40, I gave up and moved to XFCE. It's a much saner environment.
The travel distance they introduced is just too annoying.
You guys are using the mouse? I smack Super and type the first couple letters of the application I want opened or brought to the front and hit enter
Why are you even using the mouse in the activities overlay
Why create a new account just for this one comment?
Anyway, it's often legitimately faster to use the mouse with the Dash to Dock extension. It blows my mind that it's not the default behavior of the dock.
I guess there are many ways to skin a cat, but I never click on the thing. I just use Super+1-9 to immediately activate my desired app.
This requires you pin your "favorite" apps in the dock, but once you put them there they're always available with those key combos (whether they're running yet or not). Once you internalize the order, you don't even need to open the activities view at all (except for your more seldom used programs).
Just learned that double tapping the Super button opens the app drawer. game changer for me
You can open the app drawer with Super + A right ?