If it's open source, it doesn't matter who wrote it, anyone can copy it.
The people who could most benefit from this situation are the CD-ROM manufacturers, who could spend their idle time burning popular open source software and passing it to the local software merchants. If they had to compete, they could sell at a loss, as long as they didn't go below the losses they'd take from having idle factories.
The key objection to open source as a base for a profitable business is not that nobody would pay for the service of delivery, but that people who don't actually produce any software will have a competitive advantage over those who do. If hypothetical company Maroon Hat does everything Red Hat does, but doesn't spend money on any software developers, Maroon Hat has the same profitability with smaller expenses.
I think profitable open source development should be viewed as more of a busking model than any sort of traditional "give me your money, or you don't get what I'm selling" model. If it were convenient to do so (say, with a web-based micropayment system), I bet people would be more than happy to send out a few bucks here and there to the authors of their favorite free software.
"1...not a JIT system but a dynamically optimizing compiler" a slow start is a big problem (which is why they are emphasizing long-term server programs), but that's not the main issue. There's no reason that profile-based optimization can't be applied to C programs. That there's an experimental JIT (yes, it's still a JIT) that's ahead of the C compilers in common use is no reason to claim that the JIT strategy is better.
"2...as long as the results of the operation don't change" Which means that if the representation is different in a meaningful way they have to check whether the results of the operation change, reducing the efficiency, which was my point.
"3...on all but the most simple applications" But I rarely do anything but the most simple applications. I allocate an array, then I free an array. I do this for hashes, trees, stacks, queues, and pretty much any data structure I use. Only when I am being extremely lazy will I allocate and free objects recursively. Modern CPUs with slow main memory and fast cache like it when you keep all the data together, so I generally do so. I also try to access it linearly, which they also like. The point holds.
Don't try to compare the most primitive and unoptimized methods of custom memory management to the most sophisticated garbage collection algorithms. Remember, too, that a person doing custom memory management can write the same sophisticated garbage collector that Java would use.
And don't confuse "primitive" with "fundamental". Pointers are fundamental. Having to analyse reverse polish code function to prevent dangerous operations, rather than making it impossible to construct operations you don't want, is primitive.
"4...then tell me that dynamic dispatch is a problem." Okay, dynamic dispatch is a problem. Just because it can inline methods here and there doesn't mean you won't take an overall performance hit. Besides, that was only one example of the ways the lousy Java handholding slows things down.
The Sun marketing papers you linked me to are just more of the same old Java hype. They'll go on to "prove" that their new super JIT is better than anything you could code by hand by comparing optimized idiomatic Java with the same code translated poorly into unidiomatic C++.
Idiomatic C written by a competent optimizer will still blow the Java version out of the water.
The term water, in the sense I used it, indicates a singular continuum bounded by the absence of water molecules. To indicate individual molecules, this must be expressly stated or clear from context, as English is strongly biased toward the aforementioned meaning.
Water does not sink into a bucket of stones, it flows. Furthermore, it flows into the bucket and amongst the stones, but not into the stones. Water can sink into sand, but sand is not stones.
Yes, water can seep into stones, but seeping is not sinking.
On a machine with 64 bit ints, as on a machine with 32 bit ints, ints and longs are the same (assuming the compiler was competently designed; it could fit the standard without being). Using long should only ever confer a performance hit on 32-bit machines, for 32-bits and over, long is pretty much guaranteed to be the same as int (AFAIK, the standard doesn't force it, but it doesn't require any more range in the long, so it would be stupid to make it bigger).
If you want to define your own special int ranges, you can always use Ada. That's the kind of language you get when you throw in every nice little feature.
C is for efficient coding by trained experts, with the potential for portability if that is a desired goal. It provides no hand-holding that would interfere with run-time efficiency. The default behavior is and should be the most efficient behavior.
There are plenty of other languages for people who are willing to sacrifice efficiency for more hand-holding.
Seriously, when you communicate over a inter-machine connection, you have to comply with the communication standard.
If the communciation protocol is, for example, byte based and you are writing portable code, you have to have a formal, portable method of chopping up that struct into bytes at the sending end and building it back up again (from bytes) at the receiving end. It's called serializing, and it's disgusting laziness to skip it; if you do, you deserve those problems, and also to get bleeding genital warts.
Just dumping the bits of a fuzzily-defined internal data structure outside of the comfy innards of your own program is the ultimate in programmer carelessness (well, dividing by a null pointer and writing to the dereferenced quotient, with appropriate casts, is the ultimate in carelessness, but you get the point). Would you also send your pointers across a network and expect them to work at the other end?
And if you need really big numbers you can always code your own BigInt structs, though you might want to write a little preprocessor to do that (or use C++ and redefine all the ops for it).
The basic data types are defined. You can use sizeof() to generate 100% portable code when you really have to know exactly how bit your ints are. More importantly, you can use your noggin and avoid it being a problem in most cases by writing code that accepts the range of possible value limits.
Embedded systems programmers will back me up on this one: it's a Good Thing that when you write C you can write one piece of code that's perfectly happy to use a 16-bit, 20-bit, or 32-bit int and it will be equally efficient on any of those systems.
Actually, there is no absolute requirement that free() does all the cleanup work that the allocator, any more than a garbage collector must call a routine to do all of its cleanup work at the end of every block and at every assignment.
free() could just add the freed chunk to a list of chunks to be cleaned up. A second thread could run continuously tidying up all these chunks with the same system-wide view as a garbage collector.
First of all, a JIT is rushed. You can design your optimizing one-time compiler to look at the code for better ways to do it all day, if you like, and while the developers will moan, they will still use it if gets them better results.
Secondly, Java has a very specific standard (that is typically fudged... but that's beside the point). It doesn't give any leeway for a program to act a little different in boundary conditions, like C does. In C, an int is whatever size int is most easily handled by the target system; if you need a certain exact size of int, you can code that in with some extra effort. In Java, an int is a Java int and Java doesn't care in the least what the most efficient native int format is.
Thirdly... automatic garbage collection is less efficient than hand coded allocation and deallocation, and dynamic allocation is less efficient than static allocation. There are odd cases where this is false, but they generally hold true, and where they do not, the C version can always use the more efficient method anyway. (and extremely fast calls to "new" can be easily achieved... at roughly 50% memory wastage)
Fourthly: Java locks you into a OOP model which is inherently inefficient (at least as done in Java). All function calls must be dynamically redirected etc.
I could go on, but it feels like trying to describe that water is wet and stones sink in it to someone who thinks it's intuitive that water should sink into stones.
However, I will not dispute that you can definitely get better results by recompiling for each chip that something will run on. Some JITs may use this to push out ahead of one-time compilers.
BTW, an experienced assembly coder will always beat or at least equal the optimizing compiler, because if nothing else works he can always look at what the compiler produces and see if he can improve on that. Besides, optimizing compilers are good, but not that good, someone has to write them, and when was the last time that you wrote a program that can solve complex creative problems better than you can?
...when I first learned about the wonders of hydro-electrolysis, and found out about the perfect closed fuel circle that could result from the simple seperation of hydrogen and oxygen in water.
My mind spun with all the things you could use it for. Well, I'm a little older, a little less enthusiastic, and maybe a little more efficient. Now I know it's just another way to move energy around, like batteries or gasoline.
If it's as efficient as they make out, combined with the new cheap methanol fuel cells, this could be the clean, portable energy solution of the next century. It has every advantage of the hydrogen energy system (well, maybe it loses a little in simplicity of generation), plus the extremely important bonus of how easy it is to move methanol around. There are plenty of other ways to get methanol, too. Forget solar power plants: fermentation of vegetable matter into methanol is simple; you could fuel your cell phone out of your compost bin.
I'm aware of the distinction. I was also writing the words of hypothetical journalist so dumb that he broadcasts the source not knowing that it can be loaded into a computer by hand.
...if any of these clueless journalists will somehow manage to work the DeCSS source into their broadcast.
Wouldn't that be hilarious?
(camera slowly scans over the source) Concerned Reporter's Voice:...and this unreadable code is what caused the whole mess. If entered into a computer it can be used to copy DVDs...
...it's a monstrosity. It's a great wallowing pig of an application like Netscape. No wonder it's taking so long to get up to speed, they aren't doing a core functionality and building up layers of extra gadgets and niceties around it, they're globbing everything they can think of into it at once and seeing what emerges.
Furthermore, if the stated intent of involved parties is to "patent all the obvious things that the patent office shouldn't let slip through" then the patent office may well simply ignore any patent applications from them (and I can't say I'd blame them).
If the Open Source community could manage to gather these funds, a much better way to spend them would be to hire patent lawyers to go around and knock down all the silliest software patents.
Other good ways to spend it would be government lobbying and PR campaigns: to eliminate software patents, shorten patent durations, improve the patent office (I don't care how swamped they claim to be, with $10k filing charge, they ought to be able to hire someone bright enough to point out that XORing a pointer onto a screen is trivially obvious; there is a monstrous bureaucracy eating those payments and not doing its job), etc.
Of course, gathering that kind of money is a non-trivial implementation problem.
I'd probably misconfigure it so it would only make me throw up after I did something like deleting/etc/passwd...
Automated kick-me-while-I'm-down machine.
OTOH, it would be an interesting experiment in negative reinforcement (can you train a good sys admin by causing pain every time he screws the system over?).
The web will never be fully standardized. Standards lag behind the technology, and people are way too lazy to actually follow standards.
Ten years from now, there will still be messy "optimized for Netscape" (whether or not Netscape is still even used) HTML on the web, browser writers will still fudge the standard, and people will still check their HTML on the only browser they have before putting it on the web.
Who was it who said "The great thing about standards is that there are so many to choose from." ?
"Why did you not write a separate mini-language for each of the GUI widgets?"
What kind of idiot would write a language he is only going to make one statement in? I am not against solving the problems that OOP is meant to solve, it is the methods that do not work.
When I write a mini-language, it is to parse many simple and concise descriptions of a group of similar things. A group of similar things can be described as a class.
In an OOP language, there is a formal way of expressing things that fit into a class (in the general sense; the formal OO and C++ terms "class" have different meanings from each other and from this general English one). This formal method is often excessively verbose, inadequately expressive, inefficient, and generally a pain in the ass.
So the reason I don't really like the majority of the elaborations on C syntax in C++ is that they are trying to create a single comprehensive method of expressing the infinite possibilities of variations on a theme. Learning this method takes too much effort (hence the oft repeated complaint "nobody knows all of C++"), using it takes too much overhead (both in programmer effort and in inefficiency of the final product), and it doesn't even make a good fit half the time.
Slashdot Mirror
If it's open source, it doesn't matter who wrote it, anyone can copy it.
The people who could most benefit from this situation are the CD-ROM manufacturers, who could spend their idle time burning popular open source software and passing it to the local software merchants. If they had to compete, they could sell at a loss, as long as they didn't go below the losses they'd take from having idle factories.
The key objection to open source as a base for a profitable business is not that nobody would pay for the service of delivery, but that people who don't actually produce any software will have a competitive advantage over those who do. If hypothetical company Maroon Hat does everything Red Hat does, but doesn't spend money on any software developers, Maroon Hat has the same profitability with smaller expenses.
I think profitable open source development should be viewed as more of a busking model than any sort of traditional "give me your money, or you don't get what I'm selling" model. If it were convenient to do so (say, with a web-based micropayment system), I bet people would be more than happy to send out a few bucks here and there to the authors of their favorite free software.
I'll simplify:
1)Anything that can be expressed in Java can be expressed in hand-coded assembly; the reverse is not true.
2)Humans are smarter than computers.
3)Humans can always use computers as aids to their work, and so produce output equivalent to what the computer can produce as a baseline worst case.
"1...not a JIT system but a dynamically optimizing compiler" a slow start is a big problem (which is why they are emphasizing long-term server programs), but that's not the main issue. There's no reason that profile-based optimization can't be applied to C programs. That there's an experimental JIT (yes, it's still a JIT) that's ahead of the C compilers in common use is no reason to claim that the JIT strategy is better.
"2...as long as the results of the operation don't change" Which means that if the representation is different in a meaningful way they have to check whether the results of the operation change, reducing the efficiency, which was my point.
"3...on all but the most simple applications" But I rarely do anything but the most simple applications. I allocate an array, then I free an array. I do this for hashes, trees, stacks, queues, and pretty much any data structure I use. Only when I am being extremely lazy will I allocate and free objects recursively. Modern CPUs with slow main memory and fast cache like it when you keep all the data together, so I generally do so. I also try to access it linearly, which they also like. The point holds.
Don't try to compare the most primitive and unoptimized methods of custom memory management to the most sophisticated garbage collection algorithms. Remember, too, that a person doing custom memory management can write the same sophisticated garbage collector that Java would use.
And don't confuse "primitive" with "fundamental". Pointers are fundamental. Having to analyse reverse polish code function to prevent dangerous operations, rather than making it impossible to construct operations you don't want, is primitive.
"4...then tell me that dynamic dispatch is a problem." Okay, dynamic dispatch is a problem. Just because it can inline methods here and there doesn't mean you won't take an overall performance hit. Besides, that was only one example of the ways the lousy Java handholding slows things down.
The Sun marketing papers you linked me to are just more of the same old Java hype. They'll go on to "prove" that their new super JIT is better than anything you could code by hand by comparing optimized idiomatic Java with the same code translated poorly into unidiomatic C++.
Idiomatic C written by a competent optimizer will still blow the Java version out of the water.
JIT by any other name smells just as bad.
The term water, in the sense I used it, indicates a singular continuum bounded by the absence of water molecules. To indicate individual molecules, this must be expressly stated or clear from context, as English is strongly biased toward the aforementioned meaning.
Water does not sink into a bucket of stones, it flows. Furthermore, it flows into the bucket and amongst the stones, but not into the stones. Water can sink into sand, but sand is not stones.
Yes, water can seep into stones, but seeping is not sinking.
that should read "should only ever confer a performance hit on <32-bit machines"
When I hit preview, it changed the < to < in my text, and then thought it was the start of a tag when I hit submit.
Lesson: Don't use preview!
On a machine with 64 bit ints, as on a machine with 32 bit ints, ints and longs are the same (assuming the compiler was competently designed; it could fit the standard without being). Using long should only ever confer a performance hit on 32-bit machines, for 32-bits and over, long is pretty much guaranteed to be the same as int (AFAIK, the standard doesn't force it, but it doesn't require any more range in the long, so it would be stupid to make it bigger).
If you want to define your own special int ranges, you can always use Ada. That's the kind of language you get when you throw in every nice little feature.
C is for efficient coding by trained experts, with the potential for portability if that is a desired goal. It provides no hand-holding that would interfere with run-time efficiency. The default behavior is and should be the most efficient behavior.
There are plenty of other languages for people who are willing to sacrifice efficiency for more hand-holding.
Seriously, when you communicate over a inter-machine connection, you have to comply with the communication standard.
If the communciation protocol is, for example, byte based and you are writing portable code, you have to have a formal, portable method of chopping up that struct into bytes at the sending end and building it back up again (from bytes) at the receiving end. It's called serializing, and it's disgusting laziness to skip it; if you do, you deserve those problems, and also to get bleeding genital warts.
Just dumping the bits of a fuzzily-defined internal data structure outside of the comfy innards of your own program is the ultimate in programmer carelessness (well, dividing by a null pointer and writing to the dereferenced quotient, with appropriate casts, is the ultimate in carelessness, but you get the point). Would you also send your pointers across a network and expect them to work at the other end?
And if you need really big numbers you can always code your own BigInt structs, though you might want to write a little preprocessor to do that (or use C++ and redefine all the ops for it).
I hate when I skip words.
The basic data types are defined. You can use sizeof() to generate 100% portable code when you really have to know exactly how bit your ints are. More importantly, you can use your noggin and avoid it being a problem in most cases by writing code that accepts the range of possible value limits.
Embedded systems programmers will back me up on this one: it's a Good Thing that when you write C you can write one piece of code that's perfectly happy to use a 16-bit, 20-bit, or 32-bit int and it will be equally efficient on any of those systems.
Actually, there is no absolute requirement that free() does all the cleanup work that the allocator, any more than a garbage collector must call a routine to do all of its cleanup work at the end of every block and at every assignment.
free() could just add the freed chunk to a list of chunks to be cleaned up. A second thread could run continuously tidying up all these chunks with the same system-wide view as a garbage collector.
Seems profoundly intuitive to me.
First of all, a JIT is rushed. You can design your optimizing one-time compiler to look at the code for better ways to do it all day, if you like, and while the developers will moan, they will still use it if gets them better results.
Secondly, Java has a very specific standard (that is typically fudged... but that's beside the point). It doesn't give any leeway for a program to act a little different in boundary conditions, like C does. In C, an int is whatever size int is most easily handled by the target system; if you need a certain exact size of int, you can code that in with some extra effort. In Java, an int is a Java int and Java doesn't care in the least what the most efficient native int format is.
Thirdly... automatic garbage collection is less efficient than hand coded allocation and deallocation, and dynamic allocation is less efficient than static allocation. There are odd cases where this is false, but they generally hold true, and where they do not, the C version can always use the more efficient method anyway. (and extremely fast calls to "new" can be easily achieved... at roughly 50% memory wastage)
Fourthly: Java locks you into a OOP model which is inherently inefficient (at least as done in Java). All function calls must be dynamically redirected etc.
I could go on, but it feels like trying to describe that water is wet and stones sink in it to someone who thinks it's intuitive that water should sink into stones.
However, I will not dispute that you can definitely get better results by recompiling for each chip that something will run on. Some JITs may use this to push out ahead of one-time compilers.
BTW, an experienced assembly coder will always beat or at least equal the optimizing compiler, because if nothing else works he can always look at what the compiler produces and see if he can improve on that. Besides, optimizing compilers are good, but not that good, someone has to write them, and when was the last time that you wrote a program that can solve complex creative problems better than you can?
Say it ain't so!
Lynx is as small and efficient as ed, and that's all there is to it!
(hands over ears)
LALALALALALALALALA
Just think of what we can do with all that formaldehyde.
O_o
...when I first learned about the wonders of hydro-electrolysis, and found out about the perfect closed fuel circle that could result from the simple seperation of hydrogen and oxygen in water.
My mind spun with all the things you could use it for. Well, I'm a little older, a little less enthusiastic, and maybe a little more efficient. Now I know it's just another way to move energy around, like batteries or gasoline.
If it's as efficient as they make out, combined with the new cheap methanol fuel cells, this could be the clean, portable energy solution of the next century. It has every advantage of the hydrogen energy system (well, maybe it loses a little in simplicity of generation), plus the extremely important bonus of how easy it is to move methanol around. There are plenty of other ways to get methanol, too. Forget solar power plants: fermentation of vegetable matter into methanol is simple; you could fuel your cell phone out of your compost bin.
I'm aware of the distinction. I was also writing the words of hypothetical journalist so dumb that he broadcasts the source not knowing that it can be loaded into a computer by hand.
What does that mean?
...if any of these clueless journalists will somehow manage to work the DeCSS source into their broadcast.
...and this unreadable code is what caused the whole mess. If entered into a computer it can be used to copy DVDs...
Wouldn't that be hilarious?
(camera slowly scans over the source)
Concerned Reporter's Voice:
...it's a monstrosity. It's a great wallowing pig of an application like Netscape. No wonder it's taking so long to get up to speed, they aren't doing a core functionality and building up layers of extra gadgets and niceties around it, they're globbing everything they can think of into it at once and seeing what emerges.
Oh well, they can't all be Lynx. ^_^
Obviously, this would be insanely expensive.
Furthermore, if the stated intent of involved parties is to "patent all the obvious things that the patent office shouldn't let slip through" then the patent office may well simply ignore any patent applications from them (and I can't say I'd blame them).
If the Open Source community could manage to gather these funds, a much better way to spend them would be to hire patent lawyers to go around and knock down all the silliest software patents.
Other good ways to spend it would be government lobbying and PR campaigns: to eliminate software patents, shorten patent durations, improve the patent office (I don't care how swamped they claim to be, with $10k filing charge, they ought to be able to hire someone bright enough to point out that XORing a pointer onto a screen is trivially obvious; there is a monstrous bureaucracy eating those payments and not doing its job), etc.
Of course, gathering that kind of money is a non-trivial implementation problem.
I'd probably misconfigure it so it would only make me throw up after I did something like deleting /etc/passwd...
Automated kick-me-while-I'm-down machine.
OTOH, it would be an interesting experiment in negative reinforcement (can you train a good sys admin by causing pain every time he screws the system over?).
The web will never be fully standardized. Standards lag behind the technology, and people are way too lazy to actually follow standards.
Ten years from now, there will still be messy "optimized for Netscape" (whether or not Netscape is still even used) HTML on the web, browser writers will still fudge the standard, and people will still check their HTML on the only browser they have before putting it on the web.
Who was it who said "The great thing about standards is that there are so many to choose from." ?
"Why did you not write a separate mini-language for each of the GUI widgets?"
What kind of idiot would write a language he is only going to make one statement in? I am not against solving the problems that OOP is meant to solve, it is the methods that do not work.
When I write a mini-language, it is to parse many simple and concise descriptions of a group of similar things. A group of similar things can be described as a class.
In an OOP language, there is a formal way of expressing things that fit into a class (in the general sense; the formal OO and C++ terms "class" have different meanings from each other and from this general English one). This formal method is often excessively verbose, inadequately expressive, inefficient, and generally a pain in the ass.
So the reason I don't really like the majority of the elaborations on C syntax in C++ is that they are trying to create a single comprehensive method of expressing the infinite possibilities of variations on a theme. Learning this method takes too much effort (hence the oft repeated complaint "nobody knows all of C++"), using it takes too much overhead (both in programmer effort and in inefficiency of the final product), and it doesn't even make a good fit half the time.
The Mushroom top story: fake wood panels making a comeback in the console market.