that's actually a pretty intriguing idea, but upon further consideration, the reliability factor probably leaves it at nothing more than intriguing.
helical scan media (which I assume D-VHS retains) is not particularly known for reliability, although AIT boosters would argue the point; personally, my experience has been with Exabyte 8mm (far below enterprise reliability) and DLT (quite good stuff), so maybe I've got two extremes of a more varied picture.
in the long run, though, I suspect that D-VHS would not be suitable for data (where every bit counts), while for video (where dropping a bit here and there can be easily compensated for [see also: video streaming]), it is a reasonable solution.
There is a significant light rail system that covers the southern portion of the city (well, afaik it doesn't venture above market/geary). they also have electric powered buses run off of overhead power lines. relatively quiet, environmentally friendlier, but it sucks when the power poles come off the lines (driver has to get out and put them back on).
the light rail in santa clara also runs on overhead lines.
oooh, oooh, and even better, they can use callerID to obtain the number of the caller who purchased the song, and then direct market accordingly. set up one of those automated call systems to call a user with a pre-selected sample matching their purchase profile (a la amazon).
customer: hello
acs: [30 seconds of insanely catch bubblegum pop, fades to allow voiceover] hello, this is yourMusic.com. the selection you're hearing has been chosen just for you! if you'd like to purchase it, just press #...
and you thought spam was bad, just wait for junk cold-calls to catch up.
Interesting. I hadn't realized that acronym implies a pronouncable word result, i.e. laser, radar, scuba. dictionary.com agrees with you on that one. However, at least in this industry, I think the usage of acronym as abbreviation has to fall under common usage. Consider the Jargon File's treatment of TLA: TLA/T-L-A/ n. [Three-Letter Acronym] 1. Self-describing abbreviation for a species with which computing terminology is infested. 2. Any confusing acronym. Examples include MCA, FTP, SNA, CPU, MMU, SCCS, DMU, FPU, NNTP, TLA.
With the exception of SNA, all of the above would take considerable phonetic license to pronounce.
Also, I'd highly recommend looking up the "curtailed words" entry in Fowler's (second edition, circa 1965), which notes: ".... and we always welcome any opportunity of giving pet names of this sort to the new inventions of atomic or electronic science, e.g.... Ernie (Electronic Random Number Indicating Equipment). Of course, this would have had to be Gowers contribution, since Fowler kicked it in 1933. But hell, just setting the tone for such idle banter in the midst of a treatment of English grammar... whataguy.
In my experience, WinCE apps will take as much CPU power as they can get. trying to use the web with Internet Explorer while it simultaneously runs a software modem... ech, just go do something else while the page loads.
I do not get the impression at all that WinCE was ever designed to run on lower power CPUs, just ones with smaller screens and no harddrive.
might want to consider the Vadem Clio. You can pick up a reconditioned C1000 factory direct for $600. 640x480x256 (or 65K colors with the C1050), workable keyboard, acts as a laptop or flip down the LCD on top of the keboard and you've got a webpad. PCMCIA slot, takes flash memory. try 12 hours of battery life. see www.clio.com. and no, I'm not gonna give you that in html; you like your keyboard so much, right?
and Linux is already ported to it, see www.linux-vr.org.
just waiting to get the damn PCMCIA-CF adapter in the mail, and I'll be going to town on it.
Wow, someone actually gets the clue here... QoS features aren't being developed just because they are really neat. They are being developed because someday they are going to enable certain companies to more efficiently sell their network service. go read a goddamn book on ATM and learn what GBR, ABR, UBR, and suchlike mean. and understand why if you read the fine print on your DSL contract, your 1.5M/384K connection really only guarantees 128K/64K.
please, please, as relatively enlightened users of technology, understand the meshing of technological capabilities and market forces. don't just fear it, understand it.
Paid QoS makes a great deal of sense, from a capitalist perspective, as much as it might suck in terms of closing down avenues of communication for the less monied aspiring broadcaster/publisher. understandy why. understand how. then coherently assemble an argument as to why it's wrong, and how we can change it.
otherwise, shut your festering gob. you tit. your type makes me... oh you know the rest.
I think a very important question here is how can communications technology simultaneously provide a living and improve quality of life... I'm afraid I'm going down the slippery slope of neo-liberal economics, requiring everything to be viewed in terms of on economic exchange, but really, how is having access to the internet going to change the way people in bangladesh or nepal or botswana live?
obviously being able to communicate with family members who have gone abroad is one example cited in this forum. however, those families who can afford to send someone abroad are in the top 20% of those societies, not the impoverished masses.
the cellphone lady example I cited elsewhere utilized technology to provide a needed service that improved quality of life. she enables people to avoid having to spend the entire day walking between two remote villages to simply communicate. and she is compensated for providing this service. everyone wins.
going further, though, if we consider computers and telephony to be means of production, which we can conceivably make available to the impoverished in developing countries, what product can they produce? are we going to realize the Dilbert notion of Elbonia, contracting out coding to villages in tibet?
I ask this question in all seriousness. this sort of issue has come up before; a prominent senator in west virginia (I think it was byrd) got federal money for a program to teach coal miners (not a booming profession right now) to code in ADA. I believe the program was not very successful, not because coal miners are stupid (go see Matewan please), but because shifting gears like that tends to rip out your mental transmission...
but I digress...
again, my question is: how can the spread of computer and telephony technology into developing countries actually provide a sustainable livelihood for the forgotten four-fifths, the impoverished majority?
As I noted in an earlier post, wireless may be a very powerful force in these areas, as it requires less of an infrastructure. of course, generally wireless is going to require WAPs (wired access points) if the users wish to communicate beyond, say, their village. however, going even further out on this limb, consider satellite communications....
this is really a very interesting topic, because these technologies move us away from the idea of control of populace by control of geography. i.e. cutting telecom lines restricts communication quite well in a country who relies heavily on landlines; a country built more on wireless is more versatile, especially if they have a direct wireless connection to an area outside of the local/national governments region of control (i.e. satelitte uplink).
this is not completely new, of course: consider efforts made by governments using radio broadcasts into "enemy territory", i.e. Radio Free . wireless is a liberational technology -- consider one of the first orders made by the nutso commander in Dr. Strangelove: all civilian radios are to be turned in, ostensibly to prevent the infusion of misinformation by enemy forces.... ah, those simple, early years of information warfare.
I would recommend looking at Grameen's work in this area. Grameen Bank was started by Mohammed Yunnus (sp?!), and economist from Bangladesh, who realized that all his hifalutin theories were not relavant to the impoverished women next door to his university. He began a micro-lending institution which has grown to an international institution. Really terrific stuff, see his book "Banker To the Poor".
The relevancy to this topic: Grameen has gotten into telecommunications and the Internet lately, but maintained a focus on the classically impoverished portions of society. Witness the "cell-phone lady", who is a woman in a village who owns a cellphone and charges others a small fee to use it to call other villages, where another "cell-phone lady" provides a similar service.
Incidentally, wireless networking is a very good solution in third world countries, where landlines have a nasty habit of being torn down, possibly for use as scrap copper...
This is an excellent point that you make. I worked two very different tech support jobs, first as a "student consultant" at my uni. computing center. There I dealt with many of your "bad student" types, who were just generally pissed about having to deal with this stuff at all, and had no interest in understanding why/how/what was the problem.
The second tech support job was with a high-end file server company, where our customer base could generally afford to pay intelligent system administrators to maintain their systems. Suddenly I was talking to users who often knew more than I did, and looked at me to provide specific information (i.e. what version of SMT our FDDI adapter supported). And the customers that did indeed need guidance were generally much more pleasant. Still, there were/are those customers, even at this level (and payscale) who insist on having their hand held through every bad disk replacement (the simplest procedure).
However, there are the customers who are so sharp that while you dread their call in some respects, you know you will come out of that call significantly smarter than when you started. of course, this assumes _you_, the tech support person, are willing to learn.
And THIS brings me to the point of what really bothers me about the original article: the notion of tech support as something which can be trained in three weeks. I guess this is largely true of tech support in the world, which is why, on the other side of the coin, there are so many comic strips about terrible tech support experiences from the user's perspective.
BUT, good tech support requires so much more than this. sorry, this is my chosen cross to bear, but good tech support is important, and it's hard to do. the "three week" tech support staff rely heavily on some flowchart and "escalate" real problems up. they punt, and never learn anything more. and they ultimately remain only a smidgen ahead of their users on the ignorance scale...
this kills me, because now I train tech support folks, and seeing this unwillingness to learn makes my work seem meaningless. horse to water and all that... my constant question is what methods can I use to really get my audience (tech support) to learn how our system works so they can problem solve for themselves. this is the same question that needs to be asked for dealing with end-users -- what can I do, as a tech support provider, to encourage the customer to learn...
this is where tech support folks need to be more like teachers, or even salespeople -- what I find is that I try to _sell_ the idea of learning a few basics: "hey, if you read this, you don't waste 30 minutes/2 days trying to get ahold of tech support!" there's also my pedagogical tool fetish, but that belongs in a thread of its own.
1. If you prefer open-source to closed-source coding, you will love what biotech companies want to patent... 2. The US is amazingly obvlivious compared to how much Europeans are up in arms over this issue; OR: The Europeans are far more reactionary about such things than the US is. 3. Do recall that we are talking about our food supply. Yes, I know that perhaps some of these scary stories about cross-polination and terminator genes seem rather alarmist, but we are talking about our food supply, one of those things that founds Maslow's little triangle. 4. Evolution is one thing. GM is evolution on crack, without the natural selection that tends to keep things in check. This is what really scares me about GM -- the fact that we accelerate things to where Ma Nature can't keep up with her natural antidotes to human stupidity, the balance is upset, and life starts to suck a lot more than usual. okay, that would be 4 cents, so I'm $0.02 over budget. nathan
I must take issue with the "programmers don't write good documentation because they are too close to the code". Programmers write lousy documentation for two reasons: 1. They speak English as a second language (okay, this is more applicable perhaps to my current job) 2. They can't write period. Reason #1 is acceptable to me. I can't speak their language at all, so they're doing me a favor by speaking mine at all. Reason #2 is the overwhelming problem here. Too many people cannot write. Period. This extends far beyond coders; I recently reviewed an essay by an Art student which was almost unreadable, not for all the deconstructionist ArtSpeak, but simply for the poor grammar and spelling. Okay, now I sound like a bad actor doing a PSA, "stay in school! it's cool!" But hell, take some time when you choose to express yourself, being understood is important. As for the issue of being able to explain things in a sufficiently coherent manner for newbies: I would challenge you to always strive for this ability. You will find that it forces you to really make sure you understand the ins and outs of whatever technology you work with. I say this having taught things ranging from ethernet autosensing/negotiation to how to click and drag a file. When you break things down to where you're audience can understand them, you tend to learn a great deal yourself.
I'm afraid that the particular problem you describe, of X and SMB getting hosed up due to an IP misconfiguration, is an example of a very large class of problems which are simply too complex to expect easy, or at least readily available, answers to. It sounds like you knew that your IP was going to be changed, and therefor were able to resolve the problem rather quickly. I suspect you would have been down far longer than 45 minutes had you not known of this little IP switcheroo.
Perhaps troubleshooting tools and flows may help narrow down many problems, but such problems as yours which can arise in complex systems will always be very difficult to approach without having a pretty deep understanding of how the stuff actually works.
The car mechanic metaphor works rather well here: everyone knows that when the fuel needle is on E, you have to put gas in or bad stuff happens. and people know that if the oil light comes on, it's generally a good idea to add oil. however, not many people know what to do if you add oil or it's already full according to the dipstick, and the light still comes on. people that understand cars, i.e. mechanics, know that the oil light indicates oil pressure, not oil level. therefor they can deduce that the problem is likely to be an oil pump. if you don't know this, you're hosed -- your engine is going to run dry, seize up, and you will be exceedingly bummed.
so, the moral is something to the effect of: life is complicated, reading a book helps, but sometimes you need to call a mechanic.
When the average person does decide that they do need to read the manual, they refuse to read it all the way through, and instead try to find that one piece of information they currently need. This stratagem never works, of course, since they have no foundation to base that information on.
Excellent point. And I won't deny that I have a tendency to do this, at least at first. Eventually, though, if a system is complex enough, I will find time to snuggle up with a hardcopy (sorry, tree, but CRT/LCD just don't do it for me) of detailed design docs.
The point here is that you can lead a horse to water, but the pope will still shit in the woods. I encounter this same dilemma at work, being a technical instructor focusing on in-depth tech support issues. I know what I know because I've spent many hours reading design docs, text books, and the occasional chunk of code. however, I can't seem to get the tech support folks to read everything I've read so they'll become real smart and quit asking me questions.
I've decided the best I can do is try to develop tools which encapsulate what I and others know, and make sure that these tools are well-linked to the actual information sources from which they were derived. Eventually, students/users get comfortable with rooting out their own answers, when they realize that it just takes the upfront effort to familiarize yourself with system design by reading specs and such. nathan
I find it hard to hear such words springing forth from my own mouth, but the concept of a "solutions database" seems remarkably appropriate here.
Generally, I rail like nothing else against solutions databases, because my job is to enable people to solve complex problems in complex systems, and solutions databases tend to grossly oversimplify this task, which I find mildly insulting. also, we must consider the 90%/10% rule, whereby 90% of the calls/problem reports encompass 10% of the possible problem domain, but, conversely, the 10% of the calls which involve the other 90% of possible problems will also consume 90% of support staff's time. However, we are talking about newbies here. And newbies happen to consitute 99% of the 90% easy calls. Thus a solutions database becomes a realistic and productive answer.
blah blah blah solutions database blah blah solutions database blah.... okay, WTF do I mean by solutions db? think search engine, but with better semantics, and an astonishingly high signal to noise ratio. the actual database consists of answers -- and only answers, so we don't frustrate users by matching their query with an unanswered question -- which are concise, correct, specific, cross-referenced to more detailed information (THERE'S TFM). these answers will be submitted by whomever (one thing linux has is an amazing volunteer support base), but (here's the catch) must be filtered, combed, possibly edited, by a dedicated group of individuals.
What's the value add beyond the many linux-based search engines, specific help pages, newsgroups/email reflectors, etc? specificity and conciseness -- in short, a very good signal-to-noise ratio. the key is not treating this like a damn swiss army knife -- build one tool that serves one purpose well, rather than doing a shitsplatter job trying to cover everything with one tool.
if anyone is interested in hosting such a site, I'd be glad to help make such a thing a reality.
Slashdot Mirror
that's actually a pretty intriguing idea, but upon further consideration, the reliability factor probably leaves it at nothing more than intriguing.
helical scan media (which I assume D-VHS retains) is not particularly known for reliability, although AIT boosters would argue the point; personally, my experience has been with Exabyte 8mm (far below enterprise reliability) and DLT (quite good stuff), so maybe I've got two extremes of a more varied picture.
in the long run, though, I suspect that D-VHS would not be suitable for data (where every bit counts), while for video (where dropping a bit here and there can be easily compensated for [see also: video streaming]), it is a reasonable solution.
There is a significant light rail system that covers the southern portion of the city (well, afaik it doesn't venture above market/geary). they also have electric powered buses run off of overhead power lines. relatively quiet, environmentally friendlier, but it sucks when the power poles come off the lines (driver has to get out and put them back on).
the light rail in santa clara also runs on overhead lines.
nathan
oooh, oooh, and even better, they can use callerID to obtain the number of the caller who purchased the song, and then direct market accordingly. set up one of those automated call systems to call a user with a pre-selected sample matching their purchase profile (a la amazon).
customer: hello
acs: [30 seconds of insanely catch bubblegum pop, fades to allow voiceover] hello, this is yourMusic.com. the selection you're hearing has been chosen just for you! if you'd like to purchase it, just press #...
and you thought spam was bad, just wait for junk cold-calls to catch up.
beauty.
Interesting. I hadn't realized that acronym implies a pronouncable word result, i.e. laser, radar, scuba. dictionary.com agrees with you on that one. /T-L-A/ n. [Three-Letter Acronym] 1. Self-describing abbreviation for a species with which computing terminology is infested. 2. Any confusing acronym. Examples include MCA, FTP, SNA, CPU, MMU, SCCS, DMU, FPU, NNTP, TLA.
... Ernie (Electronic Random Number Indicating Equipment). Of course, this would have had to be Gowers contribution, since Fowler kicked it in 1933. But hell, just setting the tone for such idle banter in the midst of a treatment of English grammar... whataguy.
However, at least in this industry, I think the usage of acronym as abbreviation has to fall under common usage. Consider the Jargon File's treatment of TLA:
TLA
With the exception of SNA, all of the above would take considerable phonetic license to pronounce.
Also, I'd highly recommend looking up the "curtailed words" entry in Fowler's (second edition, circa 1965), which notes: ".... and we always welcome any opportunity of giving pet names of this sort to the new inventions of atomic or electronic science, e.g.
thanks for the anal grammar pointer du jour.
nathan
In my experience, WinCE apps will take as much CPU power as they can get. trying to use the web with Internet Explorer while it simultaneously runs a software modem... ech, just go do something else while the page loads.
I do not get the impression at all that WinCE was ever designed to run on lower power CPUs, just ones with smaller screens and no harddrive.
might want to consider the Vadem Clio. You can pick up a reconditioned C1000 factory direct for $600. 640x480x256 (or 65K colors with the C1050), workable keyboard, acts as a laptop or flip down the LCD on top of the keboard and you've got a webpad. PCMCIA slot, takes flash memory. try 12 hours of battery life.
see www.clio.com. and no, I'm not gonna give you that in html; you like your keyboard so much, right?
and Linux is already ported to it, see www.linux-vr.org.
just waiting to get the damn PCMCIA-CF adapter in the mail, and I'll be going to town on it.
Wow, someone actually gets the clue here... QoS features aren't being developed just because they are really neat. They are being developed because someday they are going to enable certain companies to more efficiently sell their network service. go read a goddamn book on ATM and learn what GBR, ABR, UBR, and suchlike mean. and understand why if you read the fine print on your DSL contract, your 1.5M/384K connection really only guarantees 128K/64K.
please, please, as relatively enlightened users of technology, understand the meshing of technological capabilities and market forces. don't just fear it, understand it.
Paid QoS makes a great deal of sense, from a capitalist perspective, as much as it might suck in terms of closing down avenues of communication for the less monied aspiring broadcaster/publisher. understandy why. understand how. then coherently assemble an argument as to why it's wrong, and how we can change it.
otherwise, shut your festering gob. you tit. your type makes me... oh you know the rest.
nathan
I think a very important question here is how can communications technology simultaneously provide a living and improve quality of life... I'm afraid I'm going down the slippery slope of neo-liberal economics, requiring everything to be viewed in terms of on economic exchange, but really, how is having access to the internet going to change the way people in bangladesh or nepal or botswana live?
obviously being able to communicate with family members who have gone abroad is one example cited in this forum. however, those families who can afford to send someone abroad are in the top 20% of those societies, not the impoverished masses.
the cellphone lady example I cited elsewhere utilized technology to provide a needed service that improved quality of life. she enables people to avoid having to spend the entire day walking between two remote villages to simply communicate. and she is compensated for providing this service. everyone wins.
going further, though, if we consider computers and telephony to be means of production, which we can conceivably make available to the impoverished in developing countries, what product can they produce? are we going to realize the Dilbert notion of Elbonia, contracting out coding to villages in tibet?
I ask this question in all seriousness. this sort of issue has come up before; a prominent senator in west virginia (I think it was byrd) got federal money for a program to teach coal miners (not a booming profession right now) to code in ADA. I believe the program was not very successful, not because coal miners are stupid (go see Matewan please), but because shifting gears like that tends to rip out your mental transmission...
but I digress...
again, my question is: how can the spread of computer and telephony technology into developing countries actually provide a sustainable livelihood for the forgotten four-fifths, the impoverished majority?
nathan
Excellent post!
As I noted in an earlier post, wireless may be a very powerful force in these areas, as it requires less of an infrastructure. of course, generally wireless is going to require WAPs (wired access points) if the users wish to communicate beyond, say, their village. however, going even further out on this limb, consider satellite communications....
this is really a very interesting topic, because these technologies move us away from the idea of control of populace by control of geography. i.e. cutting telecom lines restricts communication quite well in a country who relies heavily on landlines; a country built more on wireless is more versatile, especially if they have a direct wireless connection to an area outside of the local/national governments region of control (i.e. satelitte uplink).
this is not completely new, of course: consider efforts made by governments using radio broadcasts into "enemy territory", i.e. Radio Free . wireless is a liberational technology -- consider one of the first orders made by the nutso commander in Dr. Strangelove: all civilian radios are to be turned in, ostensibly to prevent the infusion of misinformation by enemy forces.... ah, those simple, early years of information warfare.
ramble ramble
nathan
I would recommend looking at Grameen's work in this area. Grameen Bank was started by Mohammed Yunnus (sp?!), and economist from Bangladesh, who realized that all his hifalutin theories were not relavant to the impoverished women next door to his university. He began a micro-lending institution which has grown to an international institution. Really terrific stuff, see his book "Banker To the Poor".
The relevancy to this topic: Grameen has gotten into telecommunications and the Internet lately, but maintained a focus on the classically impoverished portions of society. Witness the "cell-phone lady", who is a woman in a village who owns a cellphone and charges others a small fee to use it to call other villages, where another "cell-phone lady" provides a similar service.
Incidentally, wireless networking is a very good solution in third world countries, where landlines have a nasty habit of being torn down, possibly for use as scrap copper...
see www.grameen.org for more.
excellent topic, by the way.
nathan
This is an excellent point that you make.
I worked two very different tech support jobs,
first as a "student consultant" at my uni. computing center. There I dealt with many of your "bad student" types, who were just generally pissed about having to deal with this stuff at all, and had no interest in understanding why/how/what was the problem.
The second tech support job was with a high-end file server company, where our customer base could generally afford to pay intelligent system administrators to maintain their systems. Suddenly I was talking to users who often knew more than I did, and looked at me to provide specific information (i.e. what version of SMT our FDDI adapter supported). And the customers that did indeed need guidance were generally much more pleasant. Still, there were/are those customers, even at this level (and payscale) who insist on having their hand held through every bad disk replacement (the simplest procedure).
However, there are the customers who are so sharp that while you dread their call in some respects, you know you will come out of that call significantly smarter than when you started. of course, this assumes _you_, the tech support person, are willing to learn.
And THIS brings me to the point of what really bothers me about the original article: the notion of tech support as something which can be trained in three weeks. I guess this is largely true of tech support in the world, which is why, on the other side of the coin, there are so many comic strips about terrible tech support experiences from the user's perspective.
BUT, good tech support requires so much more than this. sorry, this is my chosen cross to bear, but good tech support is important, and it's hard to do. the "three week" tech support staff rely heavily on some flowchart and "escalate" real problems up. they punt, and never learn anything more. and they ultimately remain only a smidgen ahead of their users on the ignorance scale...
this kills me, because now I train tech support folks, and seeing this unwillingness to learn makes my work seem meaningless. horse to water and all that... my constant question is what methods can I use to really get my audience (tech support) to learn how our system works so they can problem solve for themselves. this is the same question that needs to be asked for dealing with end-users -- what can I do, as a tech support provider, to encourage the customer to learn...
this is where tech support folks need to be more like teachers, or even salespeople -- what I find is that I try to _sell_ the idea of learning a few basics: "hey, if you read this, you don't waste 30 minutes/2 days trying to get ahold of tech support!" there's also my pedagogical tool fetish, but that belongs in a thread of its own.
nathan
1. If you prefer open-source to closed-source coding, you will love what biotech companies want to patent... 2. The US is amazingly obvlivious compared to how much Europeans are up in arms over this issue; OR: The Europeans are far more reactionary about such things than the US is. 3. Do recall that we are talking about our food supply. Yes, I know that perhaps some of these scary stories about cross-polination and terminator genes seem rather alarmist, but we are talking about our food supply, one of those things that founds Maslow's little triangle. 4. Evolution is one thing. GM is evolution on crack, without the natural selection that tends to keep things in check. This is what really scares me about GM -- the fact that we accelerate things to where Ma Nature can't keep up with her natural antidotes to human stupidity, the balance is upset, and life starts to suck a lot more than usual. okay, that would be 4 cents, so I'm $0.02 over budget. nathan
I must take issue with the "programmers don't write good documentation because they are too close to the code". Programmers write lousy documentation for two reasons:
1. They speak English as a second language (okay, this is more applicable perhaps to my current job)
2. They can't write period.
Reason #1 is acceptable to me. I can't speak their language at all, so they're doing me a favor by speaking mine at all. Reason #2 is the overwhelming problem here. Too many people cannot write. Period. This extends far beyond coders; I recently reviewed an essay by an Art student which was almost unreadable, not for all the deconstructionist ArtSpeak, but simply for the poor grammar and spelling.
Okay, now I sound like a bad actor doing a PSA, "stay in school! it's cool!" But hell, take some time when you choose to express yourself, being understood is important.
As for the issue of being able to explain things in a sufficiently coherent manner for newbies: I would challenge you to always strive for this ability. You will find that it forces you to really make sure you understand the ins and outs of whatever technology you work with.
I say this having taught things ranging from ethernet autosensing/negotiation to how to click and drag a file. When you break things down to where you're audience can understand them, you tend to learn a great deal yourself.
I'm afraid that the particular problem you describe, of X and SMB getting hosed up due to an IP misconfiguration, is an example of a very large class of problems which are simply too complex to expect easy, or at least readily available, answers to. It sounds like you knew that your IP was going to be changed, and therefor were able to resolve the problem rather quickly. I suspect you would have been down far longer than 45 minutes had you not known of this little IP switcheroo.
Perhaps troubleshooting tools and flows may help narrow down many problems, but such problems as yours which can arise in complex systems will always be very difficult to approach without having a pretty deep understanding of how the stuff actually works.
The car mechanic metaphor works rather well here: everyone knows that when the fuel needle is on E, you have to put gas in or bad stuff happens. and people know that if the oil light comes on, it's generally a good idea to add oil. however, not many people know what to do if you add oil or it's already full according to the dipstick, and the light still comes on. people that understand cars, i.e. mechanics, know that the oil light indicates oil pressure, not oil level. therefor they can deduce that the problem is likely to be an oil pump. if you don't know this, you're hosed -- your engine is going to run dry, seize up, and you will be exceedingly bummed.
so, the moral is something to the effect of: life is complicated, reading a book helps, but sometimes you need to call a mechanic.
nathan
Excellent point. And I won't deny that I have a tendency to do this, at least at first. Eventually, though, if a system is complex enough, I will find time to snuggle up with a hardcopy (sorry, tree, but CRT/LCD just don't do it for me) of detailed design docs.
The point here is that you can lead a horse to water, but the pope will still shit in the woods.
I encounter this same dilemma at work, being a technical instructor focusing on in-depth tech support issues. I know what I know because I've spent many hours reading design docs, text books, and the occasional chunk of code. however, I can't seem to get the tech support folks to read everything I've read so they'll become real smart and quit asking me questions.
I've decided the best I can do is try to develop tools which encapsulate what I and others know, and make sure that these tools are well-linked to the actual information sources from which they were derived. Eventually, students/users get comfortable with rooting out their own answers, when they realize that it just takes the upfront effort to familiarize yourself with system design by reading specs and such.
nathan
I find it hard to hear such words springing forth from my own mouth, but the concept of a "solutions database" seems remarkably appropriate here.
Generally, I rail like nothing else against solutions databases, because my job is to enable people to solve complex problems in complex systems, and solutions databases tend to grossly oversimplify this task, which I find mildly insulting. also, we must consider the 90%/10% rule, whereby 90% of the calls/problem reports encompass 10% of the possible problem domain, but, conversely, the 10% of the calls which involve the other 90% of possible problems will also consume 90% of support staff's time.
However, we are talking about newbies here. And newbies happen to consitute 99% of the 90% easy calls. Thus a solutions database becomes a realistic and productive answer.
blah blah blah solutions database blah blah solutions database blah.... okay, WTF do I mean by solutions db?
think search engine, but with better semantics, and an astonishingly high signal to noise ratio. the actual database consists of answers -- and only answers, so we don't frustrate users by matching their query with an unanswered question -- which are concise, correct, specific, cross-referenced to more detailed information (THERE'S TFM). these answers will be submitted by whomever (one thing linux has is an amazing volunteer support base), but (here's the catch) must be filtered, combed, possibly edited, by a dedicated group of individuals.
What's the value add beyond the many linux-based search engines, specific help pages, newsgroups/email reflectors, etc? specificity and conciseness -- in short, a very good signal-to-noise ratio. the key is not treating this like a damn swiss army knife -- build one tool that serves one purpose well, rather than doing a shitsplatter job trying to cover everything with one tool.
if anyone is interested in hosting such a site, I'd be glad to help make such a thing a reality.
nathan