Dear Users... (A thread for Sysadmin, Technical Support, and Help Desk people)

[arthwollipot]

And sometimes you get a request that just makes you laugh. Just received this email:

Quote:

Hello Service Desk team

I would like to request a new mouse, please.

The wheel on my current mouse is broken.

Can I please have the most expensive, super-crash hot, ergonomically superior mouse you have? (I understand if all we have are the usual cheap ones. That’s fine)

[Faydra]

The greatest satisfaction ever comes from sweetly and politely telling them how stupid they are.

I have two examples.

1) In a previous life I worked on an sftp file transfer system. You create keys and give out your public key for them to encrypt a file with, and then use your private key to decrypt it. I was unable to decrypt a file and went back to the vendor letting them know there was a problem. They continued for days to insist that I was doing something wrong. Finally, they said "I don't know why you can't decrypt it, I downloaded it and was able to decrypt it just fine". I sweetly told them, had they encrypted it properly with MY key, they should not have been able to decrypt it. I had a correct file in about 5 minutes after that reply along with very sweet and satisfying dead silence.

2) SAP job kept failing with an error. I'm not an SAP person, I've never been on an SAP system in my life. The person kept insisting the problem was on my side. I googled the error it was reporting and gave them the solution in about 5 minutes. Never heard from them again. Sweet sweet silence, the sound of WINNING.

[arthwollipot]

I was once asked what SAP stands for, so I found out. I'm not going to look it up again, but it turned out to be something really boring like "Systems Analysis and Procedures". But probably in German.

[Faydra]

Originally Posted by arthwollipot

I was once asked what SAP stands for, so I found out. I'm not going to look it up again, but it turned out to be something really boring like "Systems Analysis and Procedures". But probably in German.

Ha! I don't remember it either. And equally not interested in finding out again.

[arthwollipot]

Originally Posted by Faydra

Ha! I don't remember it either. And equally not interested in finding out again.

I do remember when I called the person back with the information saying "I found out what it stands for, but you're going to be disappointed".

[Faydra]

Originally Posted by arthwollipot

And sometimes you get a request that just makes you laugh. Just received this email:

People that include humor in their tickets have the best chance of getting my full attention to their issue.

[arthwollipot]

Originally Posted by Faydra

People that include humor in their tickets have the best chance of getting my full attention to their issue.

Yes!

[theprestige]

Originally Posted by Faydra

People that include humor in their tickets have the best chance of getting my full attention to their issue.

Not with me. I'm definitely a time and a place kind of guy. You have a problem, all I want is to solve it as quickly as possible, so we can both relax and go back to doing something we'd each enjoy more. Jokes in tickets just get in the way of me figuring out what's broke and fixing it. And please don't spend time thinking of jokes instead of thinking how to describe the problem better.

[Faydra]

Originally Posted by theprestige

Not with me. I'm definitely a time and a place kind of guy. You have a problem, all I want is to solve it as quickly as possible, so we can both relax and go back to doing something we'd each enjoy more. Jokes in tickets just get in the way of me figuring out what's broke and fixing it. And please don't spend time thinking of jokes instead of thinking how to describe the problem better.

Stupid jokes get you nowhere. Clever humor related to the problem get prioritized below actual REAL problems and above stupid people problems.

[arthwollipot]

Originally Posted by theprestige

Not with me. I'm definitely a time and a place kind of guy. You have a problem, all I want is to solve it as quickly as possible, so we can both relax and go back to doing something we'd each enjoy more. Jokes in tickets just get in the way of me figuring out what's broke and fixing it. And please don't spend time thinking of jokes instead of thinking how to describe the problem better.

The joke in the ticket I posted above does nothing to get in the way of the user's actual problem. It is clear from the email that their mouse wheel is broken, and we know precisely what we need to do about that. The joke is merely a decoration, and we see those so rarely in this job that its mere presence makes me smile. And my colleagues and TL for that matter when I read the email out.

