Asterisk can solve that for you. I am playing with it now. It can do different things based on the received CID and even do things like play the "disconnected line" tone sequence before passing the call to you if the CID is unknown.
Just a word of advise: Don't use Quicknet's cards -- the cards work fine but the asterisk developers seem to have something against them, almost forcing you to use Digium's FXO/FXS cards instead. The PhoneJack/LineJacks will work fine for a little while and then you'll get weird problems like oddball rings, CID not being passed through, DTMF not being passed through, all kinds of little issues that you'll have to restart asterisk or reload the modules to fix. The standard answer on #asterisk is "Use Digium cards instead." Right.
That reminds me of the old DOS program, qt (qute [sic] time) -- "It's almost three" "It's just past half past four" "It's nearly twenty to two". Good stuff.:-)
Uh, Super FreeS/WAN? I use it over the stock FreeS/WAN because it includes the nat-traversal, Delete SA, and x.509 certificate patches. Mind you, I also prefer SSH Sentinel over the braindead Win2k/XP IPSec stacks. Here's a link to a nice howto if you insist on using Windows builtin, even though SSH Sentinel's under $60 a head.
Sorry, but if you think that Adabas D is actually worth something, you're short a few clues. Throw OO any ODBC or JDBC-enabled database (MySQL, PostgreSQL, MS SQL Server, hell even Access!) and you've got DB.
Adabas D sucks the big one. Not only for use, but installation is a pain on all supported platforms.
You could use gnuphone with a SSH or other VPN tunnel, or even a full blown asterisk point and use encrypted IAX transfers. Any old SIP phone would work too.
All of these are IP solutions. Any decent pair of phone encoders (where you encrypt and decrypt the audio stream) would be a lower-tech solution that might work better.
I thought everyone was settled on G.729a since that's what all the cell networks tend to use and the IP cores and whatnot are there, refined, tested and debugged thoroughly.
LKML verified it and I've experienced it personally -- TCQ on IBM Deathstar drives (mine were 60G, the LKML was 120G IIRC) can cause massive fs corruption.
Apparently a queue depth of 8 (the default it seems) is the specific culprit. LKML seems to say that TCQ of 32 works but I've turned it off entirely now.
Hmm, I must be doing something wrong... 2.2.something took about 4 hours to do on my 80386DX/33 (with copro!) with 8MB of memory (maxxed out on that old full-size DTK motherboard).
Um, I'd say forget D entirely and just use Checkinstall and compile them stuff you need on a more modern computer so you aren't spending hours compiling on that 80386 with 2MB of memory.
Sorry but I have very little faith in the American justice system to think objectively or rationally, especially in civil litigation and personal injury. I agree that people should be able to take their grievances to court, but again, I must stress that it should only be done once they're thinking clearly and objectively themselves.
Again, the court system should not be used to satisfy knee-jerk responses. If you've got a gripe and you still have it after thinking about it clearly, then by all means, bring it to court.
That's exactly the right take on this, IMHO. Shortly after the loss of a loved one, it's going to be difficult for anyone to be completely rational and objective. How about cutting them a little slack and dropping the cynicism for once?
In that case, they shouldn't be fucking around with lawyers and courts until they are thinking rationally and objectively. The courts should not be used to satisfy the knee-jerk responses of the bereaved.
Any distro will accomplish that. Hell even my personal favourite, Slackware, will do it, and IMO better than Debian or RH or SuSE, since the packages are far simpler and you don't have to fight the goddamned distro about dependencies.
Debian stable will probably work, but Moz 1.5 will make it there in, oh, 5 years? Testing and unstable are both worse than running no package manager at all, since you're trusting the packager until you need to break it to get something to work, at which point you're then running two package managers: dpkg and what's in your head.
No thanks. Give me Slackware and so long as you only [install|remove|upgrade]pkg you will never fall astray. Ever. And you get to use all the software, not just what someone's willing to maintain for you for free.
What 2G limit for email? We don't have a single email over about a couple dozen meg. Postgres stores mail attachments as large objects, which are individual files on disk. Mail headers and bodies are (this is from memory now, I may be mistaken) in a bunch of MAPI attributes.
I imagine you could get around the 2G limit by using fseek64(); you will likely have to recompile the apps you're using to make sure they use the proper seek/stat calls, and are using long longs for storing the file offsets.
We used a program called AddressMagic to convert the 7000 or so Outlook "Contacts Folder" contacts to LDIF in an attempt to get them into OpenLDAP. Much like you our efforts were in vain. Outlook's got too much crap in there that's just plain undocumented but our office staff use (categories being the biggest one).
I've been playing with Exchange4Linux -- Crappy name but some really nifty software. Everything is stored in PostgreSQL -- everything -- This is both a good thing and a bad thing; Postgres is well up to the task, but the E4L server software is quite slow at the moment. They've written it in Python, and it talks to the proprietary Outlook connector via CORBA. Why CORBA? I dunno; it doesn't talk through firewalls worth a shit.:-(
I've successfully imported our 4000 contacts without even blinking. I also imported an additional 3.2GB of email, journals, notes and schedule data. Postgres just took it in and asked for more. This is on a server with an UW3 disk subsystem and 1G of memory.
Looking at the DB any "pure" MAPI object is stored in plain english, both by parameter name and value. Any Outlook-specific crap is stored with MAPIhexstringhere names and whatever data format Outlook uses for the data. It would be dead simple trivial to convert that into LDAP, but why bother when PostgreSQL has an LDAP frontend you can probably get working.
The nicest thing about E4L is that the Outlook guys lose zero functionality and (when completed) the IMAP, LDAP and iCAP frontends will give full connectivity to the entire OSS crowd. E4L is planning on making money selling Outlook connector licenses (which aren't that dear, really) but as I mentioned earlier, the server is 100% OSS and free (beer and libre). I realize that oGo is out there but to be honest, oGo looks enormously complex and it's written in a hideous language. I'd rather spend my time learning Python than Objective-C any day, thank you very much. E4L's got a single unified backend (PostgreSQL) which is scalable and solid, and with some more work (moving more into stored procedures, using the LDAP frontend, etc.) it will be an Exchange killer. It already works flawlessly with Outlook, as I mentioned.
I've banished DHTML and all it encompasses. XWT is what I use now... No browser bugaboos, straight JavaScript, OSS, multiplatform, fast, client/server and perfectly clear separation of content from presentation.
All the thermal printers I've used with shipping computers have used pretty much standard Epson or HP-GL graphics modes. Set up a generic Epson printer with weird-ass margins and you're set.
But does anyone know what the status of v4l is in the 2.6 series? I went from 2.4.21 to 2.6.0-test3 (and now test4) as the HPT370 controller is iffy on Linux with APIC (this is an Epox EP-D3VA)... 2.6.0 completely solved all the APIC and SMP issues, but now V4L's not quite there.:-)
Slashdot Mirror
Asterisk can solve that for you. I am playing with it now. It can do different things based on the received CID and even do things like play the "disconnected line" tone sequence before passing the call to you if the CID is unknown.
Just a word of advise: Don't use Quicknet's cards -- the cards work fine but the asterisk developers seem to have something against them, almost forcing you to use Digium's FXO/FXS cards instead. The PhoneJack/LineJacks will work fine for a little while and then you'll get weird problems like oddball rings, CID not being passed through, DTMF not being passed through, all kinds of little issues that you'll have to restart asterisk or reload the modules to fix. The standard answer on #asterisk is "Use Digium cards instead." Right.
That reminds me of the old DOS program, qt (qute [sic] time) -- "It's almost three" "It's just past half past four" "It's nearly twenty to two". Good stuff. :-)
What if you just want perl to run fast on Apache? That's what I'm using it for.
Uh, Super FreeS/WAN? I use it over the stock FreeS/WAN because it includes the nat-traversal, Delete SA, and x.509 certificate patches. Mind you, I also prefer SSH Sentinel over the braindead Win2k/XP IPSec stacks. Here's a link to a nice howto if you insist on using Windows builtin, even though SSH Sentinel's under $60 a head.
Sorry, but if you think that Adabas D is actually worth something, you're short a few clues. Throw OO any ODBC or JDBC-enabled database (MySQL, PostgreSQL, MS SQL Server, hell even Access!) and you've got DB.
Adabas D sucks the big one. Not only for use, but installation is a pain on all supported platforms.
You could use gnuphone with a SSH or other VPN tunnel, or even a full blown asterisk point and use encrypted IAX transfers. Any old SIP phone would work too.
All of these are IP solutions. Any decent pair of phone encoders (where you encrypt and decrypt the audio stream) would be a lower-tech solution that might work better.
If you're running test kernels (and kernel-hacker specific patchsets to boot!) on a production server, you should be shot. Or at least demoted.
Uh, that's exactly what he was talking about; the OP had asked what mysql transaction problems he had...
I thought everyone was settled on G.729a since that's what all the cell networks tend to use and the IP cores and whatnot are there, refined, tested and debugged thoroughly.
LKML verified it and I've experienced it personally -- TCQ on IBM Deathstar drives (mine were 60G, the LKML was 120G IIRC) can cause massive fs corruption.
Apparently a queue depth of 8 (the default it seems) is the specific culprit. LKML seems to say that TCQ of 32 works but I've turned it off entirely now.
It's marked experimental for a reason. :-)
Oh come on... DopeWars! A full DopeWars run is right about perfect for a good toilet break.
Hmm, I must be doing something wrong... 2.2.something took about 4 hours to do on my 80386DX/33 (with copro!) with 8MB of memory (maxxed out on that old full-size DTK motherboard).
Um, I'd say forget D entirely and just use Checkinstall and compile them stuff you need on a more modern computer so you aren't spending hours compiling on that 80386 with 2MB of memory.
What next - somebody trying to evaluate the efficacy of NaCl in trapping avians when applied to their aft flight surfaces?
Don't be absurd -- everyone knows that you colour the edges of their beaks with a green marker to improve their sound.
But it's very rare that you get turned down at a Catholic church.
Having a child out of wedlock is a pretty easy way to get turned away, even today.
Sorry but I have very little faith in the American justice system to think objectively or rationally, especially in civil litigation and personal injury. I agree that people should be able to take their grievances to court, but again, I must stress that it should only be done once they're thinking clearly and objectively themselves.
Again, the court system should not be used to satisfy knee-jerk responses. If you've got a gripe and you still have it after thinking about it clearly, then by all means, bring it to court.
That's exactly the right take on this, IMHO. Shortly after the loss of a loved one, it's going to be difficult for anyone to be completely rational and objective. How about cutting them a little slack and dropping the cynicism for once?
In that case, they shouldn't be fucking around with lawyers and courts until they are thinking rationally and objectively. The courts should not be used to satisfy the knee-jerk responses of the bereaved.
I use something similar:
192.168.1.0/24 - LAN
192.168.2.0/24 - DMZ
192.168.3.0/24 - WLAN
192.168.4.0/24 - dialup (the firewall has 4 modems in it)
It's entirely subjective, but 10.0.0.0/8 is butt-ugly to me. :-)
Any distro will accomplish that. Hell even my personal favourite, Slackware, will do it, and IMO better than Debian or RH or SuSE, since the packages are far simpler and you don't have to fight the goddamned distro about dependencies.
Debian stable will probably work, but Moz 1.5 will make it there in, oh, 5 years? Testing and unstable are both worse than running no package manager at all, since you're trusting the packager until you need to break it to get something to work, at which point you're then running two package managers: dpkg and what's in your head.
No thanks. Give me Slackware and so long as you only [install|remove|upgrade]pkg you will never fall astray. Ever. And you get to use all the software, not just what someone's willing to maintain for you for free.
You're gonna make me ask... What's the 3 minutes and 56 seconds for?
What 2G limit for email? We don't have a single email over about a couple dozen meg. Postgres stores mail attachments as large objects, which are individual files on disk. Mail headers and bodies are (this is from memory now, I may be mistaken) in a bunch of MAPI attributes.
I imagine you could get around the 2G limit by using fseek64(); you will likely have to recompile the apps you're using to make sure they use the proper seek/stat calls, and are using long longs for storing the file offsets.
We used a program called AddressMagic to convert the 7000 or so Outlook "Contacts Folder" contacts to LDIF in an attempt to get them into OpenLDAP. Much like you our efforts were in vain. Outlook's got too much crap in there that's just plain undocumented but our office staff use (categories being the biggest one).
I've been playing with Exchange4Linux -- Crappy name but some really nifty software. Everything is stored in PostgreSQL -- everything -- This is both a good thing and a bad thing; Postgres is well up to the task, but the E4L server software is quite slow at the moment. They've written it in Python, and it talks to the proprietary Outlook connector via CORBA. Why CORBA? I dunno; it doesn't talk through firewalls worth a shit. :-(
I've successfully imported our 4000 contacts without even blinking. I also imported an additional 3.2GB of email, journals, notes and schedule data. Postgres just took it in and asked for more. This is on a server with an UW3 disk subsystem and 1G of memory.
Looking at the DB any "pure" MAPI object is stored in plain english, both by parameter name and value. Any Outlook-specific crap is stored with MAPIhexstringhere names and whatever data format Outlook uses for the data. It would be dead simple trivial to convert that into LDAP, but why bother when PostgreSQL has an LDAP frontend you can probably get working.
The nicest thing about E4L is that the Outlook guys lose zero functionality and (when completed) the IMAP, LDAP and iCAP frontends will give full connectivity to the entire OSS crowd. E4L is planning on making money selling Outlook connector licenses (which aren't that dear, really) but as I mentioned earlier, the server is 100% OSS and free (beer and libre). I realize that oGo is out there but to be honest, oGo looks enormously complex and it's written in a hideous language. I'd rather spend my time learning Python than Objective-C any day, thank you very much. E4L's got a single unified backend (PostgreSQL) which is scalable and solid, and with some more work (moving more into stored procedures, using the LDAP frontend, etc.) it will be an Exchange killer. It already works flawlessly with Outlook, as I mentioned.
I've banished DHTML and all it encompasses. XWT is what I use now... No browser bugaboos, straight JavaScript, OSS, multiplatform, fast, client/server and perfectly clear separation of content from presentation.
Screw DHTML. XWT is the future.
All the thermal printers I've used with shipping computers have used pretty much standard Epson or HP-GL graphics modes. Set up a generic Epson printer with weird-ass margins and you're set.
But does anyone know what the status of v4l is in the 2.6 series? I went from 2.4.21 to 2.6.0-test3 (and now test4) as the HPT370 controller is iffy on Linux with APIC (this is an Epox EP-D3VA)... 2.6.0 completely solved all the APIC and SMP issues, but now V4L's not quite there. :-)
Ahh, the bleeding edge...