Difference between revisions of "Talk:PC-BSD® Users Handbook/9.2"

From PC-BSD Wiki
Jump to: navigation, search
m (old signature- included for time reference)
(Concept: errata)
Line 115: Line 115:
--[[User:Tigersharke|Tigersharke]] 16:52, 20 April 2011 (PDT)
--[[User:Tigersharke|Tigersharke]] 16:52, 20 April 2011 (PDT)
An Errata section accessible from the main page and a link to it on this page has been added. This change well in advance of this note.
--[[User:Tigersharke|Tigersharke]] 16:05, 13 June 2012 (PDT)

Revision as of 15:05, 13 June 2012


Wiki for handbook

hi, any idea to break this page into smaller parts? like sub page? --Fanatix 04:05, 15 April 2009

I think that would be a good idea. Just haven't gotten to it yet. I did finish adding all the images today (4-17-09)

>> great, I will test later (2009-04-18)

>> *oops* I don't have any permission to create new page (2009-04-18)

please take a look @ http://wiki.pcbsd.org/index.php/PC-BSD_Users_Handbook#Supporting_PC-BSD

I've split it, if it's good enough, I will process the other page otherwise, I'll revert back

I have to say I don't care for the use of Wikis, especially for documentation. Can you tell who's writing what here for example? It's all well and good to have users adding to documentation but it needs to be controlled and run through the same kind of approval process as code. Not sure what sort of workflow/approval processes are available in Joomla, but in Drupal it's easy. I'd recommend ditching the wiki concept and implementing documentation as a normal revision process within the CMS. While I'm at it, I never understood the reason why mailing lists as a method of team communication still exist when forums are far superior. Most of the PCBSD community doesn't participate in the mailing lists, and that's where a lot of great information is. If they did participate, it would soon get completely out of hand and in-boxes would fill up with junk in short order.

As for this documentation wiki page, I didn't see anything get broken up. It's still a very long page that takes forever to load if you don't have bandwidth. You need to create separate URLs for each section. Blogs invariably suffer from this same problem, but this is not a blog. It's important to break into separate pages for other reasons as well: people need to make comments and ask questions (better done in a comment style, not a wiki) that are topic specific.

...Jeff (May 18, 2009)


TO: Jeff

