No lo digo yo, lo dice Linus Torvalds. Y la cosa es que tiene toda la puta razón. Un par de emails cojonudos de él sobre el tema, el primero de hoy y el otro de hace años...(si, guardo los emails que me parecen interesantes). Pero por si alguien no se los lee, no puedo evitar resaltar esto del segundo email: "Call me cynical, but I believe in standards papers just about as much as I believe in the voices in my attic that tell me to kill the Queen of England"
On Thu, 29 Sep 2005, Arjan van de Ven wrote: > > a spec describes how the hw works... how we do the sw piece is up to > us ;) How we do the SW is indeed up to us, but I want to step in on your first point. Again. A "spec" is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality. So there's two MAJOR reasons to avoid specs: - they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada. None. It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation. - specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP. The classic example of this is the OSI network model protocols. Classic spec-design, which had absolutely _zero_ relevance for the real world. We still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software. So please don't bother talking about specs. Real standards grow up _despite_ specs, not thanks to them. Linus
On Mon, 22 Nov 2004, Len Brown wrote: > > I agree that the system should work properly even if the legacy device > drivers are broken. Please understand, however, that the legacy device > drivers _are_ broken. The BIOS via ACPI clearly tells them if the > devices are present or not, and Linux isn't yet listening. I really disagree. I realize that you like ACPI, or you would have shot yourself long long ago. But I have a totally different view on things. To me, firmware is not something cool to be used. It's a necessary evil, and it should be avoided and mistrusted as far as humanly possible, because it is always buggy, and we can't fix the bugs in it. Yes, the current ACPI layer in the kernel is a lot better at working around the bugs, and it's getting to the point where I suspect Linux vendors actually decide that enabing ACPI by default causes fewer problems than it solves. That clearly didn't use to be true. > ACPI-compliant systems have three types of interrupts: Stop right there. "ACPI-compliant systems". The fact is, there is no such thing. There are systems that users buy, and they are not "ACPI compliant", they are "one implementation of ACPI that was tested with a single vendor usage test". Call me cynical, but I believe in standards papers just about as much as I believe in the voices in my attic that tell me to kill the Queen of England. Papers is so much dead trees. The only thing that matters is real life. And like it or not, real life does NOT implement standards properly, even if the standards are well written and unambiguous (which also doesn't actually happen in real life). > If somebody bolts motherboard hardware on and doesn't tell ACPI about > it, then they need to disable ACPI, which _owns_ configuration of > motherboard devices when it is enabled. No. The only thing that owns the motherboard is the user. ACPI shouldn't get uppity. > The damn good reason is that doing otherwise breaks systems. And not doing it breaks systems. See a pattern? This is why I don't trust firmware. It's always buggy. Linus