I don't have a FreeBSD box to test on, but to compile the client for MacOS X (which should be similar enough), it's enough to add -Dsocklen_t=int to the line in the Makefile that compiles source files, and -lcrypt to -lcrypto in the line that links the executable.
So, change line 8 in the Makefile from $(CC) -o dclient $(DCLIENTOBJS) -lssl -lcrypt -mhash
to
$(CC) -o dclient $(DCLIENTOBJS) -lssl -lcrypto -mhash
and line 12 from $(CC) -c $<
to $(CC) -Dsocklen_t=int -c $<
and it should compile.
According to a mail from Ingo Molnar halfway down the linked article, M:N threading doesn't really solve the real problem - it's good at switching back and forth between running threads, but the real reason for having very large amounts of threads (be they kernel or user space threads) to begin with, is to do IO, and for that, there is no real advantage of user space threads.
More info on the 1:1 vs M:N issue can be read in the white paper
Re:may god forgive him for what he has unleashed
on
The First Smiley :-)
·
· Score: 4, Funny
What more could we ask for from 2 simple characters?
If they want the opinion of random people on the web, they should have it. As a tribute to the memory of most beautiful person in the world, they should call it Hank, the angry drunken dolphin.
Slight nitpick: the GPL also covers making derivate works, and linking is by some (including RMS) considered to amount to making a derviate work.
This interpretation means that when you run a dynamically linked program, you are creating a derivate work, which is covered by the GPL. This is what prevents non-GPLed plugins from being used with GPLed programs.
What this means in this context is that in order to run a dynamically linked binary of a GPLed program, you may have to agree to the GPL, at least if you go by the letter of the license (there's little doubt that the intent of it is on your side).
Slashdot Mirror
I don't have a FreeBSD box to test on, but to compile the client for MacOS X (which should be similar enough), it's enough to add -Dsocklen_t=int to the line in the Makefile that compiles source files, and -lcrypt to -lcrypto in the line that links the executable.
So, change line 8 in the Makefile from
$(CC) -o dclient $(DCLIENTOBJS) -lssl -lcrypt -mhash
to
$(CC) -o dclient $(DCLIENTOBJS) -lssl -lcrypto -mhash
and line 12 from
$(CC) -c $<
to
$(CC) -Dsocklen_t=int -c $<
and it should compile.
According to a mail from Ingo Molnar halfway down the linked article, M:N threading doesn't really solve the real problem - it's good at switching back and forth between running threads, but the real reason for having very large amounts of threads (be they kernel or user space threads) to begin with, is to do IO, and for that, there is no real advantage of user space threads.
More info on the 1:1 vs M:N issue can be read in the white paper
Well, a version of this is being proposed, but not by the people you might think; read The Right Way to Tax DAT.
If they want the opinion of random people on the web, they should have it. As a tribute to the memory of most beautiful person in the world, they should call it Hank, the angry drunken dolphin.
Slight nitpick: the GPL also covers making derivate works, and linking is by some (including RMS) considered to amount to making a derviate work.
This interpretation means that when you run a dynamically linked program, you are creating a derivate work, which is covered by the GPL. This is what prevents non-GPLed plugins from being used with GPLed programs.
What this means in this context is that in order to run a dynamically linked binary of a GPLed program, you may have to agree to the GPL, at least if you go by the letter of the license (there's little doubt that the intent of it is on your side).