Announcement

Collapse
No announcement yet.

Fedora 19 Beta Released With Lots Of New Work

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

  • #31
    Originally posted by blackiwid View Post
    Yes I except of course bugs in betas, I even except bugs in stable releases... but not in the installer, the whole point is to be able to test the distro to find bugs. if nobody is able to install the distro nobody will find bugs in the distro.
    How do you expect the installer to be bug-free if nobody tests it? Why should an alpha or beta of a distro (which always includes the installer) be bug-free before the alpha or beta?

    Ok maybe its here a special case because of this anaconda switch, maybe I am here pampered by debian or ubuntu, becuase (if you want lvm stuff you need the alternate installer in ubuntu which is the debian installer) always everything works ever even in each alpha.
    That comment only shows that you never tested the daily builds of Debian, they have the same problems with the installer, sometimes for days, until somebody reported it, so it can get fixed. See the pattern?

    Like I said if somebody took that personal I am sorry but please stop insulting me just because I said maybe something bad about your distro.
    I can't see why pointing out flaws in your expectations (it is a beta, it has bugs) and in your behavior (it is a beta, so report the fucking bugs, especially when it is a show-stopper, that is what a beta is for) is insulting you. Also, I am not a Fedora user.
    I am a developer
    I then can only hope for you that the users of your software are more willing to file bug-reports than you.

    Comment


    • #32
      Originally posted by pipe13 View Post
      While I agree with minimal use of Anaconda, there (apparently) were reasons for dumping the old one and starting from scratch. Those I can think of are improved graphics and multi-threading. So I'm wondering if it will be possible in some future iteration to just launch gparted and system-config-lvm directly from Anaconda, thus maintaining some semblance of consistency between the install tools and the installed. (Pure speculation dept. One additional quirk is such tools require fairly complete online documentation. Gparted is good as-is, its manual is accessed from its Help menu. Somebody (yeah yeah, I know) would have to convert the lvm man page to html appropriate for the system-config-lvm gui. Then there's mdadm, which hasn't yet a gui at all. (Actually... Hmmmm. Am I [I]that[/] desperate for another time sync?)
      Actually, being a developer myself, I can certainly understand the reasons for rewriting anaconda: code decay.
      I would imagine that the old anaconda reached the point that bolting in new features was a complete nightmare (let alone supporting new hardware).
      However, in my view the anaconda team made one crucial mistake: They decided to target Joe-six-pack users at the expense of power users. (especially given Fedora's role as a test ground for the next RHEL...)

      Hopefully by F22 anaconda will be regain most of the lost power user options.

      As for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

      - Gilboa
      DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
      SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
      BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
      LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

      Comment


      • #33
        Originally posted by gilboa View Post
        Actually, being a developer myself... as for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

        - Gilboa
        Well, from both a development and project mismanagement viewpoint, it makes absolutely no sense whatsoever to write two identical very demanding GUIs - installed standalone and within anaconda -- when one will be much easier to maintain to the level of robustness demanded by sys admins of their tools. But it is Fedora, so we shall see.

        Comment


        • #34
          Originally posted by gilboa View Post
          Actually, being a developer myself, I can certainly understand the reasons for rewriting anaconda: code decay.
          I would imagine that the old anaconda reached the point that bolting in new features was a complete nightmare (let alone supporting new hardware).
          However, in my view the anaconda team made one crucial mistake: They decided to target Joe-six-pack users at the expense of power users. (especially given Fedora's role as a test ground for the next RHEL...)

          Hopefully by F22 anaconda will be regain most of the lost power user options.

          As for using s-c-l (system-config-lvm) and gparted within anaconda - I very much doubt that it'll happen. I would imagine that RedHat will rewrite s-c-l (adding btrfs advanced options support) and make it a part of anaconda.

          - Gilboa
          The installer redesign was never focused purely on just non technical users and it simply cannot be since the RHEL installer is just the same with some additional modules for handling subscriptions etc. If you look at the design mockups posted a long time back, you can see that all of the advanced functionality is part of the design.

          https://fedoraproject.org/wiki/Anaconda/UX_Redesign

          If any important advanced feature is missing at this point, it is just a matter of not having the resources to finish it all in one cycle and you should consider it a bug.

          Anaconda uses the parted library (Anaconda developer is upstream maintainer as well) and you really need to be able to handle errors etc which you can't do by sticking gparted into Anaconda not to mention that the design needs to be cohensive and gparted doesn't cover much of the functionality Anaconda needs anyway but what is important here is that Anaconda team is increasingly depending on native OS components instead of their custom rolled up functionality (dependency resolving is handled by yum, networking is handled by networkmanager, they use bash instead of busybox etc) so the path forward is likely to have a single utility within the installer and outside it.

          Comment


          • #35
            Originally posted by RahulSundaram View Post
            The installer redesign was never focused purely on just non technical users and it simply cannot be since the RHEL installer is just the same with some additional modules for handling subscriptions etc. If you look at the design mockups posted a long time back, you can see that all of the advanced functionality is part of the design.

            https://fedoraproject.org/wiki/Anaconda/UX_Redesign

            If any important advanced feature is missing at this point, it is just a matter of not having the resources to finish it all in one cycle and you should consider it a bug.
            I may have misrepresented my POV.
            The anaconda team's resources are finite and limited - no doubt about it.
            But IMHO, the decision -where- to place these resources first (read: Getting the "advanced" features first or getting the "default-and-easy" code first) was misguided - especially given Fedora's (and RH) target user-base.
            Seems to me (feel free to correct me) that a -lot- of effort was spent on automating and stupid-proofing the LVM and RAID creation - at the expense of more-or-less-zero manual management (E.g. reserve empty space inside an LVM partition).

            Anaconda uses the parted library (Anaconda developer is upstream maintainer as well) and you really need to be able to handle errors etc which you can't do by sticking gparted into Anaconda not to mention that the design needs to be cohensive and gparted doesn't cover much of the functionality Anaconda needs anyway but what is important here is that Anaconda team is increasingly depending on native OS components instead of their custom rolled up functionality (dependency resolving is handled by yum, networking is handled by networkmanager, they use bash instead of busybox etc) so the path forward is likely to have a single utility within the installer and outside it.
            /+1 for s-c-l gaining MD raid management features

            - Gilboa
            DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
            SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
            BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
            LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

            Comment


            • #36
              Originally posted by gilboa View Post
              But IMHO, the decision -where- to place these resources first (read: Getting the "advanced" features first or getting the "default-and-easy" code first) was misguided - especially given Fedora's (and RH) target user-base.
              Seems to me (feel free to correct me) that a -lot- of effort was spent on automating and stupid-proofing the LVM and RAID creation - at the expense of more-or-less-zero manual management (E.g. reserve empty space inside an LVM partition).

              - Gilboa
              If you don't do the simpler features first, in some cases, you can't build advanced functionality on top and won't get enough feedback to make the base dependandable. Part of the design focus was streamlining some of the advanced functionality. I don't think that focus was misguided at all. It certainly reduces the support cost considerably (read: misfiled bugs, less support tickets, easier guides etc). Increasingly, the expectation that it is ok for enterprise software to be clunky is going away and that is a good thing.

              Comment


              • #37
                So I thought I know the conditions when the bug happens... but on another machine the same happens.

                It doesnt matter what language I select, I can add the lvm in anaconda or from the console. Lol I even pluged in a android phone because I did that on this pc where I could install it. Maybe its a timing problem or something because when I made all the screenshots the process took longer time.

                But it says "no prepared harddisc" or something like that.

                So I think you can cause this bug just by having any pc, try to install in a existing volume group maybe it matters that I have a volume with the name root where ubuntu is on it. So maybe fedora wants this name or something.

                But other than that this pcs have nothing in common.

                If somebody post me a good link to the right categorie url where I can post this bug I do it.

                So I could easily reproduce this bug on 3 pcs till now. I had even 15gb on this pc for root btw.

                Comment


                • #38
                  Originally posted by blackiwid View Post
                  So I thought I know the conditions when the bug happens... but on another machine the same happens.

                  It doesnt matter what language I select, I can add the lvm in anaconda or from the console. Lol I even pluged in a android phone because I did that on this pc where I could install it. Maybe its a timing problem or something because when I made all the screenshots the process took longer time.

                  But it says "no prepared harddisc" or something like that.

                  So I think you can cause this bug just by having any pc, try to install in a existing volume group maybe it matters that I have a volume with the name root where ubuntu is on it. So maybe fedora wants this name or something.

                  But other than that this pcs have nothing in common.

                  If somebody post me a good link to the right categorie url where I can post this bug I do it.

                  So I could easily reproduce this bug on 3 pcs till now. I had even 15gb on this pc for root btw.
                  Try https://bugzilla.fedora.com/. The index you seek is on the upper left side. Please search the DB for similar problem reports before submitting a new one. (Tedious, I know). Have you tried a basic installation on a non-lvm disk? Read the Installation Guide (http://docs.fedoraproject.org/en-US/...ide/index.html)? Asked around at http://fedoraforum.org/? (You'll frequently get quicker, more productive response to a not-a-bug there than from Bugzilla/) Thanks for your help and perseverence!

                  Comment


                  • #39
                    Originally posted by pipe13 View Post
                    There is no such thing. You meant https://bugzilla.redhat.com although http://bugz.fedoraproject.org/anaconda is a easier shortcut in this case.

                    Comment


                    • #40
                      Originally posted by RahulSundaram View Post
                      If you don't do the simpler features first, in some cases, you can't build advanced functionality on top and won't get enough feedback to make the base dependandable. Part of the design focus was streamlining some of the advanced functionality. I don't think that focus was misguided at all. It certainly reduces the support cost considerably (read: misfiled bugs, less support tickets, easier guides etc). Increasingly, the expectation that it is ok for enterprise software to be clunky is going away and that is a good thing.
                      I must admit that even though I'm 0/2 when trying to install F19* on a VM with multiple drives, the F19 storage manager has improved considerably compared to F18, and with the help of Reartes Guillermo [1], I even managed to create my favorite MD RAID + LVM setup, though the steps to achieve it were, err, somewhat overly complex.

                      - Gilboa
                      * And having problems reporting meaningful BZ as the send bug report dialog simply hangs.
                      [1] https://bugzilla.redhat.com/show_bug.cgi?id=969771
                      DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
                      SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
                      BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
                      LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

                      Comment


                      • #41
                        Originally posted by gilboa View Post
                        I must admit that even though I'm 0/2 when trying to install F19* on a VM with multiple drives, the F19 storage manager has improved considerably compared to F18, and with the help of Reartes Guillermo [1], I even managed to create my favorite MD RAID + LVM setup, though the steps to achieve it were, err, somewhat overly complex.

                        - Gilboa
                        * And having problems reporting meaningful BZ as the send bug report dialog simply hangs.
                        [1] https://bugzilla.redhat.com/show_bug.cgi?id=969771
                        Yeah, I don't think there are any real advanced functionality missing at this point but there are few cases where the UI is still rough. One more obvious case I am aware of is https://fedoraproject.org/wiki/Commo...sed_check_mark

                        Comment


                        • #42
                          I'm really worried about Intel performance with Fedora 19. I tried Fedora 19 Beta today. Obviously it has got newer drivers than my current F18 install, but performance was poor (windows movement, animations). Intel performance has been great for me since Ubuntu 11.04, through Fedora 18. In the desktop everything have been 'flying', always better than both crp* radeon open-source driver and fglrx. Not so much with Fedora 19.

                          Well, I've been holding back with reporting bugs for F18 since F19 is not to far away. Looks like I'll have to step on it with F19.

                          Comment


                          • #43
                            Originally posted by Bucic View Post
                            I'm really worried about Intel performance with Fedora 19. I tried Fedora 19 Beta today. Obviously it has got newer drivers than my current F18 install, but performance was poor (windows movement, animations). Intel performance has been great for me since Ubuntu 11.04, through Fedora 18. In the desktop everything have been 'flying', always better than both crp* radeon open-source driver and fglrx. Not so much with Fedora 19.

                            Well, I've been holding back with reporting bugs for F18 since F19 is not to far away. Looks like I'll have to step on it with F19.
                            All pre-releases run a kernel with has reduced performance but better debuggability. That isn't something to worry about

                            Comment


                            • #44
                              Originally posted by RahulSundaram View Post
                              All pre-releases run a kernel with has reduced performance but better debuggability. That isn't something to worry about
                              That's not actually true, Rahul. We stop using the debug kernel at Beta. All builds from Beta on should perform at 'full speed'.

                              But I haven't seen anyone else, anywhere, indicate any particular problem with 'Intel performance'. Are you sure you're not seeing something else, Bucic? Have you checked performance monitors to see if there's any obvious culprit? Perhaps you're running into one of the logging bugs, or the dconf bug, and something's running your CPU to 100%?

                              Comment


                              • #45
                                Originally posted by AdamW View Post
                                That's not actually true, Rahul. We stop using the debug kernel at Beta. All builds from Beta on should perform at 'full speed'.

                                But I haven't seen anyone else, anywhere, indicate any particular problem with 'Intel performance'. Are you sure you're not seeing something else, Bucic? Have you checked performance monitors to see if there's any obvious culprit? Perhaps you're running into one of the logging bugs, or the dconf bug, and something's running your CPU to 100%?
                                Nope. The CPU load seems normal. I might record a video of what I see but is this really necessary? Windows animations in activities are choppy (below 20 FPS), while the notification bar (bottom) animation is smooth. It also seemed like my Thinkpad ran hot where the ATI graphics is even though I ran single-graphics Intel mode (Integrated, without OS detection of switchable gr.). lspci | grep VGA returned info only on the intel adapter.

                                One more thing. It was all identical between the freshly installed TC6 and updated TC6.

                                Comment

                                Working...
                                X