I am reading lots of the same comment... "Your boss doesn't know what (s)he's talking about," or worse. Perhaps the problem is that, as a tech or engineer, the "I can make that damned cable just as good as Anixter" zealot might not know as much about the overall value of a tech's time as his manager does.
As I have said before, my preference is virtually always to order custom-premade or off-the-shelf premade. This has virtually nothing to do with not knowing how to crimp up a fine cable, or a lack of understanding about the quality of a homebuilt cable, or the time necessary to do it.
Simple fact of the matter is that I pay my people to do other stuff than crimp cable. For every hour one of my staff is crimping cable, they could be doing an hour of something else, presumably requiring the skills that they were hired for.
The straight dollar value of the time spent making cables versus the cost of buying them does not take into account the relative value of cable building versus the value of, say, building out a router or firewall config (which will still be left to do even after the cable-building exercise).
It's true. Telecoms use handmade custom length cable runs created by their technicians. Telecoms use handmade cables because they pay their guys to make cables. And the value of a custom length cable in a carrier-class complex cable plant is high enough to warrant fulltime guys with that skill.
Most small to mid-size enterprises can't afford to have a network guy that is even partially dedicated to cable creation. In fact, most network operations that I have dealt with are understaffed, with no hope of being expanded out to the right headcount, and having to make cables merely puts them in a bigger resource bind than normal.
Sometimes, the manager's truly a putz. Usually, though, that perception is simply that the manager has a slightly different set of priorities than the tech/engineer.
In either case, unless you plan on getting fired or have a real good reason to think you can get your manager fired for being an idiot (which is surprisingly uncommon, something to consider), the fact remains that (s)he is still your manager, and you're going to wind up doing what (s)he wants. So, document your recommendations, in case their refusal turns out to be a critical oversight later on. At least, then, your "I told you so," will have some weight.
First, I agree with Causality on this one. The boss says buy the cables, then buy the cables. But that's not a technical issue, and really, shouldn't be argued here.
As far as the technical bit, I'll tell you what I do:
A) Argue vehemently for custom-made cabling in appropriate custom coloring. This is expensive and takes a good long while. Order extras at any length.
When that fails, or I need shorter turnaround...
B) Order closest-match premade cable. Order extras at any length.
If (and ONLY if) I need a cable RIGHT NOW...
C) I'll make a cable, or have the network guys make one or two.
In every case, the cables are tested before and after a run.
As for reliability, quality, etc... You definitely can make high quality cables manually, even with inexpensive equipment, but it requires a lot of diligence (read: time and care), or a lot of experience to get it reliably right, both of which are expensive.
If you're dealing with twenty network drops, then sure, maybe you have time to make some decent quality cables, and the overall cost impact is not going to be too high.
But, in a medium sized operation, you might be dealing with several hundred server-side connections and hundreds to thousands of desktop/office connections. At this point, the cost to build cables, even at a high rate, is going to outstrip the cost of buying (at worst) closest-fit cabling off the shelf.
There is a valid argument that datacenters and normal office cat5e/cat6 cabling is put together by hand, and homebuilt cabling shouldn't be any worse than that. There are some significant differences, though, between wiring jacks and running drops.
First, in-wall or in-rack wiring moves rarely, if ever, so degradation due to stresses on the hand-punched connections are minimal.
And second, third-party networking and cabling folks that put together office wiring and datacenter wiring en masse, do hundreds, if not thousands, of connections per job, which is to say they have a LOT of experience doing the wiring in a reasonably high-quality fashion.
This all means that, even if you're like me and have been homebrewing cables since STP ethernet made its debut, the guy doing your office punchdown is WAY more experienced than you, and can reasonably justify hand-building thousands of cables.
So, to recap: Boss wants prefab cables, boss gets prefab cables. Is it better or worse to build them? It depends.
Of course, there is also the reverse effect. Things that, as an ancient admin, you still do even though you don't have to... Evolution of the operating environment for easier living, through command enhancements or totally new utilities often goes ignored.
For instance, I find myself typing "df -k" and shifting off the decimal places in my head rather than just using the now-available "df -g". Just out of a long standing habit.
I also almost always either work in 80x25 windows, or 132x50 windows out of habit from the old days, and still get nervous when I resize.
Back in 1994, when I got my first AIX machine for administration, it took me nearly half a year to stop editing configuration files directly. For certain things which I know are safe, I still do direct-edits.
Regular expressions. People have NO clue how to assemble a regular expression. Or, for that matter that regular expressions are... well, REGULAR.
On that same line, the ancient ex knowledge that precedes vi. I use ex commands in batch to modify large numbers of files in place all the time. This includes line address searching, ranges, and blocks.
sed command separators. If you're modifying a bunch of directory names, it's not necessary to "escape" the slash character to get it into your sed line... you just choose a different separator character, which is, by default, the character after the substitute command: (i.e. what was 's/\/dirA/\/dirB/' becomes 's,/dirA,/dirB,' )
Now THAT's funny:) I love the iUniform. Standard-issue to free-thinkers everywhere.
I'm not even sure that they were supposed to even let me in this coffeeshop with my MS-laden beast. It doesn't even have a glowing logo on the lid. I think I was grandfathered in because I'm so "old".
The simple truth of the matter is this... you work for a company that not only has a say over what job you do, but to a very large extent, how you do it. The reasons for their decisions in these matters are often counterintuitive from your point of view, and may, in fact, be provably wrong. But, in the end, after all the shouting is over, the paycheck only flows one way, which means you will need to suck it up and just do it the way they want, or make a personal change.
And in the grandest tradition of American freedom, you can simply choose to work elsewhere. Plenty of Solaris in the world, you know...
Not really. they're "crossing off" other OS'es because they DO have good reasons.
The answer is this:
You don't administer your workstation, our desktop people do, and they are trained to do Windows because there's a really good business case for having a uniform Windows desktop. (Such as availability of windows software, lack of learning curve relative to company users' home dektops, uniformity in support of a narrow security profile [without getting into how Windows is less secure than OS Whatever, or not])
Yes, I can hear you already "Then *I'll* administer my desktop!" Wrong again. We don't pay you to do that. We pay you to administer Solaris service machines. That's a really strong argument. In fact, it's the strongest argument.
Is there a good reason you cannot administer Solaris from a Windows desktop?
My guess is, given a Windows-based X server, like Exceed or Reflection, and possibly some SSH tools like PuTTY and WinSCP, that there's really not much you can't do.
In fact, it has been eight years since I had a UNIX workstation of my own at work, and I find that it really hasn't hindered me at all. Now, I can't say that it's helped me all that much either. In fact, it's kind of a wash. Just another interface to my job.
It's not clear what you're going to be switching users within. You seem to be hung up on switching a windows user. But, in a kiosk scenario, you are almost certainly switching users within a specific application, which probably ought to have its own notion of user space. User switching in most applications is WAY faster than switching a user logon session at the Windows level. Just as an example, take PeopleSoft, which has its own security structure, but runs as an application (or rather a large set of interconnected applications) on many host operating systems, including Windows. You can switch PeopleSoft users just as quickly as you want because the windows profile has no bearing on the PeopleSoft user.
So, the question is... what is your reasoning for switching users at a Windows level? Further, if you don't have to do that, what authentication mechanisms does the application you are presenting support (i.e. is it extensible at all?)? Finally, does the application itself have a user profile mechnism that is light enough to switch efficiently?
Slashdot Mirror
I am reading lots of the same comment... "Your boss doesn't know what (s)he's talking about," or worse. Perhaps the problem is that, as a tech or engineer, the "I can make that damned cable just as good as Anixter" zealot might not know as much about the overall value of a tech's time as his manager does.
As I have said before, my preference is virtually always to order custom-premade or off-the-shelf premade. This has virtually nothing to do with not knowing how to crimp up a fine cable, or a lack of understanding about the quality of a homebuilt cable, or the time necessary to do it.
Simple fact of the matter is that I pay my people to do other stuff than crimp cable. For every hour one of my staff is crimping cable, they could be doing an hour of something else, presumably requiring the skills that they were hired for.
The straight dollar value of the time spent making cables versus the cost of buying them does not take into account the relative value of cable building versus the value of, say, building out a router or firewall config (which will still be left to do even after the cable-building exercise).
It's true. Telecoms use handmade custom length cable runs created by their technicians. Telecoms use handmade cables because they pay their guys to make cables. And the value of a custom length cable in a carrier-class complex cable plant is high enough to warrant fulltime guys with that skill.
Most small to mid-size enterprises can't afford to have a network guy that is even partially dedicated to cable creation. In fact, most network operations that I have dealt with are understaffed, with no hope of being expanded out to the right headcount, and having to make cables merely puts them in a bigger resource bind than normal.
Sometimes, the manager's truly a putz. Usually, though, that perception is simply that the manager has a slightly different set of priorities than the tech/engineer.
In either case, unless you plan on getting fired or have a real good reason to think you can get your manager fired for being an idiot (which is surprisingly uncommon, something to consider), the fact remains that (s)he is still your manager, and you're going to wind up doing what (s)he wants. So, document your recommendations, in case their refusal turns out to be a critical oversight later on. At least, then, your "I told you so," will have some weight.
First, I agree with Causality on this one. The boss says buy the cables, then buy the cables. But that's not a technical issue, and really, shouldn't be argued here.
As far as the technical bit, I'll tell you what I do:
A) Argue vehemently for custom-made cabling in appropriate custom coloring. This is expensive and takes a good long while. Order extras at any length.
When that fails, or I need shorter turnaround...
B) Order closest-match premade cable. Order extras at any length.
If (and ONLY if) I need a cable RIGHT NOW...
C) I'll make a cable, or have the network guys make one or two.
In every case, the cables are tested before and after a run.
As for reliability, quality, etc... You definitely can make high quality cables manually, even with inexpensive equipment, but it requires a lot of diligence (read: time and care), or a lot of experience to get it reliably right, both of which are expensive.
If you're dealing with twenty network drops, then sure, maybe you have time to make some decent quality cables, and the overall cost impact is not going to be too high.
But, in a medium sized operation, you might be dealing with several hundred server-side connections and hundreds to thousands of desktop/office connections. At this point, the cost to build cables, even at a high rate, is going to outstrip the cost of buying (at worst) closest-fit cabling off the shelf.
There is a valid argument that datacenters and normal office cat5e/cat6 cabling is put together by hand, and homebuilt cabling shouldn't be any worse than that. There are some significant differences, though, between wiring jacks and running drops.
First, in-wall or in-rack wiring moves rarely, if ever, so degradation due to stresses on the hand-punched connections are minimal.
And second, third-party networking and cabling folks that put together office wiring and datacenter wiring en masse, do hundreds, if not thousands, of connections per job, which is to say they have a LOT of experience doing the wiring in a reasonably high-quality fashion.
This all means that, even if you're like me and have been homebrewing cables since STP ethernet made its debut, the guy doing your office punchdown is WAY more experienced than you, and can reasonably justify hand-building thousands of cables.
So, to recap: Boss wants prefab cables, boss gets prefab cables. Is it better or worse to build them? It depends.
mjc
Embedding output... use the backtick, not the doubletick. '`' not '"'
echo There are `ls | wc -l` entries in this directory.
In ksh, you can also use the syntax $(command string)
echo There are $(ls | wc -l) entries in this directory.
Of course, there is also the reverse effect. Things that, as an ancient admin, you still do even though you don't have to... Evolution of the operating environment for easier living, through command enhancements or totally new utilities often goes ignored.
For instance, I find myself typing "df -k" and shifting off the decimal places in my head rather than just using the now-available "df -g". Just out of a long standing habit.
I also almost always either work in 80x25 windows, or 132x50 windows out of habit from the old days, and still get nervous when I resize.
Back in 1994, when I got my first AIX machine for administration, it took me nearly half a year to stop editing configuration files directly. For certain things which I know are safe, I still do direct-edits.
Mark
Regular expressions. People have NO clue how to assemble a regular expression. Or, for that matter that regular expressions are... well, REGULAR.
On that same line, the ancient ex knowledge that precedes vi. I use ex commands in batch to modify large numbers of files in place all the time. This includes line address searching, ranges, and blocks.
sed command separators. If you're modifying a bunch of directory names, it's not necessary to "escape" the slash character to get it into your sed line... you just choose a different separator character, which is, by default, the character after the substitute command: (i.e. what was 's/\/dirA/\/dirB/' becomes 's,/dirA,/dirB,' )
Now THAT's funny :) I love the iUniform. Standard-issue to free-thinkers everywhere.
I'm not even sure that they were supposed to even let me in this coffeeshop with my MS-laden beast. It doesn't even have a glowing logo on the lid. I think I was grandfathered in because I'm so "old".
iFree-spirited... hee.
The simple truth of the matter is this... you work for a company that not only has a say over what job you do, but to a very large extent, how you do it. The reasons for their decisions in these matters are often counterintuitive from your point of view, and may, in fact, be provably wrong. But, in the end, after all the shouting is over, the paycheck only flows one way, which means you will need to suck it up and just do it the way they want, or make a personal change.
And in the grandest tradition of American freedom, you can simply choose to work elsewhere. Plenty of Solaris in the world, you know...
Not really. they're "crossing off" other OS'es because they DO have good reasons.
The answer is this:
You don't administer your workstation, our desktop people do, and they are trained to do Windows because there's a really good business case for having a uniform Windows desktop. (Such as availability of windows software, lack of learning curve relative to company users' home dektops, uniformity in support of a narrow security profile [without getting into how Windows is less secure than OS Whatever, or not])
Yes, I can hear you already "Then *I'll* administer my desktop!" Wrong again. We don't pay you to do that. We pay you to administer Solaris service machines. That's a really strong argument. In fact, it's the strongest argument.
Is there a good reason you cannot administer Solaris from a Windows desktop?
My guess is, given a Windows-based X server, like Exceed or Reflection, and possibly some SSH tools like PuTTY and WinSCP, that there's really not much you can't do.
In fact, it has been eight years since I had a UNIX workstation of my own at work, and I find that it really hasn't hindered me at all. Now, I can't say that it's helped me all that much either. In fact, it's kind of a wash. Just another interface to my job.
It's not clear what you're going to be switching users within. You seem to be hung up on switching a windows user. But, in a kiosk scenario, you are almost certainly switching users within a specific application, which probably ought to have its own notion of user space. User switching in most applications is WAY faster than switching a user logon session at the Windows level. Just as an example, take PeopleSoft, which has its own security structure, but runs as an application (or rather a large set of interconnected applications) on many host operating systems, including Windows. You can switch PeopleSoft users just as quickly as you want because the windows profile has no bearing on the PeopleSoft user.
So, the question is... what is your reasoning for switching users at a Windows level? Further, if you don't have to do that, what authentication mechanisms does the application you are presenting support (i.e. is it extensible at all?)? Finally, does the application itself have a user profile mechnism that is light enough to switch efficiently?