Announcement

Collapse
No announcement yet.

Alan Cox Calls Fedora 18 "The Worst Red Hat Distro"

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

  • #91
    Originally posted by picasticks View Post
    Something so invisible needs to be killed. Gnome needs to stop hiding UI elements, it kills everyday usability. OS X has a few things absolutely right, like the app menu bar locked at the top of the screen (I can find the File menu of the current app with my eyes closed)
    Huh, so that was an idea from Mac OS X? I thought it was just Unity developers trying to be different for no good reason...

    Originally posted by hoyt View Post
    I agree that Fedora goes too far with the minimalization concept, but that's because the design goal seems to be the corporate desktop. Just look at all the fiddling one must do to enable the extra repos and make the installation consumer friendly. It reminds me of tweaking a Windows 98 install.
    Actually, I think you're confused here. Maybe it reminds you of tweaking a Windows 8 install? Because Windows 98 never needed any tweaking to make it usable. Actually, it barely had any options that could be tweaked in the first place. It's only later that they added more options and made them default, and thus now you need to spend a few hours to configure Windows to act as it did in Windows 98 times. And it gets worse with each Windows release.

    Originally posted by kaczu View Post
    http://i826.photobucket.com/albums/zz188/kaczu_bucket/logout_zps55487f73.jpg

    This really isn't THAT hard. You would think for those of us (not speaking to you directly) who compile programs, configure wine, or hell give me something (install RAID?). I don't know but this...
    Hah, that's pretty funny, before reading the post I thought that the image there was from Android or so. But then I realised that this is actually GNOME 3...

    Originally posted by AdamW View Post
    Perhaps you could consider *gaining* some insight into a development process before criticising it? This is not a snark, it's a genuine suggestion. All the points you raised have been raised repeatedly, and explain repeatedly, in all sorts of venues - the Fedora mailing list, the forums, here on Phoronix - over the last few months. I'm getting pretty tired of explaining it _again_.
    It was never answered in this topic before, and those are genuine questions. No need to be so harsh about that.

    Originally posted by AdamW View Post
    This is actually one of the major reasons we're doing newUI in the first place: a significant part of the work involved in maintaining any OS installer is simply in keeping it up to date with the rest of the system. You can't just take the installer from one release, shove it in the next, and call it good. It has to be maintained to account for changes in the rest of the system. oldUI in particular was getting to the point where maintaining it from release to release just so that it worked _the same_ - not noticeably better - was taking up a significant proportion of all the resources we had for installer development. That meant we couldn't really do a lot of work on making the installer better.
    That's... interesting. I don't know that much in this field, but it doesn't feel right. What changes does the installer need to reflect? New package versions? I don't think all the installers of all the distributions need as much maintenance. I suppose the old Anaconda could have been an exception, though.

    Originally posted by AdamW View Post
    At this point we have the same product and it's just about massaging the messaging. That's something we already tried to do with the release announcement and other release documentation, and see how much slack that's bought us.
    Oh come on, it's a well known fact that nobody ever reads manuals and licenses these days

    Comment


    • #92
      Originally posted by GreatEmerald View Post
      That's... interesting. I don't know that much in this field, but it doesn't feel right. What changes does the installer need to reflect? New package versions? I don't think all the installers of all the distributions need as much maintenance. I suppose the old Anaconda could have been an exception, though.
      So interesting trivia: the reason F18 Alpha was delayed had little to do with newUI itself and everything to do with dracut. Yup, dracut. anaconda is built on top of dracut, just like Fedora itself, and if your initramfs-handler-thingy decides to make drastic changes between releases, anything built on top of it is going to need to handle those changes. We merged newUI - which we'd tested in a side branch was working quite well - into Rawhide, and it promptly exploded all over the place because we hadn't had the new dracut in the side branch (for stability!) and the code hadn't been adjusted for it. (oldUI was never adjusted to the new dracut either; one of the major problems with rolling back to oldUI at any time would have been replicating all the work we did to make newUI work with the dracut changes).

      Anyway, just an example. anaconda in general is built on top of rather a lot of other components of Fedora. It uses NetworkManager for network configuration, for instance. It uses yum's interfaces for package installation. It uses the packaged grub2 to set up the installed system's bootloader, it uses packaged libparted for a lot of partitioning stuff, etc etc. It's a part of Fedora like any other in some ways - it's not a static blob of code laid on top, it builds against or calls out to the current packaged version of all those bits. When you build a Fedora installer image, you're essentially building a small self-contained special-case Fedora environment: the build process pulls in the current packaged kernel, dracut, anaconda itself, libparted, NetworkManager, systemd (that's another one anaconda commonly has to react to changes in), etc etc etc etc etc and smooshes them together. Booting anaconda is really just booting a specific Fedora instance with a systemd config that runs anaconda.

      The 'static blob of code' approach is possible, but it comes with its own problems - you're really just trading one set in for another. If you give your installer its own network config code, or just throw a static NM build in there, you solve the problem of having to potentially adjust your installer code for changes in NM, but you give yourself some other problems instead. If you write separate network code for the installer, well, now you have two piles of network code to maintain. You can leave the network code in the installer alone and it'll probably keep more or less working, but how do you support wifi installs, when wifi comes along? Well, you've got to write a bunch of wifi code into your installer at the same time you're writing a bunch of wifi code into NM. Seems stupid. If you throw a static NM build into your installer...when do you update it? Once a cycle? What if a fix for some important bug comes along and you get it in your actual distro but not in the installer? seems sub-optimal. What if your installer winds up writing out a configuration that the installed NM can't read properly because they're different versions? Again, not great. Anyhoo. Yeah. That's the issue. You _can_ write an installer that requires less maintenance than anaconda, that's true, but at the cost of not gaining the advantages of improvements in the underlying components.

      Originally posted by GreatEmerald View Post
      Oh come on, it's a well known fact that nobody ever reads manuals and licenses these days
      Sadly seems to be true, but still not excusable. I wrote it a bit flippantly, but I am _genuinely_ amazed that it seems to be quite normal these days to assume you can throw a completely unfamiliar operating system at the computer that contains lots of your precious data and just expect to be able to Work Stuff Out As You Go Along. That's just bonkers.

      Comment


      • #93
        "You basically just say 'it sucks'. This is not useful feedback for anyone."


        Anaconda is broken and it has been broken since day one and it needs a big overhaul.



        At first it was just me saying that... now there are plenty of others, are we all wrong?


        Common sense would dictate that the cheer ammount of changes, and the heavy nature of, you were about to make in fedora WOULD REQUIRE much more than the time you had in the development window.


        so a sane person would either continue to postpone the release or simply skip 18 and deliver a functioning and stable f19.


        I mentioned the problems I had in f18's live sessions as they would simply crash firefox and kill the system, someone said they could be due to memory management, strange as f17 never did that and 4gigs were always enough to test f17 beta and it never crashed once.

        I was about to install the beta but since I couldn't connect to a hidden wi fi and had a bunch of other small issues I (luckily) backed out.


        When the final release came I picked up a windows 7 laptop that had plenty of unpartioned space and installed by selecting 'boot device yes' (grub installed well) and I did let anaconda do everything automatically since it said it required no input (how hard could it be really, 1 partition with windows 7, 200g of unpartioned disk space).

        Manually partitioning the disk is a clusterfuck, mount point 500mb ?? I even picked standard partition as I had no need for LVM.

        During install I get a Kmod 04044 something error and then it boots into the fedora logo, the wi fi lights light up etc but blank screen... blank screen... blank screen.

        ext4 partitions couldnt be mounted due to fs incompabilities etc etc...


        I'm sorry but I had 0 problems, ZERO, with any linux distro thus far.



        That comment about "getting your money back" is counterproductive, why does microsoft go around the college here giving copies of windows 8 to IT students?

        The people that are using fedora today could be a rhel contract tomorrow, so you shouldn't dismiss them as cheap guinea pigs.

        Comment


        • #94
          Originally posted by Alan Cox
          Dear Slashdot, switching one system that run Ubuntu in a VM to Fedora into running Ubuntu does not constitute 'switching to Ubuntu'. I've been running Unbuntu for some jobs (like building Android images) for ages 8). In fact I run several distros (Fedora still included)

          And for that matter my goldfish boot/stress test image is a hacked Debian fs image...
          Maybe he should have mentioned Phoronix as well...

          Originally posted by Alan Cox
          I'm leaving the Linux world and Intel for a bit for family reasons. I'm aware that "family reasons" is usually management speak for "I think the boss is an asshole" but I'd like to assure everyone that while I frequently think Linus is an asshole (and therefore very good as kernel dictator) I am departing quite genuinely for family reasons and not because I've fallen out with Linus or Intel or anyone else. Far from it I've had great fun working there.

          Most of the people who should know more do, I know I've missed a few.

          I may be back at some point in the future - who knows. In the mean time if you'd like my job (or indeed one of a range of others) we're hiring 8)
          So, tell me, how does this equate to moving to Windows guys?

          Comment


          • #95
            Originally posted by LinuxID10T View Post
            Fluxbox and Blackbox.
            I took the time to reproduce the issue by installating both Fluxbox and Sugar and restarting the system. On gdm login screen, the session is available containing Fluxbox and Sugar.
            I do not know how you cannot access to Fluxbox while I successful got there without a fuss.

            Comment


            • #96
              Originally posted by AdamW View Post
              Anyway, just an example. anaconda in general is built on top of rather a lot of other components of Fedora. It uses NetworkManager for network configuration, for instance. It uses yum's interfaces for package installation. It uses the packaged grub2 to set up the installed system's bootloader, it uses packaged libparted for a lot of partitioning stuff, etc etc. It's a part of Fedora like any other in some ways - it's not a static blob of code laid on top, it builds against or calls out to the current packaged version of all those bits. When you build a Fedora installer image, you're essentially building a small self-contained special-case Fedora environment: the build process pulls in the current packaged kernel, dracut, anaconda itself, libparted, NetworkManager, systemd (that's another one anaconda commonly has to react to changes in), etc etc etc etc etc and smooshes them together. Booting anaconda is really just booting a specific Fedora instance with a systemd config that runs anaconda.
              Ah, that makes sense. But it still doesn't look to be so difficult. Sure, all these dependencies change, but do their interfaces change that often? Why would an updated NetworkManager suddenly break things? And if it does, does it really break more than once per release cycle? And building a mini environment with the required components should also not be as difficult. Sounds like building a LiveCD, and that is not really that hard. Not sure about the whole dracut situation, though.

              Comment


              • #97
                Sheesh, it's weird how a perfectly simple comment goes over people's heads: someone said I was dismissing 'customers'. I was not, since Fedora by definition has no customers. You don't pay anything for it. Simple enough. I'm not saying anyone's cheap, I'm just saying that it is an inescapable fact that Fedora has no customers.

                Your post is still borderline incoherent, but let me see if I can extract any sense from it:

                "Anaconda is broken and it has been broken since day one and it needs a big overhaul. At first it was just me saying that... now there are plenty of others, are we all wrong?"

                Define 'broken'.

                Anaconda is an operating system installer. In fact it's one of the most capable operating system installers out there. It can install several million possible combinations of software packages to several million hardware configurations using several million storage configuration possibilities expressed via two completely different methods (interactive install vs. kickstart) and all kinds of other configuration possibilities. So our problem space is at least millions multiplied by millions multiplied by millions multiplied by two, and I'm simplifying.

                When you're dealing with a problem space that large, a binary "it's broken" / "it works" distinction is entirely ludicrous. F18 installer has bugs. So did F17 installer. So did F16 installer. So did every installer anyone's ever shipped. F18 installer has more bugs than F17 and F16 (I think this is uncontroversial). Well, so did F15, and we shipped that. It's very difficult to make every release your best release ever. It's basically impossible to make a release which contains a ground-up rewrite of something as complex as an operating system your best release ever.

                You had problems with F18's installer, and I'm sorry. Other people did too, indeed. Lots of people had problems with F17's installer, and F16's, and F15's, and so on. Go to the forums for any distribution around the time of a release and you will find people having problems with that release. You cannot possibly release a PC operating system which has no problems. It's just impossible. The problem space is too large.

                So again: what does 'broken' mean? Usefully? Believe me, I'm a QA person. This is something I've thought about. Extensively.

                As far as big overhaul goes - this is the big overhaul. The whole point is that you can't do a big overhaul and nail it on the first try. It does not need a big overhaul any more, it needs refinement.

                "Common sense would dictate that the cheer ammount of changes, and the heavy nature of, you were about to make in fedora WOULD REQUIRE much more than the time you had in the development window."

                Ah, "common sense: usually neither". One of my favourite aphorisms. You cannot predicate software development on some vague notion of 'common sense'. What common sense, exactly, allows one to roadmap the development of an extremely complex piece of software? You are the master of common sense: explain to me how you would have made the decision when to jump to newUI by default, given the constraints explained in the above posts?

                "so a sane person would either continue to postpone the release or simply skip 18 and deliver a functioning and stable f19."

                Oh good, I'm glad you're here to tell me I'm insane. I wouldn't have noticed otherwise.

                So look at our situation two weeks ago: we're sitting on a build of Fedora which has some issues but basically meets our release criteria. We're already several weeks late. There is lots of good stuff in F18 taken as a whole which people have worked hard on, and which users are expecting to get to play with. Why is it so blindingly obvious that the only sane path is to say 'we're not going to release this for another few months or at all'? Because that's what you're saying. The significant issues left in F18 are not ones that are quick patch-ups. The issue with re-using existing LVM containers, for instance, involves re-working how manual partitioning handles free space calculation, since right now it doesn't really consider the possibility of 'unallocated space inside a VG'. This isn't a one-line fix that can be safely tested in two days. Making changes of that significance effectively throws us back to the Beta phase of development: we would have thrown in some similarly impactful changes and basically restarted the Final validation process. I certainly would've expected that to put back release another month or so.

                Sorry, but I disagree: neither of the things you suggested are the only possible choices for "a sane person".

                "I mentioned the problems I had in f18's live sessions as they would simply crash firefox and kill the system, someone said they could be due to memory management, strange as f17 never did that and 4gigs were always enough to test f17 beta and it never crashed once."

                That's still completely unhelpfully vague as a bug report. What were you doing in Firefox exactly? What does 'kill the system' mean? How much memory does the instance in question have? What error messages do you see? Etc. Fedora validation testing explicitly includes running Firefox in a virtual machine, I did it hundreds of times during release testing, never saw anything like what you're describing, and I haven't seen anyone else report it. I'm not saying you're not seeing a bug. What I'm saying is to bear in mind, as I explained above, that a computer operating system is a ridiculously complex thing and it can be deployed in literally billions of billions of configurations. There is absolutely no way we can guarantee weird bugs won't happen in some cases. On the contrary, they always have and always will. Check the history of absolutely any Linux-related discussion forum for this. You hit one in F18 you didn't hit in F17. That doesn't mean F18 is a crime against nature.

                "When the final release came I picked up a windows 7 laptop that had plenty of unpartioned space and installed by selecting 'boot device yes' (grub installed well) and I did let anaconda do everything automatically since it said it required no input (how hard could it be really, 1 partition with windows 7, 200g of unpartioned disk space)."

                This story never appears to finish in your post, but are you saying you did an 'automatic' install into empty space and it worked? If so, er, yay?

                " Manually partitioning the disk is a clusterfuck, mount point 500mb ?? I even picked standard partition as I had no need for LVM."

                I have no idea what you're talking about. Uh. Yes, a typical F18 install would include a 500MB mount point, I guess? That's the standard size of the /boot partition. What is your problem here?

                "During install I get a Kmod 04044 something error and then it boots into the fedora logo, the wi fi lights light up etc but blank screen... blank screen... blank screen."

                Er, but you've just talked about the partitioning process, so it sounds like you got there. What? Are you talking about a different machine here? What the hell is going on? I'm going to guess you got a kernel slowpath warn from abrt during live install (which happens sometimes) and then after install the installed system wouldn't boot. Okay, that's unfortunate, but I really can't begin to guess what the problem might be given that you don't say what your hardware is or really provide any other useful details...did you try any of the standard troubleshooting steps?

                " ext4 partitions couldnt be mounted due to fs incompabilities etc etc... "

                if this is what I'm thinking of, it's nothing Fedora-specific, it's just changes within ext4. I recall reading about something similar affecting Ubuntu users upgrading from 12.04 to 12.10. But again, you provide absolutely no useful details.

                " I'm sorry but I had 0 problems, ZERO, with any linux distro thus far. "

                That's funny, it looks like you had a problem with Lightworks crashing in Ubuntu 13.04:



                and a problem running various distros - at least Ubuntu and MorphOS - on PowerPC:

                Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.


                These are not problems with distros?

                Comment


                • #98
                  Originally posted by GreatEmerald View Post
                  Ah, that makes sense. But it still doesn't look to be so difficult. Sure, all these dependencies change, but do their interfaces change that often? Why would an updated NetworkManager suddenly break things? And if it does, does it really break more than once per release cycle? And building a mini environment with the required components should also not be as difficult. Sounds like building a LiveCD, and that is not really that hard. Not sure about the whole dracut situation, though.
                  NM was just an example, in practice, it's usually stuff like dracut, systemd and libparted that require changes. There's other bits too - these are all just _some_ of the things anaconda builds on. And you have to remember the 'problem space' calculation I just did for Pallidus: we are not working with a simple bit of software that does a couple of things, here. One set of changes to dracut can break initialization of the installer in both BIOS mode and UEFI mode, reading existing disk partitioning in all kinds of ways (we've got to consider LUKS encryption, MD and DM RAID arrays, LVM and btrfs containers, exotic storage stuff like iSCSI and multipath, and that's just a sampling), and umpteen other things - fixes to any of which can then expose other issues elsewhere. The easiest way to understand this stuff is just to get involved: go work on installer development or testing for your favourite distro. You'll pick it up in no time, believe me.

                  Comment


                  • #99
                    OH WOW

                    let me read your entire post BUT let me just reply to this:


                    " That's funny, it looks like you had a problem with Lightworks crashing in Ubuntu 13.04:

                    http://phoronix.com/forums/showthrea...000#post306000 "


                    Ubuntu 13.04 is at alpha 1, kernel 3.8 and sna for intel... it should be unstable as all hell... I had it installed for a couple of weeks and run live sessions a couple of times a week, how many times has it become unresponsive? 1

                    how many times did X die? 0


                    compare that to fedora 18... I can't count the number of times it just simply killed X and crashed.


                    Lightworks is alpha and it's crashing all the time, there's a rpm of lightworks and I can tell you they have a lot more issues with it working in fedora.

                    At least in ubuntu you get it to work.







                    "and a problem running various distros - at least Ubuntu and MorphOS - on PowerPC:



                    These are not problems with distros? "



                    y'know it's easier to attack a former user than to admit that there are issues in your product...


                    that remains true for you and alot of corporations and businesses...


                    I like to troll but I'm taking the hight road here.


                    I had many issues with fedora 18, too many, and I'm not going to use it.

                    I will try fedora 19 when it's released


                    for the mean time I'm happy with ubuntu 13.04


                    and from someone who has criticized unity to hell, it still looks like sin, but it is becoming increasingly functional and usable unlike gnome...

                    Comment


                    • Originally posted by V!NCENT View Post
                      Alzheimer patients usually live in the past, right?:

                      Source: https://wiki.archlinux.org/index.php/Systemd
                      OK, this one example was not correct, I admit that. What about the other things mentioned in this thread where logout on a single user machine makes sense?

                      Comment

                      Working...
                      X