Indeed. And since the number of users often exceeds the number of applications used, the number of developers and the number of programmers, I would be tempted to "blame" the users in first place. No users implies no password f*ckups.
Isn't the main problem that you generally cannot and don't want to get rid of users? Even a concrete walled vault, gaurded by well designed and tested software and diligent people cannot protect its contents when a user has written down its access code on a post-it sticker. (Moreover, consequences can be serious when the users does not share his password, and simply dies - like the Swedish museum guy proved recently...)
No technology or procedures can gaurantee security, at best they can assist a user...
Re:waste == cost -- Yet, but...
on
Cradle to Cradle
·
· Score: 1
I agree with your line of thinking wrt. an ideal global open market democracy.
Unfortunately, your argument only holds when the things you use cost what they cost. That is, if you don't pay an unreasonably low price for (raw or fabricated) products comming from third world countries and if don't burn fossile fuels at the rate we currently are simply because they are "cheap".
Inefficiency is really a relative thing when "cost" is as unbalanced as it is currently defined by the global currency markets.
Let's just hope (for their sake) they get there in time. It took them five-ten years to get a stable Windows version, rid of all the DOS heritage.
Of course, fixing this Gopher bug shouldn't cost them more than a few days/weeks/months, but countless bugs&holes will remain until they get support from millions of volantary peer reviewers. (Which would surely reveal so plenty that people will no longer be able use their products for some time).
Currently, things are starting to shift, with Microsoft stubornly refusing to open up on any of their sources, or cooperating with any company they don't "own" (like Lernhout&Hauspie). Some governments (like china and germany) are tentatively moving the other direction together with some major companies.
My guess is that if Microsoft doesn't change course, sooner or later they will loose their monopoly. And without that - or even before they have actually lost it - some of that $40 billion (pfew, that IS a lot!) is going to vapourise on stock markets.
Afterall, MS is really just a giant marketing machine with a lot of money but little inherently inovative assets.
How about this: Consider a number of "transition stages" from completely closed to completely (LGPL or AL -like) free software.
1. Keep source and binaries to yourself and try make buck (hell, even use DMCA to keep competitors from your back). 2. Ship binaries and API to have give seconds parties and competitors access. Or have "strategic partners" look into your code and allow others to reverse-engineer your stuff. 3. Just release sources under whatever public license...
Obviously it is hard to go from stage 3 back to 1, so naturally stages work the other direction. Now when should you enter which stage? First, anyone should feel free to enter stage 3. This works well in case you are selling a SERVICE rather than a piece of SOFTWARE. Eg. users of an Office-type package generally don't want to change your software, rather use it, get support and maybe extend it (in which case the full API and sources are available).
This does not work in case of a library that contains an algorithm your worked on for a decade. End users don't mind about its service and fellow coders will just use it. That way you won't make a buck. So to sell your software you will need stage 1. This is the only way, since software (algorithm) patents simply don't work.
Now I'd suggest any coder should be able to make a buck, a descent amount of money, that is. No like M$, still charging hundreds for each copy of excel source even though millions have been sold and COSTS OF RESEARCH HAVE BEEN COVERERED a hundred times. So informally speaking, you would want be be able to FORCE a company to enter a new stage after so-and-so many months/years have past since software has been released. Or after so-and-so many licenses have been sold. Or after support for the product/version has ceased or the company went bankrupt. Or whatever other criteria.
Main idea: Any coder should WANT to open up any source code, sooner or later. (Some companies - like Microsoft - may not yet understand this is what they want...) Therefore, any rules that enforce hard deadlines should leave a lot of space for volantary actions. But isn't it rediculous that companies are still trying to make a buck out of 20 year old software, even though they give absolutely no support on it?
When I experienced first signs of RSI I changed to a Microsoft Natural Keyboard. Nothing changed. Then I adjusted desk, chair, and screen dimensions. Nothing changed. Things got worse. I spent approx. 500 euros on an excelent chair. Things stabilised, but the RSI remained.
So, I went to a specialist that got me back behind a keyboard through half a year of therapy. Later, he told me it wasn't him that cured me, but rather me changing my working attitude and generally adjusting my lifestyle and physical condition.
OK. This is the way it worked for me, but what's the morale more generally? RSIs are caused by (at least) four factors:
Workplace - Ergonomy of devices, chair, room temparature, etc. Stress - Workload, attitude to work and leasure, etc. Physical condition - Smoking, drinking, fast food, car driving, etc. Individual - Some people do 14-hour days for years without a problem, while others suffer from CTS within months. (Live isn't fair!)
In my humble opinion, people who claim that "some inventor" could improve one device or another with such excelence that all other factors no longer matter simply don't know what they are talking about. My opinion: When you don't have a problem, don't bother - just be alert and don't ignore pain. When your wrists, shoulders, elbows or back DO hurt, then ACT. Go see a specialist, adjust your lifestyle, improve ergonomics.
Be pro active and you will safe yourself loads of pain, trouble and money in the long term.
While developing software for a large research project, I did most of the coding on my homebrew Pentium and Alpha ev4 systems. In my experience there were little problems in porting the c++ software between the different architectures, other than some minor problems anyone will experience with different versions of GCC and EGS.
In some cases, this porting back and forward even benefitted in tracing and debuggin some of the obscure data structures I had used.
Therefore, I believe porting in general and specifically wrt. different hardware benefits design en code quality.
I totally agree. And I would like to add that when a particular polynomynal time solution is found for a problem thought to be non-deterministically, this does not mean all NP problems are in P.
For example, the problem of parsing context free grammars (or mildly context sensitive languages) in the most general form was long thought to be non deterministic. Nowadays we have context-free parsers that operate within O(n^2), while there are particular problems, like the LALR(1) grammars applicalble to most programming languages, that operate within linear time. Still, many NP problems remain.
The misconception here is that non-determinism is usually incorporated into an algorithm in terms of some "enigma" which *somehow* makes the non-deterministic choice the right way. Then, the non-determinism is completely localized within this black box. Next, this line of thinking assumes that when a (some) problem that is formulated in terms of this enigma turns out to be formulatable in P as well, that in this case we have implemented the enigma itself in P. Consequently, all algorithms using this enigma are though to be in P.
In reallity, the enigma is not touched at all. When an algorithm is improved, we generally think of a way to work around the hard parts. In case of NP to P, this means bypassing the enigma.
Therefore, a solution like the solution to the context-free parsing problem has no effect at all on other problems! Although the invention is a great achievement and although we are stunned afterwards by the simplicity of the solution we could not think of earlier, it usually has only limited effect on related problems. At best, an unrelated problem can be translated to the solved problem and then be otimized as well.
Therefore, it is unlikely that solving the translation from an NP problem into a P algorithm will change the way we think of computational complexities in a revolutionary way.
I agree that Win9x is near its end and we will see a consumer-leap to NT-based windows sooner or later. In fact, the split-up might come down to the one proposed by the government.
But there is also a chance that Win9x will evolve into something that can compete with the NT-cluster. (Incorporate Linux+Wine,...)
Meanwhile, the department responsible for consumer electronics might be able to build a settop that will push Win9x from the desktop market.
Though this is all quite unlikely, the good point in my story -- I think -- is competition. Each of the three companies has a motiv to be better than the others two.
This is not the case in the government deal. In fact, I think it is likely that MS-Applications and MS-Windows will still keep close relations as was the case between Intel and Microsoft.
Hmm. Isn't there a way to shrink Microsoft's market share without government intervention?
They tried the same thing in a limited sense in several cities in the Netherlands, a few years back. These ISP's - called "digitale stad" (digital cities) - were usually sponsored by private companies, such as IBM and SUN as well as the local authorities. (See: Amsterdam, Eindhoven, Leiden, Groningen, etc)
Huge amounts subsidies (tax money) went into these so-called non-profit organizations blocking independant commercial initiatives. Back then, the monopolitized phone company earned lot's of money, as will the one in Hamburg. Meanwhile, Hamburgers will have no alternative, since THERE SHALL BE ONLY ONE.
In the Netherlands phone bills are slighly lower due to privatization (and new legislation with respect to telecommunications). Only recently, when legislation allowed ISP's to get a percentage of the customer's phone bill, commercial ISPs (such as: Zon, Wanadoo and Het Net) started to provide their services for free. If it would not have been for the digital cities, these services would have been provided by a free market much earlier...
Not at all true... self modifying code is still around not only on JIT compilers but in interpreted languages and even device drivers (Or how do you think some device drivers adjust in real time to hardware changes?)
I guess you're right, though I'm not sure whether we should consider things like function-vectors as self modifying code. These programming structures have relatively well-behaved formal counterparts (such as lamda calculus). Are more dangerous constructs used in practice too?
BTW. What happens when two threads executing on two different processors try to optimize the same piece of code? Without proper synchronisation mechanisms (such as write-through or cache snoops) this is very dangerous. Work-arounds, suche as semaphore will most probably cause a performace penalty.
Also, how to cope with asymetric multiprocessing? This obviously raises problems for binary incompatible processors using the same memory. But it will also lead to at least inefficiency when two processors ARE binary compatible but need different optimizations...
It really does not matter whether this preprocessing / VM translation is done in software by a very fast RISC like processor or in microcode, as in a Pentium-like architecture. Technically I do not see a fundamental problem here.
There is a practical BONUS, though: since the interpretor is not in the actual silicon, you don't need to worry about buying a chip that possibly has lots of small bugs that need program patches and workarounds for every single program you bought!
Of course JIT takes some time to start up. But when a program is started next time, a smart OS (environment, etc. what you call this) can aways use a copy of a previous run.
This improves time efficiency at the cost of space efficieny. Wrt. effectiveness: the original byte code (half-product) is "processor-independent".
This leave much more space for speed improvent at the hardware level.
I believe Andy has a good point in arguing that there's no fundamental reason for manually written assembly being better than automatically self-optimizing stuff. I also believe that manually written assembly will ultimately become obsolete.
Nevertheless I'd like to point out that JIT is based a somewhat dangerous technique: a program that alters (its own) code. I believe this technique was used in the eighties to scare off hackers by making code incomprehensible and hard to disassemble until the program was actually running. Also (even on a good old 6502 processor) it's possible to make some speed improvents peeking and poking into the code you're actually executing.
When compilers for Microcomputers got faster and most processor architectures (known as Harvard architecture, I believe) explicitly require a division of RW and RO memory segments, self-modifying code was abandoned. Hacking into your own code is generally conceived as bad-programming-practice.
I was wondering wheter JIT techniques also require very intelligent (and thus "heavy") disassemblers? One might also expect that developing a JIT compiler is a lot harder than doing a conventional one (without peep-hole optimization). Does anyone have experience in these subjects?
Slashdot Mirror
> I guess you could add your users to the (concrete) mix too.
;-)
Good point! Let's get a patent on this business model.
Indeed. And since the number of users often exceeds the number of applications used, the number of developers and the number of programmers, I would be tempted to "blame" the users in first place. No users implies no password f*ckups.
Isn't the main problem that you generally cannot and don't want to get rid of users? Even a concrete walled vault, gaurded by well designed and tested software and diligent people cannot protect its contents when a user has written down its access code on a post-it sticker. (Moreover, consequences can be serious when the users does not share his password, and simply dies - like the Swedish museum guy proved recently...)
No technology or procedures can gaurantee security, at best they can assist a user...
I agree with your line of thinking wrt. an ideal global open market democracy.
Unfortunately, your argument only holds when the things you use cost what they cost. That is, if you don't pay an unreasonably low price for (raw or fabricated) products comming from third world countries and if don't burn fossile fuels at the rate we currently are simply because they are "cheap".
Inefficiency is really a relative thing when "cost" is as unbalanced as it is currently defined by the global currency markets.
Good point.
Let's just hope (for their sake) they get there in time. It took them five-ten years to get a stable Windows version, rid of all the DOS heritage.
Of course, fixing this Gopher bug shouldn't cost them more than a few days/weeks/months, but countless bugs&holes will remain until they get support from millions of volantary peer reviewers. (Which would surely reveal so plenty that people will no longer be able use their products for some time).
Currently, things are starting to shift, with Microsoft stubornly refusing to open up on any of their sources, or cooperating with any company they don't "own" (like Lernhout&Hauspie). Some governments (like china and germany) are tentatively moving the other direction together with some major companies.
My guess is that if Microsoft doesn't change course, sooner or later they will loose their monopoly. And without that - or even before they have actually lost it - some of that $40 billion (pfew, that IS a lot!) is going to vapourise on stock markets.
Afterall, MS is really just a giant marketing machine with a lot of money but little inherently inovative assets.
Contrast this with the closed source free-as-in-shit Winbloze ME95NT, which nearly brought my life to its knees.
;-)
Hmm. ' Guess free shit has never been more expesive
How about this: Consider a number of "transition stages" from completely closed to completely (LGPL or AL -like) free software.
1. Keep source and binaries to yourself and try make buck (hell, even use DMCA to keep competitors from your back).
2. Ship binaries and API to have give seconds parties and competitors access. Or have "strategic partners" look into your code and allow others to reverse-engineer your stuff.
3. Just release sources under whatever public license...
Obviously it is hard to go from stage 3 back to 1, so naturally stages work the other direction.
Now when should you enter which stage? First, anyone should feel free to enter stage 3. This works well in case you are selling a SERVICE rather than a piece of SOFTWARE. Eg. users of an Office-type package generally don't want to change your software, rather use it, get support and maybe extend it (in which case the full API and sources are available).
This does not work in case of a library that contains an algorithm your worked on for a decade. End users don't mind about its service and fellow coders will just use it. That way you won't make a buck. So to sell your software you will need stage 1. This is the only way, since software (algorithm) patents simply don't work.
Now I'd suggest any coder should be able to make a buck, a descent amount of money, that is. No like M$, still charging hundreds for each copy of excel source even though millions have been sold and COSTS OF RESEARCH HAVE BEEN COVERERED a hundred times.
So informally speaking, you would want be be able to FORCE a company to enter a new stage after so-and-so many months/years have past since software has been released. Or after so-and-so many licenses have been sold. Or after support for the product/version has ceased or the company went bankrupt. Or whatever other criteria.
Main idea: Any coder should WANT to open up any source code, sooner or later. (Some companies - like Microsoft - may not yet understand this is what they want...) Therefore, any rules that enforce hard deadlines should leave a lot of space for volantary actions. But isn't it rediculous that companies are still trying to make a buck out of 20 year old software, even though they give absolutely no support on it?
When I experienced first signs of RSI I changed to a Microsoft Natural Keyboard. Nothing changed. Then I adjusted desk, chair, and screen dimensions. Nothing changed. Things got worse. I spent approx. 500 euros on an excelent chair. Things stabilised, but the RSI remained.
So, I went to a specialist that got me back behind a keyboard through half a year of therapy. Later, he told me it wasn't him that cured me, but rather me changing my working attitude and generally adjusting my lifestyle and physical condition.
OK. This is the way it worked for me, but what's the morale more generally? RSIs are caused by (at least) four factors:
Workplace - Ergonomy of devices, chair, room temparature, etc.
Stress - Workload, attitude to work and leasure, etc.
Physical condition - Smoking, drinking, fast food, car driving, etc.
Individual - Some people do 14-hour days for years without a problem, while others suffer from CTS within months. (Live isn't fair!)
In my humble opinion, people who claim that "some inventor" could improve one device or another with such excelence that all other factors no longer matter simply don't know what they are talking about. My opinion: When you don't have a problem, don't bother - just be alert and don't ignore pain. When your wrists, shoulders, elbows or back DO hurt, then ACT. Go see a specialist, adjust your lifestyle, improve ergonomics.
Be pro active and you will safe yourself loads of pain, trouble and money in the long term.
I completely agree.
While developing software for a large research project, I did most of the coding on my homebrew Pentium and Alpha ev4 systems. In my experience there were little problems in porting the c++ software between the different architectures, other than some minor problems anyone will experience with different versions of GCC and EGS.
In some cases, this porting back and forward even benefitted in tracing and debuggin some of the obscure data structures I had used.
Therefore, I believe porting in general and specifically wrt. different hardware benefits design en code quality.
Go Alpha GO!
I totally agree. And I would like to add that when a particular polynomynal time solution is found for a problem thought to be non-deterministically, this does not mean all NP problems are in P.
For example, the problem of parsing context free grammars (or mildly context sensitive languages) in the most general form was long thought to be non deterministic. Nowadays we have context-free parsers that operate within O(n^2), while there are particular problems, like the LALR(1) grammars applicalble to most programming languages, that operate within linear time. Still, many NP problems remain.
The misconception here is that non-determinism is usually incorporated into an algorithm in terms of some "enigma" which *somehow* makes the non-deterministic choice the right way. Then, the non-determinism is completely localized within this black box. Next, this line of thinking assumes that when a (some) problem that is formulated in terms of this enigma turns out to be formulatable in P as well, that in this case we have implemented the enigma itself in P. Consequently, all algorithms using this enigma are though to be in P.
In reallity, the enigma is not touched at all. When an algorithm is improved, we generally think of a way to work around the hard parts. In case of NP to P, this means bypassing the enigma.
Therefore, a solution like the solution to the context-free parsing problem has no effect at all on other problems! Although the invention is a great achievement and although we are stunned afterwards by the simplicity of the solution we could not think of earlier, it usually has only limited effect on related problems. At best, an unrelated problem can be translated to the solved problem and then be otimized as well.
Therefore, it is unlikely that solving the translation from an NP problem into a P algorithm will change the way we think of computational complexities in a revolutionary way.
I agree that Win9x is near its end and we will see a consumer-leap to NT-based windows sooner or later. In fact, the split-up might come down to the one proposed by the government.
...)
But there is also a chance that Win9x will evolve into something that can compete with the NT-cluster. (Incorporate Linux+Wine,
Meanwhile, the department responsible for consumer electronics might be able to build a settop that will push Win9x from the desktop market.
Though this is all quite unlikely, the good point in my story -- I think -- is competition. Each of the three companies has a motiv to be better than the others two.
This is not the case in the government deal. In fact, I think it is likely that MS-Applications and MS-Windows will still keep close relations as was the case between Intel and Microsoft.
Hmm. Isn't there a way to shrink Microsoft's market share without government intervention?
Why don't they want to split it up into several vertical lines: NT+development tools, 98+Office+EI, CE+extra's?
Though this would certainly endanger Windows 2000 development, it might just benefit a bit of ``company-internal'' competition...
Thoughts, anyone?
They tried the same thing in a limited sense in several cities in the Netherlands, a few years back. These ISP's - called "digitale stad" (digital cities) - were usually sponsored by private companies, such as IBM and SUN as well as the local authorities. (See: Amsterdam, Eindhoven, Leiden, Groningen, etc)
Huge amounts subsidies (tax money) went into these so-called non-profit organizations blocking independant commercial initiatives. Back then, the monopolitized phone company earned lot's of money, as will the one in Hamburg. Meanwhile, Hamburgers will have no alternative, since THERE SHALL BE ONLY ONE.
In the Netherlands phone bills are slighly lower due to privatization (and new legislation with respect to telecommunications). Only recently, when legislation allowed ISP's to get a percentage of the customer's phone bill, commercial ISPs (such as: Zon, Wanadoo and Het Net) started to provide their services for free. If it would not have been for the digital cities, these services would have been provided by a free market much earlier...
Tune
-- The More You Drink, The W.C.
Not at all true... self modifying code is still around not only on JIT compilers but in interpreted languages and even device drivers (Or how do you think some device drivers adjust in real time to hardware changes?)
I guess you're right, though I'm not sure whether we should consider things like function-vectors as self modifying code. These programming structures have relatively well-behaved formal counterparts (such as lamda calculus). Are more dangerous constructs used in practice too?
BTW. What happens when two threads executing on two different processors try to optimize the same piece of code? Without proper synchronisation mechanisms (such as write-through or cache snoops) this is very dangerous. Work-arounds, suche as semaphore will most probably cause a performace penalty.
Also, how to cope with asymetric multiprocessing? This obviously raises problems for binary incompatible processors using the same memory. But it will also lead to at least inefficiency when two processors ARE binary compatible but need different optimizations...
It really does not matter whether this preprocessing / VM translation is done in software by a very fast RISC like processor or in microcode, as in a Pentium-like architecture. Technically I do not see a fundamental problem here.
There is a practical BONUS, though: since the interpretor is not in the actual silicon, you don't need to worry about buying a chip that possibly has lots of small bugs that need program patches and workarounds for every single program you bought!
Of course JIT takes some time to start up. But when a program is started next time, a smart OS (environment, etc. what you call this) can aways use a copy of a previous run.
This improves time efficiency at the cost of space efficieny. Wrt. effectiveness: the original byte code (half-product) is "processor-independent".
This leave much more space for speed improvent at the hardware level.
I believe Andy has a good point in arguing that there's no fundamental reason for manually written assembly being better than automatically self-optimizing stuff. I also believe that manually written assembly will ultimately become obsolete.
Nevertheless I'd like to point out that JIT is based a somewhat dangerous technique: a program that alters (its own) code. I believe this technique was used in the eighties to scare off hackers by making code incomprehensible and hard to disassemble until the program was actually running. Also (even on a good old 6502 processor) it's possible to make some speed improvents peeking and poking into the code you're actually executing.
When compilers for Microcomputers got faster and most processor architectures (known as Harvard architecture, I believe) explicitly require a division of RW and RO memory segments, self-modifying code was abandoned. Hacking into your own code is generally conceived as bad-programming-practice.
I was wondering wheter JIT techniques also require very intelligent (and thus "heavy") disassemblers? One might also expect that developing a JIT compiler is a lot harder than doing a conventional one (without peep-hole optimization). Does anyone have experience in these subjects?