You happen to disagree with the wrong person. I happened to spend a few mounths studing GCC optimizations a couple of years ago because I was at a situation that required me to think about cache faults (and everything else).
That means, I did look (but am assuming that the OP is using GCC). GCC doesn't spend memory with consts. And it is smart enough to know if you cast it to a non const (you can use -Wcast-qual to see it). Of course, if your program requires that the const is at memory (you use the operator & on it, or it is in an array), it will be. Oh, and you must use -O to get that optimization, GCC is quite conservative on its output.
And, last, function paramaters are always at memory (unless you set the right optimizing flag), and you can always mess with them. You'd get the same behaviour with #define.
"Wouldn't that allocate memory to hold the value rather than having a literal in the program code?"
No.
"Would be disaserterous if it caused a cache-miss too, you coul lose a lot of efficency there. Anyone know how various compilers handle const ints?"
No, and you can't really know whre a cache miss will happen unless you know exactly what computer will run that code.
Your compiler knows that a const is constant, and won't throw memory (and lookup time) away with it. Unless, of course, you want to debug. And you shouldn't be thinking about cache size while targeting the (quite heterogeneous) PC.
A $15,000 computer to run MatLab is simply stupid. First you port your program to a decent environment*, then you add power if needed.
* At MathLab your program will consume HUGE amounts of memory, that it somehow fragments trouhg a even biger space. It makes EVERY computer that I've saw running swap data, and needs to acess the data on the disk every time. (No, 2GB or 3GB of RAM aren't even near enough.) After a few minutes, your processos runs as fast as the disk... It is a piece of amateur code, for small, demonstrative, experiments only. It may very well turn your 30-second problem into a 1-week one (if you have enough disk for swapping). It won't ever solve your 1-week problem.
"It is not difficult, nor are the tools inadequate."
The tools are obviously inadequate. Did you ever tried to debug a nontrivial piece of paralel code? Even code on a UMA is hard to debug.
It is also quite hard to write today. That problem may disapear with better tool, but our tools are bad...
But the worse problem is that paralelizing for an unknown architecture is near impossible today. That is the reason we don't see many programs taking advantaje of multicore (how many is 'multi'?) machines. It may get doable with better tools, but we aren't there yet.
Well, TFA is slashdoted, so, I didn't RTFA and will coment on the sumary.
What you seem to be doing is more like repository managment than package. You can go only so far with a repository without a custom packaging system (.msi won't make it), but even limited, it can be very usefull. A repository as I see it must be:
1: Centralized (but not too much): There must be 1 central repository that you'll maintain. People must be able to mirror it, but not change the contents of your repository. Make mirroring easy is very important, and partial mirroring is a plus.
2: Autoritary: Everything signed, and the certificates must be both distributed with the application that'll access your repository and available within the repository.
3: Free: Really, you don't want to mess with proprietary software unless you have a workforce of the size of Debian's.
Optionaly, you can permit people to access several different repositories from the same application, and require hight quality from the code in the central repository.
Also optionaly, your software (that will access the repository) can export the list of installed programs and synchronize the system when inporting such list.
"Of course the problem with this plan is that starting from step 4 on..."
Simply write programs that use command line tools (frontends), and files for I/O... Altough someone can port them to Windows, it becomes so hard that you won't find ports for most of them. If you just look around, you'll see lots of good applications that are already written that way, and consequently are *nix only.
And the fact that the above advice coincides with good programming habits shows (partialy) how much Windows is broken, and why people should migrate to a sane system.
"However, you need to keep in mind that those "huge profits" are paying off the costs of development."
But don't forget that the only reason FOSS is sucessfull is because it have much lower development costs than proprietary software. Otherwise, you wouldn't even listen about it.
Anyway, if there is a place for proprietary software (I think there is, but it is so small that we won't miss it if copyrights go away), that development model will continue to be sucessfull, GPL existing or not.
The GPL is not anti-bussiness nor anti-capitalist. It is just against one kind of business, that is selling the same software again and again for huge profits at each copy. A business plan that can not be sucessfull on a free society.
"You've got to remember, these guys live and die by sales. They *have* to look good in the numbers because that's what sells their cards at the top end. At the low end, no consumer cares either way as price dominates"
Yet, at the same time there are lots of people asking for one of them, please, support Linux so we can buy them.
It's not all one-sided. There are valid reason for subsidizing food. Most importantly, unlike other markets where you want the supply and demand curves to intersect, you don't want that with agriculture. You want to insure that your supply curve is higher than what's needed to meet demand. The reason is pretty simple - there's a lot of uncertainty in agriculture. One year you'll have a bumper crop. Next year, a cold spell may wipe out half the crop. If you lose half the crop, you don't want people starving because everyone is bidding up the price of the remaining crop up to the point where only the wealthy can afford it. The demand curve is not elastic like, say, game consoles. If game consoles cost too much, people stop buying them. If food costs too much, people still have to buy it to stay alive.
Fot that you stockpile it. You don't grow a lot more stuff then needed every year just because in one of them you may underproduce. You grow just a bit more than you need, and save it.
By subsidizing food you assure that it's price will be lower for the end consumer (worldwide) at the expenses of the taxpayer (countrywise). It is not good business, but create dirert work positions (what politicians love, and they don't pay atention to indirect ones).
Yep. Teoreticaly, the agricultural countries would be richier, while the industrial ones would be poorer (reversing the trend created by the green revolution). That may be part of the reasons for the hard opposition biofuels are getting.
But the reason lots of third world people are hungry is not because of lack of food, but because of opresive or corrupt governments and because capitalism excludes people. Producing biofuels won't change any of those factors, so, expect famine to stay the same.
No, they meant Linux. They probably worked very hard to keep the GNU part out of their claims, that is now against Linux, Open Office, "desktop software" and "other".
FOSS is about freedom (or a very nice development model if you look only to the OS part). That implies choice, but obviously not all options are equal.
OLPC is about educating children (or better said: let them educate themselves). That also implies choice, but even less than FOSS. In fact, if the choice is about a "restricted" project that is unable to run Windows or no project at all, it leads quite well to the first option...
Re:Why not make an "Uncrippled for non-US" edition
on
Dell Linux Details
·
· Score: 1
There are Brazilian distros that bundle mp3 and DVD playing by default. But it would be stupid to do so on a distro that aims at a broader (global) audience, since the US is big, and there are other countries with DMCA like laws.
Excuse-me, sir, but the programs running on my computers are COOPERATING, not competing (at least they should). They are there to serve MY wills, not to fight around resources.
Of course it would be usefull to notify processes that somebody needs memory. If a process can release some memory, one should expect it to do that. It would also be usefull to set priorities to those processes, so they know better how much memory to release. But if I want to run a process that uses lots of memory, why should the OS stop me?
Firefox is slow at my Semprom with 512MB of RAM (bad graphics card) running on Linux/KDE (where everything but Firefox and Eclipse is fast) and at my girlfriend's Semprom, also with 512MB of RAM and a 128MB nvidia card, running XP.
It is slow, and has lots of features that every normal user I saw doesn't care about. But it probably ins't slow because of those features, since they are mainly out of the way.
Now, I've tried Dillo on older machines (Konqueror used to be lightweight, but isn't anymore), but came to the conclusion that it is better to run Firefox slowly than to use a different browser. Altough, I'm not very concerned about those old (less than 128MB of RAM) computers, since that is a problem that'll go away with time.
Slashdot Mirror
You happen to disagree with the wrong person. I happened to spend a few mounths studing GCC optimizations a couple of years ago because I was at a situation that required me to think about cache faults (and everything else).
That means, I did look (but am assuming that the OP is using GCC). GCC doesn't spend memory with consts. And it is smart enough to know if you cast it to a non const (you can use -Wcast-qual to see it). Of course, if your program requires that the const is at memory (you use the operator & on it, or it is in an array), it will be. Oh, and you must use -O to get that optimization, GCC is quite conservative on its output.
And, last, function paramaters are always at memory (unless you set the right optimizing flag), and you can always mess with them. You'd get the same behaviour with #define.
No.
No.
No, and you can't really know whre a cache miss will happen unless you know exactly what computer will run that code.
Your compiler knows that a const is constant, and won't throw memory (and lookup time) away with it. Unless, of course, you want to debug. And you shouldn't be thinking about cache size while targeting the (quite heterogeneous) PC.
You may want to ask that question again AFTER GPLv3 is released.
Compile, debug, pack, play chess, translate morse code?
I guess not.
A $15,000 computer to run MatLab is simply stupid. First you port your program to a decent environment*, then you add power if needed.
* At MathLab your program will consume HUGE amounts of memory, that it somehow fragments trouhg a even biger space. It makes EVERY computer that I've saw running swap data, and needs to acess the data on the disk every time. (No, 2GB or 3GB of RAM aren't even near enough.) After a few minutes, your processos runs as fast as the disk... It is a piece of amateur code, for small, demonstrative, experiments only. It may very well turn your 30-second problem into a 1-week one (if you have enough disk for swapping). It won't ever solve your 1-week problem.
The tools are obviously inadequate. Did you ever tried to debug a nontrivial piece of paralel code? Even code on a UMA is hard to debug.
It is also quite hard to write today. That problem may disapear with better tool, but our tools are bad...
But the worse problem is that paralelizing for an unknown architecture is near impossible today. That is the reason we don't see many programs taking advantaje of multicore (how many is 'multi'?) machines. It may get doable with better tools, but we aren't there yet.
Well, TFA is slashdoted, so, I didn't RTFA and will coment on the sumary.
What you seem to be doing is more like repository managment than package. You can go only so far with a repository without a custom packaging system (.msi won't make it), but even limited, it can be very usefull. A repository as I see it must be:
1: Centralized (but not too much): There must be 1 central repository that you'll maintain. People must be able to mirror it, but not change the contents of your repository. Make mirroring easy is very important, and partial mirroring is a plus.
2: Autoritary: Everything signed, and the certificates must be both distributed with the application that'll access your repository and available within the repository.
3: Free: Really, you don't want to mess with proprietary software unless you have a workforce of the size of Debian's.
Optionaly, you can permit people to access several different repositories from the same application, and require hight quality from the code in the central repository.
Also optionaly, your software (that will access the repository) can export the list of installed programs and synchronize the system when inporting such list.
Simply write programs that use command line tools (frontends), and files for I/O... Altough someone can port them to Windows, it becomes so hard that you won't find ports for most of them. If you just look around, you'll see lots of good applications that are already written that way, and consequently are *nix only.
And the fact that the above advice coincides with good programming habits shows (partialy) how much Windows is broken, and why people should migrate to a sane system.
But don't forget that the only reason FOSS is sucessfull is because it have much lower development costs than proprietary software. Otherwise, you wouldn't even listen about it.
Anyway, if there is a place for proprietary software (I think there is, but it is so small that we won't miss it if copyrights go away), that development model will continue to be sucessfull, GPL existing or not.
The GPL is not anti-bussiness nor anti-capitalist. It is just against one kind of business, that is selling the same software again and again for huge profits at each copy. A business plan that can not be sucessfull on a free society.
I've got the entire 127.0.0.0 class A net. You losers can fight for your 5 computer networks.
Yet, at the same time there are lots of people asking for one of them, please, support Linux so we can buy them.
Fot that you stockpile it. You don't grow a lot more stuff then needed every year just because in one of them you may underproduce. You grow just a bit more than you need, and save it.
By subsidizing food you assure that it's price will be lower for the end consumer (worldwide) at the expenses of the taxpayer (countrywise). It is not good business, but create dirert work positions (what politicians love, and they don't pay atention to indirect ones).
Yep. Teoreticaly, the agricultural countries would be richier, while the industrial ones would be poorer (reversing the trend created by the green revolution). That may be part of the reasons for the hard opposition biofuels are getting.
But the reason lots of third world people are hungry is not because of lack of food, but because of opresive or corrupt governments and because capitalism excludes people. Producing biofuels won't change any of those factors, so, expect famine to stay the same.
And I have a algorithm for key exchange that you can use with your pad. It's called called rot-13 :)
It is a bluff. We may lose more by not calling it.
What a perfect match!
No, they meant Linux. They probably worked very hard to keep the GNU part out of their claims, that is now against Linux, Open Office, "desktop software" and "other".
FOSS is about freedom (or a very nice development model if you look only to the OS part). That implies choice, but obviously not all options are equal.
OLPC is about educating children (or better said: let them educate themselves). That also implies choice, but even less than FOSS. In fact, if the choice is about a "restricted" project that is unable to run Windows or no project at all, it leads quite well to the first option...
There are Brazilian distros that bundle mp3 and DVD playing by default. But it would be stupid to do so on a distro that aims at a broader (global) audience, since the US is big, and there are other countries with DMCA like laws.
Why can't them be a lot of slightly rare steps? I think it is not that hard, since we can't even estimate the probabilities of most of them.
If so, we may have few hard steps at future. Or may have already passed through all of them.
Everything nowdays goes into the media as a new kind of matter. You don't even need to use barions for that.
They can change it to GPLv2 only, as they will be able to change to GPLv3 and latter.
Excuse-me, sir, but the programs running on my computers are COOPERATING, not competing (at least they should). They are there to serve MY wills, not to fight around resources.
Of course it would be usefull to notify processes that somebody needs memory. If a process can release some memory, one should expect it to do that. It would also be usefull to set priorities to those processes, so they know better how much memory to release. But if I want to run a process that uses lots of memory, why should the OS stop me?
Firefox is slow at my Semprom with 512MB of RAM (bad graphics card) running on Linux/KDE (where everything but Firefox and Eclipse is fast) and at my girlfriend's Semprom, also with 512MB of RAM and a 128MB nvidia card, running XP.
It is slow, and has lots of features that every normal user I saw doesn't care about. But it probably ins't slow because of those features, since they are mainly out of the way.
Now, I've tried Dillo on older machines (Konqueror used to be lightweight, but isn't anymore), but came to the conclusion that it is better to run Firefox slowly than to use a different browser. Altough, I'm not very concerned about those old (less than 128MB of RAM) computers, since that is a problem that'll go away with time.