If, on the other hand, the user tried to explain their problem to me in the form of a riddle, I would have a lot less patience with that.

Here's another one that I copied into my OneNote when I received it:

Quote:

Can you please replace the faulty teleconference phone in Xxxx’s office (location). It sounds like it is possessed when being used.

[theprestige]

Originally Posted by arthwollipot

The joke in the ticket I posted above does nothing to get in the way of the user's actual problem. It is clear from the email that their mouse wheel is broken, and we know precisely what we need to do about that. The joke is merely a decoration, and we see those so rarely in this job that its mere presence makes me smile. And my colleagues and TL for that matter when I read the email out.

I'm not saying you're wrong to feel that way. But not everybody does. What makes me smile is a clear and succinct problem description, full stop. An extra line with a joke in it is another line of problem description I have to read... only to discover I didn't have to read it after all.

Quote:

Here's another one that I copied into my OneNote when I received it:

That's one of those "thinking of jokes instead of thinking of how to describe the problem" things I hate.

Sounds possessed? WTF is that? Static? Echo? Distortion? Feedback? Constant beeping? When does it happen? When you pick up the handset? On speakerphone? Only when dialing into a conference call? Only when receiving a call?

"When you have to shoot... shoot! Don't crack jokes." - Tuco, probably.

[arthwollipot]

Originally Posted by theprestige

That's one of those "thinking of jokes instead of thinking of how to describe the problem" things I hate.

Sounds possessed? WTF is that? Static? Echo? Distortion? Feedback? Constant beeping? When does it happen? When you pick up the handset? On speakerphone? Only when dialing into a conference call? Only when receiving a call?

"When you have to shoot... shoot! Don't crack jokes." - Tuco, probably.

Yeah, that one was a little harder to parse. But it was funny. The phone sounds like it's possessed. Gold.

[Wudang]

Originally Posted by Faydra

And what you invariably get in new agile shops is people "waterfalling the sprint" because it's all they know. That's where my team is at currently. It's a work in progress. Sigh.

https://www.halfarsedagilemanifesto.org/

It happens. At an IBM lab many years ago they decided to try cleanroom development. They were warned in advance that traditional management metrics would not apply. Everything ticked along nicely as predicted but cleanroom was killed despite being a success because managers missed their usual metrics.

[TheGnome]

Originally Posted by arthwollipot

Right, but it's not hard to learn the correct names for things. This particular one confused me because I'm old enough to remember the original meaning of the word "dongle", which was a pass-through device that plugged into the serial port of the computer that allowed proprietary hardware to operate. It was some time before I remembered that people use the word to refer to wireless broadband modems.

I think you are misremebering here. I don't think I've ever seen a dongle for use with any proprietary hardware. The only effect they ever had on hardware was for it to not work properly anymore.

The dongles were used for software copy protection. They were small things that you plugged (most often) into the parallel port. They then sat there and did nothing obvious.

Today I'm quite okay with calling anything a dongle that is small, plugs into the usb and doesn't do anything immediately obvious. But maybe that's because I'm a german speaking Swiss. We have a history of misusing a lot of english words.

[Darat]

Originally Posted by TheGnome

I think you are misremebering here. I don't think I've ever seen a dongle for use with any proprietary hardware. The only effect they ever had on hardware was for it to not work properly anymore.

The dongles were used for software copy protection. They were small things that you plugged (most often) into the parallel port. They then sat there and did nothing obvious.

Today I'm quite okay with calling anything a dongle that is small, plugs into the usb and doesn't do anything immediately obvious. But maybe that's because I'm a german speaking Swiss. We have a history of misusing a lot of english words.

You are both correct, they were often security devices - either to allow hardware to be connected or software to run.

These days the most common use for a dongle is as a mobile data connection.

[JoeMorgue]

And see this is what bugs me.

