Helio

For the server, it depends on the daemon. Vanilla linux I think requires some kernel level nfs support to work, but it's mostly for some of the messier locking stuff. The client however, has to be either built into the kernel or into the nfs driver. There's a site explaining some of the gentoo specific tweaks required to get nfsv4 working here: http://gentoo-wiki.com/HOWTO_NFSv4 Unfortunately I don't have a gentoo drive to test that on, but it sounds right. It's strange that version 2 was built by default, it's been obsolete for almost 11 years, and 3 has certainly become stable by now.

In all honesty, 'dependency hell' is inherent when you start modularizing code for an application. Unless the program is statically linked and written to only use raw and generic abi calls, it will always exist. The problem is hidden usually with a dependency system that's implemented in a userspace library that can be updated like any other module -- which doesn't fix the problem per se, just makes it less immediately noticable. That said, all of those applications can be built statically, and all can coexist with other userspace libraries of conflicting versions. The only time that you have

I skimmed over most of the replies, but just by looking at the first post I can see your prob, though I'm not quite sure why sun didn't modify it. Since you are installing to the primary slave, everything has to be relative to hd1. The mbr grub is using hd1 in your conf, and you are chainloading solaris's grub. Solaris's grub, however, has it specified as hd0 not hd1 (don't worry about the fact that your grub, the one on the MBR, can't read ufs, It's actually alot simpler to deal with it chainloaded, as grub's ufs support is still shaky with vendor extensions). You'll most likely need to mou

Just haven't had time to fix it or reinstall I make release'd iso images from a bad cvs checkout, so libc has some serious bugs. Mainly segfaults in str* functions, which throws up awk during a buildworld. Plus the x server was built for 5.4, so is forced to use the 6.0 vesa ko. It's actually running quite well considering how bad off it is, and I'm curious as to how long I can run it 'broken' before any serious stability issues arise

my buggy freebsd 6.0RC1 install: Perhaps one of these days I'll get around to actually fixing it, but it's running fine as it is. As for the sparseness, I'm a traditional unix kinda man, small tools that I can pipe together, and only use what I need when I need it. ROX-Filer handles my spatial file management and type association needs while windowmaker handles all my windows, and I can say I've never desired anything more. As for my netbsd 3 install, it is virtually identical (I symlinked home to this drive), except with a quarter of the dock actually launching anything and twice the build

you don't need the $2 in the event at all, mirc fills it automatically, plus the extra space may throw off the matching. try: on 1:TEXT:!income*:*:{

the match text part of the event is off, mIRC script is very simple when it comes to that. on 1:TEXT:!buy %quantity Fishing Boats:*:{ should be: on 1:TEXT:!buy * Fishing Boats*:*:{ set %quantity $2 the set %quantity $2 stores the second word in the line which matched the event (in your case, the quantity of boats) and stores it into the variable. The rest of the code looks good, but you may want to check %gc, from what it looks like it is a global gold count. I don't know the rest of the code, so I can't tell if that's what you want to do or not.

well, if the language is mIRC script, then to set a variable would be: /set %variable value to increase by 1, would be: /inc %variable to decrease by 1 would be: /dec %variable

making an IRC rpg isn't an easy task, but I can give you an idea where to start using mIRC. First you'll need to read up on "on text" events in mIRC, they will be the interface your players will use. Then you will need to learn about "hash tables" which are the best way to store info. hash tables are lists of variables, similar to a spreadsheet (though not nearly as powerful). Next would be tokens, though not required, they allow you to store alot of info into 1 hash table entry then you normally would. The only thing that remains is timers, which would be used for random events. IRC rpgs can