Don't skimp. Get a good one, name brand (Tek, Agilent, LeCroy, etc.) at least 100 MHz bandwidth (the higher the better), 4 channels if you can afford it, some way to get data off the scope and onto a USB drive/network. Everything else is fluff and you can pay for it if you want, but I'd say the above are non-negotiable.

Don't even think about a PC-based scope. A scope is a standalone instrument, always has been, always will be.

I'm not young but I tried to get into kernel driver development (out of necessity, not so much itch-scratching) and was thoroughly frustrated by:

1) Lack of useful documentation
2) Constant churn in the kernel

I wanted to allocate memory in a driver. Lots of memory (64MB on an embedded system). I read all of LDD (latest revision) and tried everything: memory mapping, kalloc, vmalloc, ioremap, etc. etc. Nothing worked, and the book was so i386-centric that on my ARM system the explanations didn't really make sense. Eventually (we're talking several DAYS) I made something work using mmap.

And don't get me started on interrupts. Where do they even start? Where's the interrupt handler? WTF is the difference between a hard interrupt, a soft interrupt, and a virtual interrupt? I spent DAYS trying to figure out the exact sequence of code that represents travel from the hardware event to the final driver code (because it was necessary in this case) and had to give up. Interrupts are just magic.

And yes, I can read source (and I did).

As for churn, it seems like every week there's a new scheduler, a new memory allocation strategy, a new filesystem, etc. etc. QUIT IT! Is it really improving things that much? Every major system that gets replaced in the kernel obsoletes a bunch of code that now has to be rewritten to keep up. Worse, it makes whatever documentation there is (e.g., LDD) out of date. It was no fun reading parts of LDD only to look at the actual 2.6.24 source and see that parts of the book were already out-of-date (I can't remember what now).

If the kernel devs are only interested in itch-scratching then their numbers will continue to dwindle and Linux will fade in favor of a system where people actually do hard work: proper documentation.

From a device manufacturer's point of view, RS232 is free to implement. No special drivers are required on the host.

Now, for USB, you have to either pony up $2000 PER YEAR to the USB implementers forum to get your own VID/PID and distribute a driver to your customers (and deal with the resulting customer service issues) or add a chip from FTDI (or similar) and piggyback on their VID/PID but then ask your customers to download and install a generic driver that does not specifically identify your hardware.

Gimme RS232 any day.

Just looked at KiCad...it doesn't have an autorouter.

Sorry, it's not even in the same class as Eagle then.

I will have to look at KiCad again (wasn't impressed last time) but I disagree with the Eagle analysis. The freeware license allows for 2-layer 4"x3.2" boards which is definitely enough for a lot of projects.

Even the completely full version for commercial use with no layer or size limitations is $1500 for schematic+PCB+autorouter. That's not the cheapest license, that's the most expensive one!

My university has the completely unlimited professional version site license -- it is NOT limited in board space or layers. And it was at a fair one-time no-yearly-fees no-dongles no-license-server price.

And I forgot to mention that Eagle doesn't screw you over with upgrade costs. When upgrading from version 4 to version 5 (which did include some major new features), the upgrade cost was very reasonable.

TOPSPICE is $500!!! And only for Windows.

No thanks.

It's quite likely you've been doing something wrong :-) I was at the same place, getting frustrated because perfectly reasonable circuits refuse to simulate. 99.9% of the time it was my fault, and it was a great learning opportunity. "Reasonable circuits" are not necessarily practical circuits. For example, you can put in an ideal switch into SPICE and cause brittleness, because practical circuit voltages and currents don't change instantaneously like ideal switches do. "But wait!", you say, "Inductor voltages can change instantaneously! That's what it says in my textbook!". No, they can't :-) There's a reason SPICE lets you specify an inductor's parasitic parallel capacitance.

Also, another source of brittleness/bugginess is poor third-party circuit models. I've downloaded some MOSFET models that just plain stunk.

BTW, LTSpice is my favorite simulator, hands down.

It's the changing college demographic. First, more non-traditional students that want to be able to work at home, at "work", on their own time, etc.

Second, more demanding traditional students that expect colleges to come with more amenities like better dorm rooms than what used to be the norm, private bathrooms, etc. The ability to work in the dorm room or "plug in" wirelessly anywhere on campus and do their homework is becoming an expectation.

We have computer-aided teaching studios now with no computers in them. Doesn't make sense when every student has a laptop. Soon we will not need any computer labs.

LTSpice for simulation, Eagle for schematic/PCB design.

In my experience, any tool that does both simulation and schematics is a) crap, or b) really expensive.

LTSpice is free, well supported and actively developed, high quality, and works well under Wine.

Eagle has native versions for Mac/Linux/Windows, has a great educational site license program (reasonable price, no yearly fees, no license server), does schematics+PCB+autorouting, is well supported with its own newsgroups (which are regularly attended by Eagle representatives), is scriptable, and in general is Not Evil.

I'm a big fan of FOSS but I hate to admit that best-effort programs like gEDA and KiCad just don't match up to Eagle.

If you want to see even more Win madness, take a look at these instructions (in three phases) for dealing with the DST problem on a Novell GroupWise e-mail system.

What a nightmare! And that's just for one (closed source, painful to use) application.

Now if my university were running an open-source mail server with proven software (*cough* Slackware *cough*) the upgrade would have gone something like this:

wget 'ftp://ftp.slackware.com/pub/slackware/slackware-1 0.2/patches/packages/glibc-zoneinfo-2.3.5-noarch-7 _slack10.2.tgz' upgradepkg glibc-zoneinfo-2.3.5-noarch-7_slack10.2.tgz