Talk:PC-BSD® Users Handbook/9.2

From PC-BSD Wiki
Jump to: navigation, search

hi, any idea to break this page into smaller parts? like sub page?

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 @

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


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


Well, that info is old and messy, and no longer partakes 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 |]. 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 (kliker, whatever its called 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 recognised and a driver is available which in many instances isn't. Without a driver your device will not work.

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


Oh, like having set a standard for screen printouts for the average user to be able to cross reference on their desktop baceuse it has the same appereance. 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 toturial, 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 stadard 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 areticle 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(sp) 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 summar. I know there will be more conventions to come, but for know we should first consider the making a of manual in here that deliniates 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 must 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?


Personal tools