Helio
-
Content Count
9 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by Helio
-
-
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 to worry is when the dependency is in the abi used by the kernel itself. You can't as easily dynamically link those calls.
Granted, most package tools aren't entirely aware of this axiom, but it's completely possible, and has been done several times. I think the problem has to do with the fact that people who usually write package managers aren't the same people who write kernels or libs. Add to this the assumption that the management tools are an unremovable component of the system, the thought is allowed to blossom into full on 'truth'.
As for doing it, you are on your own for your specific distro. However given enough work I can guarentee with little reserve that you can do it. I've done it on freebsd, qnx, and on a windows install a few years ago. Fighting with the package management software will probably be the bulk of the problems, the os typically doesn't care at all.
-
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 mount the solaris slice's label a, edit the grub menu.lst there, and change it to use hd1. try man mount_ufs on your linux distros, or download a livecd that can mount basic ufs partitions (freesbie and schillix come to mind).
here's an explanation of how bsd style labels are enumerated in the linux kernel:
http://lists.gnu.org/archive/html/grub-dev...0/msg00020.html
along with other tidbits and caveats.
I hope this helps
-
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 building tools.
And before I forget, the obligatory 'source city' screenshot:
-
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 $2the 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 be complex, so it's best to read the help file before starting, it can save alot of headaches.
good luck
Nfs Verison?
in Linux & Unix
Posted
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.