6 ms·

Not sure where Fedora sits in the current system. 1) Cutting Edge - Rolling releases of Arch or Gentoo 2) Stable - Debian (Slow and Steady on the Main Release

by baldfat 11y ago

Not sure where Fedora sits in the current system. 1) Cutting Edge - Rolling releases of Arch or Gentoo 2) Stable - Debian (Slow and Steady on the Main Release) 3) Cutting Edge and Stable - OpenSUSE (One I mostly use) 4) Ubuntu - Ubuntu (Not sure where to place it, since is its own thing now to me compared to the rest of Linux blazing its own whatever it wants to do) I am hoping that Fedora isn't just the break things fast and often it has been for me in the past. I still remember the frustrations of having a good Fedora that ran out of updates. I would skip to the current version and not be happy with my computer for months. Last version I have tried to use for my own personal use is Fedora 14 (Used it since Core through 14). Fedora was never my main distro and I always had hopes for it to work for me, but alas ...

btgeekboy 11y ago
Personally, I find it to fit in your list where OpenSUSE is -modern and moves quickly, but is reasonably stable for everyday use.
- DanBC 11y ago
  Wait what? Fedora20 is chock full of bugs. Most that I found were trivial (a programme having three different names, for example) but some were more important. Yum package lock was pretty annoying. It's fine for what it is, but peoples definitions of "reasonably stable" are probably different.
meddlepal 11y ago
I haven't had too many issues running Fedora as a main workstation OS... I'd say it's something like Cutting Edge and Stable-enough. I've been using it since 19. The only issues I usually run into are related to Nvidia graphics drivers. I'm always a bit wary of updating the kernel or drivers and usually leave those updates along until I have time to deal with potential headaches.
grp 11y ago
Maybe: 5) Cutting edge and free (not as in "free beer")?
rplnt 11y ago
What if I just want a RHEL-flavored distro? And not be stuck with enterprise (read obsolete) software as I would be with CentOS?
- bsg75 11y ago
  What is "obsolete" on CentOS?
  - kbenson 11y ago
    From experience, I think GP is referring to being a few years into a RHEL/CentOS lifecycle and no third parties are packaging RPMs for your OS/version anymore. RHEL has been taking longer between major releases the last few times (but they've also extended support lifetime)[1]. Edit: Oh, and RHEL's policy of back-patching (and back-porting features on point releases) does lead to quite old versions after a few years. An on a product with a 10-year support lifecycle, stuff can feel pretty stale. But that's a feature when looked at the right way (which generally isn't the way you see it from a desktop/workstation vantage). 1: http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Produc...
  - rplnt 11y ago
    As other reply had mentioned, with their LTS you are stuck with fairly old software. For example with RHEL 6.x (surpassed just a year ago and still supported) you still have python 2.6 on there, even though 2.7 was released in 2010 (actually before the release of 6.0). You can find similar cases for pretty much every piece of software, from kernel to desktop environment. It's not a bad thing in enterprise world, it sucks on desktop.
- SEJeff 11y ago
  This is what software collections is for: https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/ http://developerblog.redhat.com/tag/developer-toolset/ http://developerblog.redhat.com/tag/developer-toolset/ Redhat knows they messed up regarding newer stuff in RHEL5-6. That shouldn't ever happen again thanks to scl, which makes it quite trivial to get super new stuff in supported RHEL instances.
notacoward 11y ago
I think the Fedora philosophy/positioning is pretty well summarized right there on the project page. > Freedom. Friends. Features. First. Fedora is a cutting-edge distribution, but a Linux distribution is too large a thing to have only one cutting edge. Sure, if you want the latest applications and higher level libraries/frameworks, you might find them in another distribution first. On the other hand, if you want the latest core/infrastructure bits - e.g. system daemons, compilers, hypervisors - you'll probably find them in Fedora first because that's the distribution in which those kinds of developers do most of their work. Those other "cutting edge" distributions you mention might not have to wait for an actual release, but they still have to wait for the patch from the original developers plus the repackaging into their own native formats and repositories. "Cutting edge" is contextual. It all depends on what you're doing. Disclaimer: I'm a Red Hat employee and some-time Fedora contributor. But at least I'm not being gratuitously negative about others' work.
- kbenson 11y ago
  If I'm not mistaken, that's because Red Hat funds a lot of work in those areas. Even where it doesn't fund it, those are the really interesting bits for a server/enterprise OS, and that's what Fedora is a feeder for, so they get a lot of attention.
  - evol262 11y ago
    Our policy at Red Hat is upstream first. Work is being done upstream and benefiting Arch and everyone else. It's not on Fedora. Fedora just benefits from an extremely good QE cycle compared to other distros, and a well-integrated set of packages, which is something rolling-release distros don't offer, not that there's anything wrong with that. RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas. Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.
    - kbenson 11y ago
