Fedora 20 Runs Great On The Intel Bay Trail NUC

[sarmad]

I don't understand what people see in Fedora. Of all the Linux distro's I've tried Fedora ranks down near the bottom in terms of stability and usability. I tried it on my MacBook Air for a few days and the bugs were so bad I had to return to Mac OSX.

Besides, the Fedora installer is one god awful piece of software. I'm not sure what the hell they were thinking with that thing.

Installer is quite bad, but apart from that the rest is great. It's stable, especially if you are a Gnome Shell user. It also feels lightweight. It felt lighter than Ubuntu on my machine. Also, as others mentioned, its packages are more up to date.

[AdamW]

How does that equate to "runs great"? Having an unbootable system after a stable upgrade, and having to mess with development packages just to be able to use your computer is far from great as far as most users are concerned...

If Michael would actually report problems to us, usefully, with data, we might have a shot at fixing them.

Here is the sum total of all Michael's activity, ever, on bugzilla.redhat.com unless he has an account I don't know about:

* Two comments on https://bugzilla.redhat.com/show_bug.cgi?id=485596
* Er...that's it.

So, I don't have one of these systems. None of the Fedora kernel devs has one of these systems. The article provides no useful details at all about the bug. All he says is that it hangs during boot. The message about duplicate EFI variables is just a warning, and unlikely to be the cause of the issue, according to Peter Jones. So...what would you like us to do? How could we fix it? We can hardly just go around backporting the entire 3.14 UEFI patch set to 3.13, or something.

[GreatEmerald]

* Two comments on https://bugzilla.redhat.com/show_bug.cgi?id=485596

That's six.

[AdamW]

That's six.

True. Still, it's the only bug he's ever posted to. And it's not even a bug, it's the package review request for his own piece of software.

If https://bugs.launchpad.net/~michael-...ugs?advanced=1 works as expected, he's got a similarly non-existent track record of reporting bugs to Ubuntu.

[Michael]

If Michael would actually report problems to us, usefully, with data, we might have a shot at fixing them.

Here is the sum total of all Michael's activity, ever, on bugzilla.redhat.com unless he has an account I don't know about:

* Two comments on https://bugzilla.redhat.com/show_bug.cgi?id=485596
* Er...that's it.

So, I don't have one of these systems. None of the Fedora kernel devs has one of these systems. The article provides no useful details at all about the bug. All he says is that it hangs during boot. The message about duplicate EFI variables is just a warning, and unlikely to be the cause of the issue, according to Peter Jones. So...what would you like us to do? How could we fix it? We can hardly just go around backporting the entire 3.14 UEFI patch set to 3.13, or something.

The reason as I've said before on other occasions is simply due to being stretched thin as it is with myself writing articles each day and usually using at least six different systems... And with always running benchmarks on the "latest and greatest" or "most interesting" at the moment, the configurations are changing -- sometimes multiple times per day in my ~16 hour work periods. So like in this NUC Bay Trail Fedora 20 configuration, it was that way for a day while a day later it's currently running Debian Sid. By the time the relevant person sees the bug report, chances are the hardware/software configuration has already change. Most often the person looking at the bug will request running some extra tests or trying out patches, but by the time that comes up the system is totally different configuration. So in the end the bug would possibly be closed as needing more info or unresolved/abandoned, etc. With only often having only one of each piece of hardware, I can't keep the systems around in a known configuration for bug triaging any longer since other articles must be written if Phoronix is to stay in business....

I welcome feedback and ideas, but so far nothing that's been suggested has worked out. The only stuff that has worked out a few times is when Intel's supplying hardware and I am testing it and I run into an issue and any of the developers I know are immediately pingable via IRC then I am happy to work through it.

[AdamW]

The reason as I've said before on other occasions is simply due to being stretched thin as it is with myself writing articles each day and usually using at least six different systems... And with always running benchmarks on the "latest and greatest" or "most interesting" at the moment, the configurations are changing -- sometimes multiple times per day in my ~16 hour work periods. So like in this NUC Bay Trail Fedora 20 configuration, it was that way for a day while a day later it's currently running Debian Sid. By the time the relevant person sees the bug report, chances are the hardware/software configuration has already change. Most often the person looking at the bug will request running some extra tests or trying out patches, but by the time that comes up the system is totally different configuration. So in the end the bug would possibly be closed as needing more info or unresolved/abandoned, etc. With only often having only one of each piece of hardware, I can't keep the systems around in a known configuration for bug triaging any longer since other articles must be written if Phoronix is to stay in business....

I welcome feedback and ideas, but so far nothing that's been suggested has worked out. The only stuff that has worked out a few times is when Intel's supplying hardware and I am testing it and I run into an issue and any of the developers I know are immediately pingable via IRC then I am happy to work through it.

There's just about always at least one kernel maintainer active in #fedora-kernel.