That's not entirely true. The bonding happens for a big part through skin-on-skin contact, which releases hormones. Even though you can still do that if you aren't the natural mother, it's much harder than when you get that endorphin/oxytocin/prolactin boost during pregnancy, birth and breastfeeding. Most modern advice even explicitly encourages the father to hold the baby for a couple of hours, skin-on-skin, some time after birth while the mother is being cleaned up and/or asleep. With a C-section the mother isn't available to hold the baby at all during the first hours; the advice then is to get the father half naked and get him to hold the baby during that time.

Of course I agree with you that fathers and adopting parents do bond with their children through anticipation, preparation and shared experiences, but this is definitely not the main process that normally takes place and I don't think it should be the only one if it can be avoided.

I'd like to chip in with my view as a fairly recent daddy too, as we probably don't live too far apart (your username puts you in Flanders or southern Netherlands, but giving birth in hospital is very uncommon in NL nowadays, so my guess is Belgium.)

Judging from many stories (that everyone suddenly has when you are expecting a baby), Flemish hospitals, even the good ones, are not to be considered the gold standard for giving birth. In most places the doctor and hospital staff decide what's going to happen, preferring to force their way for convenience (theirs) or just because Procedures Must Be Followed rather than actual care for what's happening. We did extensive research, even before conception, on where we wanted our baby to be born and quickly chose a hospital well over an hour away because they are the maternity specialists of the province (every province has one) -- there are hospitals closer by, but just looking at their maternity ward websites was enough to reject them outright (the gynecologist decides this, this is the schedule of the maternity ward, we decide that...)

Eventually we didn't even make it there because everything just happened too fast, our baby was born at home with the help of independent midwives (don't go without professional help, there are still some risks), and I was surprised at how easy it went (of course, it's still a bit messy, it's still painful, there's still some screaming, but afterwards our midwives also told us that home birthings are always much easier, cleaner and less painful than in a hospital. ) No epidural, no inducing, no vacuum extraction, no episiotomy (because no tearing); I'm not saying that these techniques should never be used, but they are definitely overused in Flemish hospitals, sometimes to the point of normal operating procedure for _all_ births. I'm also not advocating home birthing for everyone: some parts are easier, but especially the fact that you are immediately thrown back onto yourselves after birth was very hard for us (we had household help and of course the midwives come to check up regularly for a couple of weeks, but they also have to tend to other expectant mothers, mothers and babies in a fairly large region, so you don't have someone at your bedside five minutes after you push a button, it's just the two of you.. if there are two of you, which isn't as standard as it used to be.) I just wanted to make clear that Flemish hospitals are not really the desirable solution when it comes to giving birth.

As for the original issue: I indeed see serious issues with artificial wombs. When a baby is growing, is causes a lot of violent hormonal changes within its mother. Of course this causes a lot of issues and inconveniences, but it also creates a very strong hormonal bond between mother and child. It's not just something you ordered on a website somewhere with the prime advantage of being able to watch the production process. A baby actually grows inside of you, you feel it as it starts moving around, it takes much effort to 'produce' a baby long before you see the results, which is getting less and less acceptable in modern societies. This experience of long-term effort is important for the future of the baby, because it's something that won't stop for quite some years.

Another issue my wife just pointed out to me: the number of kids from an artificial womb diagnosed with autism will probably also be much higher than average. A baby doesn't start living the moment it's born, it's already experiencing and learning a lot from the outside world long before (street noises, music, arguments, stepping around, lying still, ...) It will not have those experiences in an artificial womb, so it will be less prepared for what will happen when it's born.

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.