|
> If you do actually need to develop for Linux, I would suggest something with a rolling release model, otherwise it won't be long before you'll need to start compiling things from source because you need a more recent version of <something> than your distro is packaging. It depends on your requirements. If you constantly find yourself needing the latest and greatest upstream software releases, then yes, use a rolling release. But if not, rolling releases can make your life much more painful. If you're not paying attention when you update your system, then each update is a roll of the dice as to whether your software will still build or run afterwards, as any update could introduce incompatible changes to packages your software depends on. A distribution with a release model (usually) tries to maintain API and ABI compatibility for the duration of a release, so you can update with more confidence that it you won't have to re-build or port your code as a result. There's trade-offs between stability and shininess across the spectrum of distributions with rolling releases, with frequent releases, and with long release cycles. As long as you're aware of that, you can decide for yourself how frequently you want updates, and therefore the type of distribution you should run. > Red Hat Enterprise Beta, uh, I mean, Fedora I really wish people would stop making comments like this. I volunteer a significant amount of my free time and effort to improve Fedora, and I see a lot of others in the Fedora community doing the same. I can't speak for anyone else, but I'm doing it to make Fedora better, not to crowd-source Red Hat development for free. Fedora is a first-class distribution in its own right, with an open, inclusive, and independent community. Reducing it to a beta distribution for Red Hat glosses over that fact, which I find very unfortunate. |
I didn't mean to imply that Fedora isn't a first-class distribution in its own right. In this post's context, I see why it would look that way, and I apologize for it. I don't mean to belittle the work you folks are doing, and I know that the Fedora project is more than just the distro, and that the distro itself is more than just Red Hat's testbed for new features.
I don't run Fedora on any of my home computers anymore. I ran it up to Core 3, I think, having ran Red Hat Linux before. But I've always "ran into" Fedora computers as part of my work and occasionally ran it on my company-issued laptop at $work. While Red Hat's presence can account for some of your stranger choices, it cannot be the only reason behind your success (and I honestly don't think it is).
The origin of my snarky comment is that to many of us outside the Fedora community, it often feels like a lot of things are finding their way into Fedora largely because they need more ample testing. The fact that they're so active and so pushy means that most of them are from Red Hat. I have very few fond memories about dealing with very early breakage from NetworkManager, PulseAudio, systemd and so on. All of them are now successful technologies, but they were not "ready" by any responsible use of the word when they were first included or enabled by default in Fedora. Wayland is, to some degree, an exception, but only because it has already seen wide enough deployment in the embedded/infotainment area that, for once, the desktop is not the earliest adopter.
This is one of the reasons why I recommended Fedora as a development distribution (my wording probably didn't really look like a recommendation, sorry!). At $work, I already work on Linux software; I don't want to deal with more Linux craziness at home, so I tend to stay way from bleeding edge stuff. But if you do need to keep in touch with what's happening in the Linux world, Fedora is the most stable way of doing it that's also reasonably low-maintenance (the second best option, IMHO, is Gentoo).
Staying up-to-date with all these changes is very important, IMHO. For better or for worse, very important pieces of a modern Linux system, like systemd and GTK, are making a lot of breaking changes in-between releases. Running a bleeding-edge system is about the only reasonable way of becoming "passively" acquainted with them, and is a great way of weeding out the subtle bugs that they introduce.