amyjess 11y ago
I don't really see a point in separating Ubuntu from the others. Normal releases should go in the "cutting edge and stable" category, and LTS releases in the "stable" category. With that said, I'd place Fedora in "cutting edge and stable". It has a six-month release cadence just like Ubuntu.
- sciurus 11y ago
  Canonical is developing their own desktop environment (unity), their own windowing system (mir), their own package manager (snappy), etc. I think that is what the author was referring to when it said Ubuntu is doing "their own thing." That makes them a bit hard to compare to other distributions that are largely adopting the same technology at different paces.
  - amyjess 11y ago
    Eh, I don't see how the desktop environment and package manager really matter. Lots of distributions differ on those things. The windowing system, maybe, but remember that Mir isn't even used by default yet. And Snappy isn't out yet at all.
    - kbenson 11y ago
      And their own init system. But I agree with you, that's not all that different than some other big players such as Red Hat (systemd, pulseaudio, gnome, etc), even if the details of how they go about it are different. Investing time/manpower into a technology (whether you created it or not) and then pushing adoption through inclusion in the distro is a tried and true technique at this point.
      - vezzy-fnord 11y ago
        They dropped Upstart for systemd in 15.04, after the decision was already made over a year earlier. They're also going to replace it in Ubuntu Touch as well. It's worth noting that Upstart came at least four years prior to systemd, so it wasn't NIH.
cstoner 11y ago
I've been using Fedora pretty solidly since 20. I use it in a VM to get all of my "actual work" done and just use my host machine for email and web browsing. It's been pretty stable for me. The main reason I use it is that our production environments run CentOS and I want to get used to upcoming features before they're included in mainline (systemd, firewalld, dnf, python3, iproute2, etc). Fedora has actually gotten a lot better since around Fedora 19. If you haven't given it a shot in a while you might be pleasantly surprised.
- craigching 11y ago
  Same for me, use it in a VM, etc. I've been doing this since 18 and have found it to be very stable. My only complaint would be Fedora 21 seemed like the filesystem was a bit slow. But I yum update pretty regularly and it seems good now. This is all anecdotal, just noticing startup times of the product I work on and other programs I use daily. EDIT: I just remembered something important about my use and might be why that you say it wasn't good before 19. I use MATE mostly because 18's Gnome3 was really bad. I still don't like Gnome3 and stick with MATE. Gnome3 is just too slow for me and some of the workflows get in my way.
- baldfat 11y ago
  That was what I was digging for. I liked the idea of Fedora but I always seemed to get in trouble with stability. I just might give it a try again on a secondary machine.
edcastro 11y ago
I feel that Fedora is the closest of a rolling release without the hurdles involved into running a rolling release. I've been using as my main OS for some time now, and with the exception of rpmfusion breakage, Fedora been quite stable. So, I'd say it's close do OpenSUSE Tumbleweed, with some release cadence and support.
- baldfat 11y ago
  I don't find Arch to have many hurdles (Until there is something broken and placed on the webpage). They should have some tie in with Pacman to say read the front page before updating or front page was updated on date so and so ... Would fix the last hurdle that Arch has over other ditros.