We have a customer base that is putting no effort into describing their problem or what they need and we're so damn scared of being seen as "non-professional" that we have to laugh and shrug it off.

If the woman needed a part for her laptop she should have been able to at least try to verbalize what it was and what function it would accomplish. That's not asking too much.

But comments made here have made it obvious that such concepts make us "unprofessional" and "ungrateful since these people keep us in jobs."

[Hellbound]

Sadly, it's not just users.

I run our internal Certification Authority (the system that issues TLS certificates to our internal systems). While I don't expect everyone to be an expert, I am continually amazed at the number of system administrators and web site owners who don't even know the functional basics: how to request and apply a certificate to their own system. Heck, any software you get will have that printed out in the help documentation, usually easily found.

And this morning I get a call from someone having an issue with one of our external websites. Apparently, they still were using Symantec-issued public certs. So several of our production sites are down due to cert errors because the admin that runs those sites was out-of-touch enough to not know that Symantec was going away (something that's been in the news for over a year now).

[Wudang]

Originally Posted by Hellbound

I run our internal Certification Authority (the system that issues TLS certificates to our internal systems). .

In case it's of use a friend wrote this a few years back. Amongst other things it checks when certs will expire from a list of websites.
https://github.com/brabster/website-checker

[Faydra]

Originally Posted by Hellbound

Heck, any software you get will have that printed out in the help documentation, usually easily found.

Ha.

My software does have it in their documentation and it is fairly easily found.
But it's wrong, it doesn't include half the steps you need to do in addition to what's on the document. I've had a ticket open with them for a month and they still don't know what to do to get it to work.

Certs are the 5th level of hell for me.

[Hellbound]

Originally Posted by Faydra

Ha.

My software does have it in their documentation and it is fairly easily found.
But it's wrong, it doesn't include half the steps you need to do in addition to what's on the document. I've had a ticket open with them for a month and they still don't know what to do to get it to work.

Certs are the 5th level of hell for me.

IBM product?

ETA: There are some exceptions (IBM being the major one: seriously, java-based keystores for everything? Proprietary tools to access them? WTF?). And some of the -ix based appliances can be a bit trickier. I'm more than willing to work with an admin to find answers, but there are limits. We have one guy that, although I've written multiple copies of clear instructions, with screenshots, to walk him through the process of updating his WebSphere certs, I STILL end up having to walk him through it in a Skype session everytime they expire, because he'll do things like create the CSR on an entirely different system and never move the private key over, or put the CA certs into a personal store instead of trusted roots, or similar. Not just a matter of having issues, but refusing to learn or understand even the basics of how a certificate operates. I sometimes wonder why I'm not a 10:00 news item yet: "Downtown Man kills 16, wounds 78 in staple remover homicide!"

ETA2: Heck, I even wrote up three versions of classes for the company on encryption (a short, medium, and long, with varying levels of details) to teach our admins the basics. I did have some takers, but none of the ones that are always the most trouble. Seriously, I'm willing to give up 2 hours to train people, instead they want to waste twice that amount of time every year when they need new certs.

[Hellbound]

Originally Posted by Wudang

In case it's of use a friend wrote this a few years back. Amongst other things it checks when certs will expire from a list of websites.
https://github.com/brabster/website-checker

Well, now, we have some of those tools now for our external certificates (provided by our external cert vendor). Some departments just don't take advantage of anything that's out there.

I just get annoyed when people don't even go through the motions

[The Greater Fool]

Originally Posted by theprestige

The basic idea is that there are two broad paradigms for software development. The older paradigm, prevalent for many years, went something like this:
1. Define requirements.
2. Spend a year developing software to meet those requirements.
3. Release the software all at once.
4. Discover all the bugs and all the missed requirements and all the implemented requirements that nobody actually wanted.
5. Define new requirements.
6. Spend a year...
Etc.

This paradigm was called "waterfall" software development, for some reason. Probably because you can visualise the process as a cascade of activity, Requirements > Development > Discovery.

The waterfall paradigm made a lot of sense in the days when software came on physical media. You'd buy a disk, insert it in the computer, install the software, and use it warts and all until the new version came out next year. Then you'd upgrade, and hope that the new version had more useful features and less bugs than the previous version. Mostly this worked.

But as we moved into an age when more and more software was running as a service over the Internet (Turbotax Online, for example), software companies realized they didn't necessarily have to wait six months or a year for a new version. They could fix bugs and add features as they were discovered. You could update your service every six weeks, or every six days. Or every six hours. And being able to produce beneficial updates quickly gave you an advantage over your competition.

But to do that well, a new paradigm was needed. The new paradigm needed to have a system for breaking down software development into small tasks that could be completed quickly, tested quickly, and released quickly. And, in order to be valuable, the new system had to link these tasks to specific tangible benefits to your users.

The implications of such a system are literally paradigm-shifting. Instead of your software developer laboring for a year on a massive code base, making hundreds of changes without really knowing if they're useful or wanted or even simply not harmful; your software developer can labor for a week on something he knows is desirable, and at the end of the week he can test it and know that it's working as intended. Shortly thereafter, that improvement that customers actually want - the bug fix, the new feature - can be released, and customers can be made happier thereby. This is, in a word, *awesome*.

And this awsomeness hinges on knowing what customers want. You know there's a bug that affects database performance, but have your customers even noticed that? Or are they all clamoring for a delete button that warns them before they delete stuff? Gathering that customer feedback, and using it to decide which development goals to prioritize, is critical to the success of the system.

This new paradigm is called "agile" software development, probably because it's the same basic cycle of activity as the waterfall, but done at a much faster pace. Customer feedback about what they're trying to do and what they expect from your software is called "user stories". The phrase "recording user stories" is the agile paradigm's term for defining requirements.

A mature agile development team will usually have a Product Owner assigned or embedded with the developers. Their job is to gather the user stories, prioritize them, and bring them to the developers. The developers, armed with the knowledge of what the users want, are then responsible for breaking the requirements down into incremental development tasks that will produce real improvements as each one is completed.

One side effect of the agile paradigm is that it requires an acceleration of the entire software development lifecycle *and* of all the tooling required to get a piece of code from the developer's head onto the customer-facing website. When I started out in systems administration, I could leave a software QA server down for a week or two while I worked on more important tasks. What's a week or two of QA downtime, on a year-long development cycle?

But when that same cycle is supposed to run multiple times a day, and the developer has committed to having some good thing ready for customers by the end of the week, even an hour of QA downtime really hurts. So the entire pipeline has gotten more robust, more efficient, more fast.

And more automated. When you're cycling through the entire process multiple times a day, you can't just hand a guy an installer and some instructions and tell him to upgrade the server so they can test the new version. Instead, you fill your pipeline with robots that do all that automatically, on the fly, all day every day. Instead of telling your quality engineer to manually step through all of the testing processes, you tell him to write automated testing scripts using a standardized suite of tools, so that his expertise can also be applied continuously by robots, without having to wait for human intervention.

And that's basically my job: Administering an automated software delivery system, so that my developers can drop their code into a code repository, sit back, and let the robots do their job.

tl;dr - it means you start by finding out by what your customers actually want, so that when you give them stuff it's stuff you know they'll be happy to get.

Complements on a good summary of Waterfall vs Agile.

To the point of this thread, IT folks can likewise be bone-headed.

The company I am currently with claims to be working toward Agile, because that's what all the cool kids are doing. After three years of moving to Agile, we are more waterfall than before. If waterfalls flow up, that is.

In point of fact, we now have new Project Managers that don't understand the job, the product, or the existing software. They insist on gathering requirements and making promises to users without involving the programmers (who know the job, the product, and the software), or QA (who likewise know the job, the product, and the software), or anyone else who knows anything. Oh, and they are having off-shore programmers do the work, apparently to ensure that no one in the development cycle knows anything about how the job or the product.

As a result, they are doing a world-wide roll out of a new Order Processing system... created from scratch (!). It was a 1 year project that would be rolled out to 20 (of 70) countries initially. Cool.

The 1 year project started 2.5 years ago. They only need 6 more months [again] to roll out Phase 1. Phase 1 has limited baseline features, and will be published to 1 country when it is ready. Phase 1 was introduced as a concept about 1 year ago. They have quadrupled the off-shore teams to get this subset of the original done.

Us folks working on the 'legacy' systems were supposed to be phased out in 3 years, because all the systems would be moved off of our box. 2.5 years later, we have actually added countries and functionality.

We legacy folks shake our heads and smile. Most of us will retire before we are phased out.

[Hellbound]

Originally Posted by The Greater Fool

Complements on a good summary of Waterfall vs Agile.

To the point of this thread, IT folks can likewise be bone-headed.

The company I am currently with claims to be working toward Agile, because that's what all the cool kids are doing. After three years of moving to Agile, we are more waterfall than before. If waterfalls flow up, that is.

In point of fact, we now have new Project Managers that don't understand the job, the product, or the existing software. They insist on gathering requirements and making promises to users without involving the programmers (who know the job, the product, and the software), or QA (who likewise know the job, the product, and the software), or anyone else who knows anything. Oh, and they are having off-shore programmers do the work, apparently to ensure that no one in the development cycle knows anything about how the job or the product.

As a result, they are doing a world-wide roll out of a new Order Processing system... created from scratch (!). It was a 1 year project that would be rolled out to 20 (of 70) countries initially. Cool.

The 1 year project started 2.5 years ago. They only need 6 more months [again] to roll out Phase 1. Phase 1 has limited baseline features, and will be published to 1 country when it is ready. Phase 1 was introduced as a concept about 1 year ago. They have quadrupled the off-shore teams to get this subset of the original done.

Us folks working on the 'legacy' systems were supposed to be phased out in 3 years, because all the systems would be moved off of our box. 2.5 years later, we have actually added countries and functionality.

We legacy folks shake our heads and smile. Most of us will retire before we are phased out.

Not just with software development. I was only recently able to decommission my last 32-bit, Windows 2008 Server.

We had a guy retire a few years back. They had started on retiring a storage array for one system when he was hired. It did get retired before him, though. By a month.

We still have systems that MUST have Java 6 to operate.

Heck, it's only been about 4 years since we finally got one departments application (one that's central to our business) off a FoxPro database.

