Thursday 12 June 2008

How not to do a laptop support page

While the goal is laudable, pages like this one to support the Eee PC on Fedora 9 are what's broken about hardware support in Linux.

Grant X access to local user root: That's horrendous. Never ever do that.

Now we must [...] modprobe the eeepc module: File a bug against the kernel, with the output of "dmidecode", the module should load automatically on those machines.

Now let's handle some FN keys and events create these files: File a bug against the kernel, the eeepc module should be sending out its events through the input layer, so there's no need to install acpid, or tweak any of its config files.

I'll pass on the gruesomeness of the scripts that call into X from a daemon, remove modules by hand (why would anyone need to remove the PCI Express driver?), and the usefulness of having the camera disabled in hardware (it could also be on all the time, and only turn on the feature when the device is opened).

All in all, people writing those web pages had better spend their time filing bugs against the right components in Bugzilla. That also goes for most of the pages on sites like Tuxmobile. File bugs!

25 comments:

Anonymous said...

Actually, there's no need to file any bugs; that page just sucks. It can all be done the right way already. Mandriva does this. So do the customised versions of other distros for the Eee, more or less.

That page just uses very very hacky ways to do everything, when there's no real need to.

qhartman said...

I totally see your point, but I'd wager that those pages, and most like them, are written from a very different perspective. The people who wrote them and their audience don't much care about doing things "right" from a system admin / development POV. They just want to make it work. They've found something that makes it work, and whether or not it is the "wrong" way to do that or if it is hackish never enters their mind. The ideal would be something along the lines of "I filed a bug on this, but to make it work until it is fixed upstream, do...", but most people are simply not used to the design and development of technology being "interactive". They expect to be on their own when dealing with any problems that arise, and the idea that someone "above" them in the supply chain would actually listen to them is completely foreign.

Bastien Nocera said...

adamw, I'm pretty sure either the distributions do the hacks themselves, or they're not pushing their patches upstream.

qhartman, completely agree. I'm not fussed about the "this is a workaround" approach, as long as it's accompanied by bugs to "do the right thing".

karl said...

What's wrong with me man?

Instead of linking my blog and criticise, why don't help?

Classic elitism. Everyone is able to TALK TALK TALK and TALK, but few people do really something.

Do you think these fixes are "lamer"? It's a wiki. So instead of calling people "stupid", look at your own.

Web is full of these fixes and workarounds. I don't think it's bad to aggregate them in one page.

Are you encouraging forks?

Why forking a distribution, when with really few workarounds you can get it work?

Sure man, I'm irritated by this article. I don't like people that shout in the planet. I've an email address, publicly available. So why don't email me these critics?


The page and fixes are under construction, lamer or not, they do work eeepc.

You said...MANDRIVA. Mandriva HAS NOT a fork. Mandriva works out of the box.

now:


Now we must [...] modprobe the eeepc module - WELL, eeepc.ko has been replaced by eeepc-laptop in 2.6.26. So, eeepc.ko WAS A TEMP SOLUTION.

Now let's handle some FN keys and events create these files - MAN, no laptops handle FN keys without tweaking. These fixes are the same of the OpenSUSE project and other distributions like ubuntu, etc.

ACPI INSTALL: MAN, ever tried the LIVE CD???? I think no... ACPI isn't installed in the live cd.

remove drivers, bla bla bla: ALL the eeepc supporting distributions USE this solution. Do you have a better solution for wifi resume? WRITE IT INTO THE WIKI.

"All in all, people writing those web pages had better spend their time filing bugs against the right components in Bugzilla." You are nobody to tell me what to do with my time. I already file bugs in bugzilla.

Go to do something better please. Before talking in this way about others work.

We spent ours in making something for people wanting fedora in their eeepc.

You spent 10 minutes in talking talking and talkin.

Bye.

quaid said...

The Fedora Project wiki is ... a wiki.

Please edit the wiki and make it better. Criticizing the pages is best done on the "Discussion" tab, that's what it's there for. I'm not sure what blogging does other than to draw attention as if it is a problem that people are putting content on the wiki that needs the community to help write and update it. That is the nature of a wiki.

We need to teach folks what can and cannot go on the wiki, on the wiki. That is where to have discussions on how to fish.

The person who updated that page came to us on #fedora-docs looking for help for that page. He genuinely wants to make something useful. I agreed to work with him on the wordsmith editing, find someone to help clean up the language, and I asked him to contact the authors from the previous wiki to assist with the technical editing.