krisdol 11y ago
It fits in at 3, just a different package manager and different philosophy on what to include and exclude by default. For debian-based systems: 1. Cutting edge - Debian sid (also aptosid/sidux) 2. Stable - Debian Release 3. Less Stable but more modern - Ubuntu, Mint 4. Broken/Insecure - Debian Testing For red hat: 1. Cutting edge - Fuduntu 2. Stable - RHEL/CentOS 3. Much less stable but more more modern - fedora For arch/pacman 1. Cutting edge - Arch Linux 2. Slightly less cutting edge - Manjaro 3. Stable - no such thing, they're all rolling-release AFAIK For Gentoo 1. gentoo Don't know much about SUSE-based, but I know that OpenSUSE:Tumbleweed is the rolling release version containing the latest stable versions of software, while OpenSUSE is stable/fixed release.
- darkr 11y ago
  > 4. Broken/Insecure - Debian Testing Often, testing gets security patches at the same time as stable + unstable (dependent on the scope of the issue). Sometimes it takes a few days for a package update to make it's way from unstable to testing. Obviously you wouldn't run testing on a server, but for a dev workstation it's not a bad choice. Far from 'Broken/Insecure'..
  - krisdol 11y ago
    Debian Testing may have a nice "in-between" ring to it, but it is more likely to be broken and insecure for longer than either Unstable or Stable. All bug fixes have to go through unstable first (usually 10 days, but may often take longer). Because of this any breakage might take at least 10 days to be fixed. from Debian Testing Wiki[0]: > Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern. also, from Choosing a Distribution[1] > testing could be broken for months [...] >The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 10 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 10 days. >The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps the testing in an usable state for most period of the time. Overall a brilliant concept, if you ask me. But things are alwasy not so simple. Consider the following situation: >Imagine you are interested in package XYZ. >Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7 >After 10 days, XYZ-3.7 from unstable migrates into testing. >So on June 20, both testing and unstable have XYZ-3.7 in their repositories. >Let's say, The user of testing distribution sees that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7 >Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS. >The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30. Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version. The number 5 should not be taken literally. It could be less or more, depending upon the severity of the RC-bug at hand. >This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 10th. >But on July 5th some other person, discovers another RC-bug in XYZ-3.8 >Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days. >So on July 10, testing has XYZ-3.7 while unstable has XYZ-3.9 >This new version XYZ-3.9 is now rescheduled to enter testing on July 20th. >Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 20th. That is you essentially ended up with a broken XYZ for about one month. >The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to unusable testing distribution for months [0]:https://wiki.debian.org/DebianTesting https://wiki.debian.org/DebianTesting [1]:https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en...

by baldfat 11y ago

btgeekboy 11y ago

Personally, I find it to fit in your list where OpenSUSE is -modern and moves quickly, but is reasonably stable for everyday use.

DanBC 11y ago
Wait what? Fedora20 is chock full of bugs. Most that I found were trivial (a programme having three different names, for example) but some were more important. Yum package lock was pretty annoying. It's fine for what it is, but peoples definitions of "reasonably stable" are probably different.

meddlepal 11y ago

I haven't had too many issues running Fedora as a main workstation OS... I'd say it's something like Cutting Edge and Stable-enough. I've been using it since 19. The only issues I usually run into are related to Nvidia graphics drivers. I'm always a bit wary of updating the kernel or drivers and usually leave those updates along until I have time to deal with potential headaches.

grp 11y ago

Maybe: 5) Cutting edge and free (not as in "free beer")?

rplnt 11y ago

What if I just want a RHEL-flavored distro? And not be stuck with enterprise (read obsolete) software as I would be with CentOS?

bsg75 11y ago
What is "obsolete" on CentOS?
- kbenson 11y ago
  From experience, I think GP is referring to being a few years into a RHEL/CentOS lifecycle and no third parties are packaging RPMs for your OS/version anymore. RHEL has been taking longer between major releases the last few times (but they've also extended support lifetime)[1]. Edit: Oh, and RHEL's policy of back-patching (and back-porting features on point releases) does lead to quite old versions after a few years. An on a product with a 10-year support lifecycle, stuff can feel pretty stale. But that's a feature when looked at the right way (which generally isn't the way you see it from a desktop/workstation vantage). 1: http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Produc...
- rplnt 11y ago
  As other reply had mentioned, with their LTS you are stuck with fairly old software. For example with RHEL 6.x (surpassed just a year ago and still supported) you still have python 2.6 on there, even though 2.7 was released in 2010 (actually before the release of 6.0). You can find similar cases for pretty much every piece of software, from kernel to desktop environment. It's not a bad thing in enterprise world, it sucks on desktop.
