In Slackware, you learn how to do things on any Linux distro. In Ubuntu, you only learn how to do things in Ubuntu, Debian, and Debian derivatives. I owe to Slackware the fact that I can sit down and work with any Linux distro out there. It doesn't include its own special tools for anything, so you are forced to do everything the "standard Linux way," which is the way that works on every distro (with some special exceptions, like DSL).

I would teach them basic bash scripting, and about /proc and /sys. Then I would have them write scripts to automate extracting information from /proc and /sys in bash using grep, sed and maybe awk. Teaching them how to work with Linux from the shell and how to pull information out of the kernel like this should give them some good insights into the operating system and its tools. Additionally, I would teach them how to write init scripts and how to do "fun" things to get them excited about Linux.

I had the same dilemma, except I also knew I would eventually add 3D graphics as well. I wanted it to be portable to anything, and I needed it to render accurately and with proper anti-aliasing (anti-aliased while drawing, not via a filter after the fact). After mulling over all the options, I came to a difficult conclusion: write it myself. This is more work than I'd like, but it allows me to ensure it will run on anything, anywhere. If something new comes out that I want it to run on, I just port to it; I don't have to beg a vendor for it to be ported for me. Performance isn't paramount to my application, so I can put enough abstraction layers in to make the porting process relatively easy. All frameworks seem to put performance as the highest priority, which gets rid of the ease of portability. If your application will render graphics that sit still most of the time, this may be your best option (assuming you know linear algebra if you want vector graphics, and know graphics programming regardless).

This option worked for me.

You'll find getting back into the field, to program in high level languages with all of your previous experience outdated, to be very difficult. Companies will not want to pay you the salary your years of experience would warrant, and it would be like starting over.

Instead, the method back in that I've found for those of us who started in the "old days" is to go for embedded systems development. The embedded world uses 10+ year old technologies, so your experience with assembly language programming and writing software for systems with limited amounts of RAM and storage space is a big plus for embedded systems development. There are plenty of companies still creating software for processors that run at between 4 and 20 MHz with anywhere from 256 bytes of RAM on up to a handful of kilobytes of RAM. I've found this sort of development work is much more interesting, anyway, and people with old school knowledge are considered more valuable, rather than a dinosaur, for such work.

For such an expensive rocket launch, you'd think they'd at least have a professional photographer with professional lenses. Those pictures are terrible. Look at the flames; there's no detail. They obviously used cheap lenses. I'm an amateur photographer, but I have professional equipment because I'm too picky to have my pictures look as bad as their launch pictures do. I'm glad the launch succeeded, but you'd think they'd want better pictures for examining the launch and for PR.

He apparently wants us to take a step backwards to the days when crashes were frequent, such as with Windows 98. Software quality has a long way to go already. Does he not realize that making programmers deal with such an issue would bring software quality back into the Dark Ages?

As it is, programmers aren't given enough time to write software that works bug-free. Schedules are always rushed. This would dramatically increase: the burden on developers, the quantity of bugs, the number of developers being fired because they didn't get a project accomplished nearly as quickly as someone who pulled off a similar project 5 years earlier, the frustration of the users and developers (and transitively, the number of heart attacks around the world due to elevated blood pressure), the number of security vulnerabilities in software, and the migration rate to processor vendors who didn't make this mistake.

In short: this guy is on crack!

You're crazy!

The solution to this is simple:

1. Make sure you have an Enterprise licensed AV installed. The per-client cost is low, and the updates will be centrally managed by the server. If your network is too small for this to be cost effective, then just have Norton AV (or your favorite respected AV) on every machine in the network.

2. Don't give your employees local admin privs. This one change has, in my experience, made all the difference in the world for many small businesses.

This is much cheaper than paying the labor for having an IT person come in and clean up all the messes.

It's call Norton Ghost.