The only thing I passed direct judgement on was the handling of third-party repositories. Again, because it is so easy to edit the wiki compared to before, we need to make clear rules about how to handle this. It is not clear right now. The rule I tried for that page is, "If it is 100% FLOSS and not a ForbiddenItem and there is no Fedora Way to solve the problem, then it is OK to refer to a third-party repository for that specific package and it's similarly 100% FLOSS and not ForbiddenItems dependencies; must include caveats about the dangers of mixing repositories, probably best to provide some help in doing so."

Boy, that is an easy to read rule. And we wonder why people are confused on what to write and how?

While the Docs Project is taking the lead on making that stuff better for wiki contributors, we cannot do it alone. TIA to all the readers and writers herefor their help.

Anonymous said...

Um... the criticism seems silly. Hardware support is broken in Linux.

I'm exceedingly excited about Mandriva's work to run on the Eee out of the box. Not a custom spin, not a series of hacks, not simply filing bugs against various components. Load it, run it.

The problem seems to be that none that work has made it upstream. Perhaps if it had (or when it does...) Nobody will make pages like that, or blog posts like this.

Bastien Nocera said...

Whao, people get excited easily. The whole point was to take a page that somebody mentioned recently as an example.

I already mentioned this on the fedora-devel mailing-list.

So my question to karl is, where are all those bugs you filed, and why didn't you mention them on the Wiki page?

And mvpittmann, I'd be happy to see the results of Mandriva's work on the EeePC, but how do you think those bugs are fixed? Well, one person (which might or might not be a Mandriva employee) files bugs, and probably fixes it themselves. I'm not asking for the reporter to fix those bugs, just to file them.

Thanks to everyone for completely missing the point.

qhartman said...

Yeah, it seems you hit a nerve! FWIW, I think I got your point, but you probably should have been more explicit about the fact that you were using the pages you mentioned as an example / symptom of a larger problem. Maybe the other commentors would have not gotten so uppity. Similarly, if they had mentioned that they were filing bugs and not silently working around problems... :D

pirast said...

did you have a look at a bug which was reported and is linked to in the wiki page? https://bugzilla.redhat.com/show_bug.cgi?id=444115

what you'll notice is that it has been around for > 1 month, without anything done to it. So what should people owning a Eeepc do? Just don't use Fedora on it and wait for the bug to be fixed OR use a workaround and write it down to the wiki?

karl said...

@hadess (why didn't you mention them on the Wiki page?)

1- the eeepc page was already there, I just did a better readeable layout. shame on me.

2- I refreshed some fixes, with some new tricks.

3- I don't filed bugs, because i think, these aren't bugs... eeepc.ko was temporary, etc etc...


I'm going to remove some things in the wiki page. But sure... this is the last time I edit this page, shame on me.

Yesterday I was sure I did the right thing....contacted documentation-team, old eeepc page writers....


bye :-)

ps I have an email address. The next time, feel free to use it. I always REPLY.

Anonymous said...

Much more useful (and simpler) than dmidecode is the output of

cat /sys/class/dmi/id/modalias

Bastien Nocera said...

pirast, that's not the point. That's exactly one bug filed. Where are the others.

karl, stop playing the martyr. I only linked to your blog with the text "goal is laudable". I didn't point to you, I didn't even know you edited the page, and I don't care if you did. The person(s) that wrote that page didn't file bugs, or didn't link them from the page.

I don't have an EeePC, so I wouldn't know what bugs need filing. I'll say again that this was an example.

karl said...

You attacked me IN PLANET FEDORA using a blog page.This is not fair, ok? don't use the example as mask. Wiki pages have history. READ IT. wiki pages have also discussion tab.

So no need to shout like a fish vendor in planet fedora.

I'm the person that updated the fixes into the wiki page, and I'm also the blog's author.

So if you think I did the wrong thing, the next time contact me in private, and I will correct everything you want.

The workarounds aren't mine, but this is not the point.


The next time I'll file bugs. Now PLEASE, STOP FLAME.

Anonymous said...

Gotta say you're wrong on this one, Bastien.

If something doesn't work as shipped, and somebody manages to figure out a way to make it work, then God bless that guy for posting his results so that I can make that thing work, too.

So what if he used the Wrong Approach? At least it's Something for the rest of use while the Right Approach is being worked on.

Bastien Nocera said...

karl, I didn't attack you. I was just explaining what was wrong with this approach. I didn't yell at any point, and if you feel like I attacked you, I'm sorry because that wasn't the goal.

Anonymous, I didn't having work-arounds was a bad thing, but if you don't file bugs (or make sure fixes go upstream), then the next version of the distribution will still be as broken.

Anonymous said...

hadess: What´s the big deal of granting only local root X access? (xhost +local:root)???? Specially on a desktop environment (since it´s not likely someone would build a server on a Eee PC)?

You comments were really just stupid...

