Charlas 11-12-2000 Umeet'2000

Charlas 11/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia

[19:10] (Fernand0> Hello,
[19:10] (Fernand0> we are very pleased to present you today Nik Clayton. He is the European
[19:10] (Fernand0> Marketing Manager of BSDI (http://www.bsdi.com/ visit them :) ).
[19:10] (Fernand0> He is an expert on the FreeBSD operating system and he has been the FreeBSD
[19:11] (Fernand0> Documentation Project Manager for the past three years.
[19:11] (asmodai> MJesus : near Rotterdam.
[19:11] (Fernand0> His talk will be about: "The FreeBSD documentation project".
[19:11] (Fernand0> Thank you to the speaker and to all of you for comming here.
[19:12] (Fernand0> Nik ...
[19:12] (nik> Thank you Fernand0
[19:12] (nik> Perhaps "expert" is stating the case a bit too strongly.
[19:12] (nik> Anyway, as Fernand0 said, I've been involved with the FreeBSD project for the past 6 years.
[19:13] (nik> And the Documentation Project for the past three or four, with about two years spent as the documentation project manager.
[19:13] (nik> Documentation is often the forgotten or neglected part of many open source projects, which is unfortunate, as it poses a number of interesting challenges in its own right.
[19:13] (nik> Over the next 45 minutes or so, I plan on covering a few of the areas that the FreeBSD project has had to tackle,
[19:14] (nik> and I hope that those of you who are working on documentation for other projects (and, of course, FreeBSD) can learn
[19:14] (asmodai> [sorry nik, dinner, g'luck]
[19:14] (nik> from some of our mistakes, and avoid reinventing the wheel.
[19:14] (nik> The FreeBSD Documentation Project (or FDP, to save me all the typing) is responsible for most of the FreeBSD documentation.
[19:15] (nik> Specifically, the FreeBSD FAQ, the Handbook, and the tutorials.
[19:15] (nik> These are all kept in a doc/ source tree, separate from the FreeBSD src/ tree.
[19:15] (nik> The FDP also looks after most of the FreeBSD manual pages. However, many of the other FreeBSD committers also write man pages and help tidy them up.
[19:15] (nik> The exception is the translations of the manual pages. Those are kept in the doc/ directory.
[19:16] (nik> Currently, documentation is available in 8 different languages. The primary language is English, because most of the committers and users speak English as a first or second language.
[19:16] (nik> Japanese is the next most translated language (FreeBSD is very big in Japan)
[19:16] (nik> The other language translation efforts are at various stages. For example, the Spanish FAQ is pretty complete, and the Spanish Handbook is coming along nicely as well.
[19:16] (nik> We keep all the documentation in a CVS repository (as is everything else to do with FreeBSD).
[19:17] (nik> One of the reasons for keeping the doc/ and src/ trees separate is because we branch the src/ tree for new major releases of FreeBSD, but we don't branch the doc/ tree.
[19:17] (nik> That's mainly because we have enough problem getting people to write and maintain docs in the first place. Getting them to maintain docs on different branches would be even more difficult :-)
[19:17] (nik> There are a number of issues that we've had over the past few years in managing the project, which I'm now going to cut and paste from my prepared text :-)
[19:18] (nik> 1. How do you make documentation available in a number of different
[19:18] (nik> formats (such as HTML, Postscript, PDF, plain text) without
[19:18] (nik> needing to write separate documents.
[19:18] (nik> 2. How do you handle versions in your documentation? Not just
[19:19] (nik> different versions of the same document, but documentation that
[19:19] (nik> has to describe different versions of the same program.
[19:19] (nik> 3. How do you make it easy for people to translate your
[19:19] (nik> documentation in to other languages?
[19:20] (nik> 4. How do you make it easy for other people to contribute to your
[19:20] (nik> documentation?
[19:20] (nik> 5. How do keep the application and the documentation in sync?
[19:20] (nik> 6. How do you encourage volunteers to produce readable
[19:21] (nik> documentation?
[19:21] (nik> Points 4, 5, and 6 are closely linked. It's hard to encourage volunteers to produce documentation if it's difficult for them to do so.
[19:21] (nik> And it's difficult to maintain documentation if it's hard to do so.
[19:22] (nik> Coding on open source projects is quite a "sexy" thing to do. Finding people who enjoy writing documentation is rare.
[19:22] (nik> Hang on to these people :-)
[19:22] (nik> I'll come back to 4, 5, and 6 later.
[19:23] (nik> Points 1, 2, 3 are more "policy" questions, so they're much easier to answer. That's why I put them first.
[19:23] (nik> To tackle (1) first. You might be wondering why documentation needs to be available in so many formats. Surely HTML is enough?
[19:23] (nik> As our mailing list experience shows, that's not generally the case.
[19:24] (nik> People like to be able to print out documentation in a 'pretty format'.
[19:24] (nik> And you have to try and cater for the lowest common demoninator as well. One of the benefits of systems like FreeBSD (or Linux)
[19:24] (nik> is that it runs on, and uses old hardware very well.
[19:24] (nik> This can include old dot matrix printers, or glass ttys, and things like that.
[19:25] (nik> And believe it or not, we had requests from people on the mailing lists who wanted to be able to view the docs on Windows.
[19:25] (nik> Preferably by loading it in to Word, or another Windows word processor, and reading it there.
[19:25] (nik> Bizarre.
[19:25] (nik> Anyway, this meant that we needed a format for documentation that was flexible, and could be converted to multiple formats.
[19:26] (nik> As with most things in life, this has had to be a trade off between competing goals.
[19:26] (nik> The more flexible you make a system, the harder it is to learn for new contributors. The easier to is to use (generally) the less flexible it is.
[19:26] (nik> For a while, we used the LinuxDoc format, pioneered by the Linux Documentation Project.
[19:27] (nik> LinuxDoc had problems.
[19:27] (nik> In particular, it didn't separate the document's structure from it's presentation.
[19:27] (nik> This makes it hard to produce intelligent searches of the document.
[19:27] (nik> It's not really possible to express a search like "Show me every occurence of '/etc/rc.conf' when it's being used in an example"
[19:28] (nik> when your document is written in LinuxDoc.
[19:28] (nik> So, after some hunting, we settled on the DocBook format.
[19:28] (nik> There's lots of information about DocBook at http://www.docbook.org/, and at http://www.freebsd.org/tutorials/docproj-primer/, so I'm not going to go into great detail abot it now.
[19:28] (nik> s/abot/about/
[19:29] (nik> But (very) briefly, DocBook is a markup language, like HTML and LinuxDoc, but it concentrates on describing the meaning of your text, rather than the appearence.
[19:29] (nik> So a DocBook command line example might look like this:
[19:29] (nik> (screen>(prompt>#(/prompt> (userinput>cd / ; rm -rf *(/userinput>(/screen>
[19:30] (nik> (Don't try that at home kids)
[19:30] (nik> So my earlier search question could be phrased as "Show me every occurence of '/etc/rc.conf' when it's inside (userinput>".
[19:30] (nik> Of course, the problem with this is that, unless you like torturing yourself, reading DocBook for information is difficult.
[19:31] (nik> You want to be able to convert it to other formats, like HTML, or Postscript, or RTF, or plain text, or whatever.
[19:31] (nik> DocBook doesn't have any formatting information in it, so you need a stylesheet that explains how to convert the DocBook source in to formatted output.
[19:31] (nik> The stylesheets the FreeBSD project uses are written in a language called DSSSL, which is very Scheme-like.
[19:31] (nik> I hate DSSSL. With a passion. All the '(((' and ')))' confuse me. Thank God for Emacs :-)
[19:32] (nik> However, there exist a few open source formatting programs that can take a DocBook document and a DSSSL stylesheet and produce .html, .tex, and .rtf.
[19:32] (nik> Once you've got .html, you can get .txt by using something like "lynx -dump", or my favourite text only web browser, w3m.
[19:32] (nik> Once you've got .tex you can get Postscript and PDF (and DVI) using a TeX distribution.
[19:33] (nik> [ .html also lets you convert it to the Palm Pilot, which is really cool ]
[19:33] (nik> Once you've got .rtf, . . . well, you can load it in to Word.
[19:33] (nik> So DocBook + DSSSL + A converter lets you produce formatted output.
[19:34] (nik> Of course, the cost of this is quite high. DocBook is a very 'rich' language. (filename>, (screen>, (prompt>, (example>, (title>, (userinput>, ...
[19:34] (nik> There are about 300 or so elements in DocBook. I guess the average HTML author only uses 15 to 20 HTML tags.
[19:34] (nik> Until recently there weren't any good DocBook references. So we had to write one (that's the http://www.freebsd.org/tutorials/docproj-primer/ link from earlier).
[19:35] (nik> Now there's a good DocBook reference at http://www.docbook.org/, but it's still a lot to take in.
[19:35] (nik> In retrospect I think DocBook was a good choice. And as we converted our documentation from LinuxDoc to DocBook it became easier for others to help out because they had more examples to look at
[19:35] (nik> I've discovered that people don't like reading documentation. They'd much prefer to be able to look at examples.
[19:36] (nik> So I've tried to make sure that the FreeBSD documentation also sets a good example.
[19:36] (nik> The actual commands that are used to convert the documentation from one format to another can be quite complex.
[19:37] (nik> Some Linux distros have produced shell scripts that try and do this for you.
[19:37] (nik> That's OK.
[19:37] (nik> On the FDP, all the documentation is built using make(1).
[19:37] (nik> So we have Makefiles that contain the logic.
[19:38] (nik> The current .mk file that we use is at
[19:38] (nik> http://www.freebsd.org/cgi/cvsweb.cgi/doc/share/mk/doc.docbook.mk?rev=1.25&content-type=text/x-cvsweb-markup
[19:38] (nik> Of course, because we use CVS, you can see how that file has evolved. Some of the earlier versions are certainly much simpler :-)
[19:39] (nik> Versioning documentation is still a problem for us, and I'm still working on a solution.
[19:39] (nik> I don't mean "Am I looking at r1.38 of the FAQ, or 1.39?"
[19:39] (nik> I mean how do you include information in one document that might apply to different versions of the software you're documenting?
[19:40] (nik> For example, in FreeBSD, the system configuration mechanism changed quite a lot in 2.x, 3.x, and 4.x. But we really only want one FAQ, not one FAQ per version.
[19:40] (nik> In particular, some users really only want to see answers that apply to FreeBSD 4.x (or, to use another example, GNOME 1.x, or KDE 1.x).
[19:40] (nik> As the author, how do you do this?
[19:41] (nik> I'm still experimenting. At the moment, I'm looking at writing things like
[19:41] (nik> (para osversionmin="FreeBSD 4.0">...(/para>
[19:41] (nik> and then when the documentation is converted to another format (such as HTML) one of the options in the conversion will mean "Strip out all the content that doesn't apply to FreeBSD 4.0 and above"
[19:42] (nik> So you'll be able to produce a FreeBSD 4.0 specific FAQ (which would be smaller, and contain more relevent information) instead of the general FAQ.
[19:42] (nik> You'd also have (para osversionmax="FreeBSD 3.2"> to say that this only applied to FreeBSD 3.2 and below.
[19:42] (nik> And my personal favourite
[19:43] (nik> (para osversionin="FreeBSD 2.1, FreeBSD 3.2, FreeBSD 4.1"> for the documentation that only applied to 2.1, 3.2, 4.1 (I'm still trying to think of an example for that one :-) )
[19:43] (nik> None of the open source documentation projects have really solved this problem in a way that's easy for readers and authors to use.
[19:43] (nik> I guess translating documentation from English to Spanish is a hot topic for people here.
[19:44] (nik> I should mention Jesus Rodriguez at this point (jesusr@freebsd.org, and jesusr in this channel) who has been singlehandedly responsible for most of the Spanish translations of the FreeBSD documentation. * nik applauds jesusr
[19:44] plas plas plas plas plas plas plas plas plas plas
[19:44] plas plas plas plas plas plas plas plas plas plas
[19:45] plas plas plas plas plas plas plas plas plas plas
[19:45] (nik> I owe him several drinks :-)
[19:45] * asmodai pat pat jesusr
[19:46] (nik> Making things easy for translators is really a mixture of policy and tools.
[19:46] (nik> For example, part of the FreeBSD policy when writing documentation is to not use contractions ("didn't", "it's", "they're", etc).
[19:47] (nik> "it's" ? What's that doing in that list. Forgot I wrote that.
[19:47] (nik> Anyway, "did not", "they are", and others is, we've found, easier for translators (particularly translators who don't know as much English) to understand.
[19:48] (nik> It also sounds a little more formal.
[19:48] (nik> We have also tried to avoid using colloquiasms and idioms in the documentation, to try and make it easier for translators.
[19:49] (nik> Rules like these are in the docproj-primer document.
[19:49] (nik> That's policy.
[19:49] (nik> For tools, we try and enforce good use of the tools.
[19:50] (nik> For example, as I've said, we keep the documentation in a CVS repository.
[19:50] (nik> Changes to the documentation are committed to the repository.
[19:50] (nik> It is forbidden (well, strongly frowned upon) for anyone to change the text of a document, and it's formatting, in the same commit.
[19:51] (nik> This is so that translators can use tools like "cvs diff" and easily see just the text that's changed.
[19:51] (nik> For example. If I had a paragraph that looked like this:
[19:52] (nik> (para>This is the first sentance. This
[19:52] (nik> is the second sentance. This is the third
[19:52] (nik> sentance. This is the fourth sentance.(/para>
[19:53] (nik> And then I wanted to add a new second sentance, I would do something like this:
[19:53] (nik> (para>This is the first sentance. This is the new second sentance. This
[19:54] (nik> is the old second sentance. This is the thid
[19:54] (nik> sentance. This is the fourth sentance.(/para>
[19:55] (nik> And then I'd commit that. Then, I'd change it, so it looked like this.
[19:55] (nik> (para>This is the first sentance. This
[19:56] (nik> is the new second sentance. This is
[19:56] (nik> the old second sentance. This is the
[19:56] (nik> third sentance. This is the fourth
[19:56] (nik> sentance.(/para>
[19:57] (nik> I hope that was clear in with all the channel messages.
[19:57] (asmodai> [Of course nik meant sentence instead of sentance. :) ]
[19:58] * nik smacks asmodai. I always make that mistake.
[19:58] (nik> :-)
[19:58] (Ricardo> :))
[19:58] ¶:Þ
[19:59] (nik> By keeping the formatting and content changes separate, it's easier for translators to see what's changed, and so cuts down on the amount of text they need to translate each time.
[20:00] (nik> There are other tools as well, such as wdiff, which does a diff on a word by word basis, rather than a line by line basis, which also helps.
[20:01] (asmodai> [sidenote: And that's where the documentation mailinglist comes in. A lot of these spelling mistakes sometimes confuse our translators, and the list will sort this out.]
[20:02] (asmodai> [back to lurk]
[20:03] (nik> I've yet to see a tool that really makes it easy for translators (or at least an open source one), so this has to do for the time being.
[20:04] (nik> As I understand it, the gentleman that did a lot of the Japanese translation a few years back was blind. He had his version of Emacs *speak* the diff to him (in English) which he then translated, and he then translated it, and spoke the translation back in to another buffer.
[20:04] (nik> The amount of effort that people will put in to free software projects always astonishes me.
[20:05] (nik> I'm sure that in the Q&R session in 20 minutes time or so, jesusr will be able to talk a little bit about what it's been like translating the FreeBSD docs.
[20:05] (nik> Point 4 of my original list was "How do you make it easy for other people to contribute to your documentation?"
[20:06] (nik> As I said, the choice of DocBook, and the toolchain that we use to convert DocBook to HTML and other formats can make this difficult.
[20:06] (nik> It's true that DocBook has a bigger learning curve than HTML, and the various applications that you need to install and configure can be complex.
[20:07] (nik> We've tried to address this in a number of ways.
[20:07] (nik> Firstly, all the software that's required to write FreeBSD documentation (or any documentation using the same toolchain) is available in the FreeBSD ports tree.
[20:08] (nik> Further, we have a 'meta-port', that just contains dependencies on all the individual components. So that instead of having to download half a dozen ports, the user can do
[20:08] (fireman> oi;)
[20:09] (nik> # cd /usr/ports/textproc/docproj
[20:09] (nik> # make install
[20:09] (nik> and the FreeBSD ports system will download and install everything you need. There are similar meta-packages for Linux (I believe). I understand Debian is probably the best Linux system in this respect.
[20:10] (nik> Actually, my example above is not quite right.
[20:10] (nik> In order to produce PS and PDF output, you need to install teTeX. teTeX is huge (22MB, or something like that), and it takes ages
[20:10] (nik> to build
[20:11] (nik> So the command line above will download all the tools necessary to build the HTML, plain text, and RTF formats. There's a special command line option the user can use if they really want teTeX as well.
[20:11] (nik> We also have to make it easy for people to download the 'source code' for the documentation.
[20:12] (nik> Because it's in CVS, we can use all the FreeBSD CVS download tools (including things like CVSup) to make it easy for authors and editors to download the documentation source.
[20:12] (nik> Once they do that, the additional infrastructure that we've written (over and above the documentation itself), means that someone can then do
[20:13] (Fernand0> wholeft
[20:13] (nik> % mkdir docs
[20:13] (nik> % cd docs
[20:14] (nik> % cvs -d /path/to/repo checkout doc
[20:14] (nik> % cd doc/es_ES.ISO_8859-1/books/faq
[20:14] (nik> % make FORMATS=html-split
[20:15] (nik> We use completely standard infrastructure stuff, like Makefiles, to automate the process. There are no new command line tools the author needs to learn.
[20:15] (nik> Of course, *the* key component in all this is making sure that the process is documented, and new authors have a document they can read that explains all this.
[20:16] (nik> That's what the FDP Primer is for (the docproj-primer link from earlier).
[20:16] (nik> When I started writing it, that was originally going to be 2 or 3 pages long.
[20:16] (nik> It's now over 80 pages :-(
[20:17] (nik> But we've tried to structure it so that the information an author has to know is clearly marked, and available, and they can 'dip in' to the other information as necessary.
[20:17] (nik> I'm trying to make sure that projects like the LDP, KDE, GNOME, and others, are aware that the FDP Primer exists, and that they can feel free to take information from it and use it in their own primers.
[20:18] (nik> It would be great if we had a more general "Free software documentation project starter kit", with appendices that described how the FDP, or LDP, or KDE doc. projects work.
[20:18] (nik> But there's this ( many things to do.
[20:18] (nik> And there's this ( much time :-(
[20:19] (nik> So we try and make things as easy as possible. And we can probably do more.
[20:19] (nik> Keeping the application and documentation in sync is always tricky, particularly if the person (or people) writing the application (or OS) aren't the same people writing the documentation.
[20:20] (nik> Sometimes, we try and shame the developers.
[20:20] (nik> "Yes, that's a really cool piece of code you've written, but nobody knows how to use it, so please write some documentation".
[20:20] (nik> Some people have taken it upon themselves to learn how new bits of code work, and then document them.
[20:21] (nik> When it comes down to it, I think it's to do with pride. Engineers like to take pride in their work, and documentation is part of that work.
[20:21] (nik> Sometimes you just have to kick them hard enough :-)
[20:22] (nik> Encouraging volunteers is often tricky.
[20:22] * Ricardo stated it triyng to use pipsecd :)
[20:22] (asmodai> [which is why src/doc people are valuable]
[20:23] (nik> Sometimes you get people like jesusr, who just volunteer, and then they go and do it. Which is absolutely fantastic.
[20:23] (nik> Or people like asmodai for that matter (there are probably a dozen other people in the doc. proj. like that).
[20:24] (asmodai> [What did I do? :) ]
[20:24] (nik> As a volunteer project we don't have a lot we can use to encourage people.
[20:25] (nik> Probably the best thing to 'incentivise' (sorry I've no idea how well that will translate) people is to dangle a commit bit in front of them.
[20:25] (nik> People seem to like having @freebsd.org e-mail addresses, and that can be enough of an incentive to encourage people.
[20:25] (asmodai> nik: To rally people? To make them enthusiatic?
[20:26] (nik> I haven't really covered the website yet, but that's also the responsibility of the doc. project. We recently started a project called the "Conspectus" (it means "I look at attentively" in Latin) which is like the Linux Kernel Traffic project.
[20:26] (nik> To encourage people to contribute I said "Anyone who can produce three summaries of a list in a row, with no errors, will become a committer".
[20:27] (nik> We've got one new committer that way so far (and she'd FreeBSD's first female committer as well).
[20:27] (nik> More will doubtless follow.
[20:27] (nik> Of course, sometimes you have to pay people.
[20:28] (nik> The FreeBSD Handbook is now available as a real book, on real paper :-)
[20:28] (nik> But in order to do that there was a lot of material that either had to be written from scratch, or rewritten and updated.
[20:29] (nik> No one was volunteering to do that, so Walnut Creek CDROM (who are now part of BSDi) hired a chap called Jim Mock to do this. Which he did, very successfully.
[20:29] (nik> Jim has stayed on at BSDi, and is now a very important member of the doc. project.
[20:30] (nik> (and FreeBSD as a whole, for that matter).
[20:30] (nik> I think sometimes you need to get business involved, because there are some things that volunteers won't do.
[20:31] (nik> For example, the Handbook is available under the BSD license (basically, don't claim you wrote it, and don't blame us if it's wrong).
[20:31] (nik> One of the things the paper version (and the web version) is missing is a proper Index.
[20:32] (nik> This is "grunt work" that no one really wants to do (or has the time to do).
[20:32] (nik> So an enterprising publisher is completely free to come along and do just that.
[20:32] (nik> So far, none of them have. But I keep trying to get O'Reilly to see sense :-)
[20:33] (nik> Ow.
[20:33] (nik> My fingers are starting to hurt (I used to get RSI, partly as a result of working too much on the Handbook :-) )
[20:34] plas plas plas plas plas plas plas plas plas plas
[20:34] clap clap clap clap clap clap clap clap clap clap
[20:34] plas plas plas plas plas plas plas plas plas plas
[20:34] clap clap clap clap clap clap clap clap clap clap
[20:35] (nik> So I'll stop for a second. Any questions?
[20:36] plas plas plas plas plas plas plas plas plas plas
[20:36] plas plas plas plas plas plas plas plas plas plas
[20:36] clap clap clap clap clap clap clap clap clap clap
[20:36] plas plas plas plas plas plas plas plas plas plas
[20:36] clap clap clap clap clap clap clap clap clap clap
[20:37] (Kerberos> plas plas plas plas plas plas plas
[20:38] (nik> MJesus: Thanks.
[20:38] (Kerberos> plas plas plas plas plas plas plas
[20:39] nik, in the #media channel, danit and _raul_ are trasnlating simultaneously
[20:39] * Ricardo handclaps :))
[20:40] this conference to Spanish
[20:40] (asmodai> MJesus : Yikes. Bizarre. :)
[20:41] yes.... very kind ... those are voluntary
[20:41] (asmodai> *nod*
[20:42] (nik> MJesus: As I said. It's incredible the effort that people will put in on free software and related project.
[20:43] yes.....
[20:43] and very voluntary!!
[20:44] (asmodai> Well, some people have luck.
[20:44] (nik> How many people here have written documentation for a free software project (or translated existing documentation)?
[20:44] all our conferences, here in umeet, have bee trasnlated from english to spanis, or else spanish english, and portugues ....
[20:44] ricardo is a head os slug
[20:45] (asmodai> My company uses FreeBSD, so I get to spend quite some time on it, thanks to my company. :)
[20:45] ricardo is a head of slug
[20:45] (nik> Spanish Linux User Group?
[20:45] GULIC as Insflug
[20:46] (Kerberos> nik www.es.qmail.org
[20:46] (Kerberos> nik insflug.org & lucas.hispalinux.es
[20:46] (Ricardo> Uh
[20:46] (Ricardo> kik
[20:46] (Ricardo> I'm not head of anything
[20:47] (Ricardo> And I'm not at SLUG :)
[20:47] (Ricardo> MJesus is confused :)
[20:47] (Ricardo> I'm with Kerberos at Insflug and es.qmail.org
[20:47] (Fernand0> let's start some questions and answers time now ??
[20:47] (nik> Fernand0: Yes.
[20:47] (Ricardo> :)
[20:48] (HoraPe> i had, and writing was easier than traslating...
[20:48] (HoraPe> tracking changes on the original versions is a nightmare
[20:48] (nik> HoraPe: Which project were you translating for?
[20:48] (HoraPe> i was one of the first documenting gnome (i leave some years ago)
[20:49] (HoraPe> i was one of the first documenting gnome (i left some years ago)
[20:49] (Ricardo> I have translated 6 or 7 HOWTOS for the LDP-es. I worked too in the translation of RH 6.0 & 6.1 manuals into Spanish
[20:49] (Ricardo> (that last work was paid)
[20:49] (asmodai> HoraPe : But do you have programming experience? That makes documenting API's easier, of course.
[20:50] (nik> HoraPe: Ah. As I say, I've been trying to get some of these projects to learn from the FDP. I think the FDP was the first big free software project to switch to DocBook, and we learnt some of these lessons quite early.
[20:50] (asmodai> To emphasize nik's point. When I joined the documentation project, I knew nothing about SGML and DocBook.
[20:50] (nik> Doesn't mean we're perfect of course :-)
[20:50] (asmodai> Thanks to the FDP I got a headstart with it.
[20:51] (HoraPe> asmoadi, yep. and i'm talking about really early gnome versions (0.13 and so on, i left when orbit were being created), i was creating these APIs
[20:51] (asmodai> HoraPe : Understood.
[20:51] (HoraPe> the problem was having different versions (translations) synced
[20:51] (asmodai> HoraPe : That's where we hacked CVS a bit/changed the configs.
[20:51] (asmodai> We now use $FreeBSD$ instead of $Id$
[20:52] (HoraPe> including works where i was who made the changes to the main version...
[20:52] (asmodai> which allows the respective documentation projects [translators] to use the $FreeBSD$ for their own versioning and the $Id$ to contain the latest translated english version id.
[20:52] (asmodai> If I remember correctly, feel free to correct me nik.
[20:52] (nik> asmodai: Not quite.
[20:52] (asmodai> Drat. =P
[20:52] (HoraPe> i don't know if gnome people has solved the problems. Mark Galassi was working on them when i left.
[20:52] (nik> asmodai: See http://www.freebsd.org/tutorials/docproj-primer/translations.html#Q9.14. (the trailing '.' is important).
[20:52] * asmodai makes a note.
[20:53] (asmodai> I need to reread the FDP again. :)
[20:53] (asmodai> been over a year.
[20:53] (asmodai> [it might show I do more manpage stuff nowadays than real DocBook]
[20:53] (nik> HoraPe: Ah, Mark Galassi. He wrote an intro to DocBook, which I then used to help me learn, which mean I could write the primer. I met him at the O'Reilly Open Source conference this year, and he was updating his documentation based on the primer.
[20:54] (nik> What goes around comes around, I guess.
[20:54] (asmodai> Full Circle. :)
[20:54] (Ricardo> Hum :)
[20:54] (nik> asmodai: Indeed.
[20:54] (nik> We also have tools that can help translators.
[20:54] (HoraPe> nik, he introduced docbook to gnome
[20:54] * nik hunts through his mailbox.
[20:55] nik, I introduce Borja, hi is a member os Spanish core
[20:55] (Ricardo> Maybe we could benefit from your primer for the Insflug (LDP-es, HOWTO section) DocBook porting :)
[20:55] he has been pushing here to adopt FreeBSD :-)
[20:55] (HoraPe> and i was the most convinced disciple (sp?) at that
[20:55] (Borja> :-)
[20:56] (nik> The Japanese translation team wrote 'syncstat'
[20:56] (nik> http://www.jp.FreeBSD.org/doc-jp/syncstat/
[20:56] (nik> It shows the status of the different translations (if they follow the "Original revision" protocol).
[20:56] (HoraPe> looking out for that...
[20:56] (nik> For example;
[20:57] (nik> http://www.jp.FreeBSD.org/doc-jp/syncstat/doc-obsolete.html
[20:57] (nik> shows all the documents where the English version has been updated, but the translated version hasn't been.
[20:57] (nik> This list is generated automatically.
[20:57] (nik> The scripts are in
[20:58] (nik> http://www.jp.FreeBSD.org/cgi/cvsweb.cgi/doc-jp/syncstat/?cvsroot=freebsd-jp
[20:58] (HoraPe> it looks promising, are the scripts to do that available?
[20:58] (HoraPe> forgot :-) * nik must remember to test these out some more, then bring them in to FreeBSD proper.
[20:58] (asmodai> nik: Maybe as part of the docproj metaport?
[20:58] (jesusr> Hi Nik and company... sorry but i was talking with my boss :(
[20:59] (asmodai> Hola jesusr!
[20:59] (nik> jesusr: Hi, how's things? Were you telling your boss that it's time to buy some BSDi servers :-) :-) :-)
[20:59] (Borja> Hi, jesusr!
[20:59] (jesusr> Yes, we are thinking on it... i'll let you know in private :)
[20:59] (jesusr> Nik, great introduction to FDP... i've been able to understand what it is ;)
[20:59]* nik chuckles.
[21:00] (asmodai> Anyway
[21:01] (asmodai> Time for me to return to coding.
[21:01] (Ricardo> :)
[21:01] (asmodai> bye bye.
[21:01] (asmodai> nik: Talk to you later.
[21:01] (asmodai> jesusr : cheers!
[21:05] (Ricardo> Uh...
[21:05] (Ricardo> hi?
[21:05] (Ricardo> Anybody alive? :?
[21:06] (MJesus> I'm
[21:06] (oroz> .
[21:06] (MJesus> oroz, dueme....
[21:06] (HoraPe> more or less
[21:08] (MJesus> more questions ?
[21:10] (Ricardo> Hummm...
[21:10] (Ricardo> Any other questions? :)
[21:10] (Ricardo> Uh :) nik has been very clear, as I see }:)
[21:11] (MJesus> I like to know about the major differences about frebsd and gnu/linux
[21:11] (nik> MJesus: It's not a doc question, but if no one objects, I'm happy to (try and) answer it.
[21:11] (Ricardo> :)
[21:11] (Ricardo> Hehehe :)
[21:11] (Ricardo> Try nik :)
[21:11] (elpacheco> :)
[21:12] (_RauL_> a ataker
[21:12] (nik> OK. Keep in mind I've been using FreeBSD for something like 7 years, and last touched a Linux system about 5 years ago.
[21:12] (Borja> ;-)
[21:12] (nik> I'll try and keep this brief.
[21:12] (Ricardo> :D
[21:12] (Ricardo> Uh :)
[21:13] (nik> 1. The history. FreeBSD is a descendent of the work on Unix done at the Computer Science Research Group at University California, Berkeley, back in the '60s and '70s. That means the code base has had a *lot* of review in that time, and some incredibly talented engineers have worked on it.
[21:14] (nik> Linux is a newish (8 years or so) system. That's not a bad thing, but it also means that Linux hasn't had the same amount of work and engineering effort as the BSD code base has.
[21:14] (nik> That's neither a positive or a negative for the average user.
[21:14] (nik> 2. The licensing model.
[21:14] (nik> FreeBSD is distributed under the 2 clause BSD license. Basically
[21:14] (nik> (a) Don't claim you wrote this code
[21:15] (nik> (b) Don't blame us if this code doesn't work.
[21:15] (nik> Apart from that, you can do anything you want with the code. This includes making proprietry changes, and not donating them back. I'll explain why this is *good* thing later.
[21:16] (nik> Linux is distributed under the GPL. The GPL is a considerably longer and more legalistic license than the BSD license. It also mandates source code disclosure as soon as you distribute binaries.
[21:16] (nik> 3. FreeBSD and Linux have different development models.
[21:16] (Ricardo> urgh
[21:16] (nik> There are ~ 240 people who can make direct and immediate changes to the FreeBSD source tree.
[21:16] (Ricardo> I lost "2" :')
[21:17] (HoraPe> ric, licensing
[21:17] (HoraPe> and he'll explain the hard part later
[21:18] (nik> There is one person that can make direct and immediate changes to the Linux tree -- Linus. For some reason, this weird notion that Linux is more "open" than BSD has appeared.
[21:18] (nik> Submitting changes to FreeBSD and Linux is also different.
[21:18] (nik> With both projects, you can find out who the maintainer for a bit of code is, and e-mail them patches directly.
[21:19] (nik> FreeBSD also has a bug tracking system (GNATS), which tracks and records *every* submission that people send it.
[21:19] (nik> This means that you can see the history of a submission, and the e-mail conversation that led to the submission being included, or dropped.
[21:19] (nik> For example (
[21:19] * nik goes to hunt for an example, back in 30 seconds
[21:20] (nik> Here's a bug report in the docs that I just closed
[21:20] (nik> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23450
[21:21] (nik> Here's the commit log for the file that the PR applied to
[21:21] (nik> http://www.freebsd.org/cgi/cvsweb.cgi/doc/en_US.ISO_8859-1/books/porters-handbook/book.sgml
[21:21] (nik> and as you can see, the commit log for the change references back to the original problem submission.
[21:22] (nik> Linux doesn't have that sort of infrastructure. If there's a long discussion between developers over the merits of a particular patch, you have to hope that you can find that discussion again in the mailing list archives.
[21:22] (nik> And when a new kernel is released, the Changelog for that kernel is not going to include a pointer back in to the mailing list archives for the discussion about the change.
[21:22] (Ricardo> hi riel :)
[21:22] (nik> Everyone with me so far?
[21:22] (Kerberos> yes :)
[21:22] (Ricardo> yep
[21:23] (oroz> yes
[21:23] (nik> The 240+ committers are the people that can make direct changes to the FreeBSD tree.
[21:23] (Borja> Sure ;-)
[21:23] (nik> In general, you become a committer by submitting lots of PRs that make sense, and apply cleanly. Do this enough, and you'll be asked to become a committer.
[21:23] (nik> For example, this is how jesusr and asmodai joined.
[21:24] (nik> To be honest, I'm very lazy. Both of them kept submitting PRs, and it was a pain for me to have to go "Let me see, a new PR. Yep, looks OK. Right, now I have to commit it, and close the PR."
[21:24] (Ricardo> :D
[21:24] (nik> It's much easier for me to go "Hey, Jesus, do you want to be a committer? Then you can close all your own PRs."
[21:24] (Capo> alguien tiene idea donde puedo bajar el modulo de asp para el apache serveR?
[21:25] (nik> Seriously, that's how the process works.
[21:25] (nik> Send in high quality changes that take more time to commit than they do to review.
[21:25] (nik> You can't do that with Linux. The only person that controls what goes in to Linux is Linus.
[21:25] (nik> 4. FreeBSD is a complete OS, Linux is a kernel
[21:25] (nik> To some people, this is nitpicking.
[21:26] (nik> FreeBSD is a complete OS. It includes all the source code, and it's tested as a complete unit. You get all the libraries, include files, and everything else, for the complete system.
[21:26] (nik> Linux is the kernel only. Which is why you have distributions like Debian and Redhat, who have to provide all the missing bits to make a complete OS.
[21:27] (nik> The problem with this is that you then have an amalgamation of bits from lots of different places. Keeping them all in sync can be a nightmare. Config files get put in lots of different places.
[21:27] * nik takes 30 seconds to make a phone call.
[21:27] (Ricardo> :)
[21:28] (Ricardo> (This is why a lot of people is trying to make an agreement about the LSB)
[21:28] (nik> Ricardo: Take a look at http://www.freebsd.org/cgi/man.cgi?hier(7), and note the date at the bottom.
[21:28] (Borja> And that's why I get exptremely angry whenever I have to fix something in a Linux system
[21:29] (MJesus> rik, I listen than debian os gnu/linux + aplicatiosn.... this means that Debian is an OS
[21:29] (nik> This also means that all the distributions are trying to differentiate themselves from one another. And one of the ways they do that is by the file locations.
[21:29] (nik> There are over 180 *different* Linux distributions (see www.ldl.cx).
[21:30] (nik> All the FreeBSD code (and documentation, and website) is stored in a CVS repository.
[21:30] (nik> I can do
[21:30] (MJesus> 180 ? glub!
[21:30] (nik> cd /usr/src
[21:30] (nik> make world
[21:30] (nik> cd /etc
[21:30] (nik> mergemaster
[21:30] (nik> reboot
[21:30] (nik> and I've just updated my system using whatever version of the FreeBSD code was in /usr/src. That's the kernel *and* the userland programs.
[21:30] (nik> You can't do that with Linux.
[21:31] (nik> And I don't know of a distribution that is that integrated either (please let me know if know of one).
[21:32] (nik> Because we use CVS, it's very easy for *anyone* to get access to exactly the same code that all the developers have, any time they want to. We don't have to wait for someone (say, with the initials 'ac') to release a patch. We can just use "cvs update", and get the code any time we want.
[21:32] (nik> It's also possible to maintain a complete mirror of the FreeBSD CVS repository (i.e., the ,v files) locally. This is what I do, then I have all the revision history locally, instead of being online.
[21:33] (nik> Linux doesn't have anything like the FreeBSD GNATS repository for submissions.
[21:33] (riel> nik: both approaches can be good or bad, depending on what you need ;)
[21:33] (nik> See http://kt.linuxcare.com/kernel-traffic/kt20001120_94.epl#9 for a good example of the problems it causes.
[21:33] (maz> hay conferenci ahorita?
[21:33] (Ricardo> sí maz
[21:34] (nik> That also highlights another problem. If Linus doesn't understand the code, it doesn't go in the tree.
[21:34] (nik> The Linux kernel is not in any sort of revision control system (not CVS, not BitKeeper, not anything).
[21:34] (nik> I know that there are third parties that take Linus' code and import it in to their repositories.
[21:34] (nik> But this doesn't give you any of Linus' revision history, or reasons for making a change.
[21:35] (nik> Eric Raymond (esr, the Cathedral and the Bazaar guy) thinks this is a very bad thing.
[21:35] (nik> See http://kt.linuxcare.com/kernel-traffic/kt20000904_83.epl#4
[21:36] (nik> ESR basically says that Linus' natural talents as a developer means that, right now, he can probably do without things like submission systems, and source code control, and so on. But that sooner or later Linux will get to be too big for one person to understand. and when that happens. . .
[21:36] (riel> nik: Linus has a point though
[21:37] (riel> nik: when the kernel gets too big for any single person to understand, how will you be able to maintain it?
[21:37] (nik> Because FreeBSD uses CVS, and you can access the latest code at any time, anyone can run with a current system when they want to. Releasing a new kernel happens every time someone makes a commit, so it's not a 'flag day' for BSD users, the way a new kernel is for Linux.
[21:37] (nik> riel: Do you think GNOME is small enough that any one person can understand all of it?
[21:38] (riel> nik: I didn't say GNOME was in any way maintainable ;)
[21:38] (nik> riel: OS kernels can be complex.
[21:38] (nik> riel: You probably want to make the code as simple as possible.
[21:38] (nik> riel: That's a good thing.
[21:38] (nik> riel: However, you don't want the code to be too simple.
[21:38] (nik> riel: Linus has other demands on his time.
[21:39] (nik> riel: It is unfair to expect that a man with a full time job, a wife and three kids should be expected to understand every little thing in the kernel.
[21:39] (nik> riel: There's stuff in the FreeBSD kernel that I don't understand. But that's because I haven't got the time to follow it. I trust the other developers that they know what they're doing.
[21:40] (nik> riel: Part of the open source philosophy is (or should be) that you are prepared to relinquish some control over the code, in exchange for the extra eyes and users you get. Linus is not prepared to give up any control over the kernel.
[21:40] (Borja> riel, if only software projects understandable by a single person were viable... there would be no "computer age" as we know it :-)
[21:40] (nik> 5. Third party packages.
[21:41] (nik> FreeBSD and several Linux distributions support the notion of 'binary packages' (.deb, .rpm, etc).
[21:41] (nik> FreeBSD also has the "ports" tree.
[21:41] (nik> See http://www.freebsd.org/handbook/ports.html for more details.
[21:42] (nik> It's a mechanism for maintaining the information needed to download, patch, and compile third party applications on a FreeBSD system, and integrate the installed software with the package management system.
[21:42] (nik> The ports system *rocks*. There's nothing like it in Linux, or any commercial Unix variant.
[21:42] (nik> It really has to be seen in action.
[21:42] (nik> 6. Kernel configuration.
[21:43] (riel> nik: how about 'apt-get source ' ?
[21:43] (nik> riel: A good example of the apparent differences between the BSD and Linux philosophies.
[21:43] (nik> riel: Linux developer: Look, an interesting new problem to solve. Lets go and write a completely new and non-standard application (apt) to solve it.
[21:44] (nik> riel: BSD developer: Look, an interesting new problem to solve. Well, I already have a few hundred good tools in /bin and /usr/bin, lets see how I can solve the problem using them.
[21:45] (nik> riel: This means that a third party, with just general Unix knowledge, can use the ports system, and tweak it to their own requirements (including customising the patches, changing the configuration, and so on).
[21:45] (riel> nik: both systems have their advantages and disadvantages
[21:46] (nik> riel: Also, apt packages aren't stored in CVS. The ports tree is. Which means it's very easy for me to create a custom port that's based on an existing BSD port. Then, when the BSD port is changed, it's a complete doddle for me to integrate those changes in to my customisation.
[21:46] (nik> As I was saying, 6. Kernel configuration
[21:47] (nik> Correct me if I'm wrong, but you still configure a Linux kernel using a menu driven approach, or question and answer session, right?
[21:47] (riel> nik: menu driven, indeed ... with 3 front-ends available
[21:47] (nik> OK. And it writes a kernel config file at the end of it, yes?
[21:47] (riel> nik: yup
[21:47] (Borja> Regarding kernel config in Linux, there is a major problem: changing some variables (such as the maximum number of processes) is a nightmare.
[21:48] (nik> OK. Now, the bad thing about this is that you are not supposed to hand edit this generated kernel config file, ever.
[21:48] (nik> See http://kt.linuxcare.com/kernel-traffic/kt20001127_95.epl#3 for proof.
[21:48] (riel> nik: that's not true ... you can edit .config just fine
[21:48] (Borja> The menu-driven tools (at least which I have seen) only allow you to change the list of drivers included
[21:48] (nik> riel: You can edit it by hand, but it's not supported.
[21:48] (Borja> riel, how do you increase the maximum number of processes for a Linux kernel?
[21:49] (nik> riel: The URL has the discussion from the Linux kernel mailing list. I assume that's definitive.
[21:49] (nik> Now, this is bad.
[21:49] (riel> nik: "it's on the internet, it must be true?" ;)
[21:49] (riel> nik: that's a rather questionable attitude
[21:50] (riel> nik: it would be nice if you didn't use other people's opinions as "evidence"
[21:50] (nik> riel: I think it's fair to say that if it appeared in the Linux kernel mailing list and noone contradicated it then it's probably true.
[21:50] (riel> nik: or so dumb that it wasn't worth bothering with ...
[21:50] (nik> riel: From looking through the rest of the linux kernel mailing list, Keith Owens and Richard Johnson look to be respected members of the developer community.
[21:50] (riel> nik: ROFL
[21:51] (nik> riel: Well, reasonably respected. We all have our kooks.
[21:51] (nik> Anyway, not being supposed to edit .config by hand means.
[21:51] (riel> nik: the reason their emails don't get answered is that most developers have them killfiled ;)
[21:51] (fernand0> hola
[21:51] (nik> 1. You can't keep it in a CVS repo (or other management system).
[21:51] (nik> 2. You can't use 'diff' to see what's changed between two different kernel configs.
[21:52] (nik> 3. Making iterative changes is hard.
[21:52] (nik> In an environment with one or two machines, that's not a problem.
[21:52] (nik> Now scale it up to the enterprise.
[21:52] (riel> nik: as I said, the presumption you base this opinion on isn't correct
[21:53] (nik> That's really where FreeBSD and Linux differ. To the home user, they're pretty much identical. But as you start to scale up, the niggling things start becoming more importnt.
[21:53] (Borja> riel, I have actually experienced the Linux' approach to kernel config and I hate it.
[21:53] (nik> Ignoring the maturity of the code base and the licensing issues;
[21:53] (nik> * FreeBSD is a complete OS, integrated at the source code level.
[21:54] (nik> * FreeBSD's barrier of entry for new contributors is lower.
[21:54] (Borja> I hate to spend more than one minute on one minute tasks
[21:54] (riel> Borja: I can understand ... everybody has a different taste
[21:54] (nik> * FreeBSD provides revision control over the whole OS for free.
[21:54] (nik> * FreeBSD makes it easier to include third party applications (I know that's questionable -- if you're already familiar with RPM, then RPM doesn't cause you any problems. Nut any competant Unix SA is going to know make(1)).
[21:55] (Borja> It is not a matter or taste, riel.
[21:55] * nik has to go in about 5 minutes -- I've got a girlfriend sat at home wondering where I've got to.
[21:55] (riel> Borja: "I hate it" looks like a matter of taste to me ...
[21:56] (Borja> Well, when I have wasted time to solve otherwise trivial problems, I can get really upset if I am busy
[21:56] (viljo> borja, you dont like editing .config with your $EDITOR ?
[21:56] (Borja> viljo, I repeat a simple question: how do you increase the number of processes for a Linux kernel? It is an important question.
[21:56] (riel> Borja: with 2.4, that obvious flaw is gone
[21:56] (VERT|GO> maz
[21:57] (Borja> You must edit a /some/where/in/kernel/file.h file to change a #define value.
[21:57] (HoraPe> is 2.4 out yet?
[21:57] (riel> Borja: if you want, I'll provide you with a counterexample in BSD
[21:57] (Borja> It is a terrible problem.
[21:57] (Ricardo> HoraPe: test12-pre8 last time I looked at
[21:57] (Borja> Anyway, I don't want to enter a circular argument...
[21:57] (Borja> Sorry, nik
[21:57] (HoraPe> ric, that sounds to me as "not yet"
[21:57] (Ricardo> HoraPe: yup :)
[21:57] (fernand0> 2.2.18 is just out, i think
[21:58] (Ricardo> HoraPe: Well, I tun it fine but... You know O:)
[21:58] (fernand0> so not 2.4 in the near horizon ??
[21:58] (Ricardo> s/tun/run/
[21:59] (Ricardo> fernand0: I think Linus told something about 'a while after my wife've released Linus v4.0 ...'
[21:59] (Ricardo> fernand0: But I dunno O:)
[21:59] (fernand0> hehe
[21:59] (fernand0> and this will be before or after ricardo v2.0 ?
[21:59] (fernand0> XD
[22:00] (Ricardo> fernand0: I hope O:)
[22:00] (nik> OK guys.
[22:00] (nik> It's 20:55, and I need to go home.
[22:00] (Ricardo> Ok nik :)
[22:00] (Borja> :-)
[22:00] (nik> Thank you all for attending.
[22:00] (Kerberos> nik :))
[22:01] (nik> I hope you found it useful (and that you'll start writing or translating documentation).
[22:01] (Ricardo> We all want to thank you for being here talking us about FreeBSD :)
[22:01] (Borja> nik, I was part of the last "TCFBSD" translation effort, but now I am really busy :-(
[22:01] (nik> If any of you have got more questions about FreeBSD, obviously, check out the web site, the mailing list archives, and so on.
[22:01] (viljo> anyone have a log?
[22:02] (Kerberos> nik keep up the good work :)
[22:02] (nik> Yeah, actually, if anyone has a log, please could they mail it to me.
[22:02] (riel> nik: my compliments on the FBSD handbook ... it is a really good piece of documentation
[22:02] (nik> If you have FreeBSD questions, feel free to mail me, nik@freebsd.org
[22:02] (Ricardo> nik: You'll get it :) Don't worry :)
[22:02] (nik> Of course, I might just point you at some of the documentation instead :-)
[22:02] (nik> riel: Thanks for the compliment.
[22:02] (nik> With my bsdi.com hat on (if I can do that for a moment).
[22:02] (riel> nik: IMHO, both Linux and BSD have their strong points
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (Kerberos> clap clap clap clap clap
[22:03] (Kerberos> clap clap clap clap clap
[22:03] (Kerberos> clap clap clap clap clap
[22:03] (riel> nik: and I like the diversity ... Linux is good for some people, BSD is good for some people (or for the same people in different situations)
[22:03] (Borja> clap clap clap clap clap clap clap clap clap
[22:03] (Kerberos> clap clap clap clap clap plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:03] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:03] (nik> If you're a BSD user in Spain (or Spanish speaking countries), BSDi are expanding a lot in Europe, South America, and other places. We're looking to provide what help we can to the user groups
[22:03] (Ricardo> clap clap clap clap clap clap clap clap clap clap
[22:03] (Ricardo> :)
[22:03] (nik> riel: If it was one size fits all the world would be such a boring place.
[22:04] (nik> BSDi has a Spanish office (in Barcelona). Give them a call, or drop them a line.
[22:04] (maz> clap clap clap clap clap
[22:04] (riel> nik: which is why I don't like the "FOO is good, BAR is bad" talk done by so many Linux and BSD advocates ...
[22:04] (Borja> I know them, thanks :-)
[22:04] (riel> nik: and as a developer, I like to point people to the good points in both systems
[22:04] (nik> With my Marketing Director hat on, I plan to come to Spain at some point next year, meet the user groups, find out how we can help you guys.
[22:05] (nik> Have a few drinks :-)
[22:05] (nik> That sort of thing.
[22:05] (nik> If you've got BSDi questions, drop me a line too, nik@bsdi.com
[22:05] (Borja> See you then, nik ;-)
[22:05] (nik> Take care.
[22:05] (Ricardo> See you nik :)
[22:06] (MJesus> thanks nik!
[22:06] (nik> Bye.
[22:07] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:07] (MJesus>clap clap clap clap clap clap clap clap clap clap
[22:07] (MJesus>plas plas plas plas plas plas plas plas plas plas
[22:07] (MJesus>clap clap clap clap clap clap clap clap clap clap
Y seguimos un buen rato más charlando...

Contact: