You underestimate the power of support contracts. No sane OEM is going to ship an EOL'd Windows XP any time soon, and unless your workplace never cycles hardware, windows 7 should have started appearing a long while ago on your network anyways and some sort of migration strategy should be underway in the worst case scenario.
I heard the same thing about Windows NT4 _and_ Windows 2000. It's like end-of-life never happens for some people. Sure, you can probably find some business with http://tech.slashdot.org/story/13/08/25/1432209/windows-81-rtm-trickling-out-with-start-menu-and-boot-to-desktop?utm_source=slashdot&utm_medium=facebook#Windows 2000 running somewhere on a production system. That doesn't make it any less shitty.
Some of this should normally be offloaded to people like me, in operations, who design and maintain web facing infrastructure. App servers, web servers, system automation, redundancy, failover etc.
What I fear is DevOps and other thinly veiled attempt to save money in the name of being 'agile', where you guys are expected to just go and cover the last mile by deploying and maintaining the application servers, which is actually an entire discipline in itself. I spent most of my career getting good at this, and I do have some web development knowledge and experience as a result, just like a web developer will have some system administration knowledge and experience. I wouldn't in a hundred years consider myself the best choice to do their jobs, and I'm fairly certain the reverse is just as true. But hey, it's all "this web stuff", right?
As a sysadmin/network architect (the latter is apparently my official title), I feel somewhat offended. Good unix sysadmins will know at least enough of a system language and about computer architecture in general to understand the systems they are maintaining, on top other languages for automation.
I have sort of been dragged into the land of J2EE Application Servers, kicking and screaming. Turns out that in order to understand J2EE App Servers, you have to understand the entire gargantuan, chtulu-esque stack, and to do that, you have to understand Java to a surprisingly deep level. And in order to do this, you have to understand at least a decent subset of software engineering.
Turns out I that five years later, I fully grok things like the visitor pattern, to much of my astonishment. You would have told me 10 years ago that I would come to understand the difference between pass by reference and pass by value, I would not have believed you.
I have also contributed a fair bit of code to the application I am struggling to run decently on a production glassfish cluster, during the process of tracking down performance problems and other random issues that were being blamed on the app server. Not to mention XSS and SQL Injection vulnerabilities I unearthed and fixed.
Of course this experience may not reflect the "real world" accurately, seeing how I also ended up being the gatekeeper who packages and deploys builds. This stemmed from managing the VCS server, the CI and collab servers, etc. This eventually resulted in me pretty much shaping up the entire development process to the best of my abilities. I picked up a lot of skills I may not have had otherwise.
Now you may feel "this guy is just playing programmer, everything must be shoddy as shit", but rest assured, on a personal note, the last thing I ever wish to do is do something badly. If I don't feel 100% comfortable doing something, I usually abstain from doing it altogether.
In relation to the original topic, I often find myself knowing much about something, and being incredibly disgruntled at the fact that I possess that knowledge. On the flip side, it just makes my resume rather impressive rather than unfitting. It's all a matter of how you present it, i.e. "I am a sysadmin/networking guy that also happens to be well versed with this stuff"
The other issue you're not addressing is that most companies don't seem to understand the difference between a CS major in software engineering and a tech. To them they can ask for 3 years of experience in software engineering with skills ranging from C++ to databases, and also ask you to maintain the website, do tech support, work the servers and help with active directory.
The blur is not from the side of the fine people pursuing these jobs, it's from the management.
If all you want is a decently modern bash and unix userland on windows, you might want to investigate mingw/msys. It still uses a translation system underneath but msys is lighter than cygwin and the toolchain produces are 100% native and link against MSVCRT.
You would enjoy tremendously better performance. At least I know I did. On cygwin bash takes approximately 6 whole seconds to parse my
I still think you're not fully getting the point I was making. The behavior of cat doesn't change in theory. The behavior of the terminal when confronted with a bunch of garbage matching the mimetype of a png is what changes. It present it in a useful form. It is exactly like ansi escape codes for color output, no more no less. I still have no idea why you'd want to see the garbage in the first place, because it is just that, garbage. It's not even the bytes in the file, it's the bytes mistakenly interpreted by your terminal, which results in bleeps and borps, and other terrible fuckups until you reset it. If you pipe or redirect the output stream to something else, you're still working with data, because the view isn't involved.
It's simply a different view on the same data. This is what I meant by separation of view from data, which *is* in general, a good idea. Again, I am not saying I would love to see this in my shell. I'm just saying it isn't necessarily broken.
In short, it basically makes your terminal, the view layer, handle the garbage graciously and display the png. It doesn't mean that cat can now render pngs. If that was the case, it would indeed be broken because I don't expect cat to do this. I expect cat to con(cat)etnate files and toss the output to stdout.
It is a subtle difference, but it is quite significant, and indeed the difference between broken and just arguably useful.