You talk as if bug reports were constantly solved by developers, and it´s pretty clear they are not. I´m tired of filing bug reports that get simply forgotten.

The fixes on that page work like a charm on my EeePC and I can´t see any problem with them, except for the complete alienation from Fedora regarding the EeePC.

And please spare yourself from telling it was just a example.. Take a look again at the title.

Take a look at how age are these eeepc reported bugs: https://bugzilla.redhat.com/buglist.cgi?query_format=specific&order=bugs.bug_id&bug_status=__open__&product=&content=eeepc

Guys like you sometimes makes me want to drop Fedora. It´s a good distro, but developers don´t give a sh** to end-users. That´s the real truth.

Best regards,
Duli

pirast said...

hadess, point is though, that it does not motivate anyone to file more bug reports if the one he has reported is just lying around and no one is interested in it for over a moth (although the kernel is a core component).

karl said...

Oh Bastien...we are in gnome planet too... thanks really.

TWO TIMES fishmonger

Great man!

[sarcasm ON]
Thank you for the free advert. My blog is flooded by people coming from planet fedora and gnome
[sarcasm OFF]

Ok, the eeepc page is fedora related...but what about planet gnome?! -_-" strange.

Bastien Nocera said...

pirast, I get your point, but filing bugs against the kernel can also help with tracking, even if the bug doesn't get fixed downstream (ie. by Fedora developers). Say I've got an EeePC with those work-arounds installed, and I'm interested to know when the bug is fixed to update the Wiki. If somebody else tests a new kernel that fixes it, then puts a comment in there, we can close the bug, and update the Wiki. Otherwise it's just something that somebody might do...

karl, my blog is syndicated on plenty of planets. You'll find it's also on Planet GStreamer and Freedesktop.

Kevin Kofler said...

quaid wrote: "If it is 100% FLOSS and not a ForbiddenItem and there is no Fedora Way to solve the problem, then it is OK to refer to a third-party repository for that specific package and it's similarly 100% FLOSS and not ForbiddenItems dependencies; must include caveats about the dangers of mixing repositories, probably best to provide some help in doing so."

But the MadWifi drivers which are being referred to on that page are not "100% FLOSS" (and no, they don't fall under Fedora's firmware exception either, the proprietary code is an object file which is loaded into the host kernel as part of the kernel module).

karl said...

ok madwifi removed.

https://fedoraproject.org/wiki/EeePc#Wireless_Drivers

Benjamin said...

What all the people writing workaround pages tend to forget is that if they do not file bugs, they will have to work out all the quirks again for Fedora 10. And Fedora 11. And so on.

But it's still discouraging for me as upstream person to know people work around bugs I don't know about instead of telling me.

karl said...

Ok, bugs have been filed.

Stop complaining.

Anonymous said...

Okay... that was crazy... Although, reading it reminds me of why I use Fedora, rather than skip it because of the broken nature of it.

Someone does something, someone corrects, and discussion happens.

Eventually the "right things" happen, and stuff gets fixed. Openly and transparently.

For a community of contributers, who put their personalities on the line every time they contribute, it can be hard not to take a comment personally.

The crappy bickering sucks, but I'm certain it is ingrained into the culture... Paul said a little diddy on his blog not too long ago about an incoming/outgoing tact filter that might prove an interesting (re)read for everyone.

Here's the real measuring stick though. When Fedora 10 comes out, will this stuff be fixed?

Is working on the Eee even an official goal of the project? Should there be a sepeate spin? In addition to instructions, and bugs, and wiki edits and blog posts, someone needs to take a stand, or make an announcement on what to do with all these ultra mobiles coming out.

Even if that statement is "dammit, you want Fedora on UMPCs, spin it yourself!" Opening the toolset, and not getting this functionality "out of the box" pretty much implies that, but a simple statement from Fedora leadership might clear that up.

I'm not saying there needs to be anything like what Shuttleworth and company are working on, but maybe it is time for a UMPC Special Intrest Group, or a statement that there shouldn't be one, and that that work should just go into making the main distro friendly to small screens and proprietary hardware.

quaid said...

... but maybe it is time for a UMPC Special Intrest Group, or a statement that there shouldn't be one, and that that work should just go into making the main distro friendly to small screens and proprietary hardware.

Exactly what the Fedora SIG process is for.

Hadess -- appreciate that you were just using an example; it didn't come across that way, but life is full of mis-understandings. :) I was glad to get a chance to make my favorite point, that the best way to fix the wiki is to edit it ... and help set the guidelines. I appreciate that you were, in a different way, helping to set/influence the wiki guidelines. Definitely drew attention to this hole we have, of defining what can be put on the wiki and teaching people that ... over and over and over and over ...