SEJeff 11y ago
This is what software collections is for: https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/ http://developerblog.redhat.com/tag/developer-toolset/ http://developerblog.redhat.com/tag/developer-toolset/ Redhat knows they messed up regarding newer stuff in RHEL5-6. That shouldn't ever happen again thanks to scl, which makes it quite trivial to get super new stuff in supported RHEL instances.

notacoward 11y ago

I think the Fedora philosophy/positioning is pretty well summarized right there on the project page. > Freedom. Friends. Features. First. Fedora is a cutting-edge distribution, but a Linux distribution is too large a thing to have only one cutting edge. Sure, if you want the latest applications and higher level libraries/frameworks, you might find them in another distribution first. On the other hand, if you want the latest core/infrastructure bits - e.g. system daemons, compilers, hypervisors - you'll probably find them in Fedora first because that's the distribution in which those kinds of developers do most of their work. Those other "cutting edge" distributions you mention might not have to wait for an actual release, but they still have to wait for the patch from the original developers plus the repackaging into their own native formats and repositories. "Cutting edge" is contextual. It all depends on what you're doing. Disclaimer: I'm a Red Hat employee and some-time Fedora contributor. But at least I'm not being gratuitously negative about others' work.

kbenson 11y ago
If I'm not mistaken, that's because Red Hat funds a lot of work in those areas. Even where it doesn't fund it, those are the really interesting bits for a server/enterprise OS, and that's what Fedora is a feeder for, so they get a lot of attention.
- evol262 11y ago
  Our policy at Red Hat is upstream first. Work is being done upstream and benefiting Arch and everyone else. It's not on Fedora. Fedora just benefits from an extremely good QE cycle compared to other distros, and a well-integrated set of packages, which is something rolling-release distros don't offer, not that there's anything wrong with that. RH development is a feeder for Linux. A lot of RH employee contributions upstream are in the categories that are talked about, but so's a ton of work on GNOME and other areas. Fedora packageset stabilization is a feeder for RHEL (every few years Fedora settles down a bit as it gets ready for a branch, then screams off again), but the code itself feeds everyone.
  - kbenson 11y ago

amyjess 11y ago

I don't really see a point in separating Ubuntu from the others. Normal releases should go in the "cutting edge and stable" category, and LTS releases in the "stable" category. With that said, I'd place Fedora in "cutting edge and stable". It has a six-month release cadence just like Ubuntu.

sciurus 11y ago
Canonical is developing their own desktop environment (unity), their own windowing system (mir), their own package manager (snappy), etc. I think that is what the author was referring to when it said Ubuntu is doing "their own thing." That makes them a bit hard to compare to other distributions that are largely adopting the same technology at different paces.
- amyjess 11y ago
  Eh, I don't see how the desktop environment and package manager really matter. Lots of distributions differ on those things. The windowing system, maybe, but remember that Mir isn't even used by default yet. And Snappy isn't out yet at all.
  - kbenson 11y ago
    And their own init system. But I agree with you, that's not all that different than some other big players such as Red Hat (systemd, pulseaudio, gnome, etc), even if the details of how they go about it are different. Investing time/manpower into a technology (whether you created it or not) and then pushing adoption through inclusion in the distro is a tried and true technique at this point.
    - vezzy-fnord 11y ago
      They dropped Upstart for systemd in 15.04, after the decision was already made over a year earlier. They're also going to replace it in Ubuntu Touch as well. It's worth noting that Upstart came at least four years prior to systemd, so it wasn't NIH.

cstoner 11y ago

I've been using Fedora pretty solidly since 20. I use it in a VM to get all of my "actual work" done and just use my host machine for email and web browsing. It's been pretty stable for me. The main reason I use it is that our production environments run CentOS and I want to get used to upcoming features before they're included in mainline (systemd, firewalld, dnf, python3, iproute2, etc). Fedora has actually gotten a lot better since around Fedora 19. If you haven't given it a shot in a while you might be pleasantly surprised.

craigching 11y ago
Same for me, use it in a VM, etc. I've been doing this since 18 and have found it to be very stable. My only complaint would be Fedora 21 seemed like the filesystem was a bit slow. But I yum update pretty regularly and it seems good now. This is all anecdotal, just noticing startup times of the product I work on and other programs I use daily. EDIT: I just remembered something important about my use and might be why that you say it wasn't good before 19. I use MATE mostly because 18's Gnome3 was really bad. I still don't like Gnome3 and stick with MATE. Gnome3 is just too slow for me and some of the workflows get in my way.
baldfat 11y ago
That was what I was digging for. I liked the idea of Fedora but I always seemed to get in trouble with stability. I just might give it a try again on a secondary machine.

edcastro 11y ago

I feel that Fedora is the closest of a rolling release without the hurdles involved into running a rolling release. I've been using as my main OS for some time now, and with the exception of rpmfusion breakage, Fedora been quite stable. So, I'd say it's close do OpenSUSE Tumbleweed, with some release cadence and support.

baldfat 11y ago
I don't find Arch to have many hurdles (Until there is something broken and placed on the webpage). They should have some tie in with Pacman to say read the front page before updating or front page was updated on date so and so ... Would fix the last hurdle that Arch has over other ditros.

krisdol 11y ago

It fits in at 3, just a different package manager and different philosophy on what to include and exclude by default. For debian-based systems: 1. Cutting edge - Debian sid (also aptosid/sidux) 2. Stable - Debian Release 3. Less Stable but more modern - Ubuntu, Mint 4. Broken/Insecure - Debian Testing For red hat: 1. Cutting edge - Fuduntu 2. Stable - RHEL/CentOS 3. Much less stable but more more modern - fedora For arch/pacman 1. Cutting edge - Arch Linux 2. Slightly less cutting edge - Manjaro 3. Stable - no such thing, they're all rolling-release AFAIK For Gentoo 1. gentoo Don't know much about SUSE-based, but I know that OpenSUSE:Tumbleweed is the rolling release version containing the latest stable versions of software, while OpenSUSE is stable/fixed release.

darkr 11y ago
> 4. Broken/Insecure - Debian Testing Often, testing gets security patches at the same time as stable + unstable (dependent on the scope of the issue). Sometimes it takes a few days for a package update to make it's way from unstable to testing. Obviously you wouldn't run testing on a server, but for a dev workstation it's not a bad choice. Far from 'Broken/Insecure'..
- krisdol 11y ago
  Debian Testing may have a nice "in-between" ring to it, but it is more likely to be broken and insecure for longer than either Unstable or Stable. All bug fixes have to go through unstable first (usually 10 days, but may often take longer). Because of this any breakage might take at least 10 days to be fixed. from Debian Testing Wiki[0]: > Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern. also, from Choosing a Distribution[1] > testing could be broken for months [...] >The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 10 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 10 days. >The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps the testing in an usable state for most period of the time. Overall a brilliant concept, if you ask me. But things are alwasy not so simple. Consider the following situation: >Imagine you are interested in package XYZ. >Let's assume that on June 10, the version in testing is XYZ-3.6 and in unstable it is XYZ-3.7 >After 10 days, XYZ-3.7 from unstable migrates into testing. >So on June 20, both testing and unstable have XYZ-3.7 in their repositories. >Let's say, The user of testing distribution sees that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7 >Now on June 25, someone using testing or unstable discovers an RC bug in XYZ-3.7 and files it in the BTS. >The maintainer of XYZ fixes this bug and uploads it to unstable say on June 30. Here it is assumed that it takes 5 days for the maintainer to fix the bug and upload the new version. The number 5 should not be taken literally. It could be less or more, depending upon the severity of the RC-bug at hand. >This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 10th. >But on July 5th some other person, discovers another RC-bug in XYZ-3.8 >Let's say the maintainer of XYZ fixes this new RC-bug and uploads new version of XYZ after 5 days. >So on July 10, testing has XYZ-3.7 while unstable has XYZ-3.9 >This new version XYZ-3.9 is now rescheduled to enter testing on July 20th. >Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 20th. That is you essentially ended up with a broken XYZ for about one month. >The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to unusable testing distribution for months [0]:https://wiki.debian.org/DebianTesting https://wiki.debian.org/DebianTesting [1]:https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html https://www.debian.org/doc/manuals/debian-faq/ch-choosing.en...