Talk:PC-BSD® Users Handbook
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 @ 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)
SUBJECT: RE: Handbook CMS
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 there would be new subjects and contexts of stuff users may come up that we have no creativity about, and be able to publish it and known here. So we felt wiki was the best suited for this kind of mega upload of multiple content of multiple streams. Plus, knowing must of our users do not much about programming or markup languages, we choose wiki, since its basic enough like a text editor (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, lets say we 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 to the better 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 cohersive 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 one ifyou 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
FROM: [bebuxe | http://wiki.pcbsd.org/index.php/User: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 | http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html]. From What I got when I first read that esp. 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, the you would set 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 something like md5 you miht want to run under Runports for your mp4. So I guess its a desktop configuration setting you decide.
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)