Yup, that's a good list... some more things:

  - I assume GP meant a test plan instead of a test script: a test script is closer to automating (push button x, check value y, ...); a test plan describes what you are going to test, what you have tested and what the results were, usually starting as a very rough overview of the feature, how it works, which area should be tested in which way, which sources you used to determine what counts as 'correct behavior'... As you work on the feature, you start refining the test plan, adding tests for issues you didn't think about before, areas that turned out to be involved which you initially didn't see, dropping tests that turned out to be unnecessary, ...
  - Investigating (buying of/errors with) test tools (in my field you need some pretty high-end devices to be able to simulate large customer environments and a lot of these devices tend to be limited or broken in very unexpected ways.)
  - Testing whether the product will hold under repetitive use (endurance)
  - Testing whether the product will hold under high stress (scaling/performance)
  - Testing whether the product works well within the environment for which it is intended (lots of software needs to interact with other hardware or software, but you usually don't have control over those other products)
  - Testing whether the product is internally consistent and if your feature works well with other features in the same product (on a large project, this aspect of testing tends to explode as the number of features increases. That is when you'll need your testing and product experience to quickly filter out the risky combinations.) If the product is intended to be upgradeable: testing whether for instance data files stay usable between versions.
  - For highly available products: check that all aspects of your feature keep working if it has to switch to the backup system
  - Testing whether the product is secure
  - Discussing (I wouldn't call it arguing) with developers and product management whether issues you found are actually bugs and if the feature as designed (or sometimes even as requested!) will even solve the customer's problem. (You can make a perfectly functioning screwdriver in request for a 'device for mounting fastening materials), but if the customer was looking for something to drive in a nail, chances are it won't sell to that customer.)
  - Regularly checking the results of you automated tests and seeing if a failure is due to an intended software change or if it's a regression bug.
  - Senior testers where I work are also regularly involved in feature design together with product management and development.
  - Pushing the product to its limits (memory exhaustion handling, starvation from lack of other resources, timing issues, ...) and checking that resources are properly freed (nowadays the runtime environment usually takes care of this, but not always; some products still need very low-level coding where you cannot spare the cycles to do those tests at runtime.)
  - Working with high-level support to determine the cause of issues coming in from the field. If you have a good support group, whatever comes to the highest level there is something that needs test and development expertise to get solved. (Our highest level of support actually mostly consists of former test engineers.)

In response to the black/grey/white box testing (I actually prefer 'transparent' instead of white; a white box is still opaque): you'll usually work somewhere in between, starting from black box and going deeper if you get a bad feeling about the code you are testing (or if you need to give the developer a very detailed report about what's going wrong.) Full transparent-box testing is more akin to unit testing, which is the developer's responsibility (at least where I work).

If you are at odds with developers over the issues you find, something is wrong, at least when it goes beyond some friendly rivalry between test and development. Test and development are not enemies, they are both working together towards the same goal: a good product that the customer likes to use. In any non-trivial project, the developers *will* make mistakes, that's unavoidable. The testers will also make mistakes and flag issues that aren't really bugs... we are working on the same floor as development and when we find an issue that we can't immediately determine the cause of, we try to find as much information as possible and then ask the developers for help. We (the testers) know what we see, but the developers know exactly how the code works and what causes what we see.

More importantly: writing the test script yourself and not letting other (mostly non-testers) do it for you. If you have nothing to say about what will be tested and how, you won't be able to test thoroughly. If they won't let you write your own test script, you won't be a tester, you'll be a real QA Scapeg-erm-Engineer: you'll just be there to assure that there is 'quality' (What _is_ quality, actually?) and have your ass on the line if it turns out there isn't because your job description says _you_ assure everyone there is. You cannot guarantee perfection as a tester -- you don't have full freedom to change shipping schedules and you're not allowed to change the code -- so you cannot assure quality. You can at most provide valuable advice about the state of the product to the people that can make those decisions: that's the difference between a QA Engineer and a Tester.

Effectively you are also testing your own test script... Where is it incomplete? Did you miss requirements (it's not just your product requirements documentation that provides the requirements, you also have standards, user expectations, laws and many other sources that are typically not referenced in product requirements but are vital to making a good product.)

If you even need to test something more than once, do it the lazy sysadmin way: automate it. If you are expected to test multiple releases of the same program: prepare to spend at least 50% of your time automating (I usually start from automation, which has the added advantage that over time you build a library to quickly set up large parts of test scenarios, even for manual testing if you interrupt your automation scripts in the right spot.)

For much more information and better explanations, my advice would be to check the blog of Michael Bolton (http://www.developsense.com/blog/), who links to other great software testing minds that use the same ideas like Cem Kaner, James Bach etc... (I usually read Michaels blog though, mostly because I like his writing style.) They definitely brought more fun and insights into my testing work.

At least for Antwerp, yes. (Although the premetro is not technically a subway, it's a tramway that's been put underground in the city center; it has overhead power instead of a 3rd rail.) The power sections run from station to station (the connection diagrams are on the emergency separator switches in the stations so you know if it switches the section before or after the current station.)

The things you pay attention to as a geek.

I think the easiest explanation for this would be that that would be a manual intervention in an automated process, which is expensive, so they won't do that. (The Dutch would rather throw a couple of millions at improving efficiency rather than accept a couple hundred thousands of losses because things aren't quite as great as they could be. Apart from that it commonly also happens at big companies, it's also a cultural thing. I've lived there for over a quarter of a century; fortunately I was able to get away from it a bit ;-p )

Skip that piece, I mistyped and forgot to correct. (The insurance is there to rebuild the house as I said after that, not to pay off your loan. I got confused with the life insurance, which does have that function.)

Having bought a house last year, I can say that (at least over here) the insurance for the house is primarily for the bank providing your mortgage loan and not for you. The insured value of your house is there to pay back your loan if you can't do that anymore (and chances are you can't if it burns down because you have to pay for rebuilding it), so the bank demands that it's insured it so that it can be rebuilt if it's damaged beyond repair, protecting their investment. Actually the insurance or loan contracts probably prohibit you from doing anything other than rebuilding your house with the insurance money.

The same goes for the life insurance you are required to have when you take a mortgage loan. (Technically, it's not a mortgage. It's a loan backed by a mortgage -> you get the money in exchange for giving the bank information and/or decision rights (the mortgage) when you use or sell the property. The bank doesn't own your house, but you do give them the right to sell it if you can't pay off the loan; they aren't fond of doing that though, because having to sell it is a huge cost and possibly risk to them too.)

I'm pretty sure I first found CnD when looking for Enlightenment themes (0.9? 0.11?). I think I even used one of his themes for a while, even though I can't find it on his site anymore; even the wayback machine doesn't go back that far. It was a light brushed metal desktop with a cutout at the top revealing a darker brushed metal background.

Some time later I found it again when it had become /. and that's when I started reading regularly. I also still remember the coverage about the F00F bug (a pair of contradicting instructions that cause some old Pentiums to deadlock in hardware), with FreeBSD having it patched in software within a couple of hours and Linux following in a day or so. Has Windows ever been patched?

*waves*

I don't know how many posts and comments eventually led to invaluable information that I still use daily (underneath the mountain of completely useless but often entertaining stuff that covered it.) Most of the knowledge I use at work didn't come from my university degree but their network did give me access to it all and /. is still a part of finding that random stuff.

The low UIDs were all gone pretty fast, I was just lucky that I noticed the post about the UID system just after it got posted. Sometimes it's an advantage to be in a completely different timezone.

So long and have fun!

Ow... I still try not to use TCWWW :)

Unfortunately not. PPPoE runs the PPP protocol over Ethernet, not over an IPv4 connection (which in turn usually runs over Ethernet)
This will probably be more useful for creating tunnels between different IPv4-connected hosts, such as for VPNs.