In a conversation that began as a request to include the SAS Transport Layer in the mainline Linux kernel, there was an interesting thread regarding specifications. Linux creator Linus Torvalds began the discussion saying, “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.”
Thank God he’s not designing aircraft, automobiles, or rockets engines. Without specs., chaos would ensue.
Without specs the kernel programmers would be blind in programming peripherals. It seems to me Torvalds tried to spout a little benevolent dictator wisdom that came out too generalizing and convoluted, rather than the SAS people accepting this at face value, they challenged him on it. Rather than both sides backing down, a flame war ensued.
Without specs the kernel programmers would be blind in programming peripherals.
The specs for a peripheral didn’t come out for the programmers until the peripheral was actually implemented.
The specs for a peripheral didn’t come out for the programmers until the peripheral was actually implemented.
Not entirely true. The SCSI/SAS and IDE specs come out of t13 and other consortiums long before implementations appear. The Programmers manual for a device is what you were intending to talk about,Right?
I was involved in PCI-SIG meetings and reading PCI Express 1.0 draft specs concurrently with device vendors who were making prototype devices.
Without specs like the SAS/SCSI/PCI Express/USB. Analyser wouldn’t be possible and anyone writing device drivers and making system boards knows how important those are.
Let me guess Linus doesn’t write device drivers or design system boards. Funny he should talk about specs.
I’d say he’s pretty right for writing a kernel. It’s a different bear than rocket engines and automobiles (and I don’t know why you’d use a spec for a rocket engine, that’d be terribly silly: How much thrust and how big doesn’t count as a spec either
).
He’s used things that act for the kernel like a spec historically: He used the SunOS API for POSIX compatibility. That’s not a spec, but it did what most software engineers use specs for: To tell you what you should be writing without writing it first.
But the kernel isn’t tailored to a customer, it’s tailored against millions of customers. Its roll is pretty well defined, and where it’s not the question is an argument and not a blank (arguing if it should do something, as opposed to having no clue what to do in a situation).
Also, it’s a working stable project. They keep a working version that does the full job: Minus the couple of features being implemented at a given time.
If you wrote a spec for Linux it’d instantaneously be broken by 18 different patches anyway. Those aren’t going to be mainline patches, but someone like RedHat will probably end up using them. So then what was the point of your spec? The Linux spec would probably end up saying: “Should have this API found here (url), and should be modifiable at a source level in every possible way.”
Great spec, that sure tells you what to write.
Now, I certainly hope Linus doesn’t think specs are always useless. They certainly have their place, especially around human interaction. But the kernel doesn’t do any human interaction
. Well, except the proc filesystem.
No it is not a different bear. Operating systems control guidance systems on rockets and other potentially expensive and/or dangerous machines.
I correctly written spec, based off honest and complete requirements, is very beneficial to keeping a project, especially one with many different developers working in small groups that eventually have to tie their code together, in concert.
On the other hand, you might as well just throw away a poorly written spec because it will be entirely useless!!!!!
Specs are overrated and inflexible. Half the time they are broken too. Solve the problem first then write specs later.
I’ve personally found specifications to be *extremely* useful when (a) working on a product that is designed in conjunction with external customers and which has a lengthy release cycle, or when (b) writing software that has to interface cleanly with software being written independently by another party.
Formal specifications provide a structured way to precisely describe what the developer is contractually obligated to provide, at least on the interface level,
and that can be invaluable in many cases.
When doing support for an internal system, though, or when writing utility or applications software for my own or others’ use, I’ve rarely found a need to create a formal specification; it’s a lot easier to get on the phone or flip e-mails back and forth if I have a user whose opinions I’m interested in, and code turnaround times are a lot faster when the code and the “spec” are one and the same. 🙂
The main point, though, is this: Not all software development is the same, and there are a number of cases where formal specifications can be useful or are absolutely critical to the success of a software development effort.
For most things, though, a formal spec is probably not as useful, and it might even get in the way in a lot of cases, particularly if one is doing internal development in a fast-paced environment.
This is utter rubbish. It is no different than saying, for example, that programs are overrated and inflexible. The quality of any particular specification, good or bad, does not define the value of specifications per se.
In the world of professional software development, with the correct disciplines and processes in place, we start from the user requirements. This should answer the question: What is the program intended to do?
Surely nobody can argue with the suggestion that if a program does not do what those who will use it need it for, then it is pointless? The specification (and there are many kinds of these – highlevel design spec., functional spec., system spec., program spec., and so on) is intended to translate the user requirements, wrítten in business terms, into a definition of a system or program in technical and functional terms.
A good program, written according to a correctly formulated specification, should deliver close to precisely what was required by the user.
This is not a scenario in which the programmer’s prowess and creativity are expected to be more important than the requirements themselves, and I have seen far too many systems which give away their origins as created by programmers along the lines of “this is what we made” rather than “this is what we were asked to make”. And how many systems show the problems of lack of ergonomics which the correct design process would have avoided? I could name a few!
I have been around computers for over 30 years, and worked as an IT professional, including as a systems analyst (one whose job involves writing specifications) and as a programmer (where I was expected to write from specs.) and the negtive attitudes towards specs. expressed in this thread are indicative of the widespread problems of poor and even non-existent system design which abound.
And how can you design a proper testplan (I hope this word does not draw blank looks) without knowing what the software was specified to do? How do you know if something works correctly if you don’t have a document which defines what “working correctly” includes?
Poorly-written specs. are as dreadful as poorly-written code. But that does not mean that specs. per se are not of immense value and importance.
Oh, and a good spec. is a living document, which should be amended as requirements change, as errors are found, or as other factors affecting the development alter. A spec. should NEVER be written after the program just to show that it exists or to document what was ACTUALLY written.
AndyJ
In the world of professional software development, with the correct disciplines and processes in place, we start from the user requirements. This should answer the question: What is the program intended to do?
But alas, in this same world, we don’t always know the problem we set out to solve until we’ve actually played around with it and experimented with alternative possible solutions.
Surely nobody can argue with the suggestion that if a program does not do what those who will use it need it for, then it is pointless? The specification (and there are many kinds of these – highlevel design spec., functional spec., system spec., program spec., and so on) is intended to translate the user requirements, wrítten in business terms, into a definition of a system or program in technical and functional terms.
User requirments change with the weather. Sometimes, actually many times, users don’t even know what they want. It’s best to get a toy program out of the door quickly to allow users play with it. Lets call this toy program a prototype, for those who like technical speak.
Users can then give you their feedback on what they like about it and what they don’t. You tweak this program until the user is satisfied. After which your development team set out to write a specification, which in this case will represent an agreement between the user and development team.
At that point, you and your users understand the problems you are trying to solve. At that point, your specification is not just vaporware, it is a living “program” attached to an agreement.
A good program, written according to a correctly formulated specification, should deliver close to precisely what was required by the user.
Sounds good in theory, never works in reality.
This is not a scenario in which the programmer’s prowess and creativity are expected to be more important than the requirements themselves, and I have seen far too many systems which give away their origins as created by programmers along the lines of “this is what we made” rather than “this is what we were asked to make”. And how many systems show the problems of lack of ergonomics which the correct design process would have avoided? I could name a few!
Correct design is not a function of some silly opaque specification. Correct design is a function of iterative design and experimentation. Nobody gets it right the first time. And if you do, consider yourself very lucky and perhaps talented.
I have been around computers for over 30 years, and worked as an IT professional, including as a systems analyst (one whose job involves writing specifications) and as a programmer (where I was expected to write from specs.) and the negtive attitudes towards specs. expressed in this thread are indicative of the widespread problems of poor and even non-existent system design which abound.
That’s funny. I haven’t been in the IT industry for that long, but my observation differs. Poor software systems stem from managerial, time, resource and economical constraints. Not the absence or presence of a silly paper. Most pertinently, poor software systems are a product lack of testing, zero user feedback, and not understanding the problem domain. I could mention a thousand and one more reasons, and specifications won’t even make the list.
And how can you design a proper testplan (I hope this word does not draw blank looks) without knowing what the software was specified to do? How do you know if something works correctly if you don’t have a document which defines what “working correctly” includes?
That’s easy. You give your clients a prototype of the software you’ve been playing with. They give you their feedback.
Poorly-written specs. are as dreadful as poorly-written code. But that does not mean that specs. per se are not of immense value and importance.
They are. However, specs tend to yield overengineered solutions. You have people coding to specs, as opposed to coding to solve a real problem. It gets worse when specs are written by a different team than the coders themselves. So you have coders writing software based on the ramblings of another person about what software should do. It doesn’t matter if the spec solution is buggy, untested or unsound. The code monkeys just write software according to the spec. Oh it gets worse. Big companies like Apple and Microsoft allow marketing to write their specifications. So you have people writing specifications about software with having a clue how software actually works.
Oh, and a good spec. is a living document, which should be amended as requirements change, as errors are found, or as other factors affecting the development alter. A spec. should NEVER be written after the program just to show that it exists or to document what was ACTUALLY written.
A good spec is your well documented source code with illuminating text-book-like commentaries. Anybody who writes software based on specs as opposed to solving real world problems has huge problems to overcome. And I’m not even going to mention that almost all specs are ambigous, poorly written and abstract.
Writing programs is like solving a mathematical problem. You don’t write specs or theories to solve a mathematical problem before actually solving it. That’s just ridiculous.
Writing programs is like solving a mathematical problem. You don’t write specs or theories to solve a mathematical problem before actually solving it. That’s just ridiculous.
No it’s not, maybe writing an algorithm is like solving a mathematical problem. Writing a program is like building a bridge : you discuss the needs (where, how, material, usage, looks), then you design, then you build.
Incidently this is why we call it ‘software engineering’ and not ‘software art’ or something.
The term “software engineering” has been coined by people
who have no idea what programming is all about. Building a
bridge is nothing like writing software. The fact that
people draw parallels between real engineering disciplines
and abstract disciplines, like programming, goes to show you
how ill informed the industry is in general. If I don’t hear
the word “software engineering” and “software architect”
again for the rest of my life, I consider myself blessed. It
is such an affront and insult to real engineers and
architects.
Believe it or not, as opposed to your misconception, writing
good software is more of an art than it is a science. Good
Art is about coherent abstractions, evolved designs, an eye
for detail and good taste. So also is good software. Good
software is like magic. All the user sees are illusions,
well defined abstractions and creatively veiled
implementation details.
The people trying to force a scientific face over
programming are people who demand we write specifications
for unexplored problems. The people who use terms like
“software engineering” and “software architect.” And the
people who falsely believe programming is an “engineering”
discipline as opposed to an abstract extension of
philosophy, logic and mathematics.
Writing software is a creative art. Much like writing a good
essay or performing a magical act before an audience.
Thanks to the industry, we believe otherwise.
A piece of software is an engine : you put things in, it processes and then outputs. Each part has to fit, like the cogs of your machine to prevent friction and thing blowing up in your face. Code doesn’t have to be beautiful, it has to work. Some will see ‘art’ there, but then the strangest things pass as art.
These macho-geek attitudes Conan-the-bugslayer, the computer-wizard or the code-artist are recent delusions (and seem to exist mostly under the self-styled ‘geeks’ in the IT world). More importantly they’re keeping computing away from the ‘mainstream’ people.
Incase you didn’t read the article and linus’ discsussion his response was based on the SAS spec. Your boat load arguments of User based software design just goes out the window. The SAS spec is for hardware and software and what linuxes domain in that is device drivers, which are not driven by the SAS specs but the implmentation of the spec by hardware vendors mainly host bus adapter vendors.
I think most vendors take specs seriously, but erratas and bugs tend to deviate devices from the spec. But things work together 99.9% of the time because people followed a spec. Say a seagate, hitachi, samsung and maxtr drive connects, communicates and works with an adaptec, LSI, promise, qlogic controller is because they all followed the spec.
Linux needs more to deal with who the deivce driver interfaces with the card and not SAS itself and thus manily device driver developers work with Programmers manuals from vendors. Which can be considered specs.
Usually non compliance with the spec happens because of bugs and in corner cases. Vendors usually are good about trying to fix such cases if possible with a firmware update if they can’t will propose a workaround that goes in to the driver.
Since Linus has been so engrained in reverse engineering drivers he has netiher used nor have understood the above process. Note that the people he was responding to thought he was full of shit too.
Linus is an opnionated and often in wrong was eventually this will hurt the progress of linux if it hasn’t already. What scares me is the Linux zealot cult treats everthing he says however foolish and uniformed as gospel.
“Linus is an opnionated and often in wrong was eventually this will hurt the progress of linux if it hasn’t already. What scares me is the Linux zealot cult treats everthing he says however foolish and uniformed as gospel.”
Yes, like Linus was wrong in microkernel versus monolithic kernel war when everyone else was against him. And Linus was also wrong, when everybody criticised him when he was going to work at a commercial company. That day Linux died. *Gasp* it didn’t?! Well, what about that time Linus was wrong about GIT? That surely told those stupid Linux zealots he’s not up to any good…
Man that stupid coder has been so many times wrong I’ve lost count. But really, every time Linus opens his mouth 90% of people think he’s full of sh**. I don’t know if it’s stupidity or just jealousy, but I don’t care anymore. I know this might be difficult to understand, but there are reasons why people (read: “Linux zealots”) just trust Linus. The main reason is that he has done something incredible, not once, but for the last 15 years, and I don’t believe there’s one single person in the whole IT world who has made more right decisions, even when everybody has been against him. So you’d better have one heck of a pack of good arguments before trying to outsmart him. And the arguments made about this topic have this far been pathetic. Most people haven’t even read the whole conversation, just OSNews’s or Slashdot’s headline.
Yes, like Linus was wrong in microkernel versus monolithic kernel war when everyone else was against him. And Linus was also wrong, when everybody criticised him when he was going to work at a commercial company. That day Linux died. *Gasp* it didn’t?! Well, what about that time Linus was wrong about GIT? That surely told those stupid Linux zealots he’s not up to any good…
Linux was wrong about many things. Let’s see, debuggers, tracing toolkits, crash dumps, POSIX threads implementation. All of which many who have disagreed with him have implemnted and are fighting a losing battle trying to get into linux.
Linus was wrong about bitkeeper and hence the need for GIT.
I am not one to dwell on peoples mistakes but I take objection to people like those on this thread that take everythig their mighty dictator says as the only way to do things.
Linus has done more right that wrong but not everything she says or does is right. The minute you think that you have closed your mind to other opnions. I never claimed everything Linus did is wrong, all I said is linus is opinonated about things and many of the things he is strongly opinonated about is just plain wrong. This is one of them.
“Linus was wrong about bitkeeper and hence the need for GIT.”
First people said: “OMG BitKeeper, it’s proprietary. Fool Linus we should fire him!” However, it worked well for many, many years. Then Linus started working with GIT, and everybody went like “OMG you idiot! That won’t work, it’s illogical and stupid!” But GIT worked like a charm afterall. Then afterwards people went like: “Yea, I was right all the time. That fool Linus should’ve never trusted that stupid BitKeeper anyway.”
And that’s my problem with people opposing Linus. BitKeeper served well for its time, until it was time to move onwards to GIT, Can’t see anything wrong with that.
For the record, I did read the article. You seem to be confusing manuals with specs. They are two different and unrelated things.
A manual is a reference to how a particular piece of hardware or software works. A spec is a theoretical guideline that vendors should follow to achieve interoperability or some sort of standard.
My argument was never about the SAS spec or it’s implementation. My argument is that specs in general lead to overengineering and needless complexity prior to even writing the software.
I’d like to see specs evolve from real solutions as opposed to specs been written before a given problem is solved. This applies to drivers, the kernel, user space applications, libraries, standards, etc.
It is silly to write a spec when you are unfamiliar with the problem you are trying to solve. That’s premature design.
For the record, I did read the article. You seem to be confusing manuals with specs. They are two different and unrelated things.
I am saying Linus is too. Drivers aren’t written to specs they are written to device specific specs. Linus responded to a line that talked about SAS.
A manual is a reference to how a particular piece of hardware or software works. A spec is a theoretical guideline that vendors should follow to achieve interoperability or some sort of standard.
NO a spec is a specification on how something should work it is not just a guidline. A spec tells you how long a device should take to come back from a reset and how the electrical wave form should look on the physical layer with margins and tolerences. RAM chips and DIMMS from multiple vendors work with multiple memory controllers because they follow the specs and timings accroding to the specs.
My argument was never about the SAS spec or it’s implementation. My argument is that specs in general lead to overengineering and needless complexity prior to even writing the software.
Linus’ argument was based on SAS. You are conflating userland, business process oriented software requirements documents and specs. Linus and the who spirit of this discussion is on kernel programming and thus device drivers and software APIs applying to them.
I’d like to see specs evolve from real solutions as opposed to specs been written before a given problem is solved. This applies to drivers, the kernel, user space applications, libraries, standards, etc.
I guess you missed the point of the article and the thread on LKML. I have and the “real world” has shown you enough proof that specs are the reason stuff works together. from storage devices to RAM to USB perpherals.
It is silly to write a spec when you are unfamiliar with the problem you are trying to solve. That’s premature design.
Living in the real world I would like to assure you that most specs for hardware and thus those required to write kernel modules for such hardware are not desinged that way.
I do not need a specification to right a driver for floppy disk. Neither do I need one to write web browser to view web contents. Nor do I need specifications to right software in general. Do you follow?
Specifications are primarily guidelines that people are free to disregard at any point. There purpose is to ensure consistency and interoperability. There many broken specifications out there. We still can’t get ACPI working right on Linux because the specification says one thing, while the real world says another.
You do not need a specification to write any piece of software. People have been writing drivers and operating systems without specifications for years. The only reason we have specifications todays is so that we are all on the same page.
The W3C is another body that has a boat load of standards that many web applications have problems following correctly. Their specification are difficult to decipher, ambigious, contradictory and many time just pointless.
And don’t get me started on specs that nobody understands fully well enough to follow. SOAP anyone?
I do not need a specification to right a driver for floppy disk. Neither do I need one to write web browser to view web contents. Nor do I need specifications to right software in general. Do you follow?
No I don’t follow. Your web browser better follow the relevant RFCs for http and ftp at the very least and the CSS and html specs and standards.
Specifications are primarily guidelines that people are free to disregard at any point. There purpose is to ensure consistency and interoperability. There many broken specifications out there. We still can’t get ACPI working right on Linux because the specification says one thing, while the real world says another.
Why do you think that is? It is because of the very attitude ” that specs are wrong and can be disregarded” that got the real world into this mess in the first place. What you have is a self fulfilling propechy then. Specs are bad because they are not followed and I won’t follow specs because of it. How convenient?
You do not need a specification to write any piece of software. People have been writing drivers and operating systems without specifications for years. The only reason we have specifications todays is so that we are all on the same page
Really… Pray tell what device drivers ver written without knowing how a device behaves. I guess you can just open your favorite editor/ IDE and write a device driver out of thin air whithout even seeing a device or knowing what registers to program and how and the sequnence, right?
This’ll probably cause a whole lot of debate. Linus is sure to have purists like Theo DeRadt (?) say come out of the woodwork to label the linux kernel as hackish. Linus will fire back that it is the purism of such projects, and their resultant deficiency in features that prevents them from gaining wide acceptance. Not to sound wishy-washy, but I see no need to draw such hard lines. Best tool for the job, I say, and I’m sure Linus would agree. I like his views on many things, dislike his views on others, but his capabilities as an organizer have produced a work that is “good enough” for many applications, and excellent for others. Though spearheaded initially by his adoption of the GPL, and alliance with the FSF, (the ideological purists,) it has been Linus’s capibilities as a moderator, and organizer that have brought Linux into a capable, flexible kernel. Good job.
Those who are engineering purists will surely question the long-term viability and maintainability of the Linux kernel, but the fact of the matter is that Linux can tolerate a little bit of waste, and rewriting because there is enough manpower to keep it afloat.
I can’t imagine a world without specs. Seriously, if there were no specifications in the computer world, would anything work? How would different companies even build tools that interoperate? How would software even communicate with hardware? That’s got to be the dumbest statement in the world.
Indeed. I know a lot of companies that wouldn’t be operating today if it weren’t for the specs that drive their business models, computer systems, accounting practices, etc.
Stupid is as stupid does.
Once again. There are stable API’s and Standards, and they aren’t engineering specs. They’re something much more. Specs are something you generate and forget about after you’ve designed something to meet them. Then you dig them up later when someone says you strayed from the spec.
API’s and Standards are things you publish so that people can assume they are as they are documented. How many people have read the specs for Excel lately? And how many have read “specs” for, oh say, xml-rpc?
You’re implying the nature of a derivative work back upon its parent. ie, I’m saying API’s and standards are a child of specs, they inherit its properties and override a few and add some others.
Yea, who is this Linus guy anyway? He’s probably never managed a single project with any bigger scale. I bet he doesn’t know anything about Linux kernel development either.
Or maybe you should just read the whole conversation, not just OSNews’s bad briefing.
You know this is a surprising string of emails from one of the most balanced and interesting people that I’ve read interviews about.
He normally sounds completely rational and not zealot-like. Perhaps he should consider saving some of his emails as drafts when enraged like the rest of us…
I send my enraged e-mails
. Perhaps people should take each e-mail in its context like you do with normal people instead of publicising it and freaking out 
.
Someone wrote a long article about this somewhere. Something about how smart people tend to be very damaging when they’re wrong because they can make it so damned hard to prove they’re wrong; even when they realize they’re wrong!
“Someone wrote a long article about this somewhere. Something about how smart people tend to be very damaging when they’re wrong because they can make it so damned hard to prove they’re wrong; even when they realize they’re wrong!”
And that’s as it should be. It makes the other side put out the needed work to prove one’s wrong, instead of taking the lazy way out.
Now i understand why there are no specific standards in Linux. Code it and hope it works, yet another reason to cast a suspicious eye at the Linux kernel code base.
Specs are most useful when creating a product. They are necesary if you work for a customer, but if you work writing code for yourself, as a hobby mainly, then you dont need specs. He is talking about the linux kernel, which has been a slowly evolving project since years, and i find it natural that they dont need specs.
What they have in turn is documentation.
“Specs are most useful when creating a product. They are necesary if you work for a customer, but if you work writing code for yourself, as a hobby mainly, then you dont need specs.”
Well the implication here is that Linux doesn’t have customers. Linux has outgrown the hobbiest stage long ago, and is now competing with the big boys and their “speced” software.
What he says is that programmers should not take the specs literaly. Although a program can implement functionally the spec completely, the internal implementation may differ from what is explained in the spec.
For instance if the spec says some protocol has 5 layers – that does not mean that the internal implementation should have 5 layers.
An OpenGL driver may not implement the OpenGL block diagram:
http://www.rush3d.com/reference/opengl-bluebook-1.0/figures/OpenGLO…
, but functionally the result should be the same.
Specs are never supposed to describe internal workings… They’re entirely about observed behaviour. I don’t see how implementation is even a question.
This all seems blatantly obvious to me. If you could accurately describe internal behaviour in concise english, well why are we wasting time with this “c” thing?!
please read the discussion then start bicering, reading the posts here it sound like noone has read the entire discussion wich makes all those posts useless
This seems like a far more general topic for discussion than just “does the Linux kernel team care about protocol specs”, and whether the specs in question pertain to hardware, firmware, or software doesn’t really matter — most of the same issues tend to apply to all three.
I’m a little lost. Is someone asking them to write a spec for something that already has one? Or asking for major changes to follow some spec?
OMG. Linux’s only saving grace these days is that fact that 90+% of it was not in fact written by Linus Torvalds. He has some rather mystifying points of view…
Obviously you are missing the point (or have not read the entire thread).
As I read it. Linus is not against specs describing how something works or specs laying out a set of requirements. We *need* such specs to be able to write drivers for hardware or interoperate with other OS’s.
What Linus is saying (and which I agree with) is that if you take specs too litteral they often become useless since they are just descibing how something *ought* to work, but the real world doesn’t work like that – hardware rarely follow specs to the letter, so you have to work around that. Specs may describe a nice way to view and/or implement things from an academic viewpoint, but the actual implementation will need to differ for performance reasons, to fit in with existing API’s etc. That doesn’t mean you can’t still follow the spec, it just means you sometimes need to consider the real world and do things a little different to get it to actually work (and/or perform well).
The problem with specs is that not everyone follow them to the letter. If everyone did there would be no problem, but look at SCSI, look at (X)HTML, look at (ecma) JavaScript, look at Ethernet, look at I2C, etc, etc. All have nice specs, but if you follow them to the letter your software just won’t work in the real world. Those specs are OK as a guideline as to what should be done and how it should be done, but you need to deviate from the spec, add workarounds, implement things in a more optimum way etc, to actually get anywhere – becourse different manufacturers, software houses, whatever, all produce hardware and software that mostly implement the spec, but all with their own little twists, bugs or extensions.
Specs are OK as guidelines, but don’t take them too litteral or you won’t get anything done in the real world.
Linus made an extreme comment make a point. People took him very litteral and that’s the mistake. Please also consider the person(s) he’s communicating with – they have histories on LKML beyond this thread – also please read the *entire* thread to get the proper context.
It’s not so bad as you believe
Linus made an extreme comment make a point. People took him very litteral and that’s the mistake.
So according to your view he should not be taken literally and thus he must be a spec. But specs aren’t to be trusted and don’t represent the real world. Paradoxical, no! So by that rationale what ever linus’s position is on specs must not be applicable to the real world. Ah it all makes perfect sense now;)
Specs are just tools,standards that allow one to discuss the same process.Still what’s written isn’t by far a match of reality.Some believe the 7-layer OSI model is an exact representation of what’s going on.It isn’t, it’s just an approximation at best to make it less abstract or even a bit more effordless to talk about it.Yet regardless wether scientific models,specs,whatever are accurate,at hand,or not,real world problems have to be solved.Most of the times even without specs.
With proper specs, something like “component A can be connected to component B” makes sense, because it is already handled by the specs that other components present in the system don’t interfere, and because the specs define what “component” and “connect” means.
Without specs, chaos results: “component A can be connected to component B, by using C or D to connect them, but if D is used, E may not be present anywhere in the system unless C’s version is greater than A’s version. Exceptions to this rule are the following implementations of the components: …”
As a more concrete example… would you like a restriction which disallows certain GCC versions if you have a Realtek network card? Do I hear “a compiler has nothing to do with the networking hardware”? Well, that’s the result of proper specs.
– Morin
Someone asked me for directions today, I just told them to find out themselves. After all I’ve seen at lot of people getting lost with maps, they don’t help you find your way at all. They’re always out of date, why my perfectly good map from ’75 doesn’t help me at all anymore.
The real world always looks different too. We’ve got roadblocks and deviations. Hell sometimes entire cityblocks are under renovation and don’t reflect the map at all!
So why bother, after all real men find their way despite maps not because of them.
All Torvalds is saying is show me the code with a clean, logical interface instead of pushing needless abstractions that won’t reflect reality. It’s similiar to XP.
Naturally you don’t need spec because Linux is a clone of UNIX and so please refer to the POSIX specs. I wonder how far Linus would have gotten without POSIX/Unix specs.
If Linus was designing a brand new OS, he’d find out soon that without specs no one would be able to help him.
To all you morons arguing aginst specs – go back to school and find out what “desiging” software is all about. Don’t be surprised when you get your first programming assignment and it has something called “specifications”.
In design and development criteria plays a more important role than specs, at least initially. If the design meets all criteria and also meets the minimum specifications, then we’re getting somewhere. I guess you need to design with specs in mind but focusing on meeting the objectives (criteria). Once that is established, looking at the specs can determine if the system was designed intelligently…
As far as I’m concerned
Jb
Anyone seen the specs for a Ford Pinto?
<sarcasm>Who needs specs? Just build it as you go along. And don’t forget to take reality into account. That’s sure to throw you for a loop. </sarcasm>
A perfect example of what Linus is talking about is ACPI. Coding to the ACPI spec in the Linux kernel is not very useful because it does not match reality. Reality is that Microsoft controls ACPI and their implementation must be followed if you want working code. This is in no way a deviation from what Linus has said before. He prefers working code to code that is considered to spec or elegant, if it does not work well.
It basicly boils down to this.
If most of your users use “broken” web browsers that only implement a non conforming variant of HTML 3.2 called tag soup and they break when you serve XHTML (or conforming HTML 3.2 for that matter) you shouldn’t claim that you are following the specs and that they have broken clients.
The fact remains: YOU have failed to deliver a SERVICE to your USERS.
Linus just says that if your users use IE, serve tag soup.
An other example:
My GF had a similar problem. MS Outlook and Evolution dont collaborate very well to handle UTF-8 to Windows-1252 conversions. Resulting in it beeing hard mail potential employers asking for a job. The mail looks like crap when it reach the intended reader.
Saying that Evolution is spec conformant and that the not-so-potential-any-longer employer should fix his client to conform to specs JUST ISN’T AN ALTERNATIVE!
As specs are useless we should all delete the RFC’s and take a ‘seemed like a good idea at the time’ approach to design.
Damn those pesky IETF people, all they are doing is opressing programmer creativity, they are the devil.
sarcasm
Linux is an OS where files have no association to programs; all configuration and settings are stored “wherever” in text files that grow to be megabytes long; most shell commands are so abstractly named that you would never be able to use them without knowing how they work.. or first reading its “manual page”.
Linux is an operating system of inconsistancy. Theres over a thousand distributions of linux, and over a billion different modified versions of it. Programs come shipped as source code that you must compile and configure (by way of large scripts that attempt to figure out how your system is running.. since nothing is standard).
it looks like nobody is reading what Linus actually said.
In software design it’s very important to understand that you do not write code on basis of specs.
You use specs to define the functionality nescessary in the application (driver, OS, complete system etc.), eg. you use the specs as a basis for talks.
Just like Linus said
I think the problem here is that people use the same word with different meanings. We may need a glossary
When Linus first started developing Linux didn’t he send a post to Usenet asking for a copy of the posix spec in order to help him implement? Doesn’t Linux port to various platforms because of well defined spec? If I pluyg my USB memory card into my Linux box it mounts because of well defined USB specs and I can access it because of the FAT32 spec.
It seems to me that over the last few month Linus is beginning to loose the plot. We had the BitKeeper fiasco a few months back and now this. I read the transcript over on kernaltrap and it really seems to me that Linus is pretty intolerant and unwilling to admit he may be wrong. Instead he just keeps digging himself into a hole (just like he did with the BitKeeper issue).
I though Linux was suppose to be about freedom, but Linus isn’t too happy when people voice their opinions.
Perhaps Linus’ fame is starting to go to his head. Once there was a time when he was just a humble hacker working on a kernel that few people had heard of. Now he’s on the front cover of magazines and interviewd all the time. I wonder if he’s developing a “bigger thad god” complex..? There’s a lot of talk on the message boards about Microsoft being a monopoly, but is that what Linus is becoming..? Have we reached the point where if he doesn’t agree with it then it doesn’t get done?
If he carries on with this “holier than thou” attitude then maybe it’s time for him to go…
Software Construction is in many ways a matter of (almost magical) art – just like writing songs. But then, it’s possible to write songs according to a scheme (we all know the boring mainstream songs – technically acceptable, but artisticly utterly unacceptable).
But then, the same can be said about hardware engineering. Take a look at the classical Mac. It was based more on art than engineering, yet it was based on specs (to know which limitations to break free from).
In danish the word is “kunsthåndværk” , I believe the english word is “handicraft”. A combination of art and engineering.
Linus didn’t say that specs were unuseful. What he said was that they were unuseful in regard to coding. Which is all true. Never ever use specs as a foundation for coding. But it can be used to set out directions/goals for the result of the code.
With the stupidity shown in this thread, it would be no surprise for me if somebody came by and told me the waterfall technique was a sane technique in regard to software development.