Re: developer laptop choices
Do you guys use your WWAN card under OpenBSD at all? :) Sure. I'm typing this on a Thinkpad T41p (bought used on ebay.de 1.5 years ago), using the local wavelan at a conference. ipw(4) works fine if you read 'man ipw' and pkg_add the firmware described in the man page. On the whole I'm happy with Thinkpads, and my next laptop will probably be another one (bought used -- computers depreciate so fast that a 1-year-old model costs 1/2 the new price, and is still a very nice computer). ciao, -- -- From: Jonathan Thornburg [remove -animal to reply][EMAIL PROTECTED] School of Mathematics, U of Southampton, England C++ is to programming as sex is to reproduction. Better ways might technically exist but they're not nearly as much fun. -- Nikolai Irgens
Re: 4.1-stable 'make build' dies with 'out of memory' building perl
In http://marc.info/?l=openbsd-miscm=118786051715312w=1 I wrote: I run -stable on an IBM/Lenovo T41p laptop with 512M memory and 2G swap. I cvs-updated /usr/src on Aug 22 around 21:00 GMT. As usual, I followed the instructions at http://www.openbsd.org/stable.html to rebuild... but unlike all the other times I've done this, this time 'make build' died while building perl. [[...cut-n-paste error transcript ending with out of memory...]] A 'make build' usually takes 2 or 3 hours on this system, and the system has enough memory that (with the top-level 'make build' at nice 20) I don't notice any significant slowdown in concurrent interactive use. I've certainly never noticed 'make build' paging before. How much memory is an i386 4.1-stable 'make build' supposed to need? Or is this more likely a cvs bit-bash which has garbled my tree and the failure symptom just happens to be an infinite recursion somewhere? I'm pleased to report that I have solved the problem: Just (as root) rm /etc/malloc.conf (which previously was a symlink pointing to FGJP). So... it seems that 'make build' doesn't like malloc.conf being set to something other than the default (which is 'nothing at all'). Ok, lesson learned for next time... My question now is, was this an OpenBSD bug (which I should report on gnats), or a user error (which I should not report on gnats, at least not on the OpenBSD gnats :) ? ciao, -- -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
4.1-stable 'make build' dies with 'out of memory' building perl
I run -stable on an IBM/Lenovo T41p laptop with 512M memory and 2G swap. I cvs-updated /usr/src on Aug 22 around 21:00 GMT. As usual, I followed the instructions at http://www.openbsd.org/stable.html to rebuild... but unlike all the other times I've done this, this time 'make build' died while building perl. Here's a cut-n-paste of the last part of the build process: Running Mkbootstrap for Encode::Byte () chmod 644 Byte.bs rm -f ../../../lib/auto/Encode/Byte/Byte.so cc -shared -fPIC Byte.o byte_t.o -o ../../../lib/auto/Encode/Byte/Byte.so chmod 755 ../../../lib/auto/Encode/Byte/Byte.so cp Byte.bs ../../../lib/auto/Encode/Byte/Byte.bs chmod 644 ../../../lib/auto/Encode/Byte/Byte.bs cp CN.pm ../../../lib/Encode/CN.pm ../../../miniperl -I../../../lib ../bin/enc2xs -Q -o gb_02_t.c -f gb_02_t.fnm Reading gb12345-raw (gb12345-raw) Writing compiled form 34800 bytes in string tables 2786 bytes (7.41%) saved spotting duplicates ../../../miniperl -I../../../lib ../bin/enc2xs -Q -o eu_01_t.c -f eu_01_t.fnm Reading euc-cn (euc-cn) Writing compiled form 34638 bytes in string tables 2566 bytes (6.9%) saved spotting duplicates ../../../miniperl -I../../../lib ../bin/enc2xs -Q -o cp_00_t.c -f cp_00_t.fnm Reading cp936 (cp936) Writing compiled form Out of memory! *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/obj/ext/Encode/CN (line 778 of Makefile). *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/obj/ext/Encode (line 614 of Makefile). *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/obj (line 608 of Makefile). *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl (line 598 of /usr/src/gnu/usr.bin/perl/Makefile.bsd-wrapper). *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src (line 73 of Makefile). # A 'make build' usually takes 2 or 3 hours on this system, and the system has enough memory that (with the top-level 'make build' at nice 20) I don't notice any significant slowdown in concurrent interactive use. I've certainly never noticed 'make build' paging before. I started the 'make build' shell via 'su -' from a normal-user shell (then 'renice +20 12345' from another super-user shell). I have /etc/login.conf set to allow group 'staff' (in practice, that's just me) unlimited memory use, but the defaults are unchanged for daemon which the comments in /etc/login.conf say are used by /etc/rc and root. Checking another similarly-started root shell just now shows # ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes)8192 lockedmem(kbytes)unlimited memory(kbytes) unlimited nofiles(descriptors) 128 processes532 # How much memory is an i386 4.1-stable 'make build' supposed to need? Or is this more likely a cvs bit-bash which has garbled my tree and the failure symptom just happens to be an infinite recursion somewhere? (In which case the fix is easy, rm -rm the relevant part of the tree and re-cvs it.) thanks for any suggestions, ciao, -- -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
