If we change the alphabet so machines can read it, other people stop being able to read it. It's the wrong solution for the problem.
True, but that's not what the article's about, or at least, not what I think it's about. The question, as I understand it, is to find a script that people can use that's equally understandable by humans and machines.
In the end I guess it's the physics of bullshit. It's all spin. Hell, it's also up and down and goddamn strange, but it completely lacks beauty or charm. (Yea, I know I left out top and bottom but I couldn't think of a witty BDSM reference to justify them).
Even the top of the heap in this business is a bottom feeder.
Today that's probably what he'd be called. However, this was about 20 years ago. Also, I'm not exagerating when I call Dan a genius. Jerry Pournelle once dedicated a boot to "Dan Alderson, the sane genius." This namelist package required doing pointer arithmatic and moving bytes around absolute memory in FORTRAN, a languague designed to make that impossible. Dan did it, all in FORTRAN, with no assembler.
All that's really required is that it be in the TOS, so anybody can see it for themselves. As far as not mentioning it in the advertising goes, that's just to avoid confusing Joe Sixpack, who neither knows nor cares what Port 25 is.
Oddly enough, that's roughly what that subroutine package did. Instead of having a batch file call a program with a huge list of paramaters (Most of them set to their default value and having to be in exactly the right order.) you'd create a namelist file. In it, you'd list variable names and values, in whatever order you wanted. The namelist reader would set the variables to the right value, not touching any others. There was also a namelist writer that would output the values of everything in the namelist, in the right format. If the next program you passed it to found variables it didn't recognize, it simply ignored them. Now, of course, with everything done via GUI, there's probably no need for it, but back in '84, it saved a lot of people a bunch of work.
It's not like I do it constantly, or even every day. It's just once in a while that the subject seems Just Right for it, as it did with this. As an example, I'd not put a Ponies post into a MS vs Linux discussion, unless there were people wanking about Tux being better than the MS butterfly, and that would just be a reducto ad absurdum. Even if you want to keep the meme alive, there's just not that many places where it fits, and I never put it in unless it does.
The best way you can use an old computer to avoid spam is to have it download your email and run it through spam assasin, or some other filter program, then use that server as your POP3 server. However, that uses Port 110, and there's no problem with that.
If you're thinking of using your own SMTP server to block any zombies or worms, there's still no problem. Just use it for your SMTP server, and have it set to send everything out through your ISP, instead of directly. Yes, it's an extra step, but so what?
Back in '84-'85, I did some work with a genius programmer, the late Daniel J. Alderson. We were at JPL, so everything was public domain, which is as open source as you can get. As I worked with him, I watched what he did and how, and that taught me good coding practices that I've used to this day.
As an example, take a look at the functions in the standard I/O library for C. The various scanf() and prinf() variations use much the same arguments, but each one has them in a different order. There's no rhyme or reason to it, you either have to memorize the order or look it up. Not so with the functions Dan wrote! Part of his planning for a subroutine/function package was deciding what order the arguments would go in, and they were in exactly that order every time. (Many of the routines used either the same set of arguments, or a subset of them.) I was working with him because he'd gone blind from diabetes, and in all the time we worked on that package, he never got the arguments wrong because he'd planned it out ahead of time. In this case, there were only three functions that the average user'd need, and the rest were helpers for them. Still, if anybody needed them, they were there, and easy to use.
Now, imagine if this code were being used in a current OSS project. (Unlikely; not only is it in FORTRAN, the problem it solved had to do with command lines and batch files, mostly on a VAX.) Not only would it be easy to use, it'd be easy for somebody else to check the calls and make sure everything was in the right order. Sanity checks become quicker and there are less obscure bugs caused by misordered arguments. He also kept his variable delcarations alphabatized, as well as keeping his functions (except main() of course) in alphabetical order. Made it much easier to find the one you wanted, I can assure you.
Many ISPs block Port 25 for a good reason: open relays for spam. There aren't that many honest people who want to run their own SMTP servers, but most spammers would love to because it slips around spam blocking at the ISP level. It's always the few abusers who mess things up for everybody else.
Politicians don't pay much attention to on-line petitions. It only takes a moment to sign one, and doesn't show any real commitment to the idea. The same goes for form letters, either snail or email. Best is a personally written note, as it demonstrates enough interest to take the time to put your ideas in writing.
They *do* respond. Even if it's only a form letter from a staffer.
Some do. I was in one district for 18 years, another for 2. In both cases, my "representative" was from "that other lot." In neither case did they ever respond to me. The first one never got back with an answer when I went to his local office and spoke to his staff. I rapidly got the impression that for these two, at least, they only respond to members of their own party. I'm not saying that's always true, but it certainly seemed to be for this pair.
I wasn't trying to claim that I'm older, therefore I know better, I was pointing out that I'm older and more experienced than you'd have expected.
I agree with the point you made and I think we're really on the same side here. Note that the three techs I thought might have worked out my fix were very senior, and had roughly as much total computer experience as me. They didn't work it out, but that was after the fact and there was no pressure. Who knows what they'd nave done if they'd been faced with it?
You can work TS without understanding the product and do a good job, as long as you follow instructions and the problems fit the walk-throughs. If that's all you can do, or you can't improvise (which requires critical thinking) you're hosed whenever something unexpected comes up.
To get back to the article, certifications only show that you have memorized the material, not that you understand it. In some cases, I've heard, it requires you to know what the testers think is the right answer, even if it's wrong. I have a young friend who's trying to break into IT. He has several certs, and he's constnntly chasing more. Not because he thinks he needs them to do the job, but because he's hoping to find one that will land him a job. I wish him luck, but I sometimes wonder if the number of certs he has is holding him back; it may look like he's just collecting them, rather than using them.
You've mentored developers in their sixties? Interesting. Right now, I'm 56. As far as the FORTRAN goes, it was only to make the point, yet again, that what's obvious and easy to one is hard and obscure to another because of differing experience and training. I happen to know how to do that, but only because I helped the late Daniel J. Alderson do that at JPL in '84-85. Alas, I didn't meet him until after he'd written JPL's main space-probe navigation software; the one that never missed, unlike whatever they've replaced it with. I've never done kernal or system development, however, so I'm sure there's lots of stuff that you'd find obvious that I'd not understand, and that's exactly what I was talking about.
One thing you need to know to understand my example is that most tech support reps where I worked weren't techs by nature, they were just computer users who'd had some special training. Back when we regularly supported Win 3.1x, I found out the hard way that most of them wouldn't be able to use the output of mem/c/p to figure out what program was GPFing, even though the procedure was trivial to me. They didn't know Windows internals, they couldn't navigate in DOS because they'd never done it, and they wouldn't know how to find out which file was which, even if they'd located the right directory, and to be fair, they rarely, if ever, needed to. In short, by the standards of what you needed to know to do the job, that fix was deep wizardry. It might not be so to you, but your standards are different; not wrong, just different.
As far as that FORTRAN question goes, I'll give you a hint: it's amazing what you can do if you turn off bounds checking on arrays...
For OEM support, it wouldn't be. This was at an ISP, and we normally didn't touch non-bootable machines. This was an exception, because it happened when something went wrong while we were working on it. It was completely outside our normal baliwick and nobody would have chastised me if I'd just told her to reinstall. When I found out she had the boot floppy, I decided to try and recover. This took far longer than we're supposed to take, but as a very senior member of our Tier II, I had the discretion to take as long as it needed. If my lead had noticed the time, he would have asked me if I needed help, but not interfered otherwise. (Note that a junior tech would have had to ask permission to stay on a call that long.)
Not having done OEM support, I don't know the limits of your responsibility. Imagine doing a routine fix (I can still remember, three years later, every step in the routine.), having something that's normally not your responsibility going tits up, and improvising a fix that no other tech on your team would have thought of or known how to do. Whatever it might be, it'd take critical thinking, analysis and imagination. That may not always be needed in tech support, but doing it well, during an emergency, does.
It may not take critical thinking from your point of view, but remember, the average tech support rep doesn't have your training and experience. Also, dealing with crashed systems wasn't part of our regular job, so this was way outside their experience. I don't know how much experience you have in FORTRAN, but could you come up with a program that moves bytes around absolute memory in FORETRAN, without using assembler? I can, but then, I helped a genius write routines to do it in FORTRAN, because that was the language he was givin to work with. The point is, what's easy and obvious to somebody with one skillset is hard and obsucre to somebody with a different one. When you've been around computers half as long as I have (I first used one in 1968.) you'll begin to understand this.
Note that the clowns are all posting as AC. It looks easy because they see the whole situation laid out at once, including the solution. They also ignore (as I've pointed out in another post) that we almost never concerned ourselves with non-booting computers, as in general that wasn't our problem. This was a special case, and I never found another tech at that company that had a clue of how I'd done it.
For the type of support done at an ISP, it's an extreme case. Normally, we don't even try to work with non-booting systems because it's not related to our service and we're not going to take responsibility. The general rule was, unless you could boot Windows (not Safe Mode) we wouldn't work on it. In this case, however, it happened while I was working on it, and that made it my responsibility. I'm sure it's not extreme for an OEM support rep, because that's what he's there for.
Actually, it's not the only case of that I've heard of, and in the *NIX world, it's about the equivalent. Both needed specialized knowlege plus the ability to think. As I wrote in another post, as far as I could tell, there wasn't a single tech there other than myself who could have recovered without reinstalling Windows. I don't know if it says a lot about me or the quality of the average tech, and I don't care. I'm just glad that caller was talking to me that day instead of somebody else.
First of all, that's why I never emptied the recycling bin. Just In Case. Second, it was the only time in over seven years there that I needed to do something like that. Windows had to crash while copying in the new files, before the two in question were replaced and that's very unlikely. The point is that I was able to work out on the fly how to fix the issue, and that's a big part of what I was paid for: not how to read cheat-sheets, but how to improvise fixes when the shit hit the fan.
Slashdot Mirror
True, but that's not what the article's about, or at least, not what I think it's about. The question, as I understand it, is to find a script that people can use that's equally understandable by humans and machines.
Tanj, of course, is Larry Niven. Flup is the muck on the bottom of the Ringworld seas. Ooblick is from Dr. Seuss.
Even the top of the heap in this business is a bottom feeder.
There. Are you happy now?
But using the same phrase twice in a sentence is fine?
What's that? You don't like tanj? Well, that's just a lot of flup, isn't it? Why don't you go soak your head in some ooblick?
Today that's probably what he'd be called. However, this was about 20 years ago. Also, I'm not exagerating when I call Dan a genius. Jerry Pournelle once dedicated a boot to "Dan Alderson, the sane genius." This namelist package required doing pointer arithmatic and moving bytes around absolute memory in FORTRAN, a languague designed to make that impossible. Dan did it, all in FORTRAN, with no assembler.
Why don't you stop talking such Belgium, you Vogon!
All that's really required is that it be in the TOS, so anybody can see it for themselves. As far as not mentioning it in the advertising goes, that's just to avoid confusing Joe Sixpack, who neither knows nor cares what Port 25 is.
Oddly enough, that's roughly what that subroutine package did. Instead of having a batch file call a program with a huge list of paramaters (Most of them set to their default value and having to be in exactly the right order.) you'd create a namelist file. In it, you'd list variable names and values, in whatever order you wanted. The namelist reader would set the variables to the right value, not touching any others. There was also a namelist writer that would output the values of everything in the namelist, in the right format. If the next program you passed it to found variables it didn't recognize, it simply ignored them. Now, of course, with everything done via GUI, there's probably no need for it, but back in '84, it saved a lot of people a bunch of work.
It's not like I do it constantly, or even every day. It's just once in a while that the subject seems Just Right for it, as it did with this. As an example, I'd not put a Ponies post into a MS vs Linux discussion, unless there were people wanking about Tux being better than the MS butterfly, and that would just be a reducto ad absurdum. Even if you want to keep the meme alive, there's just not that many places where it fits, and I never put it in unless it does.
If you're thinking of using your own SMTP server to block any zombies or worms, there's still no problem. Just use it for your SMTP server, and have it set to send everything out through your ISP, instead of directly. Yes, it's an extra step, but so what?
As an example, take a look at the functions in the standard I/O library for C. The various scanf() and prinf() variations use much the same arguments, but each one has them in a different order. There's no rhyme or reason to it, you either have to memorize the order or look it up. Not so with the functions Dan wrote! Part of his planning for a subroutine/function package was deciding what order the arguments would go in, and they were in exactly that order every time. (Many of the routines used either the same set of arguments, or a subset of them.) I was working with him because he'd gone blind from diabetes, and in all the time we worked on that package, he never got the arguments wrong because he'd planned it out ahead of time. In this case, there were only three functions that the average user'd need, and the rest were helpers for them. Still, if anybody needed them, they were there, and easy to use.
Now, imagine if this code were being used in a current OSS project. (Unlikely; not only is it in FORTRAN, the problem it solved had to do with command lines and batch files, mostly on a VAX.) Not only would it be easy to use, it'd be easy for somebody else to check the calls and make sure everything was in the right order. Sanity checks become quicker and there are less obscure bugs caused by misordered arguments. He also kept his variable delcarations alphabatized, as well as keeping his functions (except main() of course) in alphabetical order. Made it much easier to find the one you wanted, I can assure you.
When Wikipedia updated the /. article to include Ponies, they used my post as an example. I feel an obligation...
Ponies. Preferrably pink. OMG! Ponies!!!
Many ISPs block Port 25 for a good reason: open relays for spam. There aren't that many honest people who want to run their own SMTP servers, but most spammers would love to because it slips around spam blocking at the ISP level. It's always the few abusers who mess things up for everybody else.
Politicians don't pay much attention to on-line petitions. It only takes a moment to sign one, and doesn't show any real commitment to the idea. The same goes for form letters, either snail or email. Best is a personally written note, as it demonstrates enough interest to take the time to put your ideas in writing.
Some do. I was in one district for 18 years, another for 2. In both cases, my "representative" was from "that other lot." In neither case did they ever respond to me. The first one never got back with an answer when I went to his local office and spoke to his staff. I rapidly got the impression that for these two, at least, they only respond to members of their own party. I'm not saying that's always true, but it certainly seemed to be for this pair.
I agree with the point you made and I think we're really on the same side here. Note that the three techs I thought might have worked out my fix were very senior, and had roughly as much total computer experience as me. They didn't work it out, but that was after the fact and there was no pressure. Who knows what they'd nave done if they'd been faced with it?
You can work TS without understanding the product and do a good job, as long as you follow instructions and the problems fit the walk-throughs. If that's all you can do, or you can't improvise (which requires critical thinking) you're hosed whenever something unexpected comes up.
To get back to the article, certifications only show that you have memorized the material, not that you understand it. In some cases, I've heard, it requires you to know what the testers think is the right answer, even if it's wrong. I have a young friend who's trying to break into IT. He has several certs, and he's constnntly chasing more. Not because he thinks he needs them to do the job, but because he's hoping to find one that will land him a job. I wish him luck, but I sometimes wonder if the number of certs he has is holding him back; it may look like he's just collecting them, rather than using them.
One thing you need to know to understand my example is that most tech support reps where I worked weren't techs by nature, they were just computer users who'd had some special training. Back when we regularly supported Win 3.1x, I found out the hard way that most of them wouldn't be able to use the output of mem /c/p to figure out what program was GPFing, even though the procedure was trivial to me. They didn't know Windows internals, they couldn't navigate in DOS because they'd never done it, and they wouldn't know how to find out which file was which, even if they'd located the right directory, and to be fair, they rarely, if ever, needed to. In short, by the standards of what you needed to know to do the job, that fix was deep wizardry. It might not be so to you, but your standards are different; not wrong, just different.
As far as that FORTRAN question goes, I'll give you a hint: it's amazing what you can do if you turn off bounds checking on arrays...
Not having done OEM support, I don't know the limits of your responsibility. Imagine doing a routine fix (I can still remember, three years later, every step in the routine.), having something that's normally not your responsibility going tits up, and improvising a fix that no other tech on your team would have thought of or known how to do. Whatever it might be, it'd take critical thinking, analysis and imagination. That may not always be needed in tech support, but doing it well, during an emergency, does.
It may not take critical thinking from your point of view, but remember, the average tech support rep doesn't have your training and experience. Also, dealing with crashed systems wasn't part of our regular job, so this was way outside their experience. I don't know how much experience you have in FORTRAN, but could you come up with a program that moves bytes around absolute memory in FORETRAN, without using assembler? I can, but then, I helped a genius write routines to do it in FORTRAN, because that was the language he was givin to work with. The point is, what's easy and obvious to somebody with one skillset is hard and obsucre to somebody with a different one. When you've been around computers half as long as I have (I first used one in 1968.) you'll begin to understand this.
Note that the clowns are all posting as AC. It looks easy because they see the whole situation laid out at once, including the solution. They also ignore (as I've pointed out in another post) that we almost never concerned ourselves with non-booting computers, as in general that wasn't our problem. This was a special case, and I never found another tech at that company that had a clue of how I'd done it.
For the type of support done at an ISP, it's an extreme case. Normally, we don't even try to work with non-booting systems because it's not related to our service and we're not going to take responsibility. The general rule was, unless you could boot Windows (not Safe Mode) we wouldn't work on it. In this case, however, it happened while I was working on it, and that made it my responsibility. I'm sure it's not extreme for an OEM support rep, because that's what he's there for.
Actually, it's not the only case of that I've heard of, and in the *NIX world, it's about the equivalent. Both needed specialized knowlege plus the ability to think. As I wrote in another post, as far as I could tell, there wasn't a single tech there other than myself who could have recovered without reinstalling Windows. I don't know if it says a lot about me or the quality of the average tech, and I don't care. I'm just glad that caller was talking to me that day instead of somebody else.
First of all, that's why I never emptied the recycling bin. Just In Case. Second, it was the only time in over seven years there that I needed to do something like that. Windows had to crash while copying in the new files, before the two in question were replaced and that's very unlikely. The point is that I was able to work out on the fly how to fix the issue, and that's a big part of what I was paid for: not how to read cheat-sheets, but how to improvise fixes when the shit hit the fan.