Linked by Thom Holwerda on Mon 3rd Oct 2005 14:52 UTC
Linux 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."
Order by: Score:
Thank God
by Anonymous on Mon 3rd Oct 2005 15:27 UTC
Anonymous
Member since:
---

Thank God he's not designing aircraft, automobiles, or rockets engines. Without specs., chaos would ensue.

Reply Score: 0

RE: Thank God
by Adam A on Mon 3rd Oct 2005 15:43 UTC in reply to "Thank God"
Adam A Member since:
2005-07-07

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.

Reply Score: 3

RE[2]: Thank God
by Anonymous on Mon 3rd Oct 2005 18:14 UTC in reply to "RE: Thank God"
Anonymous Member since:
---

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.

Reply Score: 0

RE[3]: Thank God
by Arun on Mon 3rd Oct 2005 21:44 UTC in reply to "RE[2]: Thank God"
Arun Member since:
2005-07-07

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.

Reply Score: 1

RE: Thank God
by ma_d on Mon 3rd Oct 2005 16:12 UTC in reply to "Thank God"
ma_d Member since:
2005-06-29

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.

Reply Score: 2

RE[2]: Thank God
by Tuishimi on Mon 3rd Oct 2005 16:44 UTC in reply to "RE: Thank God"
Tuishimi Member since:
2005-07-06

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!!!!!

Reply Score: 2

I feel his flow
by Mystilleef on Mon 3rd Oct 2005 15:36 UTC
Mystilleef
Member since:
2005-06-29

Specs are overrated and inflexible. Half the time they are broken too. Solve the problem first then write specs later.

Reply Score: 1

Specs are sometimes useful, sometimes not.
by rcsteiner on Mon 3rd Oct 2005 15:54 UTC in reply to "I feel his flow"
rcsteiner Member since:
2005-07-12

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.

Reply Score: 2

RE: I feel his flow
by AndyJ on Tue 4th Oct 2005 07:10 UTC in reply to "I feel his flow"
AndyJ Member since:
2005-06-30

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

Reply Score: 1

RE[2]: I feel his flow
by Mystilleef on Tue 4th Oct 2005 09:59 UTC in reply to "RE: I feel his flow"
Mystilleef Member since:
2005-06-29

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.

Reply Score: 1

RE[3]: I feel his flow
by Tyr. on Tue 4th Oct 2005 11:00 UTC in reply to "RE[2]: I feel his flow"
Tyr. Member since:
2005-07-06

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.

Reply Score: 1

RE[4]: I feel his flow
by Mystilleef on Tue 4th Oct 2005 11:27 UTC in reply to "RE[3]: I feel his flow"
Mystilleef Member since:
2005-06-29

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.

Reply Score: 1

RE[5]: I feel his flow
by Tyr. on Tue 4th Oct 2005 13:42 UTC in reply to "RE[4]: I feel his flow"
Tyr. Member since:
2005-07-06

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.

Reply Score: 1

RE[5]: I feel his flow
by Arun on Tue 4th Oct 2005 13:49 UTC in reply to "RE[4]: I feel his flow"
Arun Member since:
2005-07-07

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.

Reply Score: 1

RE[6]: I feel his flow
by Anonymous on Tue 4th Oct 2005 15:20 UTC in reply to "RE[5]: I feel his flow"
Anonymous Member since:
---

"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.

Reply Score: 0

RE[7]: I feel his flow
by Arun on Tue 4th Oct 2005 15:40 UTC in reply to "RE[6]: I feel his flow"
Arun Member since:
2005-07-07

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.

Reply Score: 2

RE[6]: I feel his flow
by Mystilleef on Tue 4th Oct 2005 15:21 UTC in reply to "RE[5]: I feel his flow"
Mystilleef Member since:
2005-06-29

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.

Reply Score: 1

RE[7]: I feel his flow
by Arun on Tue 4th Oct 2005 15:50 UTC in reply to "RE[6]: I feel his flow"
Arun Member since:
2005-07-07

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.

Reply Score: 1

RE[8]: I feel his flow
by Mystilleef on Tue 4th Oct 2005 16:23 UTC in reply to "RE[6]: I feel his flow"
Mystilleef Member since:
2005-06-29

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?

Reply Score: 1

Anonymous
Member since:
---

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.

Reply Score: 1

What an idiot
by Anonymous on Mon 3rd Oct 2005 15:57 UTC
Anonymous
Member since:
---

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.

Reply Score: 1

RE: What an idiot
by bryanv on Mon 3rd Oct 2005 16:11 UTC in reply to "What an idiot"
bryanv Member since:
2005-08-26

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.

Reply Score: 1

RE: What an idiot
by ma_d on Mon 3rd Oct 2005 16:17 UTC in reply to "What an idiot"
ma_d Member since:
2005-06-29

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.