[TheGnome]

Originally Posted by Darat

You are both correct, they were often security devices - either to allow hardware to be connected or software to run.

These days the most common use for a dongle is as a mobile data connection.

Now you've made me curious. I tried to think of something and just drew a blank. Could you give an example maybe?

You wouldn't confuse it with the pass through function of the dongle, would you?

[Faydra]

Originally Posted by Hellbound

IBM product?

.

CA.


I wrote up the whole process as we were working through it step by step, and the CA tech asked me if he could have my document. I said sure, but... it still doesn't work so I'm not sure how useful it is. the document contains 28 steps (SO FAR).

[Wudang]

Originally Posted by Faydra

CA.


I wrote up the whole process as we were working through it step by step, and the CA tech asked me if he could have my document. I said sure, but... it still doesn't work so I'm not sure how useful it is. the document contains 28 steps (SO FAR).

I heard from some ex-CA in '93 guys that some companies, when buying from smaller companies, would add a clause that if the small company was bought by CA they would be compensated as that would mean support and service would fall off a cliff.

None of the CA products I've used impress me. Ops/MVS, AutomationPoint etc

[Hellbound]

Originally Posted by Faydra

CA.


I wrote up the whole process as we were working through it step by step, and the CA tech asked me if he could have my document. I said sure, but... it still doesn't work so I'm not sure how useful it is. the document contains 28 steps (SO FAR).

