Slashdot Mirror

For me, KB is not really a pure category. More of a hybrid that fits somewhere
between/within a ContentMgmtSys and a DocMgmtSys

You mention mediawiki, which I feel is quite impressive, as a collaborative CMS.
If mediawiki is overly-complex then maybe a different one would work better:
http://twiki.org/
http://www.splitbrain.org/projects/dokuwiki
http://moinmo.in/
http://www.pmwiki.org/

OTOH, if yo mean a KB that is concerned about DocMgmt, then you probably know that
many Document Managements Systems, though ofter synonomous with a "Knowledge Base Systems" (KBS), but probably contain better features related to lifecycle management for documents,
  publication workflow and access rights management.
http://www.alfresco.com/
http://www.knowledgetree.com/
http://www.epiware.com/
http://www.jaspersoft.com/
http://www.jivesoftware.com/clearspace/
is not free for use, but I've deployed it and can say 1st hand its worth mentioning;
you can download a free 30-day trial for evaluation.

I think a wiki sounds like what you need instead of a "database", if you're using it for personal reference and not hooking it to a web server or any kind of client application, you don't really need a database.

For a wiki "engine" that will run locally on a PC try googling for "wiki on a stick". I'd recommend DokuWiki on a Stick, as DokuWiki uses flat files for storage. You can keep it locally on a PC, or as you may have guessed you can run it from a USB thumb drive on any computer. There are other wikis that run in this fashion as well, some cross platform.

One problem with documentation is the upkeep because things change
frequently. If the process of updating the dox were simple and easy,
more people would do it. We use dokuwiki because it is pretty simple
and easy to use. When I show a junior admin how to do something on
the terminal, I can past the terminal session into a dokuwiki[0] page
and it's there for reference next time. I know it's working because
now when the juniors call me it's because they don't understand something
in the dox, not where to find the dox. If you have a gui app you need
to demo, hook up vnc2swf[1] and post the flash file as a link in dokuwiki.

[0] - http://wiki.splitbrain.org/wiki:dokuwiki
[1] - http://www.unixuser.org/~euske/vnc2swf/

We have SharePoint 2003 - in document terms it's mainly document storage (.doc .xls etc), it's a poor CMS, and has poor doc management built in.
It wins because of the high integration with the office system.
MOSS 2007 should improve on many areas that 2003 was lacking - including some Wiki abilities - but I have no exp. with that.
If you're looking for similar office integration with OpenOffice take a look at: http://www.o3spaces.com/ - I have not tried this in production - but looks promising.

We also have dokuWiki as a separate service:
http://wiki.splitbrain.org/wiki:dokuwiki

Pluses: fast, easy to use and user friendly, permission management through the web(!!), integration to Windows Active directory (with multiple sub domains)
Minuses: ? flat file storage?. This is really a point of view thing. My first aim was DB storage only - but dokuwiki surprised on other ends so we took it. I don't see real performance issues because of file storage, but you lack some features you'd get if you were running a DB...

If you're looking into commercial Wiki - I was also impressed by Confluence - which would probably be my choice if I had to spend money on a Wiki today.
http://www.atlassian.com/software/confluence/

Hope this helps...
Dan

• Start with only one area of the business and get it done well. News will spread and everyone will want to be on board.
• Only deal with one individual from each part of the business. This centralises control and keeps some focus. If it's small and that means you then all the better.
• Certainly do not keep information on the wiki that is likely to go out of date any time soon. Wiki's are best at creating lots of relatively static documents that can be easily corrected and added to. You don't want to be changing minute critical details on the same pages constantly, such as keeping contacts, products, or business transactions. That is crazy! That's what business databases are for and they're far superior for many obvious reasons.
• Look to similar on-line wikis for structural concepts. Wikipedia, Wikibooks are good starting points. Link to the "empty" documents you want to create later as part of the early structural creation process.
• Avoid utilising extraordinarily special wiki features too often as they often become cumbersome to maintain and will scare away many novice users at which the page may be aimed.
• Be sure and test the wiki features out with several browsers!
• Add the documents that are immediately usable first; don't just add them for the sake of completion. This will save you time and increase the return on time invested.

