Announcement

Collapse
No announcement yet.

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

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

  • Delgarde
    replied
    Originally posted by AdamW View Post
    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.
    You say that, but why? It's not a completely unfamiliar OS - it's just the latest upgrade to the one I've been running for years, and which I expect to work *more or less* the same way as the previous version.

    And for the record, it *is* mostly working for me, once I worked out that I needed to manually install gstreamer1-libav to replace the older gst-ffmpeg - not strictly a Fedora problem since it's a third-party repo, but it did mean that none of my videos worked anymore. My complaints are with the way you're presenting this as a big deal, that people shouldn't be upgrading casually. I'm sure it's not your intention, but your messages are coming across with a strong subtext of "don't trust this release".

    Leave a comment:


  • AdamW
    replied
    Originally posted by Pallidus View Post
    I understand that but I do have a bunch of intel centrino laptops that HAVE to be 100% linux compliant.

    Everything from the gfx to wi fi has to function out of the box in every distro


    Fedora 17 worked like a dream.

    Fedora 18 my first experience I booted into the live_ram or live_session no longer remember the command and I went to firefox 16.02 (months ago) open youtube and watch a 50 minute html5 video = firefox dies, doesn't start again, entire graphical desktop environment dies, system dies.



    and to be honest my experiences with it didn't become better


    it was a punch in the stomach for someone who really liked f17, so yeah I understand that's probably working well for a lot of people but I my perception is my realiy and for me it failed.
    So I think what may be going on there is that Firefox now caches HTML5 video live so you can jump around in it, and old Firefox didn't do that. I wonder if we could disable that on the live session, or set a limit. But yeah, stuff like that happens; it's pretty hard to catch it all.

    Leave a comment:


  • Pallidus
    replied
    I understand that but I do have a bunch of intel centrino laptops that HAVE to be 100% linux compliant.

    Everything from the gfx to wi fi has to function out of the box in every distro


    Fedora 17 worked like a dream.

    Fedora 18 my first experience I booted into the live_ram or live_session no longer remember the command and I went to firefox 16.02 (months ago) open youtube and watch a 50 minute html5 video = firefox dies, doesn't start again, entire graphical desktop environment dies, system dies.



    and to be honest my experiences with it didn't become better


    it was a punch in the stomach for someone who really liked f17, so yeah I understand that's probably working well for a lot of people but I my perception is my realiy and for me it failed.

    Leave a comment:


  • AdamW
    replied
    Originally posted by Pallidus View Post
    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
    So, more than zero, then?

    Originally posted by Pallidus View Post
    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.
    I didn't say I was comparing it. You said you had zero problems with other distributions. I showed that statement was false. You're the one who went around inadvisedly making definitive statements.

    I already said, several times, that the problem with shipping a PC operating system is you're shipping a combination of several thousand moving parts and telling several billion people with several billion hardware configurations 'here is something that will probably work on your computer'.

    Every Linux distribution ever released will fail to run X on some computer somewhere. You will never find one which didn't. The 'problem space' is so huge that individual changes in it are probably more subject to chaos theory than any simplistic notion of QA: you simply cannot conclude anything definitive about the 'quality' of one distribution compared to another, or one release compared to another, based on anecdotal evidence of 'well, my computer worked with X but didn't work with Y'. It's just not plausible. There are billions and of Xs and Ys. You have to go up to the scale of thousands of reports, or something like a solidly-triaged bug of the kind 'All graphics card of generation foo completely fail to work in X', before you can draw meaningful comparisons. And even *then*, it's tricky.

    Leave a comment:


  • locovaca
    replied
    Originally posted by AdamW View Post
    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.
    Perhaps a more appropriate word is "Consumer." Clearly the Fedora team has consumers, otherwise, why would they produce anything?

    Leave a comment:


  • GreatEmerald
    replied
    Originally posted by AdamW View Post
    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.
    Hah, well, my favourite distro is openSUSE and its installer is YaST, which also happens to be the control panel and thus pretty much the central part of the distribution. So I can see how things can go wrong in that sense, but then again, YaST never had any rewrites (well, actually, there was that time when it was rewritten from YaST1 to YaST2, but it was 13 years ago). And I haven't seen many complaints about how difficult it was to maintain it - but then I haven't specifically looked for it, either.

    Speaking of which, what makes the new Anaconda better in this regard, compared to the old one? Why is it now easier to maintain, aside from no longer needing to develop both in parallel?

    Leave a comment:


  • Vim_User
    replied
    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?

    Leave a comment:


  • Pallidus
    replied
    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.


    http://youtu.be/P2kzqvPAVt0




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

    http://phoronix.com/forums/showthrea...271#post305271

    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...

    Leave a comment:


  • AdamW
    replied
    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.

    Leave a comment:


  • AdamW
    replied
    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:

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

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

    http://phoronix.com/forums/showthrea...271#post305271

    These are not problems with distros?

    Leave a comment:

Working...
X