Reply Score: 3

RE: What an idiot
by Anonymous on Mon 3rd Oct 2005 20:15 UTC in reply to "What an idiot"
Anonymous Member since:
---

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.

Reply Score: 0

Surprising change for linus
by morglum666 on Mon 3rd Oct 2005 16:03 UTC
morglum666
Member since:
2005-07-06

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...

Reply Score: 1

RE: Surprising change for linus
by ma_d on Mon 3rd Oct 2005 16:33 UTC in reply to "Surprising change for linus"
ma_d Member since:
2005-06-29

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!

Reply Score: 1

I see now
by Smartpatrol on Mon 3rd Oct 2005 16:04 UTC
Smartpatrol
Member since:
2005-07-06

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.

Reply Score: 2

I think he is in the most part right.
by Anonymous on Mon 3rd Oct 2005 16:04 UTC
Anonymous
Member since:
---

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.

Reply Score: 0

Anonymous Member since:
---

"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.

Reply Score: 0

not quite
by geleto on Mon 3rd Oct 2005 16:06 UTC
geleto
Member since:
2005-07-06

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.

Reply Score: 1

RE: not quite
by ma_d on Mon 3rd Oct 2005 16:31 UTC in reply to "not quite"
ma_d Member since:
2005-06-29

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?!

Reply Score: 1

there are specs and there are specs
by Anonymous on Mon 3rd Oct 2005 16:10 UTC
Anonymous
Member since:
---

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

Reply Score: 0

Not useless.
by rcsteiner on Mon 3rd Oct 2005 16:23 UTC in reply to "there are specs and there are specs"
rcsteiner Member since:
2005-07-12

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.

Reply Score: 1

What are they arguing over?
by ma_d on Mon 3rd Oct 2005 16:29 UTC
ma_d
Member since:
2005-06-29

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?

Reply Score: 1

v Re: Linus on Specifications
by Anonymous on Mon 3rd Oct 2005 16:46 UTC
RE: Re: Linus on Specifications
by Anonymous on Mon 3rd Oct 2005 23:17 UTC in reply to "Re: Linus on Specifications"
Anonymous Member since:
---

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 ;)

Reply Score: 0

RE[2]: Re: Linus on Specifications
by Arun on Tue 4th Oct 2005 06:11 UTC in reply to "RE: Re: Linus on Specifications"
Arun Member since:
2005-07-07

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;)

Reply Score: 1

Anonymous
Member since:
---

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.

Reply Score: 0

nonsense
by Anonymous on Mon 3rd Oct 2005 17:21 UTC
Anonymous
Member since:
---

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

Reply Score: 1

Directions
by Tyr. on Mon 3rd Oct 2005 17:31 UTC
Tyr.
Member since:
2005-07-06

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.

Reply Score: 1

Nothing to see here
by Anonymous on Mon 3rd Oct 2005 18:13 UTC
Anonymous
Member since:
---

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.

Reply Score: 0

sure....whatever you say, Linus!
by Anonymous on Mon 3rd Oct 2005 18:42 UTC
Anonymous
Member since:
---

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".

Reply Score: 0

c r i t e r i a
by GrapeGraphics on Mon 3rd Oct 2005 19:06 UTC
GrapeGraphics
Member since:
2005-07-07

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

Reply Score: 1

Specs
by aGNUstic on Mon 3rd Oct 2005 19:19 UTC
aGNUstic
Member since:
2005-07-28

Anyone seen the specs for a Ford Pinto?

Reply Score: 1

RE: Specs
by Lazarus on Mon 3rd Oct 2005 19:29 UTC in reply to "Specs"
Lazarus Member since:
2005-08-10

<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>

Reply Score: 1

I think people are missing the point...
by abraxas on Mon 3rd Oct 2005 23:23 UTC
abraxas
Member since:
2005-07-07

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.

Reply Score: 1

He's just saying...
by John Nilsson on Tue 4th Oct 2005 00:14 UTC
John Nilsson
Member since:
2005-07-06

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!

Reply Score: 1

Quick, delete all the RFC's
by Anonymous on Tue 4th Oct 2005 00:35 UTC
Anonymous
Member since:
---

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

Reply Score: 0

v Truly
by Anonymous on Tue 4th Oct 2005 02:33 UTC
Well...
by dylansmrjones on Tue 4th Oct 2005 08:06 UTC
dylansmrjones
Member since:
2005-10-02

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 ;)

Reply Score: 1

Lost the plot?
by sean batten on Tue 4th Oct 2005 09:40 UTC
sean batten
Member since:
2005-07-06

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...

Reply Score: 0

Art vs. Engineering
by dylansmrjones on Tue 4th Oct 2005 13:36 UTC
dylansmrjones
Member since:
2005-10-02

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.

Reply Score: 1