FROM: [bebuxe | http://wiki.pcbsd.org/index.php/User:Bebuxe]


Well, when we talked about doing the handbook and the pcbsd advocacy group, we decided to let the users have the ability to edit pages and write on them. And if anything looked too horrible we would email the user for clarification. Supposedly Dru Lavigne is in charged of the wiki, and what to manage and not. Josh holds the technical aspects of the wiki (the server's admin). And we did converse about using a cathedral model for adding content to the handbook, and other things, but we choose to use a bazaar method for this in particular, because we knew there would be new subjects and contexts of stuff users may come up that we have no creativity about, we decide to allow them the ability to publish it and make it known here. So we felt wiki was the best suited for this kind of mega upload of multiple content into multiple streams. Plus, knowing most of our users do not know much about programming or markup languages, we choose wiki, since its basic enough like a text editor (esp. for those that don't use markup at all). I was the primary promoter of using drupal, even pbwiki or phpbb. But after much debate on the user's knowledge base, resources, and motivation level, it looked like mediawiki was the best solution. But don't worry if some day you find all the pages gone wrong by a cracker, and many edits to do, Dru and others are making backups of articles submitted and edited (plus mediawiki keeps history and backups of all its edits). Plus, let's say all the current wiki writers die tomorrow, new users can still have the ability to edit and make things as the new version comes along. And if the user would like to learn the media wiki markup, they can do it for the betterment of themselves and everyone else here. That's why we have admins here to make sure if the user write garbage, they can edit it to sound coherent and valuable. You can join the Mod group if you like as well, just email Dru, Josh, or whomever is in charged of documentation (forgot his name, unless he left).

PS If you didn't noticed, I just used the email format to reply to your questions. We can use this standard if you like, and make an en masse declaration to use this standard when talking about different subjects in the same discussion page with multiple subjects.


Can you explain the Runports concept a little better? For example, if I install a port/package, do I have to run it using Runports(user) or not? What's the diff? If I have to, or it's advisable to, run a program using Runports, then shouldn't the menu command reflect that? Maybe I'm not understanding the concept, but it seems to me it would have been preferable to make it so changing the PCBSD ports tree required Runports, rather than having to invoke it as a normal FreeBSD user.


SUBJECT: RE: Runports

TO: Jeff

FROM: [bebuxe | http://wiki.pcbsd.org/index.php/User:Bebuxe]


Well, that info is old and messy, and no longer pertains to most of the actions done in 8.0. I am sure someone else can answer that you with detail and its purpose at the time. But for right now, I best advice you to read the freebsd handbook and the theoretics (sp) of [ports | http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html]. What I got when I first read it that article, is that you also had the ability to run ports from the kmenu. And that if you wanted users to be able to run ports from the kmenu (kicker in kde), you can do so, but don't have to. An example would be if you want your guest users to be able to run the firefox port, so they would type in in the kmenu "firefox", and they would have it. But let's say you also have gnumeric from ports, and you want that only linked to your user account in kmenu, then you would set it up as such, and ensure that other users wouldn't be able use it in their settings for their access to kmenu. However, let's say you wanted to install an awesome daemon that fetches videos from youtube into your /usr/home/jeff/video/dump directory, renders it to a .mp4 file, emails you of the update, and starts making a backup of the mp4 to your portable player. Well for a daemon like that you really don't want run it the kmenu, but in the background as soon as it boots, but something like md5checksum you might want to run under Runports for your mp4. So I guess its a desktop configuration setting you decide.


Suggested addition

I would suggest adding a humble moderation to this statement: Hardware such as video, sound, network and other devices are auto-detected and available at the first system startup.

add: If recognized and a driver is available which in many instances isn't. Without a driver your device will not work.

Screenshot standard / default settings

Many of us have modified (possibly rather heavily) the appearance of application windows and/or desktop. It would be very helpful to know the values for the various specific appearance-affecting settings so that whatever we might update for screen shots stays consistent.

--Tigersharke 02:02, 7 December 2010 (UTC)

SUBJECT: RE: Default Desktop

TO: Tigersharke

FROM: [bebuxe | http://wiki.pcbsd.org/index.php/User:Bebuxe]


Oh, like having set a standard for screen printouts for the average user to be able to cross reference on their desktop because it has the same appearance. That sound like a good idea to implement. I think in KDE we have set up a default theme, and when you want to make a a tutorial, you can change it as such. But to actually implement the standard of all the features and write them down to the smallest detail so that other users can replicate it if something went wrong with "default theme" .... mmmm.... quite a task.... I am not going to do it now, but any else is welcome. even replying to you or everyone here. but sounds good.

Hehehe, I knew there were going to be a lot of standards to implement for the wiki and the handbook, but its going to be lots of fun. I already said in the translation page we should also start implementing a standard on keynotes or ques for the users (like mods) to review and the like. For example, when a the rest of a topic in an article is not finished, but its not obvious to the user at the first glance, the text, "[WIP]," can be placed, which note its is a "Work In Progress." Another one I thought up recently was [R], which stands for review, implying for someone else to read or test what is described and confirm it. It can be confirmed in the discussion page of the article, and stamped by the user with comments if needed. Then the user or the reviewer can do the edit with his summary. I know there will be more conventions to come, but for know we should first consider the making a of manual in here that delineates all the schemes and conventions we will be using. Even a writing guide with lots of example (there may be one already in the making as i typed this, it s just i haven't checked).

But great suggestion. Someone here may answer that. (we may need a way to synchronize most of this info and updates in some sort of wiki page or rss sheet. I also don't mind the mailing list. Which reminds me... am I on the mailing list for documentation?


I like the idea of having something of a summary of defaults, whether it is for the "default theme" or for the system in general. It is easy to get into the engine of the system and tweak a few too many things, then not know exactly why something stops working. Along the same lines would be some method of resetting the whole system without having to re-install, assuming this could be done or would be the easier or quicker way.

Another way that could work to use the defaults for a screenshot would be from a vanilla installation of PC-BSD inside of Virtual Box- but only for those features that are not colored/affected by it. This is not a perfect solution, since it would require additional space and at best the VirtualBox pbi (I tend to use ports).

--Tigersharke 20:09, 17 December 2010 (PST)

Alternative formats

We provide a PDF on the desktop (somewhat strangely marked untrusted) but here is a thought: ePub format for eReaders (Kindle, Nook, etc). I can see how the concept may step on toes, but the handbook is a self-published community effort. There may be other conversion software, but a function at a new Xerox site sparked this thought. This might be useful to someone, perhaps not in addition to the PDF on the desktop but a download option from the wiki somehow.

--Tigersharke 18:00, 24 February 2011 (PST)

Concept: errata

Since the 8.2 handbook has been frozen, we cannot directly edit it any longer. However, there may be various changes or added information pertinent to 8.2, that either has no place in the 9.0 handbook or would cause undue confusion by directing 8.2 users there. So, I propose a new section, Errata, which would help to fill the need. This is not to say that mailing lists or forums or google would not also be solutions, but an Errata section here would perhaps be a more "authoritative" source.

--Tigersharke 16:52, 20 April 2011 (PDT)

An Errata section accessible from the main page and a link to it on this page has been added. This change well in advance of this note.

--Tigersharke 16:05, 13 June 2012 (PDT)

Personal tools