Zero day refers to how much time an administrator has to patch his systems before an exploit is known. Since this is still not patched, it is indeed a zero day exploit, although if the exploit is as yet unused it is not a zero day attack.

I completely agree about needing a basic understanding of reading and writing math first. I haven't seen the inside of a math classroom in many years, and my work doesn't involve a lot of "heavy" math, but I use basic algebra at work fairly regularly. Recently, an acquaintance of mine in a college algebra class commented that she understood most of the class really well except for the "word problems." I hadn't heard that phrase in so long that I had forgotten it existed. All the math I do is "word problems" and it is utterly useless to me otherwise. It astounded me that someone could consider themselves good at math when they didn't even have the basic skill of being able to transcribe back and forth between math and english.

Probably because they never took that class. I can imagine management saying, "This one doesn't have a light, so we don't need electrical engineering to approve the design, only mechanical." That sort of thing happens at my work more often than I would expect, going both ways.

SS is still taking in more than it is sending out.

Um, no.

At her insistence, a blue e opened my wife's web browser for a year or so after we switched to Linux. That was pre-firefox, I think it was just plain mozilla suite web browser.

Last week, she bought some sort of device to make Skype calls from our regular phone and manually installed the device driver and userspace daemon, all without my input at all. I couldn't be more proud :-)

Is that for results that all start with the same sound?

Unless you're foregoing those items altogether, you're probably not saving any money. Testers have significantly lower salaries than programmers. When a programmer does all the testing, you are paying programmer rates for testing work.

You're both missing the point here. Knowing the current commute time is fairly easy. The tricky part is using the measurements now to predict the commute times an hour from now. My commute ranges from 20 up to 50 minutes or so. If I can look on a website and see in a half hour my commute will be a half hour shorter, I'll just wait. If it's still going to be long, I'd rather slog it out now and get it over with.

I hate to break it to you, but even if your trunk is clean, you will still have this problem in some other branch. Let's examine a very common situation where you have an interface being changed, one or more implementations of that interface, and one or more users of that interface. Developers are working simultaneously on both sides of that interface in order to meet a deadline.

Because of your clean trunk rule, none of the changes can be checked into the trunk until all of the changes are ready, but they still need to be shared among the people working on it, or they will have no idea if it is "good and ready." So those developers create their own branch, which of necessity is sometimes in a temporarily broken state. You might not think of it as a branch, if it's John's working directory and the "checkout" procedure is him emailing files around, but it's conceptually a branch nonetheless.

Linus is simply acknowledging that temporary brokenness is inevitable when multiple people integrate changes to the same code, and therefore whatever branch contains that messy integration should use tags to communicate the best branch points. I'm not saying keeping a clean trunk isn't a good idea, just that you have to deal with broken branch points one way or another, even if it's just John deciding when the best time is to email out the new header files to his team.

I know, we could just set the punishment for distracted driving really high. Let's say the death penalty by means of fiery crash.

from the system's point of view it's the same as if someone climbed up on their roof

True, but irrelevant. Climbing on the roof is still better for the individual at the expense of the system. Just because behavior is accepted and accounted for doesn't make it optimal.

I make a living writing embedded software for telecommunications equipment and am also a ham radio operator, so I have a hard time seeing why this isn't blindingly obvious to everyone, but if you want more wireless bandwidth and less congestion, each individual's signal must have the lowest power necessary for reliable communication.

For example, say you have 100 cell phones in active use at any given time in your neighborhood. If every cell phone signal in that neighborhood is boosted to be able to cover the entire neighborhood, each subscriber necessarily is limited to 1% of the available wireless bandwidth for that neighborhood. If you limit each signal to the walls of a person's home, every individual gets 100 times more bandwidth because they aren't competing with their neighbors. You can always lay more fiber to increase bandwidth. Increased wireless bandwidth is only possible by limited technological improvements. That's an over-simplification, but you get my point.

Boosting an individual's signal may be temporarily good for that individual, but bad for the system. There are alternatives that are good for both the individual and the system. Hence, the desire for regulation.

Yeah, I remember those classes. I spent so much time trying to write really small that I accidentally learned the material.

You're right. That's much less pointless than just plugging the hotplate into the outlet the PSU is plugged into.

That's my favorite part about these sorts of laws. The death penalty doesn't deter them, but people think a small fine will.