Ahhh...yes. CA. They were the ones that gave IBM the original idea, I think .

I am soooo happy to say we managed to break the blood pact with CA. We now do more with products that cost about 1/10th as much.

To be fair, both CA and IBM make some good products (IBM moreso, I think CA only had a couple winners), but they tend to be administratively demanding. If you're a big company, and can dedicate a person or a team to the products, it works great; the complexity and flexibility pretty much let you make it do whatever you need. But for us, a mid-size company, where that CA product is only one of the dozens of systems I'm responsible for, I don't have the kind of time it takes to learn all those products to that depth and configure them. So we actually get more out of solutions that may be less capable in theory, but are easier to administer and manage for our limited resources.

[Faydra]

CA has now been bought by Broadcom. Will be interesting to see how that affects things.

[zooterkin]

Originally Posted by theprestige

<snip>

tl;dr - it means you start by finding out by what your customers actually want, so that when you give them stuff it's stuff you know they'll be happy to get.

Thank you very much for taking the time to give such a clear description. I remain to be convinced that the new way of doing things is necessarily better than the old, but it's not something I'm going to worry about since I haven't done any development this millennium and I'm unlikely to do any serious work in IT again. The 'tl;dr' description is pretty much what I was taught we should do when I did my BSc in Computing (40 years ago), find out what the customer wanted first; we called it systems analysis in those days. Plus ça change...

