Benjamin Smee - Latest comments

In response to: sguil and other riff raff

bubba [Visitor] — Sat, 12 Aug 2006 13:59:03 +0000

http://www.disciplina.net/howto/HOWTO-sguil.html seems to be down

In response to: sguil and other riff raff

marc [Visitor] — Wed, 15 Mar 2006 12:45:37 +0000

When do you plan to commit OpenCA?
thx...m

In response to: Network Monitoring

es [Visitor] — Wed, 15 Jun 2005 23:42:29 +0000

thanks!

In response to: Documentation

lotso [Visitor] — Sat, 04 Jun 2005 00:28:32 +0000

Dude.. I can't find your email address.

My email is listed, perhaps you can email me 1st?

In response to: Documentation

Benjamin Smee [Member] — Wed, 01 Jun 2005 13:15:28 +0000

I am happy to let the HOWTO be used in your magazine, if you are serious contact me via email and I can look to do some refining and give you a more suitable version.

In response to: Documentation

lotso [Visitor] — Wed, 01 Jun 2005 12:52:19 +0000

Dude.. Can I have your permission to republish your article into Edition 3 of MalaysianOSS Magazine?

I did a high-to-medium level intro into using suspend2 in Edition 1 and progressed with a Power Management Howto in Edition 2.

I think your documentation on suspend2 with LVM and encryption would fit in nicely into Edition 3.

Can you see if it's possible for me to either use it as is or if you're willing to do a polish up/review for the Magazine?

Please let me know. Thanks

URL for the magazine is --> http://mag.my-opensource.org

In response to: hello world

Benjamin Smee [Member] — Tue, 24 May 2005 12:41:09 +0000

I don't think it can be done like that. The basic issue is that for each of the component parts kolab has extensive patchsets, so that if I don't somehow lock the subcomponent versions I will be left trying to maintain mammoth patchsets against constantly revving packages. Currently the most elegant way I can think of doing it is to provite a single kolab package that will block its namesakes, at least this way I can effectively version lock, something which portage can't do right now. I am very interested in any ways you can think of to implement it using existing gentoo packages as that is my preferred method as well. I will certainly be staying away from using the openpkg setup they use and I will look to make kolab FHS compliant where possible.

In response to: hello world

Christian Parpart [Visitor] — Tue, 24 May 2005 11:24:50 +0000

oh, yeah. please get rid of Kolab in an ideal way - that is, making use of the already existing ebuilds for proftp, apache and co. I'd really like kolab working in, but I dislike the /kolab approach just because they think it's best for them(tm)