Announcement

Collapse
No announcement yet.

Fedora 27 Beta Hit By A Second Delay

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by GdeR View Post

    The only problem with Arch and Tumblewhatever is that not everyone wants an ever changing system. I, for example, have to use that particular version of gcc and that version of glibc etc.. Rolling release distributions would make my life impossible and they're not officially supported by commercial software like Matlab, Wolfram Mathematica, etc.. Even if workarounds to make them work are sometimes possible, it's not always the case (for example, I remember that the update to Ncurses 6 killed my Matlab installation on Arch). You just think that all users around the world all have the same needs you have. That's typical of rolling release fundamentalists.
    This sort of thing depends on the end use of the entire system. Some have compared computers to guns and the end user software to ammo, with the first consideration of a gun buyer being the ammo they need to shoot and what they need to shoot it at. This also applies to Linux distros in my judgement-the top level software and its intended use probably decide what distro is best.

    Someone running a CNC machining center with a non-networked machine will want to install only once, and just get everything working once. They will only need updates if they find a bug or add new hardware that needs new drivers. In that case, they will want the updates to install cleanly without breaking anything that already works. That's a job for a good, well-supported LTS.

    A developer will want the rolling release and may build crucial libraries from still newer versions or even git master, so as to catch breakage caused by library changes before end users get hit with them. For that purpose, any temporary "freezes" in rolling release can be a serious nuisance, invoking bugs in new software written on another distro with a newer version of some offending library, or just requiring locally building and installing the newer version just to rule out the older version as the culprit. Thus the most up to date possible rolling release favors this type of user.

    Thus a "fundamentalist" approach to favor rolling over stable or vice-versa is nuts. Different users have fundamentally different needs.

    Comment


    • #12
      Originally posted by duby229 View Post
      Yeah, I agree generally with you. I think if commercial proprietary software vendors adopt flatpack packages it could potentially resolve this problem. I'm really hopeful it happens.
      Thankfully it's not required for software vendors to adopt flashpack, anything can be packaged into flatpkacks easily by the community.

      Comment


      • #13
        Originally posted by debianxfce View Post

        Software you are using are implemented badly. Many Linux gamers use rolling release distros and hundreds of native Linux games run just fine.
        Gamers are a minority in Linux usage. Hundreds are no big number, moreover that would be a negible fraction. A lot of people including myself have other wishes and needs, for other tasks like server usage, workstation usage and so on.

        Comment


        • #14
          Originally posted by debianxfce View Post

          Software you are using are implemented badly. Many Linux gamers use rolling release distros and hundreds of native Linux games run just fine.
          Not everyone is a bloody gamer! Rolling releases don't work for everything.
          I for one sure wouldn't want my stable build environment to change every other week.

          Comment


          • #15
            Originally posted by debianxfce View Post
            Software you are using are implemented badly. [..]
            That software is probably not perfect, but which is? And it's closed source, so I don't even get to know how good it is, but those programs still have unique features and my job is to produce trustworthy results based on that software. It really wouldn't be smart of me to send an article for review after gathering my results on an unsupported system. Think about CUDA, Debian isn't even an option in that case either, it's a stable system but it is not supported.

            Originally posted by debianxfce View Post
            Many Linux gamers use rolling release distros and hundreds of native Linux games run just fine.
            I don't even know what games are. But I don't like when the distro I use gets in my way and I have to turn myself into a MacGyver (or LinuxGyver?) just to try to have that software work. I dare any software company to support a system that can get unrecognizable every 2 weeks. Nobody can afford to maintain such big software on rolling distributions. And like I said, official support is something many people still care about.
            Last edited by GdeR; 22 September 2017, 06:13 AM.

            Comment


            • #16
              Originally posted by mattdm View Post
              Fedora integrates thousands of upstream projects with a huge amount of change release to release. A strict-time based schedule would always have problems. A strict when-it-is-perfect policy would never ship. So, we have a compromise process. What you're seeing as "delay" is this process in action. Were we a closed project (even an open source one without transparent development), you'd never see this. We are committed to openness and transparency, though, so you see the updates as they happen.

              I definitely appreciate the reporting on Fedora, but the negative slant seems ... not appropriate, given that it's the result of our transparency, not any sort of failure.

              I'd hoped that the "rain date" built into the schedule would help correct this, but I guess not. Could we at least get "first delay beyond the built-in rain date"?
              Every distro integrates the same amount of software (some have it easier, some don't). It is not hard to set cut-off dates for features: if done by date X, merge into next release, if not, wait.
              The difference is Fedora is not RH's primary product and there's really no pressure to release on time. So you don't.

              I don't have a particular problem with this. The only thing is people tend to think Fedora is on a 6 months release schedule and it occasionally misses a month here and there. See: https://en.wikipedia.org/wiki/Fedora...ersion_history
              In the mean time, Ubuntu (and derivatives) managed to release spot on (with a single exception) since 2004.

              Comment


              • #17
                Originally posted by bug77 View Post
                In the mean time, Ubuntu (and derivatives) managed to release spot on (with a single exception) since 2004.
                Which doesn't mean much to me, as Ubuntu is perhaps the most unreliable distro for many (even in its LTS variant). I'm not sure why, I did all my best to like Ubuntu, but it had issues here and there. When the 16.04 was released I tried to install my usual applications for graphs and diagrams, but it failed to install Dia (a small simple application). Then I have learned that LTS doesn't mean it gets the same love Debian does, it just means what it says, Long Term Support: they will acknowledge their bugs for a long time, which will only get fixed *after* release, hopefully. I wouldn't care for non-LTS when you have Debian Testing or a fancy combo of Testing+Unstable. Fedora on the other hand is worth waiting for, even after 50 delays. It's a beautiful modern system, supported by many commercial software. My only complain is its relatively short-term support, and please nobody should suggest me to use CentOS because it's another planet, and the software I develop needs more recent libraries. I personally wish Fedora had a 18-months support. CUDA 9 for example is going to officially support Fedora 25, but by the time it's released, Fedora 25 will have reached its EOL. Too bad.
                Last edited by GdeR; 22 September 2017, 11:29 AM.

                Comment


                • #18
                  Just installed Feral’s port of Fable from 2008. Works without a hitch on my proprietary os. I honestly love backwards compatibility. I very much think that despite the inelegance of it from a strict point of view we should use technology like flatpak going forward. Disk space is cheap.

                  Comment


                  • #19
                    Id Software way - "It'll be released when it's ready".

                    Comment


                    • #20
                      Originally posted by unixfan2001 View Post

                      Not everyone is a bloody gamer! Rolling releases don't work for everything.
                      I for one sure wouldn't want my stable build environment to change every other week.
                      With Flatpak this problem largely disappears. Your build environment is a Flatpak SDK which is versioned and breaking changes within a version are forbidden. Your build target is a Flatpak Runtime which corresponds to the SDK. Assuming your app doesn't break the sandbox a lot, you can be confident that it will work on the end user's machine

                      Comment

                      Working...
                      X