This is true, and I think the main point is that such a parallel bus is made possible with the new serial technology. You will still need to sync up each bus, but it can be done at a higher granular level than individual bits as it was done in traditional parallel buses. For example, you can transmit packets of data through the serial bus, containing information to help the receiving end piece together the larger block of data. This isn't possible with single wires since a single bit can't hold this type of information ;)

I somewhat disagree with this. Maybe these days, finding more information about your interest is easier because of the internet. But back when I was growing up, I really liked programming, but did not find any friends sharing the same interest nor older folks that could give me direction. School made those things accessible to me.

There is a reason that the industry have been trending towards serial and away from parallel buses.

It's been a while since I've done an transmission line and bus design work. Let me see if I can explain this in 'lay' terms:

To implement a parallel bus, you have to have each and every wire be within a certain variance. Your driving and receiving chips also need to be able to send and receive the data within a certain variance. This is because you typically send your data, say a 32-bit word over a 32 wire bus, across the bus at the same time. If the wires (and drivers and receivers) do not match up, your data will be scrambled on the other end of the bus.

The larger your chips (because you need all the drivers and receivers to send the parallel signals) or the more wires you have, the variance between the parts becomes harder and harder to control because of manufacturing limits. The trick is to design your entire system to tolerate the variances of each individual parts so that they will still work together.

But at the same time, you want to increase the speed of the bus (because having 20,000 wires is just not so practical). This is a force in conflict with what you're trying to achieve because an increase in speed translates to less tolerance in the system for parts variance.

At some point between increasing parallelness and higher and higher speed, the increase in variance will exceed the system's tolerance, and the parallel bus becomes impossible to implement or unreliable.

This is why bus designers have been trending towards serial interfaces, because that at least takes most of these variances out of the equation (it's still there but less influential).

The other trend is clock encoding. Instead of sending bits synchronously, or sending a strobe (a separate clock) signal along with the data. Now we 'encode' the clock into the data, using encoding such as the 8B/10B encoding. The receiving circuit can then 'retrieve' the clock from the data signal (it basically allow you to identify each set of data from each clock cycle, and detect problems). Serial interfaces are also usually accompanied by training sequences at start up (may be software implemented) to adjust various parameters to make the data transmission ideal for the environment.

In other words, there's value in the ability to produce energy at a constant rate, rather than in bursts. Because when it's produced in bursts, you will have to find a way to store it, which means a loss in efficiency.

I work on HP's high end servers that also contains millions lines of firmware.

I've heard of accounts where customers simply refuse to take new firmware because of their prior experience of "bricking" the boxes, and causing days of outage waiting for new blades to be shipped to them. But those usually turn out to be cases of real bad HW defects that the newer firmware has found. But they still insist on running years old firmware that contains tons of nasty bugs.

We all know that software has bugs, and we fix hundreds of them every month. This is not as mission critical as firmware in a car, but it's the same thing. Take the update dammit!

It floats... they all float down here...

Seriously... if there is a lack of documentation, then you just have to start reading the source code, starting at main(). Then look at each object and read its constructors.

And start documenting it. Add comments in the code, create inheritance diagrams and sequence diagrams.

It will be tedious but you will come out of it a better programmer.

The purpose of the Ninja is to flip out and chop off your head... and to throw shurikens at people.

Thanks for making strawberry perl, Adam!

Solved... put photovoltaic cells under the green house. More efficient in land use than either one alone.