30 years a sysadmin
itworld.com
itworld.com
You consider this a downside? Customer-facing IT Support is an absolutely nightmare. It's part of my job, and by far my least favorite part of the job, as the customer is more often an impediment to solving their problem than an asset.
At any rate, I much prefer dealing with users to dealing with printers. Printers are evil. I remember the time one of our engineers wanted to print a PDF file, and the result looked superficially the way it was supposed to, except every single letter was incremented by one (so "ABC" became "BCD")... Or the time two printers were configured with the same IP address - due to ARP caching lifetime, every couple of seconds, clients would switch which printer they would send pages to, so print jobs ended up literally being all over the place. ;-)
There's a saying about dogs, that one should not be scared of the dogs, but - if at all - of the owners. I guess that kind of applies to printers, too. ;-)
Because of gravity, toner eventually falls onto the laser lens, and causes low-quality prints.
Thus, it has a manually runnable "self-clean" procedure, in which an internal squeegee runs over the lens, cleaning it. For a bit.
If they had made the laser downwards-shooting, it would have avoided this problem altogether. The printer company's service technician, who showed us the self-clean, tells me that this would make the packaging larger, however.
The printer is a gargantuan office printer. (Kyocera TaskALFA 5550ci)
I don't think packaging size for merely the laser should have been a concern...
tl;dr printer hardware can definitely suck
But like I said, hardware-wise, they haven't given me much trouble (except for a power supply with very slight fault, causing it to make kind of chirping noise every once in a while - it drove our accountants crazy - our field service guy tried replacing the hard drive, the heater, and some other thing (I forget which one), before finding the faulty part). Also, trying to print on paper that is just ever so slightly wet can be... interesting, if one happens to need to print out some one hundred pages. sigh
A couple of years back, when I was still working as a programmer, I was once given the task to write code controlling a specialized printer, the kind used in factories for printing bar codes on things. The printer used a continuous stream of ink that normally went into a tube feeding it back to the ink tank. The ink contained tiny iron particles and went through a magnet that could direct it to the position it should land.
When powering off the printer, the software controlling it had to make sure to first send the command to move the ink-catching tube right up to the nozzle before shutting down the pump, or else the printer would ... kind of soil itself. ;-)
Of course, the first time I tried to actually print something with that printer, I forgot to shut down the printer properly, and it soiled itself in a big way. Specifically, the stream of ink went through a teeny-tiny hole in a small diamond platelet; when I shut down the printer impromperly, ink stuck to that platelet and dried up, so that tiny little hole was no longer perfectly circular. As a result, whenever I tried to print something, the machine would soil itself some more.
After talking to the manufacturer's customer support repeatedly (in their defence, they were friendly, helpful and competent), a support technician told me to remove the platelet from the printer and put it in a bath of MEK (industrial-strength solvent) over the weekend to dissolve the dried remnants of ink (after I had cleaned that platelet manually several times).
The solvent was fairly volatile and highly flammable, so I put it in a small jar, dropped the platelet in the jar and screwed the top on as tightly as I could.
When I came back on Monday, the platelet was indeed clean and gave me no trouble whatsoever after that. The plastic coating covering the inside of the jar's top, however, had "molten" almost completely.
I seem to recall that the original story about how Richard Stallman was inspired to create the concept of free software was that he was stymied by proprietary software in a printer, so this would simply bring the concept back to its roots, so to speak.
Certainly it' s a double-edged sword but that's how I read it at least.
No, the reason why that comment is strange is that if I’m a sysadmin, the users who use the systems that I keep running are my customers just as much as customers of the company. Why would you not count them as customers?
Maybe the article author liked having contact with people outside the company, as a sort of social interaction substitute? If that’s the case, I can only say that if I needed social contact that badly, all I needed to do was to go outside after work, where I could socialize on my own terms with people I could choose for myself. But I can only speculate about what the author actually meant by that comment.
20 years ago, in 1995, a tech startup would usually have the programmers do the systems administration, until about four programmers or so had been hired - by then the code would be in shape to put on the Java application server, traffic was picking up, and they needed someone to deal with it full-time, who knew what they were doing. The servers would often be on-site, on the company's T-1 line, or sometimes would be at a colocation facility.
Nowadays, how many people are hired at a tech startup before they hire someone to deal with installing Red Hat on HP rack servers? It can be a while - nowadays if you need 500 servers quickly, and have the money, you can spin them up (and down) on EC2 in a few minutes. Plus there's Linode, Rackspace, Ramnode - I have a personal VPS on each of them. Why not? It's only $10-$20 a month each. It's hard to justify the cost of hiring a sysadmin, a backup person to the sysadmin, pay for colo space, leasing a server etc., when you can get a pretty nice Linode VPS for $10 a month.
Once you have hundreds or thousands of instances, especially ones with reasonable amounts of resources, the sticker shock starts to make owning and hosting your own servers look pretty tantalizing.
I spent four years with an IT consultancy piecing together 40 hours working for clients who didn't need a full time IT department. Not having enough hours to transform their operations, running around the city putting out fires, and dealing with old hardware was a bit miserable. Looking around the job market showed a lot more of the same, along with a few high-stress and non-specialized positions working for financial or legal companies. Maybe that's just the scene in New York, I don't know, but the dream of being a company neckbeard did not pan out.
Reading slashdot in the 90s made IT sound amazing, but I've found that geek dream much easier to fulfill in the software industry.
(7 track was the standard for 36 bit PDP-10s, 6 bits of data and one of parity, and some earlier IBM machines as well.)
The above describes a typical transport system; however, manufacturers engineered many alternative designs. For example, some designs used a horizontal transport deck where the operator simply set the tape reel in the supply reel bay, closed the door and pressed the load button, then a vacuum system would draw the tape along the path and onto a take-up hub within the mechanism.
Back in the day, I used a 9-track tape drive like this. It was quite the thing to watch it mount the tape. A while ago I found a video of it[0].
config management has been around for a long time...
The job of sysadmin is to recognize how systems have been designed, based on which first principles and what are the alternatives. This is how one ends up with Postgres instead MySQL (or Informix instead of Oracle) with Scala instead of Ruby (because you do understand principles Scala is based upon), with Erlang instead of Java (you do understand the differences and principles),etc. Basically, sysadmin is a system (or service) designer and architect.
Nowadays the term sysadmin is used to describe a job of issuing memorized commands to AWS or some "containers" without any deep understanding of what dynamic linking is, what is libraries and API visioning, how to compile from sources and run several versions of some sets of libs, how to recompile a source package disabling unnecessary features, and so on. This is the same nonsense as to call an auto-mechanic an engineer. Most of moderns sysadmins does not know what the ./configure; make; make install sequence or a syntax of Makefiles or how the mess they called cmake works. (how many here knows how to write RPM's spec?))
Old school sysadmins are engineers, not mechanics. They do understand access patterns, data-structures, memory allocation techniques, what are shortcomings of posix threads and its naive usage, and, of course, programming paradigms, so they could reason (more objectively than managers or other laymen) about behavior of a system.
They think that running a Hadoop on AWS (from ready images) is a big deal.
btw, in my 20 years of being sysadmin (since SCO Open Server and FreeBSD 2.0) everything worked.
btw, in my 23 years of being a help desk tech, sysadmin, architect, consultant, manager, and finally owner of my own business, nothing has ever just worked.