05 Nov 16 17:56, you wrote to me:   
      
    ml>> instead of dynamic... IIRC, paul's build of crashmail 0.71 is built   
    ml>> static... file will tell you that if you haven't looked already...   
      
    RC> ummm...$ file ~/crashmail-0.71/bin/crashmail   
    RC> /home/rec9140/crashmail-0.71/bin/crashmail: ELF 64-bit LSB  executable,   
    RC> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for   
    RC> GNU/Linux 2.6.24, BuildID[sha1]=27de05981b233984f8ca78c8af4a3d4113d0bd2b,   
    RC> stripped   
      
    RC> This shows *dynamically linked (uses shared libs),*   
      
   i thought i had seen him say that he compiled something static... oh well... i   
   didn't go hunting for that post in my bases...   
      
    RC> Guess that is 64b, which is why it runs.. as its "ELF 64-bit LSB" ...   
    RC> I don't now... too many things I've looked at...   
      
   yes, that's what it says above... i guess you'll know in time if that ace up   
   your sleeve was really the ace you thought it was...   
      
    ml>> i'm not one of those monkeys either... never have been but i can   
    ml>> mostly muddle my way through when necessary... like when i fixed a   
    ml>> couple of bugs and added some features to my private build...   
      
    RC> Well unfortunately I know a lot, A LOT more C than I care to admit..   
    RC> simply because of lot of things I'd rather not remember....   
      
   )   
      
    RC> I am looking as posted in ehco and the bug report to "fake out" PAN   
    RC> and KNode to work with JamNNTPd.. but I need to make sure I've   
    RC> resolved any potential of this nonsense in re the corruption of JAM   
    RC> bases because of the 32b v. 64b issues..   
      
   do we even know if it was an alignement problem yet? no... all we know is that   
   you were seeing corruption but there's been no detailed analysis of the data   
   files AFAIK... "detailed analysis" as in studying them under a hex viewer or   
   similar...   
      
    RC> Thats the point in asking is the SF site and 1.3 good??? No, its   
    RC> flawed like post 071 CM II's or if the resolution of an option to   
    RC> force m32 solves this.. or only the code form the eljaco.se site   
    RC> should be messed with???   
      
   i've already stated that i'm running a modified 32bit 1.2 compile over here on   
   my main system... the one you were using... my main system is/was a beta site   
   for JAM when it was first introduced... if there's corruption i definitely   
   know about it... especially with retaining posts for as long as i do...   
      
    RC> I've put several ideas on faking out PAN/KNode... I just need to find   
    RC> a decent c interpreter to play with... its not a project I want to   
    RC> take on, but I am forced to.. as using thunderturkey just crankles me   
    RC> to no end....   
      
   i've used pine, slrn, and similar with no problems... i've never tried knode   
   or pan... don't intend to, either... i'm trying to remember the python one i   
   used that allowed me to find and fix a bug or two... ahhh... XPN 1.2.6...   
      
    ml>> who needs a real iron clunker when one can run a VM? ;)   
      
    RC> Unfortunately you can't  virtualize SDR sticks or Line in's for audio.. so   
    RC> real hardware at times is what it takes....   
      
   who needs an sdr or sound card on a fidonet system?   
      
    RC> Plus I dislike throwing out perfectly working hardware that might need   
    RC> a little TLC to upgrde a CPU, max out some RAM or a bigger HD.. and   
    RC> then turn it into a VM host for somethings, or run LXC containers, or   
    RC> VPN server or .....   
      
    RC> But for the RTL-SDR stuff and some other stuff I am invoved in, I need   
    RC> hardware to plug it into.. SDR doesn't work good, no at all under VMWare,   
      
   yech... have you tried QEMU/KVM? that's all i use...   
      
    RC> and it has much better USB support than the love child of the Linux   
    RC> crowd.. thats why VMWare is my goto VM for anything production.. test   
    RC> and play with any thing from VMW to LXC..   
      
   oh well :shrug:   
      
    ml>> i'd be really surprised if these packages can be compiled on ARM   
    ml>> systems... especially jamnntpd since there's only linux, os2 and   
    ml>> win32 headers...   
      
    RC> ARMHF for the PI's probably is not a problem as the Pi's are still   
    RC> using 32b.. the Pi3 is or can be 64b, but Raspbian or something was   
    RC> not set up that way.. or.. I didn't keep up with it... Raspbian has   
    RC> issues in re Jessie and systemd.... justlike post 14.x *buntus...   
      
   i understand that they're using a 32bit OS only because there's only 1Gig of   
   RAM on the things... i've thought about getting one to play with but 1Gig is   
   not enough for the projects i have in mind... 2Gig is just barely adequate...   
      
    RC> I'd have to find some spare PI's first.. these get gobbled up for   
    RC> projects quick!   
      
   :lol:   
      
    ml>> i'd be concerned about the switching from unsigned variables to   
    ml>> signed ones...   
      
    RC> I don't know.. what was changed...   
      
   i specifically looked and read the diff...   
      
    RC> I just know I found it interesting that it showed up, and   
    RC> was/is/possibly a result of this whole mess with what ever happened   
    RC> past the 071 version..  based on that 64b support... I didn't go any   
    RC> further than bookmark it... for later review... its just something   
    RC> thats out there...but dormant too.   
      
   there's a lot out there... quite a few people have repos where they are   
   working on the code and then contributing their work back to a central repo...   
   that's why your stupid comment about having 1.3 removed from SF was well...   
   stupid... and people let you know about it... you don't go taking someone   
   else's hard work away like that when you don't know the condition or even why   
   it is like it is... there are choices in life and using ancient broken   
   binaries from some distribution's repo or pulling newer sources from another   
   repo and compiling yourself is just part of the linux world... apparently   
   you've been sheltered in that respect... that's not a bad thing but it sure is   
   a wake up call, as you've found out, when you step off into other worlds that   
   are definitely hobbiest oriented... welcome to the club! maybe you can help in   
   getting some other things updated and fixed but the first step is seeing the   
   land for what it really is ;)   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... Law of Combat: No inspection-ready unit has ever passed combat.   
   ---   
    * Origin:  (1:3634/12.73)