I recall seeing a project on freshmeat in 1999-2000 about the exact same functionnality. Granted, it wasn't as refined as this one, but it did exactly what it had to do; sniff packets over the wire, decode them, and send them to your DSP.
This is old, and that's why people today use VLAN tagged phones to seperate VOIP traffic onto another network, combined with switches that don't allow promiscuous activities, intrusion detection systems, picky switches that don't like MAC changes, and voilà, problem solved for the distribution networks.
There will always be ways to tap coversations, and if you think you pots land line is secure *chuckle*, get real.
There's a great app out there from Tivoli that's call CDP (constant data protection). The lic is cheap (40$), and basically, it replicates everything whenever it can to a central fileserver via CIFS / WebDAV or even TSM if you use Tivoli Storage Manager.
It's an amazing product, and it's even WAN conscious; so you've got the best of both worlds for data replication & recovery. It also does subfile replication which avoids to send the whole file over the wire if there's just a few blocks changed.
Of course, there's CDP that's cheap and effective; the next best thing is Tivoli Storage Manager. The clients can be configured to PUSH instead to get pulled from the backup server. So you can have your laptops everywhere and and not necessarily connected to the lan during your backup window, and it will stream all the changes over the net to your TSM server in an encrypted fashion and allows your to even do bare-metal recovery.
The workaround in the DSL world, to avoid the dreadded Bell Cloud, are ISP's/telco's who have their own DSLAM's, which means, their own private network, and DSL modems that aren't mainstream
The only ones I know in Montreal are Sprint/GT that have their SDSL service using Lucent CellPipe equipment
Actually what you don't know about Primus, is that its not their fault; but Bell Canada who hasn't been maintaining their ATM cloud that interconnects YOU and Primus together.
So, you can put the blame on the ISP, however, the true blame is the "behind the scenes" carrier that is good old Ma-Bell.
I've had soo many problems related to Bell's deficiencies, and its nothing that can be easily resolved. I've heard stories as amusing as a remote DLSAM having all of its's subscriber ports FULL, causing a waiting list for ADSL subscription in the area, and, to top-off the frustration, the 45mbps ATM link tops the 100% usage during the evening.
So, how does the enduser perceive this? The ISP is shitty as hell, tech support is incompetent, so the enduser switches DSL provider to only realize that the crappy speed continues. Next thing you know, he's subscribing to Cable where its suddenly "fast" again.
There's a lot of the voip glitches that are associated to the back-end carrier that manages the ATM cloud that interconnects the subscriber (you), and the ISP (primus). You can't see it with regular web browsing, but the second you start using realtime protocols, you'll notice it.
It depends.. (do note: I'm not the expert, I just was forced to play(hack) with it when things didn't work)
The OS/400-centric implementation would have a tendancy of managing the partitions from the OS400 operating system, feeding-off virtual scsi devices to the neighbour partitions, which is logical in a way, since you confine all your backups to one operating system.
The LPAR will pool your cpu and memory ressources, but you still have to feed it an I/O subsystem for Disks, Ethernet, etc.. I aven't seen it do that, except assign physical ethernet devices. Which means that you can't share a CDROM, a Disk, an Ethernet card, unless you have a partition managing this, in this case, the OS/400, maybe there is a way, but I'm not the expert, I just implement the guest Linux partitions.
Redundancy is achieved with multiple independent subsystems
Well, in the case of LPAR, when your host OS decides to pull a quickie on you, you find yourself on a standstil with an entire company of 100+ users without their apps running. I wouldn't like to be in the shoes of the iSeries admin in that case.
I've worked on it on a few times, and its still a bit buggy, but IBM seems to never cease to amaze me by pulling-out new patches on a daily/weekly basis. With time, this technology will perfect itself, and when it will, it will really rock, for now, I'd still go with a BladeCenter + SAN.
I do some implementation projects for an IBM reseller who does implementations on the iSeries platform, and they push (and I implement as the consultant, go figure) a lot Samba + Bynari to the point that I was actually convinced myself and bought myself a few lics for Bynari.
The nice part about Bynari is that they have great support, and they are continueously improving their product, and they use open technologies (OpenLDAP/Cyrus/Postfix) so its easily hackable. The Outlook IMAP connector rocks, and so far, I think is the only viable product out there if you're on a trim budget.
I haven't tried it yet, but having Bynari and Samba share the same LDAP schema seems to be my next personal project. Maybe even lobby the concept to them;)
Command line interface (CLI) is the way to go for real PBX systems. There is no GUI out there that really takes advantage of all the features of what Asterisk can do. And if you do need a gui to do something, chances are, you shouldn't be running your own PBX.
Very true, the average programmer is someone who is socially inept, and cannot efficiently communicate their intentions. Consequently, they get abused into the corporate structure, making them the end of the food chain.
The only way to break this social barrier is to immerse them in a situation where they have no choice but to interact with human beings. From experience, my best move was to work for a year in a call-center. Now , I have bosses who hate me because I give them the exact reality of their projects.:)
Programmers are at the end of the food chain buddy. That's why you need to upgrade and become part of a function that requires decision and analysis. Or , if you're looking for the easy exit, a Sysadmin:)
Re:Hang in there?...fP?
on
The 3Com Saga
·
· Score: 5, Insightful
3Com has always been a highly-regarded company in my opinion, because they provided quality network/communication solutions.
However, across the years, network integration got tighter, standardized, and quite honestly, 3com's purpose is loosing against companies such as Linksys, D-Link, and other names that just sound "tacky". Think about it, you've got network cards made by a company that used to make cables. Motherboard makers are embedding their network functionnality. 3Com's telephone systems weren't that great. Their switches are over-priced for what they can do.
On the other hand, the 3c5xx ethernet chipsets are still the most reliable nic's that I've even seen... But I don't think they can just survive on nic's
3Com's biggest problem is that they stayed focused to the corporate world, while the corporate world (SME's) started cutting corners and started buying SOHO stuff instead, because the product was much more adapted to their needs than an enterprise-grade device.
As much as I loved my good ole Ericsson T39, for being the first one to combine BlueTooth/IRDA/GPRS/GSM into one nice little package, the damn phone had one of the weirdest symptoms.
If it would be humid outside (just before a storm), and my hands were sweating, I would be getting shocks on my ear from my phone.
Nowadays, most cell phones use a high-voltage inverter to power the screen (color, backlit, etc..), which basically means, taking that 3.3/5v DC battery current into ~ 40-60volts AC and even more (I'm not certain).
I'm not an electrical engineer, but essentially, if the humidity is right, and you walked-out of your car that was nicely cooled and dry from your air conditionner, the fact of rubbing on your chair generated static electricity in you. Adding the cell phone as a catalyst for an electrical discharge sounds reasonable no?
You've got a device generating A/C as very low amperage that does not have any grounding point, and the humidity provides the necessary gap of discharging through your body to the gas pump (the closest grounding source)
During the days, working for a company that wanted to obtain a CLEC status, one of the prerequisites (if my memory serves me right), was to allow the RCMP to easily be able to wire-tap on-net and off-net calls.
Aside the slower-economy, and the fact that you need to wear snow-shoes year-round, to get to work, it's a wise choice;)
One day, I had nothing else to do, decided to legitimately take advantage of my hardware purchase benefits at work, and bought a Compaq TC-1000 Tablet, considering that I had gotten myself a pretty good deal.
A few little things I noticed:
1) Crusoe 1ghz really lack CPU torque
2) The Compaq is quite schweet, but lacks cpu torque
3) I still would have prefered to waste my money on an Apple PowerBook instead.
To sum it up, don't buy a tablet unless you only anticipate it to use it as a web tablet, to use it as a computer to access a Unix box at a customer, email/spreadsheets/documents, and that's about it.
On the lighter side, I have a Compaq TC-1000 for sale;)
Indeed, learning ASM before, or while you're touching a simpler programming language is a great step to learn on how to write tight and efficient code.
However, it's not just the comprehension of how the CPU works that is required. I've noticed many junior programmers, when they code, all they write and think about is inside their own little box surrounded by their compiler. Not thinking of network performance issues, interrupted database connections, data scalability, the fact that the day there is a bug, the presence of external dependancies, etc..
The problem resides on understanding the impact of all systems and subsystems that your program will be calling-out. When you program, and you're calling-out ressources that are outside of your program, you must be aware of what you're doing and who are you affecting. And, while you're at it, anticipate worst-case scenarios, like growth issues, fucked-up customer networks, the firewalls that break all the fun of calling-out RPC over a wan, etc..
So, ASM is a good step, but, it takes more than that, you need to understand (at the very least, conceptually) every single element that constitutes your production environment.
There are many different alternatives. Yes, using a laptop is much more power-efficient, and you can get yourself power-adapters to convert DC to DC current to charge your laptop from a 12v battery car.
However, there is also a Mini-ITX form-factor system, to which you can find cases with built-in DC switching power supplies.
I think the solution is to stay native to DC current, and then convert as you see fit. So, all you need to have is a set of car batteries, connected to solar panels (for charging purposes), and you set-up some sort of power distribution & management system.
Having been a patron of hand-held wireless devices for a long time. I must say, after I got my TabletPC, I'll never go to a Palm-sized pocket PC.
Besides, the tablet offers much more flexibility. The processor is an x86 compatible, the operating system is XP or can be replaced easily with Linux, the weight is just under 1.5 pounds, and the best part, it features a built-in 802.11 device, and your desktop apps work without any problem.
I currently use Netstumbler and it suits most of my needs to "audit" the airspace around me, and it works great (specialy when I combine a USB GPS)
I feel soo bad, considering that I just ordered about 2K of licensing upgrades from a SCO distributor for a client yesterday.:(
If it wasn't for a proprietary set of apps, Linux + SCO bin emu was looking very good. I even had a chance to test this scenario, but encountered some serious issues.
This just proves that, like any other commercial OS, if a company adopts a commercial OS, and their production apps are taylored to that environment, the companies are just locked-in, wether they like it or not.
I manage a web hosting service, and, before you can try to figure-out what's your best data solution, you need to understand your usage.
I solved our bandwidth issue with the developpement of a SNMP bandwidth collector that calculates every 5 minutes, the running rate, and tabulates the sum of data. With that, I was able to calculate, on my own, my total usage per month, per day, per hour, per 5 minutes.
It turns out, after 1 month of data, going with a rate that is calculated at the 95th percentile, was the most efficient method, because it allowed me to feed my bursts and not get penalized, and it lowered significantly my $$ / gig (50% cheaper).
So, like I say, good analysis tools, a traffic shaper, and good relationship with your ISP saves you a lot of $$ on bandwidth charges
Indeed, you're right, however, for this to actually become interesting, they are going to have some sort of plug-in model where you can attach protocol signatures, to build your shaper as your network evolves.
Considering the fact that there are new apps being written every day, it's going to be difficult to have a layer-7 shaper that will be "up to date" with current applications and protocol uses.
Anyways, I still believe in the militant/BOFH sysadmin approach: NO INTERNET FOR YOU!
Slashdot Mirror
I recall seeing a project on freshmeat in 1999-2000 about the exact same functionnality. Granted, it wasn't as refined as this one, but it did exactly what it had to do; sniff packets over the wire, decode them, and send them to your DSP.
This is old, and that's why people today use VLAN tagged phones to seperate VOIP traffic onto another network, combined with switches that don't allow promiscuous activities, intrusion detection systems, picky switches that don't like MAC changes, and voilà, problem solved for the distribution networks.
There will always be ways to tap coversations, and if you think you pots land line is secure *chuckle*, get real.
There's a great app out there from Tivoli that's call CDP (constant data protection). The lic is cheap (40$), and basically, it replicates everything whenever it can to a central fileserver via CIFS / WebDAV or even TSM if you use Tivoli Storage Manager.
It's an amazing product, and it's even WAN conscious; so you've got the best of both worlds for data replication & recovery. It also does subfile replication which avoids to send the whole file over the wire if there's just a few blocks changed.
Of course, there's CDP that's cheap and effective; the next best thing is Tivoli Storage Manager. The clients can be configured to PUSH instead to get pulled from the backup server. So you can have your laptops everywhere and and not necessarily connected to the lan during your backup window, and it will stream all the changes over the net to your TSM server in an encrypted fashion and allows your to even do bare-metal recovery.
Both sweet stuff.
The workaround in the DSL world, to avoid the dreadded Bell Cloud, are ISP's/telco's who have their own DSLAM's, which means, their own private network, and DSL modems that aren't mainstream
The only ones I know in Montreal are Sprint/GT that have their SDSL service using Lucent CellPipe equipment
Actually what you don't know about Primus, is that its not their fault; but Bell Canada who hasn't been maintaining their ATM cloud that interconnects YOU and Primus together.
So, you can put the blame on the ISP, however, the true blame is the "behind the scenes" carrier that is good old Ma-Bell.
I've had soo many problems related to Bell's deficiencies, and its nothing that can be easily resolved. I've heard stories as amusing as a remote DLSAM having all of its's subscriber ports FULL, causing a waiting list for ADSL subscription in the area, and, to top-off the frustration, the 45mbps ATM link tops the 100% usage during the evening.
So, how does the enduser perceive this? The ISP is shitty as hell, tech support is incompetent, so the enduser switches DSL provider to only realize that the crappy speed continues. Next thing you know, he's subscribing to Cable where its suddenly "fast" again.
There's a lot of the voip glitches that are associated to the back-end carrier that manages the ATM cloud that interconnects the subscriber (you), and the ISP (primus). You can't see it with regular web browsing, but the second you start using realtime protocols, you'll notice it.
It depends.. (do note: I'm not the expert, I just was forced to play(hack) with it when things didn't work)
The OS/400-centric implementation would have a tendancy of managing the partitions from the OS400 operating system, feeding-off virtual scsi devices to the neighbour partitions, which is logical in a way, since you confine all your backups to one operating system.
The LPAR will pool your cpu and memory ressources, but you still have to feed it an I/O subsystem for Disks, Ethernet, etc.. I aven't seen it do that, except assign physical ethernet devices. Which means that you can't share a CDROM, a Disk, an Ethernet card, unless you have a partition managing this, in this case, the OS/400, maybe there is a way, but I'm not the expert, I just implement the guest Linux partitions.
Oh, and an after-thought:
Redundancy is achieved with multiple independent subsystems
Well, in the case of LPAR, when your host OS decides to pull a quickie on you, you find yourself on a standstil with an entire company of 100+ users without their apps running. I wouldn't like to be in the shoes of the iSeries admin in that case.
I've worked on it on a few times, and its still a bit buggy, but IBM seems to never cease to amaze me by pulling-out new patches on a daily/weekly basis. With time, this technology will perfect itself, and when it will, it will really rock, for now, I'd still go with a BladeCenter + SAN.
I do some implementation projects for an IBM reseller who does implementations on the iSeries platform, and they push (and I implement as the consultant, go figure) a lot Samba + Bynari to the point that I was actually convinced myself and bought myself a few lics for Bynari.
The nice part about Bynari is that they have great support, and they are continueously improving their product, and they use open technologies (OpenLDAP/Cyrus/Postfix) so its easily hackable. The Outlook IMAP connector rocks, and so far, I think is the only viable product out there if you're on a trim budget.
I haven't tried it yet, but having Bynari and Samba share the same LDAP schema seems to be my next personal project. Maybe even lobby the concept to them ;)
Command line interface (CLI) is the way to go for real PBX systems. There is no GUI out there that really takes advantage of all the features of what Asterisk can do. And if you do need a gui to do something, chances are, you shouldn't be running your own PBX.
Very true, the average programmer is someone who is socially inept, and cannot efficiently communicate their intentions. Consequently, they get abused into the corporate structure, making them the end of the food chain.
The only way to break this social barrier is to immerse them in a situation where they have no choice but to interact with human beings. From experience, my best move was to work for a year in a call-center. Now , I have bosses who hate me because I give them the exact reality of their projects. :)
Programmers are at the end of the food chain buddy. That's why you need to upgrade and become part of a function that requires decision and analysis. Or , if you're looking for the easy exit, a Sysadmin :)
3Com has always been a highly-regarded company in my opinion, because they provided quality network/communication solutions.
However, across the years, network integration got tighter, standardized, and quite honestly, 3com's purpose is loosing against companies such as Linksys, D-Link, and other names that just sound "tacky". Think about it, you've got network cards made by a company that used to make cables. Motherboard makers are embedding their network functionnality. 3Com's telephone systems weren't that great. Their switches are over-priced for what they can do.
On the other hand, the 3c5xx ethernet chipsets are still the most reliable nic's that I've even seen... But I don't think they can just survive on nic's
3Com's biggest problem is that they stayed focused to the corporate world, while the corporate world (SME's) started cutting corners and started buying SOHO stuff instead, because the product was much more adapted to their needs than an enterprise-grade device.
As much as I loved my good ole Ericsson T39, for being the first one to combine BlueTooth/IRDA/GPRS/GSM into one nice little package, the damn phone had one of the weirdest symptoms.
If it would be humid outside (just before a storm), and my hands were sweating, I would be getting shocks on my ear from my phone.
Nowadays, most cell phones use a high-voltage inverter to power the screen (color, backlit, etc..), which basically means, taking that 3.3/5v DC battery current into ~ 40-60volts AC and even more (I'm not certain).
I'm not an electrical engineer, but essentially, if the humidity is right, and you walked-out of your car that was nicely cooled and dry from your air conditionner, the fact of rubbing on your chair generated static electricity in you. Adding the cell phone as a catalyst for an electrical discharge sounds reasonable no?
You've got a device generating A/C as very low amperage that does not have any grounding point, and the humidity provides the necessary gap of discharging through your body to the gas pump (the closest grounding source)
Are you really certain?
During the days, working for a company that wanted to obtain a CLEC status, one of the prerequisites (if my memory serves me right), was to allow the RCMP to easily be able to wire-tap on-net and off-net calls.
Aside the slower-economy, and the fact that you need to wear snow-shoes year-round, to get to work, it's a wise choice ;)
One day, I had nothing else to do, decided to legitimately take advantage of my hardware purchase benefits at work, and bought a Compaq TC-1000 Tablet, considering that I had gotten myself a pretty good deal.
A few little things I noticed:
1) Crusoe 1ghz really lack CPU torque
2) The Compaq is quite schweet, but lacks cpu torque
3) I still would have prefered to waste my money on an Apple PowerBook instead.
To sum it up, don't buy a tablet unless you only anticipate it to use it as a web tablet, to use it as a computer to access a Unix box at a customer, email/spreadsheets/documents, and that's about it.
On the lighter side, I have a Compaq TC-1000 for sale ;)
Bah, that works, but don't feel soo lucky when you end-up talking to a human being.
They can always throw you back into the holding queue
Indeed, learning ASM before, or while you're touching a simpler programming language is a great step to learn on how to write tight and efficient code.
However, it's not just the comprehension of how the CPU works that is required. I've noticed many junior programmers, when they code, all they write and think about is inside their own little box surrounded by their compiler. Not thinking of network performance issues, interrupted database connections, data scalability, the fact that the day there is a bug, the presence of external dependancies, etc..
The problem resides on understanding the impact of all systems and subsystems that your program will be calling-out. When you program, and you're calling-out ressources that are outside of your program, you must be aware of what you're doing and who are you affecting. And, while you're at it, anticipate worst-case scenarios, like growth issues, fucked-up customer networks, the firewalls that break all the fun of calling-out RPC over a wan, etc..
So, ASM is a good step, but, it takes more than that, you need to understand (at the very least, conceptually) every single element that constitutes your production environment.
There are many different alternatives. Yes, using a laptop is much more power-efficient, and you can get yourself power-adapters to convert DC to DC current to charge your laptop from a 12v battery car.
However, there is also a Mini-ITX form-factor system, to which you can find cases with built-in DC switching power supplies.
I think the solution is to stay native to DC current, and then convert as you see fit. So, all you need to have is a set of car batteries, connected to solar panels (for charging purposes), and you set-up some sort of power distribution & management system.
Having been a patron of hand-held wireless devices for a long time. I must say, after I got my TabletPC, I'll never go to a Palm-sized pocket PC.
Besides, the tablet offers much more flexibility. The processor is an x86 compatible, the operating system is XP or can be replaced easily with Linux, the weight is just under 1.5 pounds, and the best part, it features a built-in 802.11 device, and your desktop apps work without any problem.
I currently use Netstumbler and it suits most of my needs to "audit" the airspace around me, and it works great (specialy when I combine a USB GPS)
.I feel soo bad, considering that I just ordered about 2K of licensing upgrades from a SCO distributor for a client yesterday. :(
If it wasn't for a proprietary set of apps, Linux + SCO bin emu was looking very good. I even had a chance to test this scenario, but encountered some serious issues.
This just proves that, like any other commercial OS, if a company adopts a commercial OS, and their production apps are taylored to that environment, the companies are just locked-in, wether they like it or not.
I manage a web hosting service, and, before you can try to figure-out what's your best data solution, you need to understand your usage.
I solved our bandwidth issue with the developpement of a SNMP bandwidth collector that calculates every 5 minutes, the running rate, and tabulates the sum of data. With that, I was able to calculate, on my own, my total usage per month, per day, per hour, per 5 minutes.
It turns out, after 1 month of data, going with a rate that is calculated at the 95th percentile, was the most efficient method, because it allowed me to feed my bursts and not get penalized, and it lowered significantly my $$ / gig (50% cheaper).
So, like I say, good analysis tools, a traffic shaper, and good relationship with your ISP saves you a lot of $$ on bandwidth charges
Indeed, you're right, however, for this to actually become interesting, they are going to have some sort of plug-in model where you can attach protocol signatures, to build your shaper as your network evolves.
Considering the fact that there are new apps being written every day, it's going to be difficult to have a layer-7 shaper that will be "up to date" with current applications and protocol uses.
Anyways, I still believe in the militant/BOFH sysadmin approach: NO INTERNET FOR YOU!
;)
I've been doing traffic shaping based on port policies for months using the CBQ.init Script.
What's the advantage of using Layer-7 shaping, when CBQ does it quite efficiently?