[theprestige]

Originally Posted by The Greater Fool

Complements on a good summary of Waterfall vs Agile.

To the point of this thread, IT folks can likewise be bone-headed.

The company I am currently with claims to be working toward Agile, because that's what all the cool kids are doing. After three years of moving to Agile, we are more waterfall than before. If waterfalls flow up, that is.

In point of fact, we now have new Project Managers that don't understand the job, the product, or the existing software. They insist on gathering requirements and making promises to users without involving the programmers (who know the job, the product, and the software), or QA (who likewise know the job, the product, and the software), or anyone else who knows anything. Oh, and they are having off-shore programmers do the work, apparently to ensure that no one in the development cycle knows anything about how the job or the product.

As a result, they are doing a world-wide roll out of a new Order Processing system... created from scratch (!). It was a 1 year project that would be rolled out to 20 (of 70) countries initially. Cool.

The 1 year project started 2.5 years ago. They only need 6 more months [again] to roll out Phase 1. Phase 1 has limited baseline features, and will be published to 1 country when it is ready. Phase 1 was introduced as a concept about 1 year ago. They have quadrupled the off-shore teams to get this subset of the original done.

Us folks working on the 'legacy' systems were supposed to be phased out in 3 years, because all the systems would be moved off of our box. 2.5 years later, we have actually added countries and functionality.

We legacy folks shake our heads and smile. Most of us will retire before we are phased out.

In defense of IT folks, this sounds like more of a management problem. IT managers are not typically IT folks themselves - even if they may have been at some point. And Project Managers (agile or otherwise) are almost never IT folks at any point in their career.

I have been fortunate in my exposure to Agile, in that most of the Agile folks I've worked with - Project Managers, Product Owners, Scrum Masters - have been good folks. They haven't been very technical, but they have been enthusiastic and supportive process enthusiasts. In general, a good Agile person will recognize each contributor's specialty and role. They seem to see their job as encouraging and maturing a process that enables the technical folks to apply their expertise in productive and satisfying ways. Agile project management, properly understood, is very much a "servant leader" proposition.

[theprestige]

Originally Posted by zooterkin

Thank you very much for taking the time to give such a clear description. I remain to be convinced that the new way of doing things is necessarily better than the old, but it's not something I'm going to worry about since I haven't done any development this millennium and I'm unlikely to do any serious work in IT again. The 'tl;dr' description is pretty much what I was taught we should do when I did my BSc in Computing (40 years ago), find out what the customer wanted first; we called it systems analysis in those days. Plus ça change...