Look, if you're a Vim or Emacs wizard, this app probably isn't going to do much for you that those editors don't do. Except, perhaps, rendering Markdown and a variety of wiki markups (works very nicely with DokuWiki for one.) If you're coming from Homesite or Joe, like, oh, say ... me, this editor gets you nearly to the power of Vim/Emacs in a much shorter timeline.

I think the best way to see what its capable of is to watch Macromate's screencasts. For me, the columnar editing (and I found a somewhat flakey bundle that lets you mark several points in the buffer to insert the text you're typing simultaneously) has made a lot of my common HTML editing tasks way less painful.

sanity.pl

http://www.splitbrain.org/projects/sanity

Also,

http://filerenameutils.sourceforge.net/

http://sourceforge.net/projects/miscutils/

I switched from pine to CONE a long time ago. It looks nearly like Pine, but has integrated GPG support and works fine with IMAP folders.

See http://www.courier-mta.org/cone/cone00index.html for the website and http://wiki.splitbrain.org/cone for some info on compiling it.

It's not a blog service/package per se (although there are some blogging-type plugins for it) but I find DokuWiki to be excellent at handling code snippets with decent syntax highlighting, and easy to use.

An example bit of code can be done as easily as:

<code perl>
# some code here
</code>

There are already plenty of free Linux distributions that work OK. RedHat has two things going for it that keep everyone I know with licenses buying them.

The web-based management tools that are available as part of the RedHat network are pretty good. You can inventory all your machines, see who hasn't been keeping their systems patched (and push updates to them if you want), find out exactly what hardware is in the system, all sorts of useful things right from the admin web interface. I've even used it to lookup the Dell service tag for a system. One place I worked with found it worth buying the RedHat subscription just because of how much these features reduced their Linux TCO by letting administrators manage more machines efficiently.

The second thing is the more important one. RedHat puts a lot of work into keeping their Enterprise products stable for a long time period. That's one of the reasons so many application vendors have standardized on them: they don't have to worry about totally uncontrolled package upgrades.

An example will illustrate what I'm talking about here. Some months ago, I was doing work on a RHEL machine that involved installing some PHP software. When reading through the requirements, I discovered there was a security exploit in the version of PHP installed on that system (php-4.3.9), and got a bit paranoid about it. Upon checking further, I discovered that RedHat had backported the security fixes into the older version of PHP they ship with the system, and the exploit I was concerned about was in fact closed. Most vendors in this situation would have just upgraded everyone to php-4.3.10 because backporting takes considerable resources to do, leaving the customers exposed to whatever functional differences there are between 4.3.9 and 4.3.10.

It's fine for my PCs, but when I'm in a situation where I'm supporting lots of machines, the thought of users being to get a whole new set of packages with who knows what changes just by running some variant on apt-get gives me the willies. RedHat's pace is just fast enough to stay useful in a corporate environment, while going out of their way not to upgrade any more than is necessary. I'm curious how the Ubuntu server plays out in this situation; the desktop version is clearly far too quick in its pace of upgrades for any of the RedHat customers I deal with to be comfortable with it.

If you need to decide which Wiki you want to use this site may be of help: http://www.wikimatrix.org/

It allows you to compare the features of over 50 Wiki Engines. My personal favourite is of course DokuWiki http://wiki.splitbrain.org/wiki:dokuwiki but your mileage may vary.

I was thinking the same, however, this would probably rather impractical for uploading videos. Also I've noticed the method for linking to files is somewhat confusing. I'm not sure if thats necessarily the best option.

But if a wiki were used, here's some info:

MediaWiki would be a good one, however it uses databases. Dokuwiki can be used to upload files of all sorts. It isnt very helpful in terms of creating a gallery of pictures however.

