s/wall/bridge/

When the client starts as "we want to build a wall", your first step is to reformulate it as "we want to go from side A to side B of the river". This way, you can notice that the right solution is to buy a ferry boat.

They fully expect you to know their needs and usually have a very hard time communicating them because a lot of things that make no sense to you are obvious to them because it's their daily bread and butter. And hence these things will be sorely missing in the specs.

That's why requiring a big upfront whole signed specification is useless. Users may not know what they want exactly, but they're very good at knowing it when they see it; they know exactly what problem they want to solve.

Your job is to understand the problem well enough to build a solution; and showing the working result to the user is the only way to know if you understood the problem, and if the solution is good enough. That's why iterative design works, and waterfall doesn't.

you find a small yellow star with 8 or 9 planets

I see what you did there

Why does the single comment that hit the spot go unanswered? There's a reason why programing tools are called ''languages'' - before problem solving or building architectures, programming is a form of *communication*: we try to express the ideas in our heads in a form that needs to be interpreted, either by the machine, by your fellow team programmers, or the system users. All them need to be able to make sense of the program's effects (at different levels), even though their understanding will be different.

There's no right way to write a program, because programing is not as much writing "a" solution to "a" problem as saying new things about the world. Until developers understand this, they will remain flabbergasted, wondering why their project's requirements change so much.

since the comment is not executed, there is no guarantee that it reamains correct

As the purpose of comments is to explain *why* a part of code was created (and why it was written in that particular way), it not being executable shouldn't matter much, as completely repurposing a bit of code rarely happens. (Generalizing it yes; abandoning the original purpose of a routine or function is uncommon).

The best comments are those targeted for the programmer reading them, not the machine that must execute the code; and letting fellow programmers know why you needed that piece of code in the first time is invaluable, even if what the code does changes over time.

Return your geek card (and your low ID at once). Calligra has been talked about many times at Slashdot. It's a fork and renaming of the KOffice suite, the original KDE clone of MS Office.

Plus, the human brain is massively parallel, much more than anything we know how to build, yet it learns as a single global epiphenomenon. If you split learning in separate niches, what makes you think that the computer would learn faster than the brains of the whole human race learning in parallel?

It's plausible that a pure information thinking system, once freed from the constraints of chemical processes on top of which our brains process information, could work much faster than our nature-evolved brains. But such system wouldn't resemble anything approaching the design of current computers.

Are you sure the algorithm won't learn much more slowly than humans instead? Learning happens by relating what you see to what you already know. So the more you know, the more it takes to add new facts. You can see that process in children, which learn much more quickly than adults.

We are not talking of merely recording events and dumping them into databases, but of building knowledge from them - that task could turn to be essentially non-parallelizable if you don't want schizophrenic computers.

That's because logic is unambiguous, and it allows us to clarify our own thoughts. Otherwise our brain gets ridden with misconceptions, prejudices, and lousy thinking. The need of pure logic is a testament to our brains' messy nature, not any characteristic of the workings of the world.

Of course it will be useless for you if you already have some understanding of the UNIX heritage. As with all metaphors, its value is for people who know very little about the topic, in that it helps them relating the topic to something which they're already familiar with.

For someone without a previous knowledge in the history of UNIX, the metaphor provides a mental map to navigate intuitively what was perceived as an impenetrable technical mess. It can provide the idea that there is a heritage of branching from a common origin, a sense of what are the main branches, their relative antiquity and importance.

Moreover, it's funny and light-hearted. Why does everything has to have a practical purpose?

Sort of. I wouldn't call it a lie but, as it's true that all modern applications (the only parts of the computer the user interacts with) depend on the operating system to work.

s/trail/trial/
s/know how an OS /know how an OS works /

Because it conveys the right message for the people hearing it. That's why MS used it -it's a very good definition for someone who doesn't program computers for a living. MS tried to derail the trail by dumbing down the tech details, which shouldn't have been done at the Court. This doesn't mean that hiding tech details is always wrong.

End users don't get any direct benefit from the OS- it's a tool for the developers, so users don't require any detail about it's inner working; they literally don't need to know how an OS in order to accomplish their goals when using the computer.

Users only interact with the shell, the package system and maybe the file system; and those do not strictly belong to the OS, but are just applications bundled with it. And those are precisely the parts described in TFA.

That definition is not intended to win trials here, nor to be used in any technical context. Their choice of words means that their target audience is not the stereotypical Slashdot crowd.

It implies that we can install this environment to our families, and still hope to use it ourselves. Some of us believe it's a good thing, that the people who think "the beige box is the hard drive" can use computers. But not many developers know how to make a computer that they can use; making software easy to use is much more difficult than most programmers realize.