Re: [vox-tech] Persistant hardware problem kicking my butt
I have been overclocking since those famous/infamous celeron 300A to 450. Overclocking can destroy CPU and cause other problems so when you overclock, please keep that in mind. I will give you an example. Back in 2001, I wanted to help my wife's PhD project. I built 3 systems to help her run monte carlo with matlab. One of the primary number cruncher was an Asus KT133 chipset system. I overclocked an OEM thunderbird core Athlon 1Ghz to 1.2Ghz and the system ran 24/7 for several months without one crash. However, after about an year, I can no longer stay at 1.2Ghz without system crash. After I switched back to 1Ghz, system stopped crashing. Based on your description, your overclocking may have damaged some components, but unless I know exactly what you did, it's hard to tell. Overclocking tend to adjust FSB (I was able to unlock my athlon's multiplier lock with a pencil but I don't think that's possible now). When you adjust FSB, depending on chipset (your nforce2 chipset should have some locks), you may inadvertently adjust AGP (need to stay 66mhz or below, depending on FSB divider value), PCI (need to stay at 33mhz or below, again depending on FSB divider), IDE speed (you can corrupt your IDE devices, especially hard drives) can all be affected. Of course, CPU and memory speed are affected and you may have boosted voltage to increase stability. All these has the potential of shorten your hardware life. I overclock knowing all those because I retired my celeron 300A not because they failed, but because they were too slow. I also retired my athlon 1GHZ as it developed other hardware problems. I believe my system will become obsolete before hardware failure. In general, when you overclock, you need to pay special attention to motherboard, RAM, heatsink and fans, case, and power supply. You need to use quality components because you are pushing your system to the limit, any of those component fail can cause the whole system to fail. I would check RAM, don't buy Fry's generic RAM please. I used to do that to save money until 1998, I purchased mushkin memory and suddenly, 90% of my system's random crashes and hang went away. Ever since that experience, I stick with only quality RAM. Power supply is another problem, you need to use good power supplies that deliver a clean stable current. Bad power supplies may cause some of those symptoms you are describing as well as random system reboots, etc. Good power supply companies are PC Power Cooling (expensive though), Antec, Enermax (about two years ago, some of their top end PSU had some issues, they have since fixed it), and Sparkle. There are some new companies who seem to produce decent power supplies but since their track record is short, I hesitate to recommend them. Even companies on my list has had periodic problems with some batches of their power supply. You can find people's complaints against power supply by google. Does your power supply have enough juice for your 12V rail? Your IDE devices consume your PSU's 12V rail. Not enough can cause problems. Power supply are given a total wattage rating but you really need to pay attention to its composition as not enough juice in any of the 3.3V, 5V, 12V rail can cause system problems. A good case will help with your system's cooling but your problem does not seem to be heat related. If you can, borrow some good quality RAM and a good PSU and proceed to test by leaving only one HDD, video card, CPU, 1 stick of RAM inside your system, run memtest for a few hours. If it passes, put another stick of RAM in and memtest for another few hours again. If possible, run memtest for 24 hours everytime to get a larger sample size. When all those pass, then you can add components back one by one, perhaps DVD burner after your RAM to make sure, then other components back in. Since you use good RAM and PSU, that eliminate those two possibility. If you cannot pass memtest even with just CPU, memory, video, and 1 HDD, then it's likely it's your motherboard. Best way to figure out what caused your problem is through process of elimination. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] (Moved from [vox]) Errors in software compilation
On Wednesday 09 March 2005 11:00 pm, Bill Kendrick wrote: On Wed, Mar 09, 2005 at 05:58:40PM -0800, Mark K. Kim wrote: Where's your `./configure` step??? In Dylan's original post, he said the configure step worked fine, but that IS a good question. Dylan, can you start fresh and cut-n-paste the initial configure and make steps into an email here? Right I should have included it from the start. please see the configure output at the end of this email... here were the configure options; ./configure --prefix=/usr --with-png=internal --with-jpeg=internal \ --with-gif=internal --with-libtiff=internal \ --with-geotiff=internal --with-libz=internal\ --without-pg --without-ogdi --with-python \ --with-threads=yes Also, is this app downloadable from anywhere? (I don't remember if you had mentioned an URL in any prev posts) yes, from here: http://www.gdal.org/index.html Thanks for looking at this! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/i486-slackware-linux/bin/ld checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes checking for /usr/i486-slackware-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag CXX to libtool checking for ld used by g++... /usr/i486-slackware-linux/bin/ld checking if the linker (/usr/i486-slackware-linux/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag F77 to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/i486-slackware-linux/bin/ld) supports shared libraries... yes checking dynamic linker
Re: [vox-tech] Persistant hardware problem kicking my butt
on Wed, Mar 09, 2005 at 11:59:14AM -0500, Peter Jay Salzman ([EMAIL PROTECTED]) wrote: I think that's all the data I have. It's imperative that I have a reliable fast machine right now to run physics simulations. That's crucial. To me, the available clues seem contradictory. Somethings points to RAM. Other things point to something resident on the mother board. Still other things point to the DVD drive. Occam's razor: Three things connected at one common point suggest the common point. If you have the option of testing RAM/DVDR on another system, do it. If they're cle Otherwise, I'd punt, say mobo, and read my warranty, and check my bank balance / credit limits if necessary. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? The revolution will put you in the driver's seat. signature.asc Description: Digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Apache question: preventing direct access to files
We've got some .pdf documents on our website that we'd rather people not
view by directly typing the URL into the browser; we want them to get
there via a link.
My boss is convinced that we can do this using the same tricks with the
.htaccess file that can be used to prevent images from being stolen. I'm
not entirely sure about that.
Here's the .htaccess file in question. I've kept all my failed attempts
and commented them out. Any help would be grand. The first one -- using
mod_auth_cookie -- seemed to work (because users shouldn't even be in that
directory unless they have logged in) but we needed a broader solution.
#AuthName DLC Resource Only
#AuthType Basic
#AuthUserFile /web/config/users.txt
#AuthGroupFile /web/config/groups.txt
#Require group members
#AuthCookieName CFTOKEN
#FilesMatch \.pdf$
#SetEnvIf Referer http://152.79.198.7; local_referrer=1
#Order Allow, Deny
#Deny from all
#Allow from env=local_referrer
#/FilesMatch
#RewriteEngine on
#RewriteCond %{HTTP_REFERER} !=
#RewriteCond %{HTTP_REFERER}
#!=^http://152.79.198.7/cfmx/DLC/Campus/Courses/wineAnalysis/lesson_10/les_010_002.cfm;
#RewriteRule .*\.pdf$ - [F]
#SetEnvIf Referer ^http://152.79.198.7; internal
#Limit GET POST
#order deny,allow
#deny from all
#allow from env=internal
#/LIMIT
--
Sláinte,
Richard S. Crawford (AIM: Buffalo2K)
http://www.mossroot.com http://www.stonegoose.com/catseyeview
We live as though the world were how it should be,
to show it what it can be.
--Angel, Season 4 ep. 1
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Apache question: preventing direct access to files
Richard S. Crawford wrote: We've got some .pdf documents on our website that we'd rather people not view by directly typing the URL into the browser; we want them to get there via a link. My boss is convinced that we can do this using the same tricks with the .htaccess file that can be used to prevent images from being stolen. I'm not entirely sure about that. Isn't it exactly the same problem, though? In either case, you're trying to make sure that HTTP's Referer field is set. #FilesMatch \.pdf$ #SetEnvIf Referer http://152.79.198.7; local_referrer=1 #Order Allow, Deny #Deny from all #Allow from env=local_referrer #/FilesMatch The above seems right. I don't know whether there are bugs in it, or what, but that's the idea. 'Course, nothing's gonna work if it's commented out ;-) It's not foolproof: with wget, for example, you could forge a Referer field. But the chances of encountering that are pretty low; and anyway, there's not much you could do about it, short of actually authenticating the tokens. Since you seem to be using ColdFusion (evidence has been snipped), you could probably write a short wrapper that will serve up the pdf file if the person deserves it; and remove the PDF files to outside of the web docs repository. BTW, don't ColdFusion suck? :-) -Micah ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Apache question: preventing direct access to files
And behold, Micah Cowan flailed at a keyboard and did expound:
Since you seem to be using ColdFusion (evidence has been snipped), you
could probably write a short wrapper that will serve up the pdf file if
the person deserves it; and remove the PDF files to outside of the web
docs repository.
I tried that. Didn't work, because in the setup, CF pages are delivered
by the JRun server, and not by the Apache server, so I can't use an Apache
redirect to get the wrapper to work. And if I use an Apache rewrite to
make the page *not* delivered by JRun (I can do this by removing the cfmx
from the URL), then the Cold Fusion page does not work. Oy.
Yes, it is exactly the same problem as the hotlinking to image issue. I
was thinking about it in the wrong way. Silly me.
Here's what I finally put into httpd.conf:
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} !^http://152.79.198.7/.*\cfm
RewriteRule .*\.pdf$ - [F]
I also added:
RewriteRule ^/cfmx/(.*\.pdf)$ /$1 [R,L]
though it's probably not necessary.
BTW, don't ColdFusion suck? :-)
Yeah. Oh, yeah. More than you can imagine. Fortunately, we're going to
start transitioning over to a PHP solution starting next month (the
transition will probably take over a year, but I'm really excited about
it).
--
Sláinte,
Richard S. Crawford (AIM: Buffalo2K)
http://www.mossroot.com http://www.stonegoose.com/catseyeview
We live as though the world were how it should be,
to show it what it can be.
--Angel, Season 4 ep. 1
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Apache question: preventing direct access to files
Richard S. Crawford wrote: Yeah. Oh, yeah. More than you can imagine. I doubt it: I've had to work with the sucker before. Had to make a living... It's great for doing really simple things. Anything beyond that, and you're better off using practically anything else. Fortunately, we're going to start transitioning over to a PHP solution starting next month (the transition will probably take over a year, but I'm really excited about it). Good for you! I don't understand how people can actually justify paying good money for ColdFusion, when PHP or mod_perl is free! But it's one of those products that look terrific and likely to save lots of development time, to managers; until someone actually tries to accomplish something with it. -Micah ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Apache question: preventing direct access to files
#FilesMatch \.pdf$ #SetEnvIf Referer http://152.79.198.7; local_referrer=1 #Order Allow, Deny #Deny from all #Allow from env=local_referrer #/FilesMatch Isn't there a way to use the above regex to do a redirect to a 404 file not found Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Apache question: preventing direct access to files
Jay Strauss wrote: #FilesMatch \.pdf$ #SetEnvIf Referer http://152.79.198.7; local_referrer=1 #Order Allow, Deny #Deny from all #Allow from env=local_referrer #/FilesMatch How about something like: SetEnvIf Referer 152\.79\.198\.7 let_me_in FilesMatch \.pdf$ Order Deny,Allow Deny from all Allow from env=let_me_in /FilesMatch ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
