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.
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.
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.
What do you want to change in systemd specificaly?
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.
Cant wait until we say the same about systemd.
Fedora is a "makers" distro. Every big innovation in Linux has happened in Fedora first.
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.
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.
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.
That's because is the beta version of RedHat. I wouldn't call SystemD and Pulseaudio innovations but ymmv.
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).
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 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.
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.
But overall, they are really similar.
This sounds like a great improvement! Is this Gnome-specific or can we soon expect to see this in other DEs as well?
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.
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-1I'd highly recommend waiting to upgrade
I hope you meant unusable.
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
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.
Anecdotally, I've been running Btrfs for over five years with zero problems. And it has saved me from data corruption multiple times.
the upgrade really smooth, less than 1 hour.
Just do it and let see what happen :). Make sure 100% your backup working
Really wish Fedora would cut an official WSL2 image.
Also works for Fedora 34. It results in a very lean image, but works for me as my primary dev image on WSL2.
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...
The travel distance they introduced is just too annoying.
Why are you even using the mouse in the activities overlay