Erm careful there. That's like saying because I can design and build a small car, that I'll be able to build and F1 car.
It might just be a matter of scaling things up, it's quite an overstatement to say that it was german technology that went to the moon. It was american technology based upon German technology with a significant portion of the design team being german.
On the note of this, I'd say that the space program is the engineering version of art. It does have some tangible benefits, but that's not the main reason we're doing it.
Like some people have said Art (Opera?) is perhaps what money is for, why can't the space program be considered in the same league? If there is a reason for human existance, I'd rather think it was to push boundries and explore rather than any of the other mainstream justifications for life.
But that's a belief so treat that as you will:-)
-- "Science is like sex. Sometimes something useful comes out, but that is not the reason we are doing it." -Richard Feynman
The figures I saw, said that they were doing it on a shoestring budget. It has cost $2.3 billion to date http://www.msnbc.msn.com/id/9685477/ and If I remember right nasa has twice this much per year(but nasa does MUCH more than manned space flight). Granted Chinese labour costs less, but I don't think it's fair to say nasa doesn't have the money.
I think another thing people forget is when it is working nasa is doing much more in orbit than putting people up there. When China is regularly lifting cargo up and maintaining and building the ISS as nasa has been doing then I think we can compare the two.
Until then China is playing catchup and good on them, the more people at the table the better! Hopefully they will do what we all want and lower the cost of access to space.
There'sa difference between watching sci-fi and reading sci-fi. I'd agree the sci-fi I'm watching has been done to death before, but not what I'm reading. I would agree most popular Azmov or Clarke has been done to death, but there's a LOT more sci fi out there than that. Ok Dune too.
What of OSC's concepts have been explored in depth? When I first read it a few years ago i found it new. (ok I've only read 3 of the ender series but...) Which feature films/Startrek cover the exploits of an invading alien race trying to use earth for it's drugs supplies trying to subvert their own government? (Mission Earth - L Ron Hubbard) Need I mention Ringworld?
Clearcase is the thing of gods and I curse CVS constantly as it doesn't do some of the things clearcase does. (or at least when someone else admins it and I just get to use it:-))
Now what you're saying isn't that it's possible to make a bug free system, but rather through the judicious use of baseball bats, you can encourage a relatively predictable and manageable set of bugs.
No that's not the point I'm making. I'm saying that it is possible to write any level of complexity of system at what equates to bug-free if that is a design goal.
Like a brick each component must be tollerant of flaws in the input and have sufficient capacity in its design that if it is overloaded it can cope. Similar philosophies on which there have been many books written apply.
Baseball bats and other methods such as legal recourse as discussed in the article are there to provide the motivation that PHBs and hack school developers would like to and currently do skip.
On the other hand they build new features on top of that stack that then have problems
Quite, but what I see happening in the industry is that these new functions get more stable and features get built on top of those that then initaly suffer bugs. etc.
hat in the end, buggy software, hacked together at the last second may be sufficient for certain needs. That the software may be "good enough" even if it's not high quality.
Quite and that's a lot of the software industry today, you might be fine with your ipod crashing every now and then, I might be able to suffer my simulator crashing occasionally. All I'm trying to say is that it doesn't have to be this way, it can be different if the desire is there to make it so.
I would argue that buildings are more fault tolerant because if they aren't people die
You know there's an old story going back to the development of the apple where the manager is trying to encourage the developers to speed up the boot time. The developers question if it's worth the effort. He then does the maths of 30 seconds * number of days in the year * number of years you would use that computer * number of people they beileve will buy this computer(assuming 30 seconds can be saved on the boot and that people start it once a day every day). The answer he comes out with says that this exercise will save about 3 user lifetimes.
How much time does the average user waste on buggy crashing software - it's not the same as the building falling down around you, but it does add up much faster in the software world than the building world
The physics of building construction is very well understood at this point.
Yes and no. They got the millenium bridge in London very badly wrong on the physics of construction:-) I'm not sure of the full story on this one, but I beleieve they were surprised as to something about the way the physics worked:-)
But that's besides the point, I believe we are now where ship builders were in the Tudor age. They had a set of proportions that if you built a ship to, then it generally worked (although not always). No-one could really blame them too much when it went wrong as they lacked the understanding of the fundamental principles. Centuries later we understand construction much better and have learned from our mistakes.
However the fact that it's comparatively new is no excuse. Here we make the rules, not nature. Construction required an understanding of material science, physics etc etc . Computer Engineering is under no such problems, we define the rules and the only reason we fall down is because we're running before we can walk. Here is the problem though, we don't learn from our problems and try to make the same mistake again because we say "Oh you can't write complex systems without bugs, its inevitable" or arguments such as you present that "it's impossible to make systems bug free above a certain complexity". This is the attitude similar to sticking fingers in your ears and saying "it's too hard". This might be acceptable in some fields, but what the article seems to say on one level is that they think it is no longer acceptable to keep falling
Indeed, to get cutting edge features and bug free-ness and security will take longer than just getting the cutting edge features. I would never argue that.
All I'm trying to say is that we could write a system of the complexity of your current desktop without any known bugs and with no known security flaws. The designer could also be sufficiently confident in it that if it did succome to attack then he could be confident that he had done everything that was good practice; in the same way a structural engineer is confident that even if the bridge did collapse in the typhoon that it did meet all the building regulations that he was supposed to. I am not saying we could develop it in the same timescale or to the same cost as current software.
As to your $5000 word. Well I run openoffice, so I don't pay $1 for my word processor. I would however pay $100 for a word processor with the current features of OpenOffice that NEVER lost my document. And if it did lose my document I could sue them for damage to my property. Face it, what else is there left to do in the word processor market except make it more stable. Oh MS tries to add stuff, but what features were added in the last release of Word that you use? I believe that the desktop applications as we know them now will advance on 2 fronts compatability/integretion and stability; the same applies from networking stacks to webcam software. The stuff that we accept as cutting edge today will be run of the mill tomorrow, so that stuff will HAVE to be stable/reliable/fault tollerant in order that the next new thing can crash willy nilly without putting the user off his computer.
That said I am very much in favour of regulations that say that the things that people depend on for revenue are subject to the same quality that we expect from any other product. If my camera stops taking photos after its 36th shot and I have to refit the battery, then it is not fit for purposes intended and I can at least recieve a refund. Why should software be different? As many people on the YRO section of slashdot are fond of saying, there is no need for one set of laws(/patents/copyright rules etc) for the real word of books and CDs and cars, and another for the world of bits, bytes and itunes. The rights of the user to his product and his life are the same regardless of the product that is sold.
Ok I think we're talking at cross purposes here. One point I'm trying to make is that it is possible to write an arbitrarily complex system that is fault free. This may have a time and a cost, but the notion that software is too complex to be bug free is false. It is possible to be bug free, but it will take time money and effort. The second point I'd make and I think you try to make too is that to write bug free systems takes more time and resources. At the moment we do not have systems of the complexity of desktop systems that are bug free for this reason.
However we do have most of the elements of a desktop os virtually bug free. e.g. networking stack, memory management, process management, HAL, etc all exist in certain OSes in a "bug free" state. (bug free as defined above as something that you can beat over the head with a baseball bat if any fault is found). So the major building block are there and remain there. With code re-use the foundations should only get more secure with time. I see no reason why in X years time we couldn't have all the things we expect in a desktop OS to be rock solid.
The third point I'm trying to make is that when the stability becomes a design goal (as would happen if it were a legal requirement) then this would further force effort onto making bus free systems as opposed to systems with lots of bells and whistles (which is where we seem to be now). Perhaps now we are in a marketing lead industry as opposed to a legally goverened industry.
As a final thought which occured to me earlier, a reason a building is more robust than your average system of software is that there is lots of redundancy in every part of the design. Not to say that my house doesn't have certain supporting walls that musn't be removed, but no individual brick being removed will cause the house to fall down. No single rotten beam will destroy the building. Maybe this is a design philosophy that the software world will move to as it matures over the comming decades.
Contrast this to the building industry then: Let's suppose I am an architect working for a company contracted to build a building. Let's suppose a car drives into it and a large part of the building falls down killing many people. Now the families of those injured and killed would probably sue the owners of the building, who would in turn sue the arcitects. Now it might in the end be determined to be an: * overall design flaw - system architects * failure to meet building regs - lack of standards/api compliance * A lack of thorough analysis by those throughout the design - lack of testing/unit design * Construction company not following the design - coders cocking up * Material flaws (such as weak concrete) - bugs in the compiler/os * a million other things
Given the rough analogies I've given to software design the software engineer is not that different to a construction process. Take a nuclear reactor, people talk about lines of code, but I imagine if you took the specification and implementation for a reactor as a whole it would be much much larger than many software projects.
The point I'm trying to make is that it is possible to engineer these things to be reliable if that is your goal. We do it in the construction industry all the time. Admitadly the software field moves faster, but perhaps it shouldn't in areas that matter.
Perhaps as software matures as a field of engineering things will stabalise, both out of a lack of new innovations (so the value add is that of robustness) and due to people relying on them more and more, and greater use of reusable small modules. Seriously, if each new building had to design it's own air-con system we'd be screwed, but how many memory management systems have I seen???
To tackle your point more directly, if the bug was traced to a flaw in the OS, then like the architect would sue the construction company for messing up, then the software engineer could sue the OS company for fowling up.
When I worked at nortel we had a contract with our OS supplier that they were allowed no bugs in their os. As in if we found a flaw in their OS they had to fix it within a certain time period or face damages. Likewise were we sued for loss of revenue if it was determined they were responsible they would bear a proportionate measure of the blame. It is possible to produce good software if you treat it as engineering as opposed to hacking. If you hack construction, you might build a log cabin, if you engineer construction, you may take much longer designing it (and learning your skill) but you can see what we can build with engineering. But then the millenium bridge in london shows us what happens when you hack that field:-)
Which begs the question, why are so many cops shooting people when other countries manage quite well without most police officers being armed. I know I get shocked when I see a policeman carrying a gun (and not at an airport). And this is living in London at the moment where if I believe what i am told then the number of armed officers has proportionatly (sp??) gone through the roof given recent events.
I hate to feed the troll, but: "I do this for free" is never an excuse for poor manners. It is fundamental to living in society that we behave well towards each other.
If a project attracts pissed off agressive people, or gives the impression that it does then the project deserves to suffer. It's like saying that it's fine to troll and be offensive on slashdot because no-one is paying you to post. It's Anti-Social behaviour and should be looked on in the manner it deserves.
Doesn't this mean that the speed of gravity would be related to gravity at that point? i.e. in the same way that the speed of light is observed to slow down near a gravity well (such as a black hole). Doesn't this therefore mean that the speed of gravity at a black hole would also tend to zero in the same way the speed of light would tend to zero?
Airbus' argument back is that Boeing receives illegal and hidden subsidies from the american government by the Military paying over the odds for military aircraft to subsidise the civilian wing of the operation (pun intended).
So both sides do have some just cause to cry foul. But isn't the whole concept of subsidies foul? I'll let someone else debate that one:-)
Really, last I heard more people buy the bulk of their things from Wallmart than from their local grocer. Isn't too many options a bad thing that as a customer of Linux I don't know who to buy.
Last I checked a few goliaths competing tended to advance further than lots of Davids each with the fixed overheads then repeating the same work.
That said, Windriver do some pretty nifty RTOS stuff with VxWorks, so I'm glad they're progressing with their Linux solution
Looking at the article they're planning to liscense this on a per devloper per year basis. One thing I don't get though is how this fits in with the GPL, surely the key thing Windriver offer is tweeks to the kernel to make it a good RTOS and associted BSPs for the various phones. But those would have to be GPLed as well. So what is there here that isn't GPLed and therefore why would someone pay for this? Or is it the tools, this CELF of which they speak?
I don't think ATI will loose sleep over it, and I will vote with my feet and not buy an ATI card in the future (well they are competitors for the company I work for, so that goes without saying, anyway...). However I assumed avid PC games were often Uber-Geeks who were normally(judging by slashdot) Linux Geeks. You thoughtless pleb will stick with the card that comes in his desktop that dell sold him. Your enthusiast who will upgrade his machine himself and buy the top of the line card probably knows enough to be the kind of person who experiments with Linux. Or at least would experiment if he could get it to work (but can't and blames linux for flaky drivers when he should be blaming ati).
If the above is accurate I don't know who their target audience is, unless they will release decent drivers "in good time". Which to be fair seems to have been their track record so far.
Dual boot? Without stable drivers under linux how do I have a dual boot desktop? So either linux is confined to my spare old machine or I can't run the latest hardware. Either way it makes it a LOT harder and more painful for me to run linux.
With you all the way there:-) Still this isn't my favorite way to do parallel processing - something like the approach http://www.celoxica.com/ use (with FPGAs and C-like parallel languages) is my favorite, but still not mature and going no-where near the desktop yet. Although one group has got linux synthesised into hardware which you have to admit is cool:-)
Seems like we have the worst of all worlds at the moment, if we could just get a hardware platform that was easy for the compler to map an inherantly parallel language onto and then re-train all the worlds programmers to use it:-)
multi-core processors may be a way to this, they may not, I'm just glad that we're finally on the route to parallelism.
That was always a weight loss idea of mine... First you need to implant a couple of discrete tubes into a major vein and artery (how you stop the body from forming clots in them when not in use though I don;t know). Then when you want to loose weight you wear this shirt that plugs into these tubes. The jacket burns the glucose and O2 and radiates the resulting heat keeping you warm at the same time.
If too many deposits build up then it's easier to buy a new jacket than replace an implant.
<silly voice> Welcome to the world of tomorrow! </silly voice>
The Short version: I agree with many of the points you make, but I think it's over simplified.
Let me take the main points as this could otherwise drag out...
"As I said, there are overheads associated with multiprocessing even in an ideal situation (which you almost never, if ever, have) so multi-core paralellism can never even be as good as a single core chip that goes twice as fast."
I can see where you're comming from, but I think you underestimate the cost that context swapping has. Let me define some terms: I would say that most algorithms can benefit from parallel processing I would say that most systems are built from many algorithms that can be handelled in parallel. With correct design, mindset amd tools software can be written to take advantage of this massive parallelism. We are much more limited by clock speed than by area in modern processors. Memory access in modern processors is the main bottleneck for many algorithms. Multi-threading in a single core makes better use of one memory because while one task is stalled on data from memory, the processors resources can be used for another thread that has its data sat in cache. I refer to a thread as a very ambiguous concept, it could be a whole chip, it could be an execution context on an individual core.
If you had as many cores as you had x tasks and all tasks required the same ammount of processing (very unrealistic) then there would be no task swaps. If you then put this same problem onto a prosessor that was x times faster but only had 1 core then it would be slower because of the task swapping. How slower would depend on how often it had to swap.
Inter process communication which you say is a problem is indeed a problem, but not for all algorithms on all architectures. Take a network processor, often there are dozens of processors but the architecture is designed for this so there is lots of communicarion between the cores; so interprocess communication is not an issue. As another example of inter-process communication take the transputer - that was even better as it had next to no cost for a context swap too.
Give me an example of a task an embedded device that is processor limited that couldn't be improved by more memory speed. I'll bet that this could therefore be helped by splitting the dataset up into multiple streams and running these on separate cores.
I really think all the problems you/we state are flaws in the current dominant architecture, not real limitations as I have worked with systems that have ways round them all. Cranking up the clock speed has already hit a hard limit, like it or not if we want more speed, we have to think parallel. This is not a cheat, most systems are already parallel, so why not make use of this. Why go to an effort to serialise a problem just to put it on a single thread processor that could be a 10 thread processor.
But yes it would be nice to have a 5Ghz machine on my desktop, but it's not going to happen any time soon. simply to keep cranking up the speed is a very simple solution to the problem, but that's hit a limit. The free lunch is over, you may want this to happen, but magic is for what people want, engineering and science deals with what is. I suggest a read of this: http://www.gotw.ca/publications/concurrency-ddj.ht m as it puts that argument far better than I could.
Multi-core may not be a fundamental advance, but you give me a single fundamental advance in computing since the 60s? hey the 4040 wasn't a significant advance, as all it did was combine the separate parts into a single chip which had years of precidence anyway, so that's not a significant advance; the microprocessor was not a significant advance by those rules. I think we can only judge what is a significant advance in retrospect and so far I'm seeing the mainstream thinking moving towards a more parallel one (which is what is happening) as being the f
Slashdot Mirror
Erm careful there. That's like saying because I can design and build a small car, that I'll be able to build and F1 car.
It might just be a matter of scaling things up, it's quite an overstatement to say that it was german technology that went to the moon. It was american technology based upon German technology with a significant portion of the design team being german.
But yes paperclip was important
On the note of this, I'd say that the space program is the engineering version of art. It does have some tangible benefits, but that's not the main reason we're doing it.
:-)
Like some people have said Art (Opera?) is perhaps what money is for, why can't the space program be considered in the same league? If there is a reason for human existance, I'd rather think it was to push boundries and explore rather than any of the other mainstream justifications for life.
But that's a belief so treat that as you will
--
"Science is like sex. Sometimes something useful comes out, but that is not the reason we are doing it." -Richard Feynman
The figures I saw, said that they were doing it on a shoestring budget. It has cost $2.3 billion to date http://www.msnbc.msn.com/id/9685477/ and If I remember right nasa has twice this much per year(but nasa does MUCH more than manned space flight).
Granted Chinese labour costs less, but I don't think it's fair to say nasa doesn't have the money.
I think another thing people forget is when it is working nasa is doing much more in orbit than putting people up there. When China is regularly lifting cargo up and maintaining and building the ISS as nasa has been doing then I think we can compare the two.
Until then China is playing catchup and good on them, the more people at the table the better! Hopefully they will do what we all want and lower the cost of access to space.
Am I the only one singing "You're not the boss of me now[..] and you're not do big"?
There'sa difference between watching sci-fi and reading sci-fi. I'd agree the sci-fi I'm watching has been done to death before, but not what I'm reading. I would agree most popular Azmov or Clarke has been done to death, but there's a LOT more sci fi out there than that. Ok Dune too.
What of OSC's concepts have been explored in depth? When I first read it a few years ago i found it new. (ok I've only read 3 of the ender series but...)
Which feature films/Startrek cover the exploits of an invading alien race trying to use earth for it's drugs supplies trying to subvert their own government? (Mission Earth - L Ron Hubbard)
Need I mention Ringworld?
I'll shut up now...
Can I stand up for the press here and modify the above to how sensational the tabloids are.
Not all newspapers are The Sun or News Of The World!
Clearcase is the thing of gods and I curse CVS constantly as it doesn't do some of the things clearcase does. (or at least when someone else admins it and I just get to use it :-))
What they've got a scroll bar that goes up to 11?
Now what you're saying isn't that it's possible to make a bug free system, but rather through the judicious use of baseball bats, you can encourage a relatively predictable and manageable set of bugs.
:-) I'm not sure of the full story on this one, but I beleieve they were surprised as to something about the way the physics worked :-)
No that's not the point I'm making. I'm saying that it is possible to write any level of complexity of system at what equates to bug-free if that is a design goal.
Like a brick each component must be tollerant of flaws in the input and have sufficient capacity in its design that if it is overloaded it can cope. Similar philosophies on which there have been many books written apply.
Baseball bats and other methods such as legal recourse as discussed in the article are there to provide the motivation that PHBs and hack school developers would like to and currently do skip.
On the other hand they build new features on top of that stack that then have problems
Quite, but what I see happening in the industry is that these new functions get more stable and features get built on top of those that then initaly suffer bugs. etc.
hat in the end, buggy software, hacked together at the last second may be sufficient for certain needs. That the software may be "good enough" even if it's not high quality.
Quite and that's a lot of the software industry today, you might be fine with your ipod crashing every now and then, I might be able to suffer my simulator crashing occasionally. All I'm trying to say is that it doesn't have to be this way, it can be different if the desire is there to make it so.
I would argue that buildings are more fault tolerant because if they aren't people die
You know there's an old story going back to the development of the apple where the manager is trying to encourage the developers to speed up the boot time. The developers question if it's worth the effort. He then does the maths of 30 seconds * number of days in the year * number of years you would use that computer * number of people they beileve will buy this computer(assuming 30 seconds can be saved on the boot and that people start it once a day every day). The answer he comes out with says that this exercise will save about 3 user lifetimes.
How much time does the average user waste on buggy crashing software - it's not the same as the building falling down around you, but it does add up much faster in the software world than the building world
The physics of building construction is very well understood at this point.
Yes and no. They got the millenium bridge in London very badly wrong on the physics of construction
But that's besides the point, I believe we are now where ship builders were in the Tudor age. They had a set of proportions that if you built a ship to, then it generally worked (although not always). No-one could really blame them too much when it went wrong as they lacked the understanding of the fundamental principles. Centuries later we understand construction much better and have learned from our mistakes.
However the fact that it's comparatively new is no excuse. Here we make the rules, not nature. Construction required an understanding of material science, physics etc etc . Computer Engineering is under no such problems, we define the rules and the only reason we fall down is because we're running before we can walk. Here is the problem though, we don't learn from our problems and try to make the same mistake again because we say "Oh you can't write complex systems without bugs, its inevitable" or arguments such as you present that "it's impossible to make systems bug free above a certain complexity". This is the attitude similar to sticking fingers in your ears and saying "it's too hard". This might be acceptable in some fields, but what the article seems to say on one level is that they think it is no longer acceptable to keep falling
Indeed, to get cutting edge features and bug free-ness and security will take longer than just getting the cutting edge features. I would never argue that.
All I'm trying to say is that we could write a system of the complexity of your current desktop without any known bugs and with no known security flaws. The designer could also be sufficiently confident in it that if it did succome to attack then he could be confident that he had done everything that was good practice; in the same way a structural engineer is confident that even if the bridge did collapse in the typhoon that it did meet all the building regulations that he was supposed to. I am not saying we could develop it in the same timescale or to the same cost as current software.
As to your $5000 word. Well I run openoffice, so I don't pay $1 for my word processor. I would however pay $100 for a word processor with the current features of OpenOffice that NEVER lost my document. And if it did lose my document I could sue them for damage to my property.
Face it, what else is there left to do in the word processor market except make it more stable. Oh MS tries to add stuff, but what features were added in the last release of Word that you use?
I believe that the desktop applications as we know them now will advance on 2 fronts compatability/integretion and stability; the same applies from networking stacks to webcam software. The stuff that we accept as cutting edge today will be run of the mill tomorrow, so that stuff will HAVE to be stable/reliable/fault tollerant in order that the next new thing can crash willy nilly without putting the user off his computer.
That said I am very much in favour of regulations that say that the things that people depend on for revenue are subject to the same quality that we expect from any other product. If my camera stops taking photos after its 36th shot and I have to refit the battery, then it is not fit for purposes intended and I can at least recieve a refund.
Why should software be different? As many people on the YRO section of slashdot are fond of saying, there is no need for one set of laws(/patents/copyright rules etc) for the real word of books and CDs and cars, and another for the world of bits, bytes and itunes. The rights of the user to his product and his life are the same regardless of the product that is sold.
Ooops sorry, went off on a bit of a rant there...
Ok I think we're talking at cross purposes here.
One point I'm trying to make is that it is possible to write an arbitrarily complex system that is fault free. This may have a time and a cost, but the notion that software is too complex to be bug free is false. It is possible to be bug free, but it will take time money and effort.
The second point I'd make and I think you try to make too is that to write bug free systems takes more time and resources. At the moment we do not have systems of the complexity of desktop systems that are bug free for this reason.
However we do have most of the elements of a desktop os virtually bug free. e.g. networking stack, memory management, process management, HAL, etc all exist in certain OSes in a "bug free" state. (bug free as defined above as something that you can beat over the head with a baseball bat if any fault is found). So the major building block are there and remain there. With code re-use the foundations should only get more secure with time. I see no reason why in X years time we couldn't have all the things we expect in a desktop OS to be rock solid.
The third point I'm trying to make is that when the stability becomes a design goal (as would happen if it were a legal requirement) then this would further force effort onto making bus free systems as opposed to systems with lots of bells and whistles (which is where we seem to be now).
Perhaps now we are in a marketing lead industry as opposed to a legally goverened industry.
As a final thought which occured to me earlier, a reason a building is more robust than your average system of software is that there is lots of redundancy in every part of the design. Not to say that my house doesn't have certain supporting walls that musn't be removed, but no individual brick being removed will cause the house to fall down. No single rotten beam will destroy the building.
Maybe this is a design philosophy that the software world will move to as it matures over the comming decades.
Contrast this to the building industry then:
:-)
Let's suppose I am an architect working for a company contracted to build a building.
Let's suppose a car drives into it and a large part of the building falls down killing many people.
Now the families of those injured and killed would probably sue the owners of the building, who would in turn sue the arcitects.
Now it might in the end be determined to be an:
* overall design flaw - system architects
* failure to meet building regs - lack of standards/api compliance
* A lack of thorough analysis by those throughout the design - lack of testing/unit design
* Construction company not following the design - coders cocking up
* Material flaws (such as weak concrete) - bugs in the compiler/os
* a million other things
Given the rough analogies I've given to software design the software engineer is not that different to a construction process. Take a nuclear reactor, people talk about lines of code, but I imagine if you took the specification and implementation for a reactor as a whole it would be much much larger than many software projects.
The point I'm trying to make is that it is possible to engineer these things to be reliable if that is your goal. We do it in the construction industry all the time. Admitadly the software field moves faster, but perhaps it shouldn't in areas that matter.
Perhaps as software matures as a field of engineering things will stabalise, both out of a lack of new innovations (so the value add is that of robustness) and due to people relying on them more and more, and greater use of reusable small modules. Seriously, if each new building had to design it's own air-con system we'd be screwed, but how many memory management systems have I seen???
To tackle your point more directly, if the bug was traced to a flaw in the OS, then like the architect would sue the construction company for messing up, then the software engineer could sue the OS company for fowling up.
When I worked at nortel we had a contract with our OS supplier that they were allowed no bugs in their os. As in if we found a flaw in their OS they had to fix it within a certain time period or face damages. Likewise were we sued for loss of revenue if it was determined they were responsible they would bear a proportionate measure of the blame.
It is possible to produce good software if you treat it as engineering as opposed to hacking.
If you hack construction, you might build a log cabin, if you engineer construction, you may take much longer designing it (and learning your skill) but you can see what we can build with engineering.
But then the millenium bridge in london shows us what happens when you hack that field
Which begs the question, why are so many cops shooting people when other countries manage quite well without most police officers being armed.
I know I get shocked when I see a policeman carrying a gun (and not at an airport). And this is living in London at the moment where if I believe what i am told then the number of armed officers has proportionatly (sp??) gone through the roof given recent events.
I hate to feed the troll, but:
"I do this for free" is never an excuse for poor manners. It is fundamental to living in society that we behave well towards each other.
If a project attracts pissed off agressive people, or gives the impression that it does then the project deserves to suffer.
It's like saying that it's fine to troll and be offensive on slashdot because no-one is paying you to post. It's Anti-Social behaviour and should be looked on in the manner it deserves.
Doesn't this mean that the speed of gravity would be related to gravity at that point? i.e. in the same way that the speed of light is observed to slow down near a gravity well (such as a black hole).
Doesn't this therefore mean that the speed of gravity at a black hole would also tend to zero in the same way the speed of light would tend to zero?
Or have I missed something fundamental here?
Airbus' argument back is that Boeing receives illegal and hidden subsidies from the american government by the Military paying over the odds for military aircraft to subsidise the civilian wing of the operation (pun intended).
:-)
So both sides do have some just cause to cry foul. But isn't the whole concept of subsidies foul? I'll let someone else debate that one
That was kind of my point, that you don't have to clone something to provide the features that it offers.
Would it be anymore of a OpenOffice clone than gmail was a Thunderbird clone?
Really, last I heard more people buy the bulk of their things from Wallmart than from their local grocer.
Isn't too many options a bad thing that as a customer of Linux I don't know who to buy.
Last I checked a few goliaths competing tended to advance further than lots of Davids each with the fixed overheads then repeating the same work.
That said, Windriver do some pretty nifty RTOS stuff with VxWorks, so I'm glad they're progressing with their Linux solution
Looking at the article they're planning to liscense this on a per devloper per year basis. One thing I don't get though is how this fits in with the GPL, surely the key thing Windriver offer is tweeks to the kernel to make it a good RTOS and associted BSPs for the various phones. But those would have to be GPLed as well.
So what is there here that isn't GPLed and therefore why would someone pay for this? Or is it the tools, this CELF of which they speak?
I don't think ATI will loose sleep over it, and I will vote with my feet and not buy an ATI card in the future (well they are competitors for the company I work for, so that goes without saying, anyway...). However I assumed avid PC games were often Uber-Geeks who were normally(judging by slashdot) Linux Geeks.
You thoughtless pleb will stick with the card that comes in his desktop that dell sold him.
Your enthusiast who will upgrade his machine himself and buy the top of the line card probably knows enough to be the kind of person who experiments with Linux. Or at least would experiment if he could get it to work (but can't and blames linux for flaky drivers when he should be blaming ati).
If the above is accurate I don't know who their target audience is, unless they will release decent drivers "in good time". Which to be fair seems to have been their track record so far.
Dual boot?
Without stable drivers under linux how do I have a dual boot desktop? So either linux is confined to my spare old machine or I can't run the latest hardware. Either way it makes it a LOT harder and more painful for me to run linux.
With you all the way there :-) :-)
:-)
Still this isn't my favorite way to do parallel processing - something like the approach
http://www.celoxica.com/
use (with FPGAs and C-like parallel languages) is my favorite, but still not mature and going no-where near the desktop yet. Although one group has got linux synthesised into hardware which you have to admit is cool
Seems like we have the worst of all worlds at the moment, if we could just get a hardware platform that was easy for the compler to map an inherantly parallel language onto and then re-train all the worlds programmers to use it
multi-core processors may be a way to this, they may not, I'm just glad that we're finally on the route to parallelism.
That was always a weight loss idea of mine...
First you need to implant a couple of discrete tubes into a major vein and artery (how you stop the body from forming clots in them when not in use though I don;t know).
Then when you want to loose weight you wear this shirt that plugs into these tubes. The jacket burns the glucose and O2 and radiates the resulting heat keeping you warm at the same time.
If too many deposits build up then it's easier to buy a new jacket than replace an implant.
<silly voice>
Welcome to the world of tomorrow!
</silly voice>
The Short version: I agree with many of the points you make, but I think it's over simplified.
Let me take the main points as this could otherwise drag out...
"As I said, there are overheads associated with multiprocessing even in an ideal situation (which you almost never, if ever, have) so multi-core paralellism can never even be as good as a single core chip that goes twice as fast."
I can see where you're comming from, but I think you underestimate the cost that context swapping has. Let me define some terms:
I would say that most algorithms can benefit from parallel processing
I would say that most systems are built from many algorithms that can be handelled in parallel.
With correct design, mindset amd tools software can be written to take advantage of this massive parallelism.
We are much more limited by clock speed than by area in modern processors.
Memory access in modern processors is the main bottleneck for many algorithms.
Multi-threading in a single core makes better use of one memory because while one task is stalled on data from memory, the processors resources can be used for another thread that has its data sat in cache.
I refer to a thread as a very ambiguous concept, it could be a whole chip, it could be an execution context on an individual core.
If you had as many cores as you had x tasks and all tasks required the same ammount of processing (very unrealistic) then there would be no task swaps. If you then put this same problem onto a prosessor that was x times faster but only had 1 core then it would be slower because of the task swapping. How slower would depend on how often it had to swap.
Inter process communication which you say is a problem is indeed a problem, but not for all algorithms on all architectures. Take a network processor, often there are dozens of processors but the architecture is designed for this so there is lots of communicarion between the cores; so interprocess communication is not an issue.
As another example of inter-process communication take the transputer - that was even better as it had next to no cost for a context swap too.
Give me an example of a task an embedded device that is processor limited that couldn't be improved by more memory speed. I'll bet that this could therefore be helped by splitting the dataset up into multiple streams and running these on separate cores.
I really think all the problems you/we state are flaws in the current dominant architecture, not real limitations as I have worked with systems that have ways round them all.
Cranking up the clock speed has already hit a hard limit, like it or not if we want more speed, we have to think parallel. This is not a cheat, most systems are already parallel, so why not make use of this. Why go to an effort to serialise a problem just to put it on a single thread processor that could be a 10 thread processor.
But yes it would be nice to have a 5Ghz machine on my desktop, but it's not going to happen any time soon. simply to keep cranking up the speed is a very simple solution to the problem, but that's hit a limit. The free lunch is over, you may want this to happen, but magic is for what people want, engineering and science deals with what is.
I suggest a read of this:
http://www.gotw.ca/publications/concurrency-ddj.ht m
as it puts that argument far better than I could.
Multi-core may not be a fundamental advance, but you give me a single fundamental advance in computing since the 60s?
hey the 4040 wasn't a significant advance, as all it did was combine the separate parts into a single chip which had years of precidence anyway, so that's not a significant advance; the microprocessor was not a significant advance by those rules.
I think we can only judge what is a significant advance in retrospect and so far I'm seeing the mainstream thinking moving towards a more parallel one (which is what is happening) as being the f