It's the rate of change that matters, I think. The basic principles have been around forever. What Agile does is tighten that feedback loop as much as possible.

[The Greater Fool]

Originally Posted by theprestige

In defense of IT folks, this sounds like more of a management problem. IT managers are not typically IT folks themselves - even if they may have been at some point. And Project Managers (agile or otherwise) are almost never IT folks at any point in their career.

I have been fortunate in my exposure to Agile, in that most of the Agile folks I've worked with - Project Managers, Product Owners, Scrum Masters - have been good folks. They haven't been very technical, but they have been enthusiastic and supportive process enthusiasts. In general, a good Agile person will recognize each contributor's specialty and role. They seem to see their job as encouraging and maturing a process that enables the technical folks to apply their expertise in productive and satisfying ways. Agile project management, properly understood, is very much a "servant leader" proposition.

My problem isn't with Agile, but as you correctly named: horrible IT management.

My previous position was with a company that was a true Agile shop, and I felt about my team as you felt about yours. It was well organized and well planned and generally well executed. Teams generally consisted of a Scrum Master (who worked on 8-12 teams), Project Manager (also 8-12 teams), Product owner, 2 QA, 2-3 Developers, and a documentation person. The whole team was involved from beginning to end, and we put out a good product. The experience showed me what Agile can do.

But, as the thread is more about bonehead users and IT departments, I shared the horror story, and not the rom-com.

[theprestige]

You actually had a documentation person? So much envy.

[Dancing David]

Originally Posted by JoeMorgue

I would argue about... half my time is trying to pull what the actual problem out of a user that only wants to keep saying some minor variation on "It doesn't work" over and over.

That is truth, however translating corrective actions is a challenge. In terms they use and understand, which I accept as the nature of the work.

Today I had a hall monitor who has a student assist in the translation.

Then there are those who don't follow instructions and seem to do whatever they want.

Me: Please Click on the Start button and then on the Start Menu select Devices and Printers, now towards the top of the screen you should see Add a Printer

User: (paraphrase) I did whatever thing I usually do, it doesn't look like that

[Dancing David]

Originally Posted by arthwollipot

Indeed. This is something that I'm usually very good at. That particular call stumped me, though. How are you with strong accents?

We have a lot of native french speakers immigrating from Africa and have started Dual Language French classrooms. I was working with someone who spoke english well, but was using french Gmail
One of my greater disasters was trying to communicate signing out of a personal Gmail, and they kept asking 'I should disconnect?"

I was thrown and needed a time out

[Hellbound]

This is one of the reasons I love Skype, WebEx, and similar screen sharing technologies. The user can show you what they're doing, and you can walk them through the process. That is SUCH a timesaver.

[phiwum]

Originally Posted by Tolls

That's not really her fault, of course.
It's the old "whisper the mystical incantation" idea that seems to pervade some places.

Either that or Python:
"One of cross beams has gone out skew on treddle."

Right, not her fault.

[phiwum]

Originally Posted by arthwollipot

Right, but it's not hard to learn the correct names for things. This particular one confused me because I'm old enough to remember the original meaning of the word "dongle", which was a pass-through device that plugged into the serial port of the computer that allowed proprietary hardware to operate. It was some time before I remembered that people use the word to refer to wireless broadband modems.

Surely, dongle applies to lots of USB devices these days?

I'm not computer illiterate, but I don't recall "dongle" before USB.

[Hellbound]

Originally Posted by phiwum

Surely, dongle applies to lots of USB devices these days?

I'm not computer illiterate, but I don't recall "dongle" before USB.

I do...it just wasn't in common use before then. I remember dongles for various devices (including software and in one case a networked printer/scanner) that were parallel or serial port devices.

[xterra]

I think the last time I used the word, it denoted a device that plugged into a computer's RJ-11 port, but I can't remember what the dongle attached to the computer.