When this happens, brides develop "super strength" a bit like the incredible hulk and destroy every object (including humans) within a 3 mile radius. Bring a backup camera!
It is impossible to assess someone's level of smartness without first understanding what they are trying to acheive.
But maybe you're right. Perhaps during the day I should go along with the half-assed ways of modern software and take my specs underground, to keep them from being implemented by the wrong hackers. Our day will come.
Even within apps like word processors, the slow parts are inherantly optimisable via parallelism. For example, rendering the screen display is certainly parallelisable (eg word-wrap is an independent problem for each paragraph). The "behind-the-scenes" slowness of many apps is due to dynamic linking, which is also parallelisable.
The problem is that none of the frameworks for parallel programming are used by apps writers, and none of the apps writers' frameworks address basic efficiency considerations, let alone parallelism.
Maybe embarissingly parallel (and relatively simple) cases like sound and grpahics will drive the required software frameworks, which can then be applied more widely.
The question we really should be asking is, what is the best abstraction of parallel hardware: it should apply to as much actual hardware as possible, but complicate software development as little as possible.
All you need to know is that there are some people in this world called compiler weeinies. They had over-protective mothers and spend their lives looking for the same kind of protection in the adult world. They worship compilers because compilers protect them from the scary realities of computer architecture and keep them nice and safe in the world of high-level languages.
Compiler weenies believe, above all else, that a good compiler can always do a better job than any human at optimisation. They are in denial of the following facts:
- Languages usually do not specify important info that may be used for optimisation, eg typical values of inputs
- Algorithm cannot be separated from architecture. A vector machine might do DFTs faster than FFTs. No compiler can turn FFT into DFT.
How can having a document to hand actively do anything? It's made of paper! Paper doesn't hinder you unless you slip on it, or put a big pile of it in the way of something.
Seriously though, if you're famliar with the sources to a library or OS then you already know what the docs say (or should say) and can go straight to the code. But if you are working with something new it is much quicker (I mean orders of magnitude) to go with the spec and then deal with the discrepancies as they arise than to try and deduce everything about how to use it from the code.
Naturally, when issues do arise, you should pass a detailed bug description back to the vendor/author with an explaination of why the lib doesn't match the spec. To do otherwise is irresponsible.
Tell me, are you the sort of coder who quietly hacks around issues so you can go home having appeared to have had a productive day? I spend too much of my time tidying up after people like you.
...the behaviour differs from the spec, it doesn't matter why the spec is wrong, just that it is. Red pen it and move on.
Maybe the code is wrong. Ever heard of bugs?
In the absence of specs, bugs are indistinguishable from features. Then people depend on them which is why so many utilities have flags for "enable fix for bug". Enabling the fix by default would break all the people who used the source code as a spec.
I shudder to think that Linus never wrote any specifications for Linux. Did he just open up a compiler and start typing?
Yes, but only after spending years studying the source code for various existing UNIX systems. He learned how to write a UNIX-style OS this way. In a sense those sources were his specs. He no more knows how UNIX actually got designed than a tea leaf knows the history of the east india company.
I can't even imagine he'd lower himself to use a compiler that was developed around (and hence tainted by) those damn language specs.
GCC is filled with hacks for compiling Linux and other programs. Each time it was eg a 5-line change in GCC vs a 10-line change in the program itself. The shorter change generally wins and now "man gcc" takes 24 seconds CPU time on a 2GHz Pentium 3. (it's big enough, so presumably not accurate, according to Linus).
How did he develop drivers to interact with the hardware without any specifications?
They reverse engineer Windows drivers. There's zero chance of a Linux driver being faster or more reliable or performing better, because instead of determining how the hardware works and then how to drive that hardware, they simply take the driver piecemeal (retyping the code so it can be GPL'd).
Did he just guess at what they needed, shifting bits around one at a time until the network card responded?
That's what I would expect to happen if there wasn't a precident whose design could be borrowed. Right now I can't think of any examples of drivers (or any software) that have been written that way and been successfully finished. By Linus' logic that means there aren't any, nor will there ever be.
Linus has a skewed view of the software process because Linux basically has no new designs in it. All the "high level" (or as Linus would say, "theoretical") work behind that OS had already been done by earlier OS designers, most notibly the designers of various Unices. All Linus et al have done is to create new source code to implement these old designs.
When you are actually designing new stuff (instead of re-typing established algorithms) you have to do a lot of thinking about how it will work. If it's big, then you will spend time and have multiple people involved. The best way to remember stuff over that time, and to allow people to understand each other is via certain documents. Code is slow to write and is easily misunderstood (as a way of communicating design intent).
Of course up-front designs are usually wrong, but they're still better than nothing (in the absense of an overwhelming precident such as UNIX). Imagine if make had been designed first, for example.
I think if you are going to write something similar to something that's been written before, then you can just jump in and start coding. But please, Linus, don't pretend your method is right for large new designs, or that you even have any knowledge of that area of software.
PS anyone noticed how in KDE the backdrop goes monochrome at the log-out window, only to flash back to colour just before shutting down? Just like Windows? Maybe sticking too closely to established designs duplicates established problems...
Oh yeah, you configured a RAID array and now you are the expert in safety-critical engineering. Is there any field of knowledge you can't absract your IT skills onto from the safety of the machine room?
In which case Chicago's trade mark protection will lapse and there will be no way to stop anyone distributing an incorrect (eg out of date) map as though it were official. Planning to travel in Chicago any time soon? Better be careful you have the right map!
Yes, because the emporor pwned the galaxy. You'd know how Yoda feels if you've ever found yourself suddenly accountable to a new boss who thinks you suck wihout ever being consulted. Resume time.
In a closed PC, this device will basically rely on the power supply's fan to circulate air around the heatsink. But if you were to run your PC with the case open (as open as possible) there should be sufficient free-air cooling.
You should keep your room cool (which you should do anyway when gaming because warmth will make you soperific and slow your reactions). You may also want to use a mosquito net or other gauze-like sheild to stop dust accumulating on your hardware.
Actually, I don't think the average person has evar known how their tech works. Before the age of reason, technology evolved in a Darwinian fashion with new ideas appearing randomly and being discarded most of the time unless they solved a very direct and strong need. People no more knew how their tech worked than knew how their bodies worked.
At the advent of rationalism, and during the industrial revolution that followed, only the elite classes (aristocracy) were involved in creating the new tech (according to the newly invented principles of science). For others it was a lifestyle change imposed on them, they didn't know why and they probably didn't like it (working hours shot up).
The industrial revolution led to the concept of mass production, in which the produce of tech became widely available; average people became consumers (as opposed to producers). A consumer no more knows how his keyfob lights up than his ancestor knew why his scythe should be curved.
Computers have brought a certain level of domain-specific knowledge into sort-of fashion, but many resisted all the way through, and it should be no surprise that the younger generation is doing the same because it's human nature.
Innovators will always be a despised minority, and it is only they who truly understand any kind of tech.
The problem is, are we safe as a race that has learned to depend on tech but continues to reject understanding it the same way we reject genetic mutants?
"difficult is beautiful and better than easy or correct"
I don't think the problem is that Linux dudes choose not to do things correctly. The problem is that many of them think there is such a thing as correct - and in attempting to do the mythical correct thing, usually end up on planet difficult rather than planet easy.
Slashdot Mirror
That would be US Government, Russian government and private enterprise (Bert Rutan's company). So that would make China the fourth.
But using effect as a noun effects a different meaning. Or maybe it just affects the original meaning. I dunno...
When this happens, brides develop "super strength" a bit like the incredible hulk and destroy every object (including humans) within a 3 mile radius. Bring a backup camera!
Dinosours are huge invincible green monsters. The monster mammals must have been brown or purple or something
But maybe you're right. Perhaps during the day I should go along with the half-assed ways of modern software and take my specs underground, to keep them from being implemented by the wrong hackers. Our day will come.
Even within apps like word processors, the slow parts are inherantly optimisable via parallelism. For example, rendering the screen display is certainly parallelisable (eg word-wrap is an independent problem for each paragraph). The "behind-the-scenes" slowness of many apps is due to dynamic linking, which is also parallelisable.
The problem is that none of the frameworks for parallel programming are used by apps writers, and none of the apps writers' frameworks address basic efficiency considerations, let alone parallelism.
Maybe embarissingly parallel (and relatively simple) cases like sound and grpahics will drive the required software frameworks, which can then be applied more widely.
The question we really should be asking is, what is the best abstraction of parallel hardware: it should apply to as much actual hardware as possible, but complicate software development as little as possible.
All you need to know is that there are some people in this world called compiler weeinies. They had over-protective mothers and spend their lives looking for the same kind of protection in the adult world. They worship compilers because compilers protect them from the scary realities of computer architecture and keep them nice and safe in the world of high-level languages.
Compiler weenies believe, above all else, that a good compiler can always do a better job than any human at optimisation. They are in denial of the following facts:
- Languages usually do not specify important info that may be used for optimisation, eg typical values of inputs
- Algorithm cannot be separated from architecture. A vector machine might do DFTs faster than FFTs. No compiler can turn FFT into DFT.
That doesn't even remotely follow.
OTOH if you ignore a spec that's available, you're betting it won't draw your attention to a mistake in your implementation.
Seriously though, if you're famliar with the sources to a library or OS then you already know what the docs say (or should say) and can go straight to the code. But if you are working with something new it is much quicker (I mean orders of magnitude) to go with the spec and then deal with the discrepancies as they arise than to try and deduce everything about how to use it from the code.
Naturally, when issues do arise, you should pass a detailed bug description back to the vendor/author with an explaination of why the lib doesn't match the spec. To do otherwise is irresponsible.
Tell me, are you the sort of coder who quietly hacks around issues so you can go home having appeared to have had a productive day? I spend too much of my time tidying up after people like you.
Maybe the code is wrong. Ever heard of bugs?
In the absence of specs, bugs are indistinguishable from features. Then people depend on them which is why so many utilities have flags for "enable fix for bug". Enabling the fix by default would break all the people who used the source code as a spec.
Yes, but only after spending years studying the source code for various existing UNIX systems. He learned how to write a UNIX-style OS this way. In a sense those sources were his specs. He no more knows how UNIX actually got designed than a tea leaf knows the history of the east india company.
I can't even imagine he'd lower himself to use a compiler that was developed around (and hence tainted by) those damn language specs.
GCC is filled with hacks for compiling Linux and other programs. Each time it was eg a 5-line change in GCC vs a 10-line change in the program itself. The shorter change generally wins and now "man gcc" takes 24 seconds CPU time on a 2GHz Pentium 3. (it's big enough, so presumably not accurate, according to Linus).
How did he develop drivers to interact with the hardware without any specifications?
They reverse engineer Windows drivers. There's zero chance of a Linux driver being faster or more reliable or performing better, because instead of determining how the hardware works and then how to drive that hardware, they simply take the driver piecemeal (retyping the code so it can be GPL'd).
Did he just guess at what they needed, shifting bits around one at a time until the network card responded?
That's what I would expect to happen if there wasn't a precident whose design could be borrowed. Right now I can't think of any examples of drivers (or any software) that have been written that way and been successfully finished. By Linus' logic that means there aren't any, nor will there ever be.
When you are actually designing new stuff (instead of re-typing established algorithms) you have to do a lot of thinking about how it will work. If it's big, then you will spend time and have multiple people involved. The best way to remember stuff over that time, and to allow people to understand each other is via certain documents. Code is slow to write and is easily misunderstood (as a way of communicating design intent).
Of course up-front designs are usually wrong, but they're still better than nothing (in the absense of an overwhelming precident such as UNIX). Imagine if make had been designed first, for example.
I think if you are going to write something similar to something that's been written before, then you can just jump in and start coding. But please, Linus, don't pretend your method is right for large new designs, or that you even have any knowledge of that area of software.
PS anyone noticed how in KDE the backdrop goes monochrome at the log-out window, only to flash back to colour just before shutting down? Just like Windows? Maybe sticking too closely to established designs duplicates established problems...
Oh yeah, you configured a RAID array and now you are the expert in safety-critical engineering. Is there any field of knowledge you can't absract your IT skills onto from the safety of the machine room?
In which case Chicago's trade mark protection will lapse and there will be no way to stop anyone distributing an incorrect (eg out of date) map as though it were official. Planning to travel in Chicago any time soon? Better be careful you have the right map!
Yes, because the emporor pwned the galaxy. You'd know how Yoda feels if you've ever found yourself suddenly accountable to a new boss who thinks you suck wihout ever being consulted. Resume time.
You should keep your room cool (which you should do anyway when gaming because warmth will make you soperific and slow your reactions). You may also want to use a mosquito net or other gauze-like sheild to stop dust accumulating on your hardware.
At the advent of rationalism, and during the industrial revolution that followed, only the elite classes (aristocracy) were involved in creating the new tech (according to the newly invented principles of science). For others it was a lifestyle change imposed on them, they didn't know why and they probably didn't like it (working hours shot up).
The industrial revolution led to the concept of mass production, in which the produce of tech became widely available; average people became consumers (as opposed to producers). A consumer no more knows how his keyfob lights up than his ancestor knew why his scythe should be curved.
Computers have brought a certain level of domain-specific knowledge into sort-of fashion, but many resisted all the way through, and it should be no surprise that the younger generation is doing the same because it's human nature.
Innovators will always be a despised minority, and it is only they who truly understand any kind of tech.
The problem is, are we safe as a race that has learned to depend on tech but continues to reject understanding it the same way we reject genetic mutants?
Uhhh, I think you just advocated censorship.
I agree. Good call, sir.
Amen.
How much of the "real world" software work that you do actually works at all?
Vishnu wants you to keep semantic quibbling in its proper place.
...domain whoring!
I don't think the problem is that Linux dudes choose not to do things correctly. The problem is that many of them think there is such a thing as correct - and in attempting to do the mythical correct thing, usually end up on planet difficult rather than planet easy.
He would be standing in the river.