Forgot your password?
typodupeerror

Comment: Simple answer is no (Score 1) 596

by Tired and Emotional (#31157366) Attached to: Are All Bugs Shallow? Questioning Linus's Law
You can "pump" the difficulty of finding a bug arbitarilly. Make a bug that only happens in an illegal state that can only be entered because of a second bug. If you like you can hide one of these bugs in the compiler. Repeat until blue in the face.

In practice, even difficult bugs are usually only second order. Plus disciplined programming using strongly typed languages helps a lot. So one could perhaps claim that "all bugs should be shallow" and that any failure to be shallow wis in fact a tools failure.

The other fly in this ointment is that a lot of bugs happen because of incomplete specifications. Before you can find the bug you have to first recognize that the spec is incomplete. For new code, there may be no person who can recognize that. Of course you can quibble the hard ones in this category away by relabelling them "feature requests" but some of them result from building in constraints that are inessential to solving the problem at hand, and those are really bugs.

Comment: Re:Patentable? (Score 1) 241

by Tired and Emotional (#30312588) Attached to: Windows 7 Under Fire For Patent Infringement
Indeed - lets look at that: What is claimed is: > 1. A method in a computer system for processing a message having a sequence of packets, the method > comprising: > providing a plurality of components, each component being a software routine for converting data > with an input format into data with an output format; Every file convertor ever written does this part. Nothing new here. > for the first packet of the message, This is standard patentese - it does not mean anything > identifying a sequence of components for processing the packets of the message such that the > output format of the components of the sequence match the input format of the next component in > the sequence; and So, this is claiming the ability to recognize a sequence of components that need to run to do the conversion from the first packet. But this is just a function of the input data. It just means the data is "flat" in some sense. Absolutely nothing new here. > storing an indication of each of the identified components so that the sequence does not need to > be re-identified for subsequent packets of the message; and > for each of a plurality of packets of the message in sequence, > for each of a plurality of components in the identified sequence, > retrieving state information relating to performing the processing of the component with the > > previous packet of the message; So this looks like a claim on software pipelining. You do a bit of processing, save some state, and send the data on its way. There must be hundreds of uses of this prior to 1999. Its probably even in the textbooks in 1999. > performing the processing of the identified component with the packet and the retrieved state information; and > storing state information relating to the processing of the component with the packet for use when processing the next packet of the message Well, yeah, how else would you do it?

Save the whales. Collect the whole set.

Working...