Crossfire Forum

Mith wrote: most users are users, not ppl that can spent their lives on learning how their system works
...
download cvs and compile. its not that hard

Am I the only one to spot a disparity between these two statements?

Server: This is Crossfire v1.5.0
Client: GTX Unix client 1.7.0

Sound was enabled but I had no sounds anyway (ISA Soundcard). Disabled now. I'll see how it goes.

cavesomething wrote:

Mith wrote: most users are users, not ppl that can spent their lives on learning how their system works
...
download cvs and compile. its not that hard

Am I the only one to spot a disparity between these two statements?

i think so, for - i hope - you are the only one that ignores the context of these statements.
the first statement was about Borts comments: " LEARN HOW MEMORY WORKS." and "use a memory management program that allows you to delete the semaphores and unused segments that are in use."
while the second statement you quote is about typing ./configure && make && make install

if you were talking about a source release I would agree. However CVS is something slightly different, it isn't even guarenteed to compile at any given time, let alone run, run stably, or be able to be fixed to do so (this is part of what the whole alsa 0.9 buffer thing seems to be about anyway).

CVS has two purposes
1. to keep track of source code revisions
2. to test source code revisions between releases.

both of these require some knowledge that it is not expected that everyone should have. Therefore learning will be required.

My claim is not that this makes learning about CVS bad, it is merely that it is not automatically easier or more important than learning how memory works (which to some level, is no more complex than learning CVS, although the relative utility of both forms of knowledge is questionable).
It is one thing to be able to co a module, or look up the meaning of SIZE RSS and SHARE and another thing to write your own VM system or source revision control system.

cavesomething wrote: write your own VM system or source revision control system.

Nowdays you'd be more likely to cludge Linux's VM system. It's not great, but it does the job and is stable unlike any VM system I'm likely to write were I to try.

Also "using a memory management tool" != "writing a memory management system", like "script kiddie using hacking tool to root Wintoasterz" != "hacker taking apart windows rpc handling binary to discover a security hole".

exactly, there are differing degrees of knowledge in any field of study, and whilst complete understanding of anything non-trivial is a lifetime's work, a grasp of the key concepts and results is not so difficult.

From the point of view of memory, It is reasonable to expect someone to be prepared to know what an adress is, what a byte is, what a word is, what a register is, what protected memory is. I don't mean the 'proper' definitions, just enough to get by.

just like there is no need to expect someone to understand the complexities of CVS, but just know enough to understand what a checkout is, and what it will do for them.

Rednaxela wrote:

bort wrote:Also, build SDL image support into the client. That stops the leak.

My memory still leaks some with SDL turned on. I can cause the system to run out of memory completely (1GB of swap and 512MB ram) by rapidly inscribing in books with a keybinding till the book is full, then repeating for another few books that there goes all my memory

This is where you put something called a limiter in.
I run BSD, and I think linux does this, I set the maximum amount of physical memory that can be used by one user at half my normal memory. Then if things slow down, you have enough memory to login as root and kill the process.
It is the /etc/login.conf file.