Here is a comparison of wikis: Wiki Comparison Table

A photogallery would be a nice wiki plugin to have ;-)

Seconded - & the database design running it all is dodgy too ( and barely documented last time I looked at it ).

A far superior wiki is DokuWiki

We use dokuwiki here (http://wiki.splitbrain.org/)

Although it might not be as featureful as MediaWiki, which imho is a behemoth, it has one key advantage: it Stores your pages in plaintext files, so that if you lose your webserver, php, whatever, you have still access to your stored info. very useful if you're a company that has to worry about DRP

It's also a breeze to setup and customize. MediaWiki seems to require a ponytail, pizzastained t-shirt and sandals.

Dokuwiki includes code markup elements with syntax highlighting. I use it to document Oracle packages, procedure and functions on the code part plus process documentation, etc. I highly recommend it.

just trash all those complicated CMSes.

Just use Dokuwiki ! http://wiki.splitbrain.org/wiki:dokuwiki

Heck we even use it for our corporate site !

Why take notes on a keyboard?
- handwriting 25 wpm, borderline legibility, cannot edit/restructure/search
- typing 70-80 wpm, completely legible, can edit/restructure/search

And if you ask why does one need 70-80 wpm, you've never tried to keep up with Dr W's immunology lectures! I do admit to taking more selective notes by hand, simply because it's slower. But if I have to capture a high rate of information-flow, keyboard is best.

Keyboard is frequently a Treo600 with PalmOne keyboard. I can then email notes to myself or to my Backpack page http://www.backpackit.com/ for immediate backup.

I also use an internal Wiki, for keeping ongoing expanding notes. Current favorite is DokuWiki http://wiki.splitbrain.org/wiki:dokuwiki: installation's elementary, and it stores info as readable flatfiles.

Re pen and paper: After years of recording on 3-ring paper, reshuffling, refiling and losing, I got religion and now make a point of (almost) never writing anything that I mean to keep on a single piece of paper. It all goes into notebooks, tens of notebooks. BTW, check the permanence of the ink, if there's any chance you'll want them longterm. I recently retrieved some old letters and notes from my parents' basement. The turquoise ink I so loved back then? - It was faded almost to unreadability.

All my development right now is on a Windows box. What's the best way to go about ensuring Linux/POSIX compatibility over the web? Compile farms? Recruiting a Linux maintainer?

If I don't have access to my own server, where is the best place to host? Sourceforge (the only one I really know about) or somewhere else?

Somebody's submitted a patch. What's the protocol for crediting them for the work?

What are the criteria for determining whether or not something is "pre-alpha", "alpha", "beta", etc. Is there a set standard, or do I get to determine this on my own?

How useful are wikis for OS projects?

If I have legal questions regarding licenses or IP, who should I talk to?

Sing it brother! I am daily poked in the eye by Notus Lotes clumsy and slow interface that takes a bafflingly long time to draw (baffling b/c as such an old app written on much slower hardware, the UI should be blazingly fast on a 2.4 Ghz machine). As of 6.x, they still don't have a decent scroll widget!

The teamrooms (the content management component) are all but unusuable--impossible to usefully search (and why doesn't it search the content of attached documents? My team only writes a scant subject and dumps in some word file as an attachment), and clumsy at best for managing recent changes. I also hate the "widgetized" Notes docs, with the tabs and buttons and other such rubbish; it's not that I'm opposed to widgets, it's that the content is not the star in the Notes pageant, Notes is.

I own stock in IBM and I can't wait until they pull plug on this gross abuse of computering resources!

(plug for my favorite wiki: DokuWiki . Elegant interface, trivial to setup and use.)

Try it - http://www.splitbrain.org/dokuwiki/wiki:dokuwiki

There are a few similar projects out there as well that I've been tracking.

• Myth TV has a music mode AND does live tv functionality! (I will probably migrate to this instead of continuing my project).
• Dave/Dina project may fit the bill too.
• IR File Chooser for the perl hackers. :)