This is good distro for developers by developers. I wouldn't suggest it for everyday users though. There are too many beta quality bugs since it uses really bleeding edge releases.
If the 6-month release cycle is too frequent for you as a desktop user, consider using RHEL/Centos. In general Red Hat's distros are top-notch and easier to reason about than other distros.
What? The software in CentOS' official repositories is horribly outdated (aka 'stable', which is why it runs on many servers). Why should a desktop system run CentOS? I'd rather recommend Ubuntu or one of its descendants. They also have LTS versions, if stability is a concern, but are not as outdated as CentOS.
Fedora is too cutting edge and CentOS is too outdated? Ok then, go off to Canonical land where everything falls apart outside the most common use cases and your entire desktop experience changes every couple of years.
Fedora isn't cutting edge compared to actual rolling release distros so if that's still too much for you then RHEL or CentOS should be enough.
Debian was nothing but trouble for me. I found myself in opposition to too many of their design choices and some packages to be too outdated. At the end of the day it lacks the polish and moddability I've come to expect from Fedora.
I'm at NASA Goddard and we use RHEL/CentOS for servers and a few desktops and Ubuntu on some desktops. I am sometimes frustrated by the age of certain CentOS packages, but having compatibility with our servers is a plus. I've avoided Fedora due to the rapid release cycle and the lack of official support by NASA (at least here at Goddard). There's no perfect solution.
No. But at least RHEL 8 (based on Fedora 28) has been available as a beta release for a while now (since 25th November 2018), so it shouldn't be too long.. I'd speculate another 4-6 months and we'll have it.
I agree, but if you want to develop .Net or Swift, the available rpm's seem to originate downstream and lag the releases for ubuntu significantly. The releases of .Net core, the Swift toolchain, and Kitura, the IBM open source Swift web framework (even though IBM owns Red Hat), all come out targeting ubuntu. Because the different linux distros have significantly older or newer versions of some .so and .h files, releasing for all the major flavors is harder than it should be, and ubuntu seems to come first.
Swift is a PITA on Linux in general; the Ubuntu-only releases is only a symptom.
It is a pain to build it at all, from the sources. With the exception of the apple/swift repo, all the other apple/swift-* repos do not even seem to have tagged releases. At least not in the sense that other projects do releases.
I think the Fedora community is pretty responsive when it comes to fixing bugs that are under their control, and the developers dogfood the desktop enough that they care about these things.
Also, Fedora gets new kernels all the time, and that often takes care of problems that sometimes persist in more "stable" distributions.
I have one mid-level issue per release, I figure, and it is usually patched within a couple of weeks.
I did have a bad experience upgrading from F27-29, so I've only been on F29 for maybe a month or so, and it has been smooth so far. I will probably wait a few weeks to a month to upgrade to F30 to increase my chances of a trouble-free transition.
This is true, F29 just happened to ship with an extra-broken default config.
Though I have yet to see any BT implementation that isn't at least a little bit broken. Nobody actually conforms to the spec so you have to attempt to make your noncomforance work with the widest possible variety of other vendors' nonconformance and you'll always find device combinations that just don't work together.
Certainly YMMV applies, however, it's important to distinguish the nature of the two cases.
Broken BT support in a Windows context generally means poor drivers for a given device - at least the Windows 10, which is almost 4 years old, has a stable BT stack. Therefore, BT problems are of particular (per-device) nature.
In Ubuntu, the problem is systemic, due to (even ignoring how terrible the BT protocol is) both Bluez's (alleged) terrible engineering practices, and Ubuntu's utter carelessness of the area. In this terms, BT problems are of universal nature.
This is not an exception; the Pulseaudio/BT configuration has been broken in a way or another since... forever. Very evidently, the Ubuntu devs prefer to ship a broken-but-up-to-date BT stack, than a working-but-old one.