Talk:User manual

This is the talk page for discussing the article.
Please sign your comments using four tildes (~~~~). Place comments that start a new topic at the bottom of the page and give them == A Descriptive Header ==. To improve readability, it's recommended you add a ":" at the start of your paragraph to indent your text when replying to someone.	Talk page guidelines Please respect Etiquette, assume good faith and be nice.

Terminal Commands

I'm pondering whether to add job control into this section, or whether a seperate section would make sense. Eg, & to launch an app in the background, CTRL-Z to stop an app, bg and fg to background and foreground it. It's really handy. -- Gricey

Also, I put a (use with care) next to the killall command. Killall is fun for casual stuff, but you may end up killing more instances of something than you planned. A better way of doing it, though it isn't as fast, is to use ps with grep and kill the specific PID. You can also kill a process by PID from top by pressing k, although your process may not appear in the top list. -- Gricey

I question whether terminal commands should even be in the user manual. The only people who have any cause to be messing around with the CLI are those who already know what they're doing. A casual user might go for years without ever opening a terminal window. An in-depth explanation of terminal commands is a good thing to have somewhere on the wiki, but probably not in this section. All you are likely to do is frighten and confuse people with this information, which they will probably never need to use anyway. Chip 00:30, 7 January 2010 (MET)

I disagree. A lot of tutorials have terminal commands, and they seem to be needed even for some basic and important things such as making sure that the NAND doesn't run out of room. Instead of leaving them out, there needs to be a simple, easy-to-follow explanation of how to get to a window where you can type them in (not explaining all the technicalities, just simple (1) (2) (3) instructions that any layman can follow). I'd do it myself, but I won't have my system for another few days yet. Maybe then. Also, I've never used Linux and used terminal commands in Windows/DOS only very rarely, so I'll try to make it as stupidly-simply as possible. :p Esn 23:05, 14 January 2011 (MET)

Duplication of existing Linux or application documentation must be kept at a minimum. Writing about basic commands for common usage is ok, but for more advanced usage, Pandora documentation should point the user to official resources. If the official resources suck, then for sure we write better stuff here and then make fun of the official guys to goad them into fixing themselves. I'll stress these and other philosophies as I go through the existing docs here. More ranting on my documentation philosophies page. — spiralofhope / ^(talk) 23:14, 10 May 2012 (CEST)

splitting into smaller articles

I think it would be a good idea to split this huge page into smaller chunks. That way updating it might be more convenient.

I've moved the linux guide and minimenu configuration docs into their own pages.--Cheese 04:12, 28 June 2010 (MEST)

The splitting out needs to be even more radical, I think. It seems this was written as the community's version of the printed user manual. if it is going to stay like that, it should be split into chapters, with better navigation (the page is much too big). As an alternative, some info should be removed (e.g. specifications are not useful to be insered inline here. I was initially wondering how we should use this page to link to other pages. At the moment, my best effort would be to provide with each heading a link to a a group documentation page, and introduce them at the start of this page. That way it becomes something short to read, and also provides one possible jump-off page into the main wiki. --Tsh 13:26, 19 July 2010 (MEST)

I did do a bit more splitting up a while ago. I moved the PND section to it's own article, but I also added in a very short version of how to install software and what a PND is, with a link to the new PND page. Just sharing that as an example for one way to do it. --Cheese 18:40, 19 July 2010 (MEST)

OK, i nearly did an example, but I think i want more input from folks. I agree than PNDs need that Intro to PND page, but I'd go one step further and also create Intro to apps, which takes the existing apps section in toto, and is replaced by Apps come as PNDs, See these lists, Copy to the SD like this. That keeps the user guide as an absolute minimum, with no distractions about opkg and the nand filling up (which can then be better expanded on once there is a new page). Actually, the firmware section was badly out of date, so I used that as an example. --Tsh 20:24, 19 July 2010 (MEST)

Would it be ok to you to outsource e.g. Minimenu, XFCE? I'm not sure if this wouldn't interrupt the information flow :/ --ABC 17:08, 22 April 2011 (MEST)

I'm not sure. The whole "Basic use" section actually looks pretty concise to me as it is. But I DO think it might make sense to create separate articles for "minimenu" and "XFCE", so the wiki can provide more detailed info than can be provided inside another article such as this one. On the other hand, the "configuration and customization" section is pretty XFCE-specific. It might make sense to move ALL XFCE-specific and minimenu-specific stuff to their own articles. But then this wouldn't really be a "user manual" as such. So... I don't know.

Actually, it might make sense to describe some of the other options that are available now, or at least mention them. There's a list in software projects - scroll down to "operating systems". Esn 07:02, 23 April 2011 (MEST)

---

I recommend the article be split into several parts:

1. Overview, information. Features, safety, warranty.
2. Setup. Storage, recharging, initial bootup.
3. Usage. Basic software stuff - how to get to the software. A software list. From here there could be links to the various home pages for any software that's included. No documentation should be made for "how to use Firefox", etc. Just point people to that project.
4. Advanced. Hardware hacking, using an alternate OS, repairs, etc.

— spiralofhope / ^(talk) 19:49, 22 February 2012 (CET)

Dangerous unsourced battery charging information

Discharging batteries, putting them in the fridge etc.. is very old knowledge. This does not apply to new technologies. Suggesting this sort of thing is wrong unless we can get official statements talking about the battery technology and we can confirm from _proper_ sources that treating a battery in this manner is a good idea. "I read it somewhere" or "I've done this for years" are not good enough. Propagating crappy advice like that is akin to telling people to sleep with it under their pillows so the demons don't get at it. — spiralofhope / ^(talk) 20:12, 22 February 2012 (CET)

Heh heh... a bit of an extreme example but you make a good point. The information here should be stuff you can rely on, not hearsay. Cheese 05:05, 25 February 2012 (CET)

I'm going to work on this issue more seriously: [1] — spiralofhope / ^(talk) 23:40, 10 May 2012 (CEST)