Happy New Year! Sorry I've missed posting in a couple months.
It's odd to me, when sysadmins tell me that "Serial Consoles are Dead. USB killed them." But, when I ask them what they mean, I get different answers.
The first meaning is: "RS-232 is dead, long live USB!" So, then I ask them what they do when they need to get to the serial console, and they tell me about needing to find a USB-to-DE9 serial adapter, get that to work, and point the serial console getty to that device. ("I bet that's tough to do when you are having trouble with a server" I offer. They usually agree that it is...)
The second meaning is: "You don't need DE-9 connectors anymore, you can do it all with USB". This has more insidious meanings...
2a) Most new servers don't have a DE-9 connector on the chassis, just USB ports.
2b) If I need a serial port, I can add a USB-to-DE9 dongle, and use minicom.
Have you ever tried plugging in a USB-connected external modem, and then tried to dial into it, to access the serial console (getty) on your server? The adventure is fraught with problems, which must be solved with a Crash Cart or other form of KVM or remote desktop (which means you need to think about it BEFORE you have a problem, so that it's a useful avenue when trouble presents itself).
Remember, the serial console has been your friend, when the network or the network-facing configuration goes awry. Do you think USB is ready to replace that role? Can you go to Fry's, and buy a USB-to-USB cable which you can simply plug in between two servers, and automatically establish a "null-modem"-type data path? I haven't seen one. Why Not?
Someone needs to develop a little, microprocessor pod, with two USB cables. Power the unit from the 5-volt signal from either USB device. Maybe even add some TX and RX data status LEDs, to show which USB cable is talking. You don't even need to do the conversion from TTL to RS-232 and back...just keep it all at TTL levels! But the microprocessor needs to be able to talk to each USB port when the computer inquires "Who are you, what are you?"...this is the key!
USB relies on drivers, residing on your computer(s), to recognize the ID sent from a USB-attached device when you first plug it in. To make things easy, many basic drivers are bundled into Operating System packages, which lets you plug in many devices without needing to install the drivers first. (This is the difference between Play and Pray in "Plug-n-Play" architecture.)
Looking at the basic USB-to-DE9 dongles, most are derivative works from two basic hardware types. For example, since Brands A, G, M and Q all use "Chip X", and Brands D, I and S all use "Chip Z", it's easy to see that just having two basic (generic) drivers will let you plug in most of the devices from these 7 brands of dongles. Getting Microsoft, and the various Linux distributions is an important step in making things easier for the folks who use these operating systems with serial devices.
But, if you make this USB cable I'm describing, and you try to use either of these USB-to-Serial chips as a base, you will find that most systems will think that you are attaching a plain serial device, and they'll use the generic driver. So, you'll need a bit more engineering...you need a driver that will determine if it needs to find (or create) a getty process, and connect it to the I/O address for the cable. Since you are going to need to make your own driver, you just gave yourself the flexibility to define how this type of cable communicates with the computers.
In a basic "Crash Cart" scenario, I want to plug the "Server" cable into my server chassis. If there is a console getty process running, I want it to be directed to this new device (even if it thinks it was connected to some other previous USB-to-Serial dongle, since that may have failed - causing me to need the crash cart).
When I plug in the "Client" cable to my crash cart, or a laptop, I want them to think that it's just another serial port. (For real Ease Of Use, let's default the serial speed to 9600 8N1.) If it's a Windows box, I'd like the option to choose (in the driver configuration) which COM port this device is assigned to (so it's going to ALWAYS be there...even if it needs to steal the assignment from a previous device). I'd also like to be able to associate this interface with an application, so that the OS will try to launch that application when the cable is plugged in.
I want to walk up to a server, just out of the box, with my laptop, and plug this cable into the server and into the laptop...and have the laptop launch my copy of ProCom, or TerraTerm, or HyperTerm...and have the server configure it's getty to talk to the new port, if the OS is healthy.
If we can loop in a few of the big BIOS makers, the BIOS might notice this device on startup, if BIOS redirection has been turned on, and use the cable (as a preference above the usual COM A assignment).
Of course, until we can get to this point, USB hasn't replaced the venerable RS-232 serial port, at least in my data center.
Good luck with this winter!
-Z-
20081130
Why aren't service processors "easy to use"?
You could try to tell me that it's because serial consoles are sensitive access points to vital hardware, and that Security is inversely proportional to Ease Of Use, therefore Service Processors cannot be Easy, because they need to be Secure. And, doing my best Jeremy Clarkson (Top Gear) impression, I'd tell you that "you'd be wrong".
I'll tell you that it's because most the consumers are not asking for ease of use, or for interoperability. Because it seems (to me) to be on the minds (and mouths, and blogs) of a relatively small subset of vocal customers, and the 'collective voice' of this subset is further diminished because we are asking different vendors. (That is, I ask Dell, you ask HP, she asks Sun...but darn few of us are asking more than one or two vendors.)
Security features are only just now beginning to be built-in, either already enabled, or very easy to configure, largely because the US government has tied such requirements to their purchasing rules. If you want to sell the US government a desktop computer, there is now a whole checklist of security items to tick on the list before your kit might be considered. The US government, across many departments, now speaks with a large, unified voice (through the purchasing rules and policies)
Similarly, in the early days of the Point-to-Point Protocol (the follow-on to S.L.I.P. for IP-over-modem communications), PPP would allow more computer network protocols to connect and exchange data. As a customer, you'd have thought that vendor A's PPP (the choice inYOUR shop) would talk to Vendor B's gear at some Strategic Partner's network. But you'd have been wrong. Coupled with the birth of the Commercial Internet (it wasn't just for DARPA anymore), many companies were trying to get onto the Internet, or to connect to other companies to exchange information.
There was a large dissatisfacton with a lack up interoperability. And many companies spoke with the vendors to complain. BUT, besides complaining to the vendor who supplied the kit to YOU, you also would have complained to the vendors of the other guys gear as well. You might complain to 5 or 10 vendors, between routers and modems.
As a result of the dissatisfaction of LOTS of users, 6 companies started the PPP Consortium, with a week-long meeting at Telebit Corp in Sunnyvale, CA, with the express purpose of trying to test all of their gear with each other, and test across the matrix of then-new (and still evolving) PPP protocol options. At then end of it, the scorecard wasn't too bad, and all of the participants had a list of things to fix. They also hashed out some of the ambiguities in the draft Request For Comments (RFCs) describing the options. (Many of the vendors were part of the IEEE, and were helping define the RFCs, but the meeting helped settle misunderstandings about the options.)
Because the group of six could now claim a large amount of interoperability with the others in the group, it helped their marketing. Because the customers saw progress, they harped on the vendors who were NOT part of the original group, and they wanted to get in on the consortium. Six months after the first group, I believe there were 13 members, and 18 at the next. By the third meeting, PPP was Stable. PPP 'just worked', most of the time. PPP had become "easy", and SLIP was largely relagated to antique links on old equipment.
When I look at the various implementations of BIOS redirection to the serial port, they almost exclusively presume (or require) a modem connection, which then requires hardware level wiring issues if you are using a Console Server connection. The mapping of Function Keys, command sequences, and the timing issues to invoke the commands make using them tricky on a Console Server. It makes them impractical on any link slower than 19.2 Kbps. Yet the few BIOS makers don't see a need to try to do better, let alone to work with the other vendors to provide some consistancy of user interface to their customers. Do they know whether you care?
Now that Service Processors are becoming prevalent on new servers, it's hard to get a server without one. Yet they suffer from problems very similar to BIOS. The user interfaces are different from vendor to vendor. But what about processors from the same vendor. What about within the same vendor, across a hardware platform? You'd think that a vendor might want to keep their command sequences consistent, for the sake of their customers (who might be scripting support sequences for their machines). You'd probably like to think that...but you'd be wrong. A couple vendors seem to change at will, but I'm guessing that they are just buying server designs from other companies...and those same vendors probably haven't taken the time to design that Human User Interface, they probably simply rely on the hardware maker to fulfill the tasks (power cycle the server, set the IP address of the Ethernet interface for service processor, implement a web interface with certain features), leaving the details of keystrokes to the hardware maker...and when the vendor chooses another hardware maker, they get the same latitude with the design, and make different choices. (I wonder what Donald Norman thinks about tis problem.) Do your vendors know if you care?
When you tell a sales person that you want some new feature on their next year's model, the usual response is "OK, if we can get that done, how many will you buy?". It's going to cost them labor hours, engineering and QA time, technical documentation, maybe changing part of a training class. While you may only want 6, or 12, or 40, your voice will be tallied. When they from enough of you, it's going to be worth it to make a change. But we need to tip that scale by asking, and probably tying that request to some money. (My dad would sometimes ask me to "write your request on a $5 bill, and I'll consider it", but I have seen this over and over again, from different seats in different companies. For the vendor, it's all about money.)
My point here, is that you are going to spend money on new servers at some point. Make your money count! Tie the money to your requests for easier-to-use service processors. Decide what you want, and tell your possible vendors about your requirements. They all want your money...so vote with your wallet! Reward the responsive vendors! If the unresponsive vendors don't get the order, they'll at least know why, and they'll learn that you were serious. As more of us tie our requirements to purchasing, we can make a difference.
As you get into your busy end-of-year, some of you are already going through your budget cycle for 2009. Use any slowdown you get to think about requirements to go along with those purchases. Get them on paper, and in email, so they are ready to send to your vendors with your Request for Quote. And good luck in the new year.
-Z-
I'll tell you that it's because most the consumers are not asking for ease of use, or for interoperability. Because it seems (to me) to be on the minds (and mouths, and blogs) of a relatively small subset of vocal customers, and the 'collective voice' of this subset is further diminished because we are asking different vendors. (That is, I ask Dell, you ask HP, she asks Sun...but darn few of us are asking more than one or two vendors.)
Security features are only just now beginning to be built-in, either already enabled, or very easy to configure, largely because the US government has tied such requirements to their purchasing rules. If you want to sell the US government a desktop computer, there is now a whole checklist of security items to tick on the list before your kit might be considered. The US government, across many departments, now speaks with a large, unified voice (through the purchasing rules and policies)
Similarly, in the early days of the Point-to-Point Protocol (the follow-on to S.L.I.P. for IP-over-modem communications), PPP would allow more computer network protocols to connect and exchange data. As a customer, you'd have thought that vendor A's PPP (the choice inYOUR shop) would talk to Vendor B's gear at some Strategic Partner's network. But you'd have been wrong. Coupled with the birth of the Commercial Internet (it wasn't just for DARPA anymore), many companies were trying to get onto the Internet, or to connect to other companies to exchange information.
There was a large dissatisfacton with a lack up interoperability. And many companies spoke with the vendors to complain. BUT, besides complaining to the vendor who supplied the kit to YOU, you also would have complained to the vendors of the other guys gear as well. You might complain to 5 or 10 vendors, between routers and modems.
As a result of the dissatisfaction of LOTS of users, 6 companies started the PPP Consortium, with a week-long meeting at Telebit Corp in Sunnyvale, CA, with the express purpose of trying to test all of their gear with each other, and test across the matrix of then-new (and still evolving) PPP protocol options. At then end of it, the scorecard wasn't too bad, and all of the participants had a list of things to fix. They also hashed out some of the ambiguities in the draft Request For Comments (RFCs) describing the options. (Many of the vendors were part of the IEEE, and were helping define the RFCs, but the meeting helped settle misunderstandings about the options.)
Because the group of six could now claim a large amount of interoperability with the others in the group, it helped their marketing. Because the customers saw progress, they harped on the vendors who were NOT part of the original group, and they wanted to get in on the consortium. Six months after the first group, I believe there were 13 members, and 18 at the next. By the third meeting, PPP was Stable. PPP 'just worked', most of the time. PPP had become "easy", and SLIP was largely relagated to antique links on old equipment.
When I look at the various implementations of BIOS redirection to the serial port, they almost exclusively presume (or require) a modem connection, which then requires hardware level wiring issues if you are using a Console Server connection. The mapping of Function Keys, command sequences, and the timing issues to invoke the commands make using them tricky on a Console Server. It makes them impractical on any link slower than 19.2 Kbps. Yet the few BIOS makers don't see a need to try to do better, let alone to work with the other vendors to provide some consistancy of user interface to their customers. Do they know whether you care?
Now that Service Processors are becoming prevalent on new servers, it's hard to get a server without one. Yet they suffer from problems very similar to BIOS. The user interfaces are different from vendor to vendor. But what about processors from the same vendor. What about within the same vendor, across a hardware platform? You'd think that a vendor might want to keep their command sequences consistent, for the sake of their customers (who might be scripting support sequences for their machines). You'd probably like to think that...but you'd be wrong. A couple vendors seem to change at will, but I'm guessing that they are just buying server designs from other companies...and those same vendors probably haven't taken the time to design that Human User Interface, they probably simply rely on the hardware maker to fulfill the tasks (power cycle the server, set the IP address of the Ethernet interface for service processor, implement a web interface with certain features), leaving the details of keystrokes to the hardware maker...and when the vendor chooses another hardware maker, they get the same latitude with the design, and make different choices. (I wonder what Donald Norman thinks about tis problem.) Do your vendors know if you care?
When you tell a sales person that you want some new feature on their next year's model, the usual response is "OK, if we can get that done, how many will you buy?". It's going to cost them labor hours, engineering and QA time, technical documentation, maybe changing part of a training class. While you may only want 6, or 12, or 40, your voice will be tallied. When they from enough of you, it's going to be worth it to make a change. But we need to tip that scale by asking, and probably tying that request to some money. (My dad would sometimes ask me to "write your request on a $5 bill, and I'll consider it", but I have seen this over and over again, from different seats in different companies. For the vendor, it's all about money.)
My point here, is that you are going to spend money on new servers at some point. Make your money count! Tie the money to your requests for easier-to-use service processors. Decide what you want, and tell your possible vendors about your requirements. They all want your money...so vote with your wallet! Reward the responsive vendors! If the unresponsive vendors don't get the order, they'll at least know why, and they'll learn that you were serious. As more of us tie our requirements to purchasing, we can make a difference.
As you get into your busy end-of-year, some of you are already going through your budget cycle for 2009. Use any slowdown you get to think about requirements to go along with those purchases. Get them on paper, and in email, so they are ready to send to your vendors with your Request for Quote. And good luck in the new year.
-Z-
20081020
A little perl of wisdom
When it comes to finding some quick help (after the Helpdesk has closed), or those tidbits of knowledge and experience of someone who has tread the path before me, Google has been my friend for many years (taking up the mantle after AltaVista!).
But, there is a downside to learning all about a topic from Google. It is that you, the reader, are guiding the learning. You are getting the answers to the questions you ask...but it doesn't always offer things that you should know (or at least consider), based on your searches.
I taught myself perl, reading books, and using Google for answers, and examples...but I sometimes found myself confused when reading someone else's code. This year, I'm taking formal classes, from a few sources, hoping to patch a few holes in my foundation of knowledge.
While I'm glad to have taken this approach, to have someone guiding me through the learning, systematically, and answering my questions...I'm finding that the Teacher in this equation is even more important than the content. Even if someone knows the content well, that doesn't mean that they will be a good teacher. (Answering the occasional question does not equal teaching.)
After 5 weeks in a semester-long class at a local community college, I too a full-day Perl 101 course from Bayview Training...and then I coded for 15 hours straight, because that class had made a number of concepts more concrete for me (several "light-bulb" moments), and I was excited about the possibilities for my future projects.
I heartily recommend Bill Ward as an instructor. While he teaches primarily in Silicon Valley, he does travel for some classes and consulting as well. The cost of the course was money well spent! If you really need to learn some perl, check out Bayview Training and Bill Ward!
But, there is a downside to learning all about a topic from Google. It is that you, the reader, are guiding the learning. You are getting the answers to the questions you ask...but it doesn't always offer things that you should know (or at least consider), based on your searches.
I taught myself perl, reading books, and using Google for answers, and examples...but I sometimes found myself confused when reading someone else's code. This year, I'm taking formal classes, from a few sources, hoping to patch a few holes in my foundation of knowledge.
While I'm glad to have taken this approach, to have someone guiding me through the learning, systematically, and answering my questions...I'm finding that the Teacher in this equation is even more important than the content. Even if someone knows the content well, that doesn't mean that they will be a good teacher. (Answering the occasional question does not equal teaching.)
After 5 weeks in a semester-long class at a local community college, I too a full-day Perl 101 course from Bayview Training...and then I coded for 15 hours straight, because that class had made a number of concepts more concrete for me (several "light-bulb" moments), and I was excited about the possibilities for my future projects.
I heartily recommend Bill Ward as an instructor. While he teaches primarily in Silicon Valley, he does travel for some classes and consulting as well. The cost of the course was money well spent! If you really need to learn some perl, check out Bayview Training and Bill Ward!
20080828
Big News! SSH clients for iPhone!
I haven't had any 'big news' on the console front for a couple months now. I have been missing my BlueConsole adapters (which I've blogged about before), and SSH access from my iPhone, BUT that has changed!
New in the Apple Apps Store are four SSH applications (use the search dialogue, look for "ssh"...). I've already bought two to try, and one has already met my most common needs. In a nutshell, here are the four I found, with URLs to the maker's websites, in case you want to do your own homework on the topic.
TouchTerm http://www.jbrink.net/touchterm/index.html $2.99 This one looks pretty good, from the online docs. There is only basic information on the maker's home page, BUT, check the SUPPORT page! Key Exchange, font colors, different input modes (immediate, batch, command history). The developer offers an email address for comments and suggestions. This looks like a good pick!
pTerm http://www.instantcocoa.com/products/pTerm/ $4.99 This maker also lists an email address, as well as a Google discussion group. The web page posts a short-term development schedule. They also boast that this app is based on PuTTY, and I'm a big PuTTY fan (but I understand that this app is only scratching the surface on features). I've sent email to the developer with my wants, and I already received a positive reply. He is also willing to work on the bluetooth-serial-devices interfacing as well.
iSSH http://www.zinger-soft.com/iSSH_features.html $4.99 This one also looks good. The main web page is odd... there are small, light-grey arrows under a few of the descriptions...they indicate that there are additional items at this menu level of the web page. Clicking on them will show you the other topics. This one also supports shared keys, but doesn't seem as flexible (to me, yet), as TouchTerm.
SSH http://www.throughput.biz/ $3.99 This looks simple, and it word-wraps the screen. There is little information on the maker's homepage. I'm currently not inclined to try it.
So, with this in mind, I have bought the first two (TouchTerm and pTerm), and I'm spending my efforts to put TouchTerm through it's paces first, because pTerm doesn't have RSA/DSA keys yet (though keys are on the short-range list for new features, so I'll be giving them both a good workout in September). I was able to set up a basic profile, with screen and font colors, RSA-2048 key, emailed the key to another host, so I could place the key, and use the session. It will take a bit of getting used to, since I'll need to leave the fonts a bit larger, and pan around the screen (using mutt was kinda awkward, but that won't be my primary use of SSH). I like it so far, and I hope to be able to put my BlueConsole adapters back into service sometime in the near future.
I hope you had a chance to enjoy some vacation this summer as well.
-Z-
New in the Apple Apps Store are four SSH applications (use the search dialogue, look for "ssh"...). I've already bought two to try, and one has already met my most common needs. In a nutshell, here are the four I found, with URLs to the maker's websites, in case you want to do your own homework on the topic.
TouchTerm http://www.jbrink.net/touchterm/index.html $2.99 This one looks pretty good, from the online docs. There is only basic information on the maker's home page, BUT, check the SUPPORT page! Key Exchange, font colors, different input modes (immediate, batch, command history). The developer offers an email address for comments and suggestions. This looks like a good pick!
pTerm http://www.instantcocoa.com/products/pTerm/ $4.99 This maker also lists an email address, as well as a Google discussion group. The web page posts a short-term development schedule. They also boast that this app is based on PuTTY, and I'm a big PuTTY fan (but I understand that this app is only scratching the surface on features). I've sent email to the developer with my wants, and I already received a positive reply. He is also willing to work on the bluetooth-serial-devices interfacing as well.
iSSH http://www.zinger-soft.com/iSSH_features.html $4.99 This one also looks good. The main web page is odd... there are small, light-grey arrows under a few of the descriptions...they indicate that there are additional items at this menu level of the web page. Clicking on them will show you the other topics. This one also supports shared keys, but doesn't seem as flexible (to me, yet), as TouchTerm.
SSH http://www.throughput.biz/ $3.99 This looks simple, and it word-wraps the screen. There is little information on the maker's homepage. I'm currently not inclined to try it.
So, with this in mind, I have bought the first two (TouchTerm and pTerm), and I'm spending my efforts to put TouchTerm through it's paces first, because pTerm doesn't have RSA/DSA keys yet (though keys are on the short-range list for new features, so I'll be giving them both a good workout in September). I was able to set up a basic profile, with screen and font colors, RSA-2048 key, emailed the key to another host, so I could place the key, and use the session. It will take a bit of getting used to, since I'll need to leave the fonts a bit larger, and pan around the screen (using mutt was kinda awkward, but that won't be my primary use of SSH). I like it so far, and I hope to be able to put my BlueConsole adapters back into service sometime in the near future.
I hope you had a chance to enjoy some vacation this summer as well.
-Z-
20080713
Social Networking, professional connections
The question comes up, from time to time... Why do System Administrators seem to be better at (Social) Networking than Network Administrators. You'd think that Netadmins would have the communications thing down cold. But, I've found, we tend to have smaller social networks, but with links we can rely upon to do our jobs.
Linked in? Yep, I've been there a while...
But, why are there so many more Systems-related conferences than Network-related? OS related trade shows, versus Network trade shows.
I just find it odd, that's all.
-Z-
Linked in? Yep, I've been there a while...
But, why are there so many more Systems-related conferences than Network-related? OS related trade shows, versus Network trade shows.
I just find it odd, that's all.
-Z-
20080704
Can you hear me now? Wait, now I can't hear you!
California's two new laws regarding hands-free cellphone use while driving have Bluetooth headsets in the news, and on the front page of many papers. I still haven't found the right combination in any solution that I've tried. Every one has had some deficit.
Since I wear glasses, I don't like anything that has an ear-loop. None have been comfortable so far. I also prefer an in-ear (ear-bud) style, versus an over-the-ear solution with a headband. This certainly limits my choices, but there have been a few good choices. Good, but none were Great.
For listening to calls, the best for me has ben the Sony HB-808 headset. Good talk-time, and lightweight, with sufficient audio to the earpiece, and the microphone has some automatic gain control, but it is not so good about noise cancellation. It comes with an earloop, which can be reversed to wear on either ear (that's fairly standard), but the art near my ear was also uncomfortable, because it pressed against my ear when I used the earloop. But, the diameter of the earphone was slightly smaller than an original iPhone earphone, so I tried using the Griffin EarJam earbud adapters for the iPod earphones...This was a HUGE improvement! It now fits in my ear without an earloop. It's light enough to stay in my ear. And, because the earbud is in my ear, it seals out local noises, while allowing me to turn the earpiece volume down! Even in a data center, staring down dozens of fans, I can hear my calls just fine...but, that's where it all breaks down. Because the microphone has gain control, it hears all of the fans, so I constantly have to juggle the phone to mute and unmute the microphone during calls in the data center to service gear. It frustrating for me.
I finally bought an original Jawbone, because of the noise canceling technology. It really is great, for the people I call. I don't have to mute my microphone in the data center (in most cases), which has been really useful. But, the device has an awkward earloop, since the device MUST rest on your cheek in order for the noise canceling to work. And, since it's pressing the microphone aginst my cheek, the earpiece hovers above my ear. Folks can ear me, but I've got to turn the volume up to 11 to hear them over the local noise.
I tried all 4 of the ear-bits that came with the Jawbone, but none were comfortable, and only one came close to helping me lower the volume of the earpiece. The earpiece is also slightly smaller than the iPod earphone, so the Griffin earbud trick wouldn't seat securely. Even trying to secure the Griffin part, it would fit in my ear, but then the microphone wouldn't press against my cheek (defeating the noise cancellation), so that trick didn't work. BUT, at MacWorld SF 2007, I found Comply's "Whoomp!" earbud enhancers. They are snugger, and more flexible than the Griffin part, with a foam earpiece on a slightly slanted axis. This held the Jawbone snugly, pressed the mirophone against my cheek, and sealed the outside noise nicely...but, the foam bit was hard to clean. I still use it, but each earbud only lasts about 3-4 months for me.
A friend turned me on to another option for the original Jawbone; Using the Jabra Ear-gels (available from Hello Direct for about $6US), which gives you another set of 4 sizes, which SNUGLY fit the Jawbone. hey are more supple than the original Jawbone ear-bits, but they still aren't as comfortable as I would like. My friend has already tried the new Jawbone, and has been favorably impressed.
I've tried using commercial adapters (cable, switch and microphone) with my own iPod earbuds, but the microphone still hears the fans. (It's a dichotomy; If I can hear you well, you can't hear me well...why can't they make a headset that allows both?)
I'm fine using a headset in the car, but I received a Tom-Tom for my birthday, since it has bluetooth hands-free speaker phone capability. This works OK, but I understand it's a high-theft-rate target. I can't leave it in the car, lest someone breaks a window to steal it. (Even if you take it inside, I'm told that leaving the suction-cup mount on your windshield is enough attraction that a thief may smash your window to see if you stashed it inside the car.) As a result, I now have one more thing to stow and carry back and forth.
Should I try using the Tom-Tom as a speakerphone in the data center? They don't brag about noise cancellation, but folks seem to hear me pretty good when I'm in the car. :-)
-Z-
Since I wear glasses, I don't like anything that has an ear-loop. None have been comfortable so far. I also prefer an in-ear (ear-bud) style, versus an over-the-ear solution with a headband. This certainly limits my choices, but there have been a few good choices. Good, but none were Great.
For listening to calls, the best for me has ben the Sony HB-808 headset. Good talk-time, and lightweight, with sufficient audio to the earpiece, and the microphone has some automatic gain control, but it is not so good about noise cancellation. It comes with an earloop, which can be reversed to wear on either ear (that's fairly standard), but the art near my ear was also uncomfortable, because it pressed against my ear when I used the earloop. But, the diameter of the earphone was slightly smaller than an original iPhone earphone, so I tried using the Griffin EarJam earbud adapters for the iPod earphones...This was a HUGE improvement! It now fits in my ear without an earloop. It's light enough to stay in my ear. And, because the earbud is in my ear, it seals out local noises, while allowing me to turn the earpiece volume down! Even in a data center, staring down dozens of fans, I can hear my calls just fine...but, that's where it all breaks down. Because the microphone has gain control, it hears all of the fans, so I constantly have to juggle the phone to mute and unmute the microphone during calls in the data center to service gear. It frustrating for me.
I finally bought an original Jawbone, because of the noise canceling technology. It really is great, for the people I call. I don't have to mute my microphone in the data center (in most cases), which has been really useful. But, the device has an awkward earloop, since the device MUST rest on your cheek in order for the noise canceling to work. And, since it's pressing the microphone aginst my cheek, the earpiece hovers above my ear. Folks can ear me, but I've got to turn the volume up to 11 to hear them over the local noise.
I tried all 4 of the ear-bits that came with the Jawbone, but none were comfortable, and only one came close to helping me lower the volume of the earpiece. The earpiece is also slightly smaller than the iPod earphone, so the Griffin earbud trick wouldn't seat securely. Even trying to secure the Griffin part, it would fit in my ear, but then the microphone wouldn't press against my cheek (defeating the noise cancellation), so that trick didn't work. BUT, at MacWorld SF 2007, I found Comply's "Whoomp!" earbud enhancers. They are snugger, and more flexible than the Griffin part, with a foam earpiece on a slightly slanted axis. This held the Jawbone snugly, pressed the mirophone against my cheek, and sealed the outside noise nicely...but, the foam bit was hard to clean. I still use it, but each earbud only lasts about 3-4 months for me.
A friend turned me on to another option for the original Jawbone; Using the Jabra Ear-gels (available from Hello Direct for about $6US), which gives you another set of 4 sizes, which SNUGLY fit the Jawbone. hey are more supple than the original Jawbone ear-bits, but they still aren't as comfortable as I would like. My friend has already tried the new Jawbone, and has been favorably impressed.
I've tried using commercial adapters (cable, switch and microphone) with my own iPod earbuds, but the microphone still hears the fans. (It's a dichotomy; If I can hear you well, you can't hear me well...why can't they make a headset that allows both?)
I'm fine using a headset in the car, but I received a Tom-Tom for my birthday, since it has bluetooth hands-free speaker phone capability. This works OK, but I understand it's a high-theft-rate target. I can't leave it in the car, lest someone breaks a window to steal it. (Even if you take it inside, I'm told that leaving the suction-cup mount on your windshield is enough attraction that a thief may smash your window to see if you stashed it inside the car.) As a result, I now have one more thing to stow and carry back and forth.
Should I try using the Tom-Tom as a speakerphone in the data center? They don't brag about noise cancellation, but folks seem to hear me pretty good when I'm in the car. :-)
-Z-
20080605
Zonker needs a Bluetooth terminal emulator App for iPhone
The longer I go without this capability, the stronger my desire for an application for the iPhone to fill my needs. But, I don't want to hack my phone...I want a real iPhone App, and now it's worth money to me. I can't find a 'Wish List' page that hasn't been taken over by spammers. So, I'll try the Open Letter approach.
I have two needs, with a common root...both need a basic vt-100 terminal emulator underneath. ANSI color would be a nice touch, but isn't necessary. I don't need Wyse, or full-blown TN-3270 emulation...keep it simple. Some scrollback buffer would be useful (say ~2600 lines), and the ability to capture to a log file (and email the log later?) would be very handy. So, what else?
The primary need is to have an SSH v2 client, so I can SSH directly to my machines using the Edge or wifi connections. This also probably means solving the pre-shared keys issue...how do I get the keys onto the iPhone? I still can't sync a simple file to my phone. Maybe I need a key-generator on the phone, but I still need to get the public key to the hosts.
The secondary need is to communicate with a Bluetooth serial device. Specifically, a BlueConsole dongle, although there are other devices with which you should be able to interoperate. (I used to use the Tri-connect package (from Tridone) on my Treo 650. It wasn't great, but it was a good option, which let me do a lot of quick, little jobs without lugging a computer around.) I'm sorely tempted to carry the Treo around in my tool bag, for those occasions when I'd really like to use these serial devices...if I could find a good way to keep the Treo battery charged while it's in the tool bag, I'd do it. But, I'd much rather use the iPhone for this task.
If you're an iPhone developer, working on a terminal emulator that will use the Bluetooth port, let's talk! I'm willing to be a software tester, give feedback, and help with documentation. I've got good credentials in both the serial console and the communications software test realms. We may also be able to work out a loan of a BlueConsole device while you're developing.
If you're an iPhone developer, working on an SSH v2 client, I want to talk to you as well, and I'm willing to be a tester for this as well. (I'd love to know that someone is trying to fulfill this need.) My favorite SSH app is PuTTY (by Simon Tatham and others), if you want to set your sites high. If you are trying to determine what folks 'want', versus what the 'need' (and would be willing to pay for), I'd like to talk to you.
Since Father's Day is in June, I'm going to post information about some of my favorite new tools in my next posts, in case you are shopping for special gifts. (Yes, the iPhone is on the list.)
-Z-
I have two needs, with a common root...both need a basic vt-100 terminal emulator underneath. ANSI color would be a nice touch, but isn't necessary. I don't need Wyse, or full-blown TN-3270 emulation...keep it simple. Some scrollback buffer would be useful (say ~2600 lines), and the ability to capture to a log file (and email the log later?) would be very handy. So, what else?
The primary need is to have an SSH v2 client, so I can SSH directly to my machines using the Edge or wifi connections. This also probably means solving the pre-shared keys issue...how do I get the keys onto the iPhone? I still can't sync a simple file to my phone. Maybe I need a key-generator on the phone, but I still need to get the public key to the hosts.
The secondary need is to communicate with a Bluetooth serial device. Specifically, a BlueConsole dongle, although there are other devices with which you should be able to interoperate. (I used to use the Tri-connect package (from Tridone) on my Treo 650. It wasn't great, but it was a good option, which let me do a lot of quick, little jobs without lugging a computer around.) I'm sorely tempted to carry the Treo around in my tool bag, for those occasions when I'd really like to use these serial devices...if I could find a good way to keep the Treo battery charged while it's in the tool bag, I'd do it. But, I'd much rather use the iPhone for this task.
If you're an iPhone developer, working on a terminal emulator that will use the Bluetooth port, let's talk! I'm willing to be a software tester, give feedback, and help with documentation. I've got good credentials in both the serial console and the communications software test realms. We may also be able to work out a loan of a BlueConsole device while you're developing.
If you're an iPhone developer, working on an SSH v2 client, I want to talk to you as well, and I'm willing to be a tester for this as well. (I'd love to know that someone is trying to fulfill this need.) My favorite SSH app is PuTTY (by Simon Tatham and others), if you want to set your sites high. If you are trying to determine what folks 'want', versus what the 'need' (and would be willing to pay for), I'd like to talk to you.
Since Father's Day is in June, I'm going to post information about some of my favorite new tools in my next posts, in case you are shopping for special gifts. (Yes, the iPhone is on the list.)
-Z-
Subscribe